I’m looking for assistance with updating Jetson Orin Nano boards. I want to push an OTA Update containing a custom rootfs Image. The board is set up with A/B Partitions and Disk Encryption enabled (SecureBoot enabled, with PKC+SBK burned).
I’ve set the environement variables BASE_BSP and TARGET_BSP to the same l4t directory.
Further i have used the following command to generate the update payload package:
Then i have copied it to the device: scp bootloader/jetson-orin-nano-devkit/ota_payload_package.tar.gz nvidia@192.168.55.1:/home/nvidia scp ota_tools_R36.3.0_aarch64.tbz2 nvidia@192.168.55.1:/home/nvidia
Then i tried to deploy the update package with following command:
sudo mkdir -p /ota
sudo mv /home/nvidia/ota_payload_package.tar.gz /ota/
cd /ota
sudo tar -xpf ota_payload_package.tar.gz
sudo mkdir -p /home/nvidia/ota_work
export WORKDIR=/home/nvidia/ota_work
sudo tar -xpf /home/nvidia/ota_tools_R36.3.0_aarch64.tbz2 -C ota_work
cd ota_work/Linux_for_Tegra/tools/ota_tools/version_upgrade
If you are upgrading from a version earlier than 35.5.0 to this release, please first upgrade to 35.5.0, and then upgrade to this release. For example, if upgrading from 35.4.1, you should first upgrade to 35.5.0 and then from 35.5.0 to this release.
We plan to update the rootfs from the host after making modifications directly in the rootfs itself, so we don’t have an updater or an image available for testing with nv_ota_rootfs_updater.sh.
it looks there’s OOM issue during your OTA update.
we’ve tested again with the latest JP-6.1 public release (i.e. r36.4).
it’s confirmed OTA update success on fused Orin-Nano + RootfsA/B + disk encryption.
hence…
could you please moving forward to the latest JP-6.1 for verification.
We are using a custom carrier board and the supplier only supports BSP 6.0.
We have double checked the usage of nv_ota_rootfs_updater.sh and don’t find any issue with our command used before.
Can you confirm that we can use the nv_ota_rootfs_updater.sh with a custom board (RootfsA/B + disk encryption + Secureboot). We expected that that updater is used per default when nothing else is provided.
We were also wondering why the update failure does not lead to a reboot in the other rootfs partition.
Could you please explain that?
Thanks in advance.
please refer to readme file, $OUT/Linux_for_Tegra/tools/ota_tools/version_upgrade/Image_based_OTA_Examples.txt
BTW,
it’s suggest to check the r36.4 version, which adding the Case <number>: at the front of each example to make it easy to be referred to.
thank you for your help. It worked using case 15!
One last question: Is it always necessary to provide a golden image for partition A and B?
In our case they are the same and we expect the board to fall back to the other partition (with the old Image) if the update process fails.
No, it is depending on your use case.
If you don’t add -s option during generating OTA payload, it would generate the system image from <Linux_for_Tegra>/rootfs.
Yes, it would load another slot if the update is failed and that’s the reason for A/B slot.