I am seeking a better understanding of the following commands i am using to flash a jetson orin nano devkit with LUKS FDE.
Ideally i would like to save the outputs of these “no-flash” commands, so i can later mass flash a bunch of boards with the same image and not have to run all these commands in order to flash each board.
Create a QSPI Image? What is the output of this command and where does it get saved? Does the jetson orin need to be plugged in recovery mode when i run this command?
Create an image of the rootfs folder system? What is the output of this command and where does it get saved? Does the jetson orin need to be plugged in recovery mode when i run this command?
Flash the QSPI and rootfs Images that were created in the past 2 steps? sudo ./tools/kernel_flash/l4t_initrd_flash.sh --showlogs --network usb0 --flash-only
I definitely can’t answer it all, but so far as intuitive knowledge goes (you may already know this, but it is easier to just repeat this even if you already know), here’s some random information.
About the initrd, or initial ramdisk: This serves as an adapter between bootloader and the operating system. A desktop PC has a BIOS, and it can select what to boot to fairly easily, but Jetsons don’t have a BIOS (they have the equivalent in software, e.g., partitions or QSPI memory on the module itself). The “pointer” to the first boot medium is less flexible than what you’d be used to from a desktop PC motherboard. The initrd can be used to adapt between bootloader and Linux kernel stages when the bootloader does not understand the filesystem type where Linux modules are found, but it also works for adapting a less flexible “pointer” such that the boot stages can use the internal QSPI to find the initial Linux kernel, and the kernel itself can then find the external media (media such as the NVMe cannot load directly on a Jetson, but can load from the Linux kernel). Some initrd information: https://forums.developer.nvidia.com/t/kernel-customisation-jetson-orin-nx-bsp-install/262647/19
Jetsons tend to have a kernel and device tree available in “/boot” under most circumstances, but they also have this in partitions or QSPI memory at times. When not found in “/boot” that content is signed. If pulling content from the QSPI or eMMC partitions, that content must be signed (only the rootfs is not signed). It is true that the default is to sign with a NULL key, but if not signed, that content will be refused. On the eMMC models you can burn security fuses and force only the signed content to be accepted (rejecting “/boot” content). SD card dev kit models (not the same as third party carrier boards with SD cards) cannot have the fuse burned, so they just use the NULL key. Because you are loading to an NVMe it is possible that the initrd will be using that non-rootfs content and require signing.
The normal flash mechanism is to sign all of that other content, flash it, and then delete the content (avoiding leaving signed content around). When you use the “--no-flash” option the content is signed and kept rather than being flashed and deleted. If you needed to do something like copy the content into a partition on the Jetson, then this signed version is what you’d use. Other flash or install steps might use the signed content.
Don’t know if any of that is of use to you or not.