When we flash the device with initrd option ( flash.sh -I myinitrd -v myk2 -u myk1 jetson-xavier-nx-devkit-emmc mmcblk0p1), the initrd is written to the /boot/initrd directory. However when we delete this file (/boot/initrd) and the reboot the device, the initrd is still executed. This tell us initrd is also stored somewhere else. Is that on the QSPI chip? How can we update the stored initrd without flashing?
In this case extlinux.conf has: INITRD /boot/initrd
I can’t give you an exact answer. However, most boot content is indeed available in the QSPI of an SD card model (or in a partition of an eMMC model). The priority is to first use the resource named in the extlinux.conf file, and if that is not there, then to fall back to the QSPI (or for eMMC models, a signed partition). By removing a file from extlinux.conf the search for that item falls back to the next priority: QSPI.
All modification to QSPI is done via flash in recovery mode. I don’t know the specifics of where this would be. However, consider that you might test this: Instead of deleting that file in “/boot”, name an alternate file which has no content. Example to create an empty file: “sudo touch /boot/initrd-empty”, and then name “/boot/initrd-empty” (you could even leave the old initrd in place, or simply rename it). Beware though that there is a good chance this Jetson will no longer boot, and if you don’t have a valid boot entry (e.g., by making a new entry with the empty initrd instead of replacing the existing entry), then you could end up flashing again for eMMC models (for an SD card model you’d just have to put the SD card on a Linux host PC and reedit).
As usuall great info, thank you linuxdev, can we dump the content of QSPI ( /dev/mtd0 ?) from one device that has been flashed (and has the most recent content), create an image, and then write it to another device using dd or flashcp? We would like to know how to update our production devices without flashing. This will allow us to upgrade bootloader and everything else with it as well. Is this possible?
The other option would be to generate the QSPI image with: ./tools/l4t_generate_jetson_xavier_nx_qspi_images.sh
do you know if this method will include the initrd also?
I do not know how to dump the QSPI, but that is something I’d also like to know. Maybe someone from NVIDIA can comment on dumping QSPI? Since QSPI would be in binary format, and not an ext4 partition, it might not be completely useful, although an initrd partition could be useful since (after removing any signature) it would become a cpio archive (which can be expanded and examined just like a filesystem).
Keep in mind that all partitions other than the rootfs/APP are signed. If you dd copy, then the signature is also copied. During a flash, the signature is added to the unsigned content. I do not know for certain, but I suspect that the signed content of one Jetson may not work with a second Jetson even if the NULL key is used in both, since there is probably some sort of seed data that the NULL key is used against.
During a normal flash the binary content to non-rootfs is signed, the content flashed, and then the signed version deleted from the host PC. The “--no-flash” option (to various flash.sh commands) will result in the signed content not being deleted on the host PC. If you were to use dd to replace content in non-rootfs partitions (and I don’t know if you can do this on QSPI content…for sure you can on eMMC content), then you have to use this method to sign the unsigned binary first, and dd the signed version (you’d add the non-signed version to replace the stock version of that content, run with --no-flash, and then dd to the right place).
Can anyone from NVIDIA suggest if or how the QSPI partitions can be dumped? It might be a security thing that these cannot be dumped, e.g., via dd, or it might just be possible. I do not know.
Almost forgot: I have not used ./tools/l4t_generate_jetson_xavier_nx_qspi_images.sh, but it is a human-readable script, so you’d have to just go through it line by line, or even modify it to log each line that doesn’t have useful debug output. Due to security, I expect flashing that content to differ from reading it.
Thank you linuxdev, you are probably correct that the content of QSPI is signed. I noticed that the l4t_generate_jetson_xavier_nx_qspi_images.sh script takes -u -v (for keys) as option. However I am not sure if those keys are different between Jetsons. If the keys don’t change across Jetson instances then the dump and write may work. Hopefully someone Nvidia can help here.
hello KavehA,
you may prepare the OTA payload to update bootloader remotely.
(1) You should also visit L4T page, https://developer.nvidia.com/embedded/jetson-linux-r3541 to download [OTA Tools] package.
(2) You may refer to developer guide for [Preparing the OTA Payload Package] section to prepare the OTA payload.
for instance, Software Packages and the Update Mechanism — Jetson Linux Developer Guide documentation
(3) Running below commands to generate an OTA payload package to only update Bootloader.
for example, $ sudo -E ./tools/ota_tools/version_upgrade/l4t_generate_ota_package.sh -b jetson-agx-orin-devkit R35-4
Thank you JerryChang
Do you know if we can use this OTA update method to update the bootloader on existing JP 4.4 devices that have secure boot enabled? The JetPack 4.4 devices use CBOOT as bootloader and trusty libraries for secure boot.
it’s supported with PKC+SBK.
please refer to Preparing for an Image-Based OTA Update.
Hi @JerryChang,
I am just double checking this with you to see if the following command can upgrade the bootloader on the 4.4 devices (note that this question is only about bootloader and not rootfs). 4.4 Uses CBOOT so we would like to know if we can upgrade to UEFI using the following mechanism:
sudo -E ./tools/ota_tools/version_upgrade/l4t_generate_ota_package.sh -b jetson-xavier-nx-devkit R35-4
hello KavehA,
you cannot update bootloader only across two major release versions, since JP-4.x uses CBoot and JP-5.x moving to UEFI.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.