There’s no cute project name, given it’s just upstream TianoCore support for the platform, but you’re welcome to call it rpi4-uefi or rpi-uefi for the entire family of upstreamed TianoCore implementations, which today encompass Pi 3/3B+ and Pi 4B.
This is very much a continuation of the original Raspberry Pi (3B/3B+) support in TianoCore, but with bigger goals and bigger stakes.
The Pi 3 UEFI is a classic EBBR implementation, capable of booting 64-bit Arm (AArch64 aka arm64) operating systems with explicit Raspberry Pi 3B/3B+ support. This includes FreeBSD, NetBSD and various Linux distros via Device Tree, and Microsoft Windows 10 (Windows PE) via non-standard ACPI. See unofficial releases.
The Pi 4 UEFI is aiming at full compliance with SBBR for running 64-bit Arm (AArch64 aka arm64) operating systems that are part of the ServerReady ecosystem. This includes stock FreeBSD, NetBSD, Microsoft Windows 10 (Windows PE) and Linux distributions which boot via standard ACPI and expect an SBSA-compliant system. Arm ServerReady ensures that Arm-based infrastructure works out-of-the-box with off-the-shelf software, offering seamless interoperability with standard operating systems, hypervisors, and software. See the status page for up-to-date official release info.
In simple terms, with SBBR your favorite Linux distro ISO or other OS will boot without needing a custom kernel. You might need drivers for specific I/O like on-board networking, but at its core the system will be usable with standard USB devices and HDMI video, enough to get on the network or do basic development.
Because ServerReady might mean certain functionality is not available due to non-compliance (e.g. explicit PCIe), the Pi 4 UEFI will still support booting all your favorite 64-bit Raspberry Pi 4 OSes EBBR-way with Device Tree.
The high-level goals:
- Provide a low-cost and high-volume developer platform, compatible with the Arm Server ecosystem.
- Standardize Arm Edge “ecosystem” to catalyze adoption of Arm-based Edge Compute deployments.
- Provide a credible example for the applicability of ServerReady in any footprint.
Low-Cost and High-Volume Developer Platform
To date, getting started with the Arm server ecosystem is not easy. Smaller systems aiming for compliance (but not necessarily delivering) start at around $500+, while proper servers are a multi-thousand dollar proposition that’s hard to swallow for hobbyists, students, folks across the wider income distribution, or even for kicking the tires in a commercial setting. Cloud instances help significantly, but are still more expensive over time and may not be appropriate for all manner of development, such as low-level kernel or device driver development, research projects, etc.
A $35-55 Raspberry Pi providing even 90% of ServerReady compliance and same it just works experience will go a long way to solve this problem.
To look at it differently, IBM PCs became a dominant hardware and software ecosystem way before anyone even considered building servers with x86, and by then servers became naturally an extension of the dominant home/business computer ecosystem. Arm servers, on one hand, owe their existence to the Arm-dominated embedded and mobile SoC ecosystem, yet there is no continuity between the two largely due to the wild incompatibility of the latter.
We need proper standards-compatible “Arm PCs” for proper growth and adoption of Arm servers
To capture the “high end” (servers), you need the capture the “low end” (SBCs, laptops, desktops, etc), but both sides must be compatible. Just like x86. It has to be the same world. To rephrase: people riding more bikes doesn’t lead to more EVs on the road, even when both are made in the same factory, have wheels and can be steered.
Arm Edge Standardization
Arm-based Edge Compute must become a horizontally-integrated ecosystem – just like the Arm servers. Horizontal means silicon providers, platform integrators, OS vendors, application developers and solution providers all being separate entities from each other. Right now it’s a vertically-integrated ecosystem – many separate silos with end-to-end stacks locked in a perpetual Mexican stand-off. That has been its historic state.
Why is it important for Edge to be a horizontally-integrated ecosystem? Because vertically-integrated ecosystems don’t grow as fast and they provide bad customer value due to lock-in and countless wasted developer efforts to support many different boards. Many of the Edge devices, figuratively, become “bricks” – locked to outdated software, as vendors become disinterested in supporting older devices.
There’s only one standardized Arm ecosystem – ServerReady. Edge needs to be ServerReady.
The Raspberry Pi is a pragmatic choice for showing the value of standardization. To drive change, we need to change something in this ecosystem that has gravity. Pi has gravity – high volume, low price, great mindshare. It’s also fairly weird as a platform, so if the Pi can be made even 90% compliant, it’s a great victory – basically, others would have no excuse for doing their own thing instead of ServerReady.
|2016||Microsoft’s original 32-bit implementation for the Pi 2 and Pi 3, part of the first Windows 10 IoT release|
|02/2017||Ard Biesheuvel develops early 64-bit UEFI support as a TF-A payload.|
|11/2017||Andrei Warkentin creates RaspberryPiPkg, a 64-bit Pi 3B UEFI firmware, based on Ard’s initial port and I/O drivers reworked from the 32-bit Microsoft firmware. Integration and beginning of significant changes to a DWC2 UEFI USB host driver (originating with Linaro) to support HID.|
|12/2017||First RaspberryPiPkg release with HDMI and Arasan SDHCI support. Booting SUSE Linux.|
|03/2018||Reasonably stable DWC2 USB host support.|
|04/2018||ACPI implementation matching Microsoft’s. First 64-bit Windows PE boot.|
|05/2018||Pseudo-NVRAM and Pseudo-RTC support.|
|06/2018||SDHost and “stable” Windows PE on Arm support.|
|11/2018||VMware ESXi-Arm demoed on stage at VMworld’2018 Barcelona.|
|01/2019||Support for official 64-bit DWC2 USB2 drivers from MCCI for Windows 10. RNG support for Pi 3 added. https://pi64.win/ launched.|
|02/2019||RaspberryPiPkg upstreaming finished by Pete Batard to TianoCore master branch. Long live RaspberryPiPkg! Upstream is the future.|
|08/2019||First PoC of Raspberry Pi 4 firmware. VMware, Inc and Arm Holdings agree to collaborate to develop SBBR-compliant Pi 4 firmware as a community project.|
|10/2019||VMware ESXi-Arm demoed on Pi 4B at Arm TechCon’19. https://github.com/pftf is set up as a staging area for WIP prior to upstreaming.|
|11/2019||VMware ESXi-Arm demoed on Pi 4B at VMworld’2019 Barcelona.|
|12/2019||VMWare presents “Making Pi ServerReady” and demos ESXi-Arm on Pi 4B at IFX’19 in Las Vegas. Pi 4-specific code hits TianoCore upstream. UEFI support for PCIe RC and xHCI. First ever SBBR boot with vanilla Debian and xHCI via ACPI. Work ongoing to prototype ACPI _DMA descriptor support and evaluate upstream OS changes to work-around 3GB limitations with xHCI. NetBSD first OS to support ACPI device DMA constraints/translation.|
|01/2020||#rpi-uefi-dev channel launches on Arm Developer-Ecosystem Discord server. @marcinoo97 demonstrates full Windows 10 build 17134 running on Pi 4 with 1GB RAM and MCCI drivers for USB2 (not xHCI).|
|02/2020||GENET work continues on exposing/consuming the SoC Gigabit via ACPI. Switch to DualSerialPortLib, transparently supporting both PL011 and miniUART consoles. v1.1 release out. https://rpi4-uefi.dev is launched.|