It seems to be quite difficult to flash a custom system.img using the initrd flash pathway.
If I specify an external-device to l4t_initrd_flash.sh:
l4t_initrd_flassh.sh --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_t234_nvme.xml -p “-c bootloader/generic/cfg/flash_t234_qspi.xml --no-systemimg” jetson-orin-nano-devkit-nvme internal
it always generates a bootloader/system.img from the rootfs directory. There doesn’t seem to be a way to preserve my pre-built system.img (that I copy into bootloader).
The only instance in which I see this happen is if the flag --external-only is specified, in which case the flags specified py the -p parameter (as above - “-c bootloader/generic/cfg/flash_t234_qspi.xml --no-systemimg”) are actually passed through to l4t_create_images_for_kernel_flash.sh:generate_flash_images().
However this isn’t ideal because it then won’t flash the rest of the system…
l4t_initrd_flash.sh calls l4t_initrd_flash_internal.sh
l4t_initrd_flash_internal.sh : generate_flash_package calls l4t_create_images_for_kernel_flash.sh
in l4t_create_images_for_kernel_flash.sh : generate_flash_images(), if --external-device is specified, it will call:
generage_signed_images ${EXTOPTIONS} 1 ${root}
where ${EXTOPTIONS} will be empty. This is because ${EXTOPTIONS} is only filled if the --external-only flag is set (and if it is, then it is filled with the ${OPTIONS} contents (the -p passed in from the beginning).
Eventually, flash.sh is called, but then it will not have the --no-systemimg flag and my bootloader/system.img will be overwritten by the one generated by the rootfs contents.
The only way I could get around this is to:
- Do the initial call with --no-flash
- Copy my pre-built system.img into tools/kernel_flash/images/external (overwriting the new system.img)
- Call l4t_initrd_flash.sh again with --flash-only
Is there another way of preventing the generation of the system.img rootfs if I have the external device specified?