coreos
Support for Raspberry Pi firmwares/bootloaders
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.
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.
FTR, I came up with a horrible, incomplete, but working workaround, see https://github.com/ondrejbudai/fedora-bootc-raspi
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
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.
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 https://github.com/coreos/bootupd/issues/651#issuecomment-2109364904, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACF5LYQOQDZXAF3TNHZVODZCGTOZAVCNFSM6AAAAABHLI6NI2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBZGM3DIOJQGQ . You are receiving this because you commented.Message ID: @.***>
@cgwalters @ondrejbudai @nullr0ute adding the firmware files(dtb,elf) in /boot/efi is done by the rpm, we need to ensure it copied over correctly while building the image, but for the bootloader (uboot) binaries seems to vary as per SOC rpm -ql uboot-images-armv8 we need to know the device on which the image will be installed. I see this part to be handled by arm-image-installer as it already consumes --target=rpi4 and can put the binary accordingly.
I think this issue is a dup of https://github.com/coreos/bootupd/issues/766 - I don't have a strong opinion on which we do the dup, I filed that one having forgotten that this one exists.
