Frequently Asked Questions

Who is behind this project?

This project started as an official collaboration by VMware, Inc. and Arm Holdings, to develop the Pi 4B UEFI firmware out in the open as part of the upstream TianoCore edk2 UEFI code base. As an open project for and by the community, it is not “owned” by anyone. Everybody is encouraged to participate and contribute. We call ourselves the Pi Firmware Task Force.

To date, we have contributions from (in no particular order) Arm Holdings, VMware Inc., TianoCore, NetBSD, Akeo Consulting and Broadcom Inc.

I want to help or have a question! What’s the best way to engage and collaborate?

Our main gathering point is the #rpi4-uefi-dev channel on the fine Developer-Ecosystem Discord server. This is a developer-oriented channel, but all visitors are welcome.

While not directly affiliated, you may be also interested in the #raspberrypi, #windows-on-arm and #works-on-arm channels.

Is this an “official” Raspberry Pi Foundation project?

Raspberry Pi UEFI Logo
Logo used by the 64-bit TianoCore UEFI for the Raspberry Pi 3B/3B+ and Raspberry Pi 4B.

No. It is not affiliated with or endorsed by the Raspberry Pi Foundation. Select hardware and firmware engineers are aware of it, and we have permission from their marketing to use the stylized black-and-white logo.

We would love to collaborate closer.

What’s the relation with the 64-bit Raspberry Pi 3B/3B+ UEFI?

It’s the same upstream TianoCore edk2 UEFI code base, refactored and extended to support both Pi 3B/3B+ and the Pi 4B. This code is a cleaned-up version of the original 64-bit RaspberryPiPkg Pi 3B firmware, which in turn was derived from Microsoft’s RPi-UEFI (used for the 32-bit Pi 2B/3B IoT Core) and Ard Biesheuvel’s original 64-bit port for the Pi 3B.

Wait, but there’s no way the Pi can be made fully ServerReady?

The purpose of this project is not just “technical compliance” achieved by ignoring 90% of the platform or by setting a ridiculously low base line. It is fully anticipated that where required, we (Arm and the various stakeholders) will work together to propose specification changes to support standardized infrastructure at the Edge, as exemplified by the Pi. Of course, any proposed change has to make sense in the wider ecosystem (server, edge, client) – there will be no Pi-specific hacks, but all of the lessons being learned with the Pi apply 100% to other SBCs.

What operating systems will you support booting?

In SBBR mode, the firmware is aimed to support booting 64-bit ServerReady-compliant operating systems using ACPI. Such operating systems include, but are not limited to, off-the-shell Linux distributions (like Ubuntu or RedHat), NetBSD, FreeBSD, OpenBSD and Microsoft Windows 10 (Windows PE).

Actual levels of support will depend on availability of device drivers and levels of ACPI support in the OS. OS enablement activities (e.g. in Linux or BSDs) are part of the development charter for this project, and are consistent with typicsl silicon provider enablement activities for new chips.

In EBBR mode, the firmware will support existing 64-bi operating systems with explicit Rasperry Pi 4B support using Device Tree (FDT/DTB).

32-bit OS support (e.g. Raspbian, RISC OS) is not currently planned, but is a possibility.

So this will support (64-bit Arm) Windows 10?

Hopefully! We can boot Windows 10 (Windows PE) and there is limited support for USB2 via Type-C via MCCI’s TrueTask drivers (but only when booting with 1GB RAM). USB3 and other I/O doesn’t work at the moment. It’s still a work in progress!

Note: Windows PE is the only “public” version of Windows 10 for Arm that’s available, so that’s all we’re targeting. Full Windows 10 client builds are only currently available for Qualcomm Snapdragon-based systems, so for unsupported and officially unreleased Windows 10 builds it is anticipated that others in the community (such as Windows-on-Raspberry and Pi64.win) will provide for directions (and discussions) on deploying Windows 10 on the Pi 4B (much like they are for Pi 3B/3B+ today)…