Support for Raspberry Pi firmwares/bootloaders

[ondrejbudai]

Raspberry Pi requires a bunch of files to be available in the root of the ESP partition (traditionally mounted as /boot/efi on Fedora) in order to boot. In the case of Fedora, this means the firmware, uboot, device trees and probably more. This is the content of /boot/efi on Fedora Server for aarch64:

$ ls /boot/efi
bcm2710-rpi-2-b.dtb*       bcm2710-rpi-cm3.dtb*       bcm2711-rpi-400.dtb*  bcm2711-rpi-cm4-io.dtb*  bcm2712-rpi-5-b.dtb*        bootcode.bin*  fixup4cd.dat*  fixup4x.dat*   fixup_db.dat*  rpi-u-boot.bin*  start4.elf*    start_db.elf*
bcm2710-rpi-3-b.dtb*       bcm2710-rpi-zero-2.dtb*    bcm2711-rpi-4-b.dtb*  bcm2711-rpi-cm4s.dtb*    bcm2712-rpi-cm5-cm4io.dtb*  config.txt*    fixup4.dat*    fixup_cd.dat*  fixup_x.dat*   start4cd.elf*    start4x.elf*   start.elf*
bcm2710-rpi-3-b-plus.dtb*  bcm2710-rpi-zero-2-w.dtb*  bcm2711-rpi-cm4.dtb*  bcm2712d0-rpi-5-b.dtb*   bcm2712-rpi-cm5-cm5io.dtb*  EFI/           fixup4db.dat*  fixup.dat*     overlays/      start4db.elf*    start_cd.elf*  start_x.elf*

However, bootupd currently only manages the /boot/efi/EFI directory, so there's no way to put these files under /boot/efi without any kind of post-processing run after bootupd backend install.

[nullr0ute]

It might be useful to be able to have dot.conf files to allow different bits to be managed using bootupd, I know fwupd-efi may have similar requirements.

[ondrejbudai]

FTR, I came up with a horrible, incomplete, but working workaround, see https://github.com/ondrejbudai/fedora-bootc-raspi

[aenertia]

Likewise for other SBC's which use uboot and/or need custom dtb/dtsi definitions. I am currently investigating bootc for rk3588/rk3566 deployment and am running into lack of flexibility. At the moment it looks like a wash for IOT and/or configurable dtb

[nullr0ute]

Likewise for other SBC's which use uboot and/or need custom dtb/dtsi definitions. I am currently investigating bootc for rk3588/rk3566 deployment and am running into lack of flexibility. At the moment it looks like a wash for IOT and/or configurable dtb

They will need to be dealt with differently actually.

[aenertia]

Both the rk3566/rk3588 have working e2dk uefi at this point; so as long as it's been loaded it could be delt with similarly to the rpi hack linked currently. There are also a number of ways to use an uefi shim to chianload other uboot targets.

…

On Tue, 14 May 2024 at 18:13, Peter Robinson ***@***.***> wrote: Likewise for other SBC's which use uboot and/or need custom dtb/dtsi definitions. I am currently investigating bootc for rk3588/rk3566 deployment and am running into lack of flexibility. At the moment it looks like a wash for IOT and/or configurable dtb They will need to be dealt with differently actually. — Reply to this email directly, view it on GitHub <#651 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACF5LYQOQDZXAF3TNHZVODZCGTOZAVCNFSM6AAAAABHLI6NI2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBZGM3DIOJQGQ> . You are receiving this because you commented.Message ID: ***@***.***>