We want to employ full A/B redundancy using a production-use Jetson Xavier NX with external eMMC storage as fallback and internal eMMC storage as the main system. Our use case doesn’t allow physical access to the Jetson after deployment, so the backup system is meant to give us a way to fix the main image in case of data corruption.
Booting from the internal eMMC is no issue, the system can see and mount our storage on the sdmmc3 bus (for now this is a SD card on a carrier board). We can even use the external rootfs as our system but this is not enough, as kernel and devicetree-files would still be vulnerable to damage at this stage.
Next I tried to flash our kernel and dtb files onto the sd card just like I’d do with internal storage:
sudo ./flash.sh -r -k kernel-dtb jetson-xavier-nx-devkit-emmc external
(I’ve previously put the UUID of the SD card partition /dev/mmcblk1p1 inside of
bootloader/l4t-rootfs-uuid.txt to be sure the right device gets flashed)
This runs without any troubles! But after a reboot I see this on the debug console:
I> found decompressor handler: lz4-legacy I> decompressing BMP blob ... I> Kernel type = Normal I> Loading kernel-bootctrl from partition I> Loading partition kernel-bootctrl at 0xa42b0000 from device(0x1) W> tegrabl_get_kernel_bootctrl: magic number(0x00000000) is invalid W> tegrabl_get_kernel_bootctrl: use default dummy boot control data I> ########## SD boot ########## W> Error: failed to get sd-card params I> -0 params source = E> Failed to initialize device 6-0 E> SD boot failed, err: 252641293
So I guess C-Boot can’t access the SD card by itself? Which makes sense, as far as I understand it the devicetree file which enables the sdmmc3 bus is loaded at a later stage.
Do I need to reflash and reconfigure the bootloader itself?
I’ve attached debug UART output as well as dmesg output from the internal eMMC system. Please let me know if you need further information.