Decouple bootloader update from rootfs update

[pberginkonsult]

I'm using Jetpack 6 (scarthgap branch) on Jetson AGX Orin. In our OS we are using Mender as OTA framework and we have integrated what is in meta-mender-community/meta-mender-tegra. During upgrade from 36.4.0 to 36.4.3 I became aware of an issue that relates to updates on the platform. I would like to discuss it in general terms here, how to implement and solve the issue in Mender is next step.

Nvidia's OTA implementation relies on two bootchains A and B where they have A and B paths both in bootloader and in rootfs. Bootloader A is tightly coupled to rootfs A and same for B. When performing a Capsule update of bootloader chain the capsule is placed at EFI\UpdateCapsule and the EFI variable OsIndications is set. When the bootloader detects this on next reboot is will update bootloader in the inactive path and after programming is done switch to that updated path, both for bootloader and rootfs. This is currently what Mender implementation rely on. When triggering a new update it will first from Linux userspace program inactive rootfs with new image, then put a bootloader capsule in EFI partition and set OsIndications variable.

When I now went from 36.4.0 to 36.4.3 I realized that this failed for me some times. After some debugging I found out that there is a check in the bootloader to not program a bootloader with lower version than the running one.

Here is the error message from bootloader built with debug:

Jetson System firmware version v36.4.3 date 2025-06-18T12:17:46+00:00
ESC   to enter Setup.
F11   to enter Boot Manager Menu.
Enter to continue boot.
Failed to find memory test protocol
FmpDxe(NVIDIA System Firmware): CheckTheImage() - Version Lower than lowest supported version. 0x00240400 < 0x00240403
FmpDxe(NVIDIA System Firmware): SetTheImage() - Check The Image returned that the Image��

In my case I did an update to 36.4.3 and then during my work I wanted to program an older image with version 36.4.0. Mender update started normal but after reboot it came back to same rootfs as before due to the check above. The capsule update error was reported in /sys/firmware/efi/esrt/entries/entry0/last_attempt_status and can be seen with nvbootctrl "Capsule update status:":

~# nvbootctrl dump-slots-info
Current version: 36.4.3
Capsule update status: 3
Current bootloader slot: B
Active bootloader slot: B
num_slots: 2
slot: 0,             status: normal
slot: 1,             status: normal

The obvious solution to this problem is to never go back in versions of the bootloader. This is probaly fine in a production environment but during development it is not optimal. So the question is how you can decouple updates of bootloader from updates of the rootfs?

If it is a hard requirement that always have same or newer version of bootloader how to check this on a TEGRA_BL.Cap file before update? This can also be useful to not update on every rootfs update if the bootloader already is up to date.

[dwalkes]

Hi @pberginkonsult
You may find the reference swupdate implementation at https://github.com/OE4T/tegra-demo-distro/tree/master/layers/meta-tegrademo/dynamic-layers/meta-swupdate and the features added in OE4T/tegra-demo-distro#327 and OE4T/tegra-demo-distro#320 as a useful reference. These accomplish some of the decoupling/version checking you are looking for. I'm not aware of anyone who has tried to do something similar for mender yet but I think this logic could most likely be reused there.

[pberginkonsult]

Tried to implement something in this line in meta-mender-community. mendersoftware/meta-mender-community#478 I'm happy to get some review and feedback on that one.