Xavier NX ignoring boot order

[cakre]

While trying to boot a Xavier NX 16GB from emmc with a nvme ssd attached I had some struggle getting it to boot from emmc. I adjusted the boot order in L4TConfiguration.dts and also set NewDeviceHierarchy to 0 in that file.

There is a system installed on that ssd (from booting an orin nano with it), which panics when booted on the xavier nx. When using a clean ssd (no system installed on it) it works and boots from emmc. I also played around a bit with redundant/non-redundant, booting in slot a and b and I noticed that this does not occur when installing the ssd with the active slot being slot B on the device. The installation on the ssd seems to be setup non-redundant.

Sure I could format the ssd before using it but this doesn't seem to me to be intended behaviour. Do you have any pointers towards how to troubleshoot that further or am I just missing something? I haven't tried this on stock l4t yet btw. Seems to work on stock l4t

Boot log (UART):
xnx_ssd_noredundant.log

Boot log with edk2 debug info (includes log from when I flashed the device):
xnx_ssd_noredundant_edkdebug.log

[madisongh]

So you formatted and installed the SSD on an Orin Nano, but you want to reuse that SSD, without re-formatting/re-installing, with a Xavier NX?
You could probably hack something to make that work, but unlike the stock Ubuntu/Jetson Linux that comes with everything prebuilt, in Yocto-land our builds are per-machine, and there are some build-time decisions/settings that customize/optimize things for the specific target. So reusing the kernel/DTB/rootfs partitions without re-flashing when you change machines is not intended to work.

[cakre]

Oh no, you misunderstood. I don't intend to boot the SSD. I intended to use it as data storage for the xavier nx, it just so happened to still contain an installation for jetson orin. I set the boot order so that the xavier should boot from emmc so I can just reformat the ssd from the jetson.
The problem is that no matter what the xavier always tries to boot the system on the ssd instead of the system on emmc I want it to boot.
I could also just format the ssd from another device but It doesn't seem intentional that the xavier nx ignores the bootorder I set (that it is supposed to boot from emmc) and still tries to boot from the ssd if it contains a system

[cakre]

The installation on the emmc boots fine without the ssd attached.

This is my L4TConfiguration (as txt because of github):
L4TConfiguration.txt

[dwalkes]

This seems like it could be related to the note at https://github.com/OE4T/meta-tegra/wiki/initrd-flashing-support#notes

Depending on your device's configuration (e.g., having multiple storage devices attached), you may need to manually configure the boot order in the UEFI bootloader by hitting ESC when UEFI starts, and then selecting Boot Maintenance Manager, then Boot Options, then Change Boot Order. This is a limitation in JetPack 5.0 that is supposed to be fixed in JetPack 5.1.

[madisongh]

Oh no, you misunderstood. I don't intend to boot the SSD. I intended to use it as data storage for the xavier nx, it just so happened to still contain an installation for jetson orin. I set the boot order so that the xavier should boot from emmc so I can just reformat the ssd from the jetson.
The problem is that no matter what the xavier always tries to boot the system on the ssd instead of the system on emmc I want it to boot.

Ah, OK, right, then the problem is likely due to there being an APP partition on both the NVMe drive and the eMMC. The tegra-minimal-init script isn't very particular about the location, and blkid is probably returning the NVMe-resident partition first.

You can work around this by explicitly setting root=/dev/mmcblk0p1 in your KERNEL_ARGS. We could probably make the init script a bit smarter by having it probe the device pointed to by the TNSPEC_BOOTDEV variable, too.

The stock L4T flashing scripts generate a UUID for the rootfs during flashing and insert that in the kernel command line, IIRC, which would explain why it works OK in that environment.