Upgrading from r32.2 to r32.5

Autonomous Machines Jetson & Embedded Systems Jetson TX2
1

Hi,

We have deployed fleet of TX2 running r32.2 and we would like to upgrade them to r32.5. Reflashing them is not an option since it’s already in production and deployed so we would like to perform an OTA.

Unfortunately the partition layout has changed (mostly the user partition) between the 2 releases. And I am trying to understand what should be done in order to migrate to r32.5.

Here are the main differences:

  • BPFDTB-NAME has changed from 512 000 to 1 048 576 => Is it a problem ? should we keep it like this ? Is it possible to increase it ?
  • SOS partition has disappeared from r32.5 => Should we simply delete it ?
  • RECNAME was added instead of SOS partion.
  • BOOTCTRLNAME & BOOTCTRLNAME_b were added in r32.5
  • CAC partition was removed in r32.5
  • RECROOTFS was added in r32.5

What should be done ?

Thank you for your help !

3

I can’t answer, but have a few things you might find useful to think about.

First, there might be changes to the QSPI boot content, and this probably has to be done via flash. I don’t know if it is possible to dump the QSPI of an R32.5 unit, and I don’t know if it is possible to use OTA methods with (for example i2c) tools to install a new QSPI content. You can expect most all content (aside from APP/rootfs) to require signing, and you’d have to be very careful to sign correctly (even units without the secure boot fuse burned require a signature, but the non-secure boot units still have to go through the signing procedure prior to a flash despite signing without a key).

If you have a sample unit available to you locally (one which is just like the units in the fleet), then you should test everything on that first. If there is some manual method of updating OTA, then you have to succeed on the first try using a running o/s. Failures which stop boot imply a guarantee that you have to have physical access for flash. All of your questions above can be tested in person if you find some workaround to actual flash.

Note that if you have more than one board hardware revision in your fleet that there could be changes required to device tree (or other changes) based on revision.

4

Hi @linuxdev,

Thank you for your feedback.
The signing is handled by meta-tegra and BUP updates.
I think there is no QSPI on TX2 or it doesn’t boot from it by default. Boot source other than eMMC or USB - #17 by matanliber11

I need information from nvidia about the new partitions which isn’t detailed in Welcome — Jetson Linux<br/>Developer Guide 34.1 documentation

Best regards

5

That URL started some time back. You might be correct about not needing QSPI, but my thought is that older releases (like R32.2) did not need QSPI for boot, but newer releases (like R32.5) have a trend of needing this (someone from NVIDIA would have to verify if a TX2 under R32.5 will have QSPI requirements during migration from R32.2 to R32.5). I am personally curious about that.