[RPi5] Support loading custom Arm firmware directly from EEPROM

[nosoul78]

Hello,

Since Raspberry Pi 5 has 2 MB of EEPROM and only about 600 KB are used by the closed blobs, I think it would be a great addition to support loading custom Arm-side stubs (EDK2, U-Boot), along with DTB and config.txt parameters directly off the remaining free space.

There's already an ATF armstub included, but it gets conditionally loaded on presence of a boot media containing config.txt.

Why does this matter?

The firmware mentioned above can provide many more features and boot a larger number of OSes out-of-the-box. Having this all in a separate onboard storage would bring the Pi closer to being a regular PC and leave other boot media completely to the OS.

With community EDK2 flashed to EEPROM, one could just grab a standard Debian / Ubuntu / ESXi / whatever image from their official website, burn an USB and then the Pi be able to boot straight into it, no other messing around.

Not to mention that both EDK2 and U-Boot are fully open-source. Giving users the choice to flash software like this on EEPROM can help achieve the goal of moving more stuff from the closed VPU firmware to the Arm side (+ benefit from better, battle-tested boot drivers).

Space requirements

I understand that the VPU firmware may grow beyond its current size with updates. That's okay, but realistically, will it ever cross the 1 MB mark? And at that point, wouldn't it make more sense to offload features to open Arm firmware anyway?

I'm thinking that 1.2 MB free space for 3rd party firmware is a decent compromise. For instance, a release build of EDK2 can fit in there, although by stripping some functionality (parts of the UEFI Shell app or networking, pick your poison)...

This is why I'm asking for a bit more: providing alternative trimmed down VPU blobs with no Netboot, USB, PCIe and other redundant code (that the armstub could provide on its own).

What do you think?

[Marcinoo97]

omg. yes pls. I being attempting to slice some of original EEPROM to fit edk2 firmware unofficially with tiny bits of success but official way would be very much prefered.

[timg236]

There are currently no plans to do this but will leave the issue open.
The VPU firmware will get bigger and most of the space is for A/B booting.
it’s conceivable that we might make a chunk of say 128K available for user data but don’t plan to add ARM code in the flash

[nosoul78]

Thanks for the reply.

What about at least an unofficial, "undocumented" bootconf.txt option for it, so folks that still want to do it (and there aren't few - server usage on Pi is quite common), won't have to go to the extent of patching VC4 assembly?

I'm thinking maybe an "ARMSTUB_ADDRESS=" option (offset in flash) and allow having config.txt options in bootconf.txt? The latter would actually be useful not only in this case.
Since you already provide a TF-A armstub, I figured this wouldn't be difficult to add on top of that.

Of course, no strings attached in regard to the free space available. It would be the user's responsibility to ensure they keep their ARM code away from the VPU blob and don't clobber it.

[pelwell]

Mentioning an option here is documentation. Its existence creates a precedent, and removing it in the future would cause howls of protest. Until the bootloader matures a bit it would be shooting ourselves in the foot to add such a feature.

This issue remains open, and your wishes have been preserved.

[geerlingguy]

Just chalking up one more vote of "yes it'd be cool to have this" ;)

It would certainly be nice to be able to manage my Pi the same as I can manage my $2000 Ampere server, in terms of OS installs.

[Marcinoo97]

To simulate how good it could be to have such feature i allowed myself to use rpiboot. It would have been a lot better if my PC could send more than 5V 0.9A over usb c port. Also this doesn't even uses 2MB yet.
bootfiles.zip

[timg236]

Not sure why the size of bootfiles.bin is relevant. Anyway, A/B booting will likely partition the EEPROM in two