Support optional update payloads, notably for ARM/AArch64 firmwares

[travier]

For Raspberry Pi and other AArch64 systems, we usually need some firmware files to be installed either in the ESP, or at fixed offsets on the disk. Some firmwares are usually specific to each board and can not all be installed at the same time on an image. The installation step for those devices is also often performed from another system and not done on the system itself so we can not guess at runtime which firmwares we should install depending on the installation environment.

Thus we need a mechanism to select which one bootupd would install when setting things up when called by bootc install (directly or via bootc-image-builder with a new option) or by Anaconda.

We would then allow users to extend this list of firmwares via a container build in the case of Bootable Containers using a mechanism similar to #766 and #926.

This would let users build their own images with custom firmware files, build their image with bootc-image-builder, select their custom board variant, and then install it on a device for direct use.

This would provide an alternative user experience to the existing flows from:

• https://docs.fedoraproject.org/en-US/fedora-coreos/provisioning-raspberry-pi4/
• https://github.com/fedora-arm/arm-image-installer/

See previous discussions:

• extend-payload-to-esp: extends any src_input_dir to esp  #935 (comment)

[travier]

We would probably need to extend to the current JSON status format to include a board/firmware ID that would then be resolved to a list of firmwares in the image to install.
For the case of installing a file to the ESP, we should be able to re-use the logic that already exists.
For the case of installing files at specific disk offsets, we should probably create a config format that encodes what is done in scripts right now: https://github.com/fedora-arm/arm-image-installer/blob/main/socs.d/AllWinner

[kfox1111]

It might be nice if the same algorithm used to determine the bootloader/firmware to load could be used with devicetree loading too, so its always consistent.

[say-paul]

#935 implements a new command bootupctl backend extend-payload-to-esp which bib can implement to rpi - hw specific images.

[travier]

Proposed flow (generic image for all devices). Slightly updated example for Raspberry Pi 4 (from #935 (comment)):

RUN dnf install -y uboot-images-armv8

# rpm -ql uboot-images-armv8 | grep rpi
# /usr/share/uboot/rpi_arm64
# /usr/share/uboot/rpi_arm64/u-boot.bin

RUN mv u-boot.bin /usr/lib/efi-firmwares/{name}/{version}/EFI/
RUN bootupctl backend extend-firmwares

What extend-payload-to-esp does:

• Looks at each folder in /usr/lib/efi-firmware/{name}/{version}/EFI/
• Stores rpm details and timestamp in /usr/lib/efi-firmware/{name}/{version}/EFI.json

bash-5.2# tree /usr/lib/efi-firmware/uboot-images-armv8/
/usr/lib/efi-firmware/uboot-images-armv8/
`-- 1:2025.04-1
    |-- EFI
    |   `-- u-boot.bin
    `-- EFI.json

• bootupd install --board uboot-images-armv8 is updated to install the files from /usr/lib/efi-firmware/uboot-images-armv8/ as well and store in /boot/bootupd-state.json that it also wrote uboot-images-armv8 firmware files.
• bootupd update is updated to read the new field from the state and also update the firmware files from /usr/lib/efi-firmware/uboot-images-armv8/ in the esp.

---

• Update bootc-image-builder to add a new --board foo argument (like the current --rootfs one) that will pass the value to bootc install --board foo, which will pass it to bootupd install --board foo.

---

We would need some kind of mapping so that we can have bootupd install --board raspberry-pi-4 map to bootupd install --board uboot-images-armv8.

---

For ARM devices where we would have to write a firmware file to an offset, we would need to add another folder with different behavior:

/usr/lib/boot-firmware/{name}/{version}/boot/<files>
/usr/lib/boot-firmware/{name}/{version}/boot.json

We would store the offsets where the files should be written in boot.json, similarly to what is done in https://github.com/fedora-arm/arm-image-installer/tree/main/socs.d.

bootupd install --board foo would install those files at the offset on the root disk, write that it did that in the state file and update would then update those as well.

[travier]

Alternative using #938 to specialize an image right now.

• "Undo" the generate-update-metadata command
• Place the uboot-images-armv8 in /usr/lib/efi/uboot-images-armv8/
• Re-run bootupctl backend generate-update-metadata

Containerfile example:

FROM bootc-arm64-image

RUN <<EOL
updates=/usr/lib/bootupd/updates
rm -fv ${updates}/{BIOS,EFI}.json
cp -r ${updates}/EFI /usr/lib/ostree-boot/efi
# prepare /usr/lib/efi/<grub2|shim>/<ver>
if [ ! -d "/usr/lib/efi" ]; then
    arch="$(uname --machine)"
    if [[ "${arch}" == "x86_64" ]]; then
        surfix="x64"
    else
        # Assume aarch64 for now
        surfix="aa64"
    fi
    grub_ver=$(rpm -qa grub2-efi-${surfix} --queryformat '%{VERSION}-%{RELEASE}')
    mkdir -p /usr/lib/efi/grub2/${grub_ver}/EFI/fedora
    mv ${updates}/EFI/fedora/grub${surfix}.efi /usr/lib/efi/grub2/${grub_ver}/EFI/fedora/
    shim_ver=$(rpm -qa shim-${surfix} --queryformat '%{VERSION}-%{RELEASE}')
    mkdir -p /usr/lib/efi/shim/${shim_ver}/EFI/
    mv ${updates}/EFI /usr/lib/efi/shim/${shim_ver}/
else
	rm -rf ${updates}/EFI
fi

###
uboot_version=$(rpm -qa uboot-images-armv8 --queryformat '%{VERSION}-%{RELEASE}')
mv u-boot.bin /usr/lib/efi/uboot-images-armv8/${uboot_version}/EFI/
###

bootupctl backend generate-update-metadata -vvv
EOL

---

Or we do both and also add the logic to specialize an image for a specific board (current state of #935 IIUC).

[jtligon]

you should talk to @alexlarsson about this work and look at what we're doing in the a-i-b repos on AutoSD

[alexlarsson]

@jtligon Currently, the rpi4 builds in a-i-b just don't work for the same reason this issue explains. I.e. there is no way to install files via bootupd to the root of the ESP (/boot/efi), all the support is for adding stuff to the EFI directory (/boot/efi/EFI). I see some references to #938 (now merged) solving this, bit I don't think so. It just makes it more flexible to copy stuff to /boot/efi/EFI, you cannot add stuff to /boot/efi.

It seems like #935 is maybe doing the right thing, but its not merged and seems to somewhat conflict with the merged #938, so I don't know what the plan is here.

Anyway, we are also interested in having this solved.

[travier]

Hum, this is indeed a case I don't remember thinking about (updating files at the root of the ESP) so I don't remember if the current code handles that properly.

With https://fedoraproject.org/wiki/Changes/BootLoaderUpdatesPhase1, we should be able to copy files to the root of the ESP as we properly have the EFI folder there: https://koji.fedoraproject.org/koji/rpminfo?rpmID=45004244

[travier]

I remember that we chose to do updates as the "directory under /EFI (i.e. /EFI/foobar)" level a while back as there could be other things at the root that we should not touch as we don't own those.

[travier]

Answering questions from #935 (comment):

• Are those firmware files versioned?
• Are they always installed under the same name?
• Are it tied to a kernel version?
• What happens when we rollback?

In the RPi case, the those firmware files are loaded by the board's firmware from the ESP and not tied to a kernel version (i.e. they are not loaded by the kernel). They are installed under a pre-determined name in the ESP, at the root and not under a folder (i.e. EFI). There is no rollback mechanism.

[travier]

From a side chat, adding a distinct option to be able to create generic images for all devices (option described in #959 (comment)) is not currently desirable as it's unlikely we'll have those generic images soon and that adds too much complexity / pieces.

So we are leaning on extending/fixing #926 (option in #959 (comment)) to properly update files at the root of the ESP, preferably at the end (after the /EFI sub folders), and in a predictable, stable, alphabetical order. This way we could write the new file, do an atomic exchange, repeat.

[travier]

New suggested update logic:

• Update each subfolder in /EFI atomically in a sequence (i.e. /EFI/BOOT, /EFI/fedora, etc.)
  • This is what we do right now
• Then update other folders at the root of the ESP, atomically, in a stable order (i.e. /overlay)
  • We have to be careful here to not remove anything that we did not create
• Then update the files at the root of the ESP, in stable order