Update mechanism (A/B) and ESP

[loblik]

I have Orin based board with NVME storage and I'm looking for options how to implement an update mechanism.

It seems there is a quite complex logic in L4TLauncher, with all A/B and failovers. But I still don't understand how EFI system partition (ESP) is fitting in. How is this loader (L4TLauncher) supposed to be updated in A/B scheme?

I know there is this second (not active) ESP partition, but how that is supposed to work. Is ESP (with launcher) supposed to be flashed each time the boot firmwares and UEFI on QSPI get updated? How this then work with failover mechanism? I guess in case boot failure, still the same version of launcher gets executed as there is only one ESP partition active at the time.

[madisongh]

Yep, lack of redundancy for the ESP partition was one of the things I noticed when NVIDIA started talking about the shift to UEFI. I vaguely recall hearing some plans from them to address it, some time back, but from what I can see, there's nothing implemented. The "miniUEFI" implementation that came in L4T R36.3.0 sounds like it might help, but it's limited to the AGX Orin platform and only supports booting off eMMC. I haven't actually looked at the code for it, though, so I could be mis-reading the documentation.

In theory, at least, you could try activating that esp_alt partition and setting the BootOrder EFI variables during an update to switch between the ESP partitions... I did that on an x86-based project, many years ago, and it was reasonably successful. However, the big unknown with the NVIDIA hardware is how tight the coupling is (or, more accurately, will remain, based on the history) between the boot firmware (including UEFI), the launcher in the ESP, and the OS. I don't think we'll know that until NV puts out some more L4T releases.

[madisongh]

@AndersGnistrup That section of the developer's guide doesn't actually address redundancy for the ESP partition, just the boot chain up through UEFI.

@loblik If you have success with using systemd-boot, let us know. Last time I tried it, I couldn't get UEFI to load the BOOTAA64.efi. That was some time ago, though.

[AndersGnistrup]

@loblik ,Thanks for the response and I agree if the "atomic" behavior is done by altering GPT tables.
I had hoped that the MB2 bootloader could be told which ESP to use.
If this is not the case, not much have been archived.
@madisongh Ok, thanks. I did read it like a redundancy from and including UEFI bootloader/ESP partition.

[loblik]

@loblik If you have success with using systemd-boot, let us know. Last time I tried it, I couldn't get UEFI to load the BOOTAA64.efi. That was some time ago, though.

It seems to work just fine. But I was thinking about simplifying things even more by building unified kernel image (UKI) and placing it directly on ESP. This would allow to skip systemd-boot completely in some scenarios, executing UKI directly. I was able to hack it together and basically it works, but I'm having trouble to integrate it to the build properly. This introduced circular dependency.

It seem's tegra-minimal-initramfs depends on tegra-espimage. It seems it's releated to bup-payload conversion and cpio.gz.cboot.bup-payload type. Could someone shine some light on this? Is there some description somewhere what is this all about and why there exists such a dependency?

I thought BUP is for firmware update (UEFI and other proprietary stuff on QSPI), but how is this related to initrd and EFI system partition?

[loblik]

Ok, it seems there is also a BUP variant for kernel update. If there is bup_type=kernel specified in TEGRA_BUPGEN_SPECS. Then of course we need initramfs to be built first if it's part of the kernel image.

But I didn't find a reason to have a dependency for ESP. I was able to fix this by moving esp.img outside of tegraflash_populate_package so won't get called for BUP, only for tegraflash case. And removing the dependency declaration.

diff --git a/classes-recipe/image_types_tegra.bbclass b/classes-recipe/image_types_tegra.bbclass
index ce4e2fbe9afb..0fe58fb428ee 100644
--- a/classes-recipe/image_types_tegra.bbclass
+++ b/classes-recipe/image_types_tegra.bbclass
@@ -284,7 +284,6 @@ tegraflash_populate_package() {
         cp "${STAGING_DATADIR}/tegraflash/${EMMC_BCT_OVERRIDE}" .
     fi
     cp "$kernelimg" ./$lnxfile
-    cp "${IMAGE_TEGRAFLASH_ESPIMG}" ./esp.img
     if [ -n "${DATAFILE}" -a -n "${IMAGE_TEGRAFLASH_DATA}" ]; then
         cp "${IMAGE_TEGRAFLASH_DATA}" ./${DATAFILE}
         DATAARGS="--datafile ${DATAFILE}"
@@ -333,6 +332,7 @@ create_tegraflash_pkg() {
     mkdir -p ${WORKDIR}/tegraflash
     cd ${WORKDIR}/tegraflash
     tegraflash_populate_package ${IMAGE_TEGRAFLASH_KERNEL} ${LNXFILE} ${@tegra_bootcontrol_overlay_list(d)}
+    cp "${IMAGE_TEGRAFLASH_ESPIMG}" ./esp.img
     if [ -n "${IMAGE_TEGRAFLASH_INITRD_FLASHER}" ]; then
         cp "${IMAGE_TEGRAFLASH_INITRD_FLASHER}" ./initrd-flash.img
     fi
@@ -492,6 +492,6 @@ create_bup_payload_image[vardepsexclude] += "DATETIME"
 CONVERSIONTYPES += "bup-payload"
 CONVERSION_DEPENDS_bup-payload = "tegra-flashtools-native python3-pyyaml-native coreutils-native tegra-bootfiles \
                                   dtc-native \
-                                  virtual/bootloader:do_deploy virtual/kernel:do_deploy virtual/secure-os:do_deploy \
-                                  ${TEGRA_ESP_IMAGE}:do_image_complete ${TEGRA_SIGNING_EXTRA_DEPS} ${DTB_EXTRA_DEPS}"
+                                  ${TEGRA_SIGNING_EXTRA_DEPS} ${DTB_EXTRA_DEPS} \
+                                  virtual/bootloader:do_deploy virtual/kernel:do_deploy virtual/secure-os:do_deploy"
 CONVERSION_CMD:bup-payload = "create_bup_payload_image ${type}"

Not totally sure if this is proper fix and it can't break something else. If it will be ok I can make a PR.

[madisongh]

That looks right. The ESP image really is only needed for the tegraflash package, not the BUP.

In master and scarthgap latest, BUP generation has moved to the tegra-uefi-capsules recipe, so the dependency change would need to be made there.