Running R28.2 on a TX2 flashed with R28.1

I’ve received a new TX2 that was flashed with R28.1.
Instead of flashing R28.2, I’ve just used a previous R28.2 rootfs on a SATA drive and copied the R28.2 kernel image to MMC0 and boot it through an extlinux.conf entry.
This seems to work fine, I see no errors till now…but I wonder if there are some potential problems with the different partition scheme…Does some software rely on the partitions layout ?

Further than fixes in [url]http://developer.download.nvidia.com/embedded/L4T/r28_Release_v2.0/GA/Docs/Tegra_Linux_Driver_Package_Release_Notes_R28.2.pdf[/url], are there some features that would not be working fine ?

Thanks for any comment.

Thank you for sharing.
I know that folks somewhat manage to use sdcards and ssd disks with the default disk image.
If it works with sdcard/ssd/sata
and if it appears to work with the kernel uploaded to eMMC,
I do not see any explicit reasons why should it prevent from functioning generic software.
However, in general they would rather tend to copy/ restore the entire eMMC, than to operate with extlinux.conf, as it appears to me.

I had previous been running R28.1 kernel + rootfs on a TX2 flashed by R28.2. But I think there were some errors, although it was mainly working.
Here I don’t see any. Not sure it was the same R28.1, however.

The question is also about what is different in early boot stages, what u-boot receives as environment and how device tree seen by linux kernel may be different.

It appears that you got 28.2 rootfs and 28.2 kernel.
In my opinion that means that devtree is also of 28.2. I am somewhat inclining to believe that device tree belongs to the rootfs.
However, may be someone more experienced than me will correct me if my assumption is wrong.
Upd: I can remember that some update did shifted devtree files to a separate partition.
I am just wondering if that partition belongs to 28.1 or 28.2 in your case.
Moreover, in case 28.1 and 28.2 have the same partition structure, but different content of the partition that contents devtree - there will be a way to mount at HOST PC 28.2 image and over the network update from the mounted image the Jetson corresponding partition with dd , but that will work only if the partitioning is the very same in both cases.

Since the device tree scheme changed between R28.1 and R28.2 (partition layout) it is possible something in device tree won’t be quite right. On the other hand, U-Boot is what reads this…if the U-Boot is from R28.1 and is designed to read R28.1 device tree layout, and then the kernel inherits this, it might be that it’ll work fine. You just won’t have a guarantee…test it for awhile.

The caveat is that the kernel/drivers in R28.1 and R28.2 would have to have not changed. This is possible (likely) since they are both 4.4.38 kernels (their config may differ, but I’d expect how the drivers themselves name things in device tree would be exact matches).

For the sake of others who may find the thread, it’s officially recommended to reflash with JetPack-L4T 3.2 due to the issues that linuxdev mentioned.

However, it may be that Honey_Patoucuel may not have a PC for flashing at the moment due to a recent unfortunate event involving 1.21 gigawatts…

I think the triflux capacitor burned out.

In fact, I still have an old Athlon64 that can flash with a USB hub between it and the Jetson, but being lazy I just tried that and found it seemed to work, so I was just asking which features would be known as not working.
Indeed I do try weird things that I don’t advise others to do, but I wasn’t responsible for the bolt ;-)