That blueberry patch is also stuck on old downstream 6.1.y DTB as you can read. Also RPi are 'graphical' focused while U-Boot philosophy is to do just enough to get a proper kernel+initrd+dtb(o) loaded and running. So Debian13 is too new and upstream, this won't work. On the other hand kernel 6.12 is way too old, you would need sid, currently at 7.1.x as that should include a dtb you need for that hardware, but check yourself.Seems UEFI + GRUB gets very close… and the mechanics are there for U-Boot to at least throw a boot logo on the screen… I was hoping there was some work in that space. U-Boot would allow for much safer "over-the-air" style updates than the current "replace kernel, reboot and pray" situation we have with the standard boot firmware.
I am using 7.1.3+deb14-arm64 in ACPI mode but that is https://github.com/pftf/RPi4 and 'server' only, serial cable only used for emergency although whole colored UEFI menu works via that cable. AFAIR also via HDMI, but is 3 years ago or so I used that.
RPi5 EEPROM device is too small for normal PC like UEFI, it is 16Mbit while it would need 16MByte or so like in the ROCK5B in order to have multiple distros using standard (GRUB) multi OS boot. Note that EDK2 UEFI based bootloader/firmware needs dedicated SPI-flash to store boot entries like is standard for PC's, it won't work with eMMC/SD-card.
RPi works like per type of device, so eMMC/SD or NVME or USB. Means you can have 3 distros, each with your own hack of RPL/config.txt boot sequence on a separate bootFAT partition. All roots can be anywhere, you would GPT the NVME with 10 partitions or so, that is what I always have done. Although max 4 MBR would also work, but I hope you are aware of all those auto resize functions and know how to disable those upfront.
But your device is a niche, so already what you choose, downstream or upstream, will be a small minefield to pass. EDK2 based UEFI does not store the URLs per OS, so only the 1 default EFI/BOOT/BOOTAA64.EFI is used, not e.g. EFI/debian/grub64.efi EFI/gentoo/shim.efi to name some random entries.
Also this means your OSses are not separated, they share the ESP, that is how it is by default. But as said, RPI works per device, so some fundamental issue. You should probably give up on that separation as you anyhow will have a high update rate of the firmware, unless you block eeprom update service. I use UEFI with a NanoPi-R6C, that has soldered eMMC and I put in my own Samsung 970 NVME. Even though that is not bothered by a closed-source proprietary firmware/bootloader like for RPi4/5, it cannot select OS from UEFI. So I use the GRUB from 1 OS the boot all OSses. There is no Windows like for Intel/AMD, so it works somehow by sharing GRUB. But note GRUB does not do/load DeviceTree by default, so you need extra script.
Statistics: Posted by redvli — Tue Jul 14, 2026 6:39 am
