Yes, you make it clear that Ubuntu is the supported platform but on R32.4 you could at least flash a device on Fedora with ninimal fiddling.
Now…
flash.sh requires a root filesystem in rootfs even with -r -no-systemimg. It seems to try and build a recovery initrd which I could care less about.
Even if you use -k cpu-bootloader to just flash cboot, flash.sh still tries to build the recovery initrd.
The root filesystem has absolute links to things like /etc/alternatives/w which doesn’t exist on Fedora so the flash fails.
OK, so I set up a Ubuntu docker container.
flash.sh fails to see the device when ti starts so it fails.
If you use --no-flash flash.sh does find the device as evidenced by the serial console and creates a flashcmd.txt file which I can run from the Fedora host.
BUT running flash.sh with -k cpu-bootloader in the container stops at signing cboot_t194.bin and doesn’t create a flashcmd.txt file. The only solution is to flash all the partitions again.
Don’t get me wrong, I’m not asking you to support other distributions. I’m just asking you to not make it so hard for those of us who don’t already use Ubuntu.
assume you’re working with Jetson Xavier NX eMMC version.
since you’re able to generate signed cboot binary.
please check the partition labels as following, $ ls -al /dev/disk/by-partlabel.
you may use dd commands to overwrite that manually to accomplish that without flash the board.
thanks
the -r options is reusing the existing system image, this command to skip building system.img;
how about only enable --no-systemimg options to the flash script commands for verification?
thanks
OK, I’m still not understanding what happened to flash.sh…
In R32.4.3, running sudo ./flash.sh -k cpu-bootloader --no-flash jetson-xavier-nx-devkit-qspi mmcblk0p1 just signs cboot_t194.bin and exits. As long as there was a rootfs directory, it didn’t care if there was anything in it.
In R32.5.0, that same command attempts to sign rootfs/boot/Image, rootfs/boot/initrd, and the dtb (all of which needs a good rootfs) before signing cboot_t194.bin.
it’s flash script to call another internal script file, l4t_sign_image.sh .
however, you may perform this script to generate a signature header of the provided file in the provided file’s directory.
for example,
I’m able to generate cboot_t194_sigheader.bin.encrypt as following, $ ./l4t_sign_image.sh --file bootloader/cboot_t194.bin --chip 0x19
Yeah, that’s what I’m doing now. It’s just confusing and irritating that things behave completely differently in R32.5.0 than in earlier releases. It means additional work having to re-write local scripts. Changes to the flash.sh ecosystem should be better documented.