Help understanding pre-flash and flash commands

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.

  1. 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?

sudo ./tools/kernel_flash/l4t_initrd_flash.sh --network usb0 --no-flash --showlogs -p "-c bootloader/t186ref/cfg/flash_t234_qspi.xml" jetson-orin-nano-devkit internal

  1. 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?

sudo ROOTFS_ENC=1 ./tools/kernel_flash/l4t_initrd_flash.sh --showlogs --no-flash --external-device nvme0n1p1 -i ./sym2_t234.key -c ./tools/kernel_flash/flash_l4t_t234_nvme_rootfs_enc.xml -S 300GiB --external-only --append --network usb0 jetson-orin-nano-devkit external

  1. 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

Hi,

I don’t know what you want to know with the output of this command. Output does not matter at all, and it’s the command being used really matters.

  1. Commands are right, but you can only flash one device at a time because disk encryption is not compatible with massflash .
  2. Images are stored in Linux_for_Tegra/tools/kernel_flash/images/
  3. YES. You have to put the device into force recovery mode for running each command.

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.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.