rpi 4 / 5 firmware for UEFI boot

[necrose99]

Summary

Add rpi 4 / 5 firmware for UEFI boot ... Note the firmware is zipped , it is PREBUILT .. TF-A + EDK2 UEFI firmware port for Raspberry Pi 5.

https://github.com/worproject/rpi5-uefi/raw/master/images/edk2_setup_screen.png

rpi5 comes with a bios like boot menu for picking say grub or efi-stub kernel ...

these are pre-baked RPI4 or 5 UEFI ready to install zip files ,

[sidenotes : one can make bootable cards with fresh firmware for SPI/EEPROM update and just unpacking to a new card into /boot/efi manually but , and chroot in debian and migrate the genpi64 to efi by hand .... but that's not as automated nor fun... as the ebuild updates one can just emerge to uzip new firmware to /boot/efi and done without having to download manually etc.. ]

fixes added missing gentoo headers and QA-prebuilt

Motivation

Build.Dist the python buildy thing ... one could add Grub2 and rpi-efi to image builds and sys-boot/refind or from the refind-iso ... dual boot genpi64 or some other os on other partitions ... (if one resized m.2 for rpi5 etc) or booting from SDcard or m.2 for multiple os support on users end..

into json and bake via build.dist.... rpi5 add the firmware grub2 to packages to add... /boot/efi @ fat32.efi 150 megs /boot/ @ext4 550 /genpi64-rootfs @btrfs grow /boot/overlays symlink /boot/efi/overlay ... (device tree blobs) on /usr/src/linux @ make install ... for custom kernels,,

efi supposedly boots faster ....

Grub2 failover ... if you release a newer kernel and it goes tits up because something upstream puts in config , with grub you could just boot the previous kernel ... or use gentoo-bin-kernel: arm64 can test and revert if things go bad... one could test a new kernel pkg with perhaps more resiliency and not making the thing a brick... and having to re-image it. Grub2 has that familiar look and feel... so one could load it pick your kernel as one can with a desktop or laptop... and its flexible..

youtube has many a overly techy melt my brain presentation on grub and dev conferences

to straight forward grub2 arm64 guides using this sets of firmwares for boot... on rpi4/5 and similar rockchip pi clones..

[samip5]

Again, your text seems all over the place. Please try to keep it readable, which currently it's not.

[necrose99]

I've tried short I've tried overly verbose..

A) These boot the device in GPT/UEFI mode or allow you to point at grub-aarch64.efi. ( Or efi stub kernel/s ) Then, using the GRUB config, you can select a kernel. If you compile a custom kernel, you still have the stock Genpi64 kernel to fall back on. This workflow is similar to how desktops boot.

A2) This includes the RPi4 uefi version as well.

B) The EFI partition (/boot/efi) is typically 120-150 MiB. However, if you symlink /boot/overlay (550 MiB +/-) to /boot/efi/overlay, 128 MiB might be slightly undersized for the ARM64 binary blobs.

C) Once the RPi5 uefi firmware is configured, it operates like BIOS: a set-and-forget system unless the user overrides it. In contrast, the RPi4 UEFI firmware requires more manual setup using the config file.

D) You can build from sources, but it requires checking out the full repository plus nested git repositories of EDK2 UEFI sources. This isn’t a ready-to-go firmware and could be more challenging than it's worth at the moment.

E) While the release packages binaries, Gentoo philosophy tends to prefer sources. However, the sources also require EDK2 UEFI and are more difficult to manage than simply unzipping new firmware. Avoiding accidental downgrades or via CONFIG PROTECT of the config file in boot.. from accidental overwrite.. (/boot efi) As a package one can apply automatic updates..

As for rpi5, netboot.xyz, refind for slicing the nvme or picking boot devices for trying other os/s are also available options..