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.
- 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.
Yeah I forgot about dd but my specific comments about flash.sh still hold. It shouldn’t require rootfs for operations that use
-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?
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,
however, you may perform this script to generate a signature header of the provided file in the provided file’s directory.
I’m able to generate
cboot_t194_sigheader.bin.encrypt as following,
$ ./l4t_sign_image.sh --file bootloader/cboot_t194.bin --chip 0x19
please have a try,
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.