to evaluate our next update strategy I have been trying to verify the steps of how I can update from L4T 35.5.0 to L4T 36.3.0 using the Jetson Orin Nano Dev-Kit. However, it fails to boot after the OTA-update.
In accordance with the docs, I followed those steps:
Reflash the Dev-Kit with L4T 35.5.0 sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 -p "-c ./bootloader/t186ref/cfg/flash_t234_qspi.xml" -c ./tools/kernel_flash/flash_l4t_t234_nvme.xml --showlogs --network usb0 jetson-orin-nano-devkit nvme0n1p1
Prepare on the ota_package on an Ubuntu 22.04 Linux Host sudo -E ./tools/ota_tools/version_upgrade/l4t_generate_ota_package.sh --external-device nvme0n1 jetson-orin-nano-devkit R35-5
which finishes (after figuring out the issue with the use of python) successfully:
.....
./nv_ota_update_rootfs_in_recovery.sh
./nv_ota_update.sh
./nv_ota_validate.sh
./ota_nv_boot_control.conf
./ota_package.tar
./ota_package.tar.sha1sum
./TEGRA_BL.Cap
./update_control
./user_release_version
./version.txt
SUCCESS: generate OTA package at "/home/lneuner/nvidia/l4t-36-3-0/Linux_for_Tegra/bootloader/jetson-orin-nano-devkit/ota_payload_package.tar.gz"
So I assume this is a mismatch with the NVME and it therefore does no boot anymore. But I didn’t get to the step where I have to update the qpsi-memory from the device.
As this is a vanilla setup, I wonder what am I missing that it does not work as described in the example or the online docs. Thanks for your help!
no I did not explicitly enable Jetson security unless the default flashing command that I posted does enable so? How I can check if its enabled or not?
after looking at the outlined chapter, I can confirm that I have not taking any steps regarding secure boot. I also did never execute the odmfuse.sh script. Yes I downloaded the official OTA tools r36.3.0.
For the sake of comparison I can later check with another Jetson-Orin Nano module. Can you confirm the commands I have used are correct and its expected to actually work to perform an OTA update in this fashion?
we’ve tested OTA from r35.5.0 to r36.3.0 on Orin Nano DevKit, and it works normally.
please setup serial console to gather the complete logs after you perform $ sudo reboot to trigger OTA update.
thanks for the feedback. I have tried to update today another time with the console output attached and it worked. However, at the output
Validate /mnt/ota_work/external_device/system.img
[ 8.264523] mmc1: SDHCI controller on 3400000.sdhci [3400000.sdhci] using ADMA 64-bit
it was hanging/waiting for close to 1min after it resumed. Is this normal?
I likely was to impatient on the first attempts as it takes quite a while till you see something on the screen again, but with the serial output this was mitigated. Thanks!
One more question - the examples state to do this and follow up steps:
Generate the OTA payload package that updates the bootloader only from R36.3.0 to R36.3.0:
$ cd Linux_for_Tegra
$ sudo ./tools/ota_tools/version_upgrade/l4t_generate_ota_package.sh \
-b jetson-agx-orin-devkit R36-3
Note: The purpose of this step is to update the other boot chains to R36. It is not supported
using R35 boot chains to boot the R36 kernel/root FS.
Is this generally needed or only if I do exploit using the A/B bootloader? The system did start from the new bt after the initial ota-update.
Again thanks for your guidance and sorry for not looking into the serial log earlier.
you should ignore that example to update bootloader only.
furthermore,
as long as you did not specify -b or -r options to generate the OTA update payload package, you’ve already running OTA tool for updating a full system to r36.3.0
