UEFI bootloader, storage location and recovery?

[AndersGnistrup]

I am running the meta-tegra demo distro with the machine jetson-orin-nano-devkit-nvme.
I have used scarthgap-l4t-r35.x branch and a redundant boot setup, using the guide https://github.com/OE4T/meta-tegra/wiki/Redundant-Rootfs-A-B-Partition-Support
It works, but I still have some problems understanding the boot procedure.

I have been reading the documentation for both jetson 35.5 and 36.5 and I have had some problems figuring out where the UEFI bootloader, UEFI variables and L4T launcher is stored.

UEFI bootlaoder:
In the QSPI partition layout there are two cpu-bootloader entry's. For some reason I believed that the UEFI boot loader was in the SSD disk but when I removed the SSD disk, the UEFI bootloader started. So, I was wrong.
The A/B cpu-bootloader partitions in QSPI, contains an UEFI bootloader. The L4TLauncher is compiled into the UEFI bootloader,

UEFI variables:
It seems that there are two places for these variables.

• uefi_variables partition in the QSPI device
• esp partition on the SSD disk.
  ESP in SSD should contain most but in the NVIDIA setup UEFI binary is in QSPI and variables in uefi_variables.
  Could someone elaborate on this? What is the ESP partition in SSD disk used for?

Recovery mode
From NVIDIA documentation, https://docs.nvidia.com/jetson/archives/r36.3/DeveloperGuide/SD/Bootloader/UpdateAndRedundancy.html?highlight=redundant
If BootRom does not find a current slot, the device enters NVIDIA recovery mode.
And this is where stuff gets tricky. If one sets a jumper on REC/GND the BootROM loader enters recovery mode and loads the MB2, but from where?
this page, https://docs.nvidia.com/jetson/archives/r36.3/DeveloperGuide/AR/BootArchitecture/JetsonOrinSeriesBootFlow.html#id7 does not give an clear answer, just that it is the MB1 that loads MB2.
I gees that BootROM sets the recovery flag, disables print to UART, and loads latest MB1.
MB1 detects the recovery mode and loads the MB2 in the CCPLEX.
But where is this MB1/MB2 recovery? is it just the latest MB1/MB2 that is loaded into CCPLEX instead off BPMP (R5)

Also, in the flash_l4t_t234_nvme.xml file (v35.5) there are some recovery mode partitions.
If BootROM selects the recovery mode and MB2 starts on CCPLEX, how can a system ever load recover mode partitions in the SSD disk?
Or is there another "recovery mode"?

Thanks for a great job making the OE4T branch!

[madisongh]

UEFI itself, as you found, resides in the SPI flash, with the rest of the boot firmware. The ESP partition on the rootfs drive is for the interface between UEFI and the OS, so it contains the bootaa64.efi executable that's loaded by UEFI to launch the OS. That partition is also where update capsules get stored.

There's more information about the Jetson UEFI implementation in this chapter of the Jetson Linux documentation. For more general information on the UEFI architecture, you'll find specs on the uefi.org site.

"Recovery" means different things in different contexts. When the boot ROM goes into "recovery mode", it's expecting to get the boot firmware downloaded to it via the USB interface.

The "recovery" partitions on the rootfs drive are more for handling OS booting failures, rather than boot firmware failures. The UEFI chapter I linked to above talks about that a bit more. We don't currently implement populating the recovery kernel/dtb/etc. here in the layer, but it should be possible to do that, if you have a use for them.

[AndersGnistrup]

It was close to what I expected.
This information is quite hard to find, so Thanks for the reply.