I’ve added a new link to menu – a status page, providing a fairly-detailed view of things working or broken in the current release. It probably needs to be split into more pages to separate UEFI implementation from operating system-visible aspects like SMBIOS and ACPI, but it’s a place to start.
What’s inside this release?
- Fix packet losses and network instability by switching to rgmii-rxid for phy-mode [tianocore/edk2-platforms@5250e8b]
It may not look like much, but it provides a radically improved networking experience, courtesy of a heads up by Jared and his recent work on the NetBSD GENET driver.
Of course what use is improved GENET via ACPI, when there is barely an OS support? Well, courtesy of the amazing work done by Pete and Jeremy Linton, the Linux ACPI patch for GENET has been merged into net-next.
As always, read the release notes and usual caveats.
NetBSD’s amazing Jared McNeill, who appears to crank out Arm platform support code for NetBSD at an inhuman rate, has coded up a driver for the on-board gigabit NIC (aka GENET).
While a great milestone for NetBSD, this is also the world’s first BSD-licensed implementation of a GENET driver. For our UEFI development effort, this finally means being able to implement a proper UEFI driver for the on-board NIC for PXE booting, iSCSI…you name it.
The NetBSD driver already supports the ACPI bindings for GENET, which first appeared in our 1.1 release, and its development is providing great feedback on further evolving the ACPI support. See, the MAC address is not stored in the NIC itself, but comes from the outside (via mailbox interface, I’m guessing via OTP). Of course, you can hypothetically read it from the NIC itself, if it’s been initialized. But apparently that only works if the NIC has been taken out of reset and the MAC is programmed. NetBSD today can boot 3 ways on the Pi 4 – TianoCore UEFI, U-Boot and “straight up” via config.txt. For booting via UEFI, the NIC is taken out of reset and the MAC is programmed. For others, the MAC is not programmed or the NIC is not taken out of reset, making it unsafe to try and read the MAC address, so there needs to be a more reliable mechanism. This might mean a local-mac-address _DSD property is in order for best compatibility. Having to fall back to the VPU mailbox interface in ACPI mode is a no-go: that would amount to Pi-specific platform knowledge and definitely be not SBBR. Another angle to consider is operating systems performing a fast reboot (aka kexec on Linux) – it would be totally unexpected to see a MAC address change to leak across kexec, so that’s another reason for persisting via an ACPI property.
Stepping back, I want to extend a huge thanks to Jared for both his feedback and for his work on supporting our firmware. NetBSD today is the most advanced OS to boot on the Pi 4B SBBR-way: networking, xHCI, 4GB boards, SD card, etc. Once we get the new SDHCI controller (MMC2) described in ACPI and working this should also bring in Wi-Fi. Jared reports that the existing Arasan driver could be sufficient to support MMC2 – that is to say, the old Arasan SDHCI controller’s set of quirks appears to be a direct superset – at least on NetBSD. 🤣
NetBSD also is the only OS today to fully support ACPI _DMA descriptors for describing DMA translations/constraints. This is very important for supporting Pi and Pi-like platforms via straight-up ACPI and without platform DMA quirks. If you like what you’re seeing with NetBSD and Arm support, consider supporting the NetBSD Foundation.
As many of the regular Arm Server community members already know, there is a huge discrepancy between the small, cheap, fun, “toys” known as Single Board Computers, and the enterprise-grade, standards-compliant Arm Servers that are meant to be racked and deployed in datacenters. And in the middle exists…nothing much. There have been some attempts over the years such as the SoftIron Overdrive 1000, the 96Boards Developer Box, and few other specialty (read: expensive) adaptations of server parts, but for the most part, the relatively cheap, standards-compliant Arm developer machine landscape has been barren.
As a result of this missing puzzle piece, Arm Server adoption has lagged behind industry and Arm’s own projections. Rewinding 5 years, in 2015 Arm predicted they would have a 20% market share in the Datacenter. Now here we are in 2020, and that clearly hasn’t come to fruition.
If the middle-ground is going to remain mostly empty, then we as a community need to focus on a different task: Showing the SBC makers how to build a standards-compliant system, and steer them towards making Arm boards that “just work” with any OS, boot in a fashion similar to what developers already know and understand (UEFI / ACPI), and act like an x86 machine. It shouldn’t take an Arm Engineer to boot an Arm board.
Then, once the SBC makers are nudged in this direction, two things can occur. First, more developers can begin the process of building software that is Arm compatible and a first class citizen on Arm Servers. Second, once individual developers get accustomed to using Arm SBC’s for coding, they’ll want something a bit more powerful…creating more demand for that mid-tier Arm “PC” class device.
And coming full circle, that means, it’s time to make the Raspberry Pi 4 ServerReady, to show people it can be done, and jumpstart this process.
Pete Batard, who has single-handedly upstreamed the original RaspberryPiPkg to TianoCore edk2-platforms, has an excellent blog post up for a while now, detailing how easy it is to install vanilla Debian on the Raspberry Pi 3B/3B+ with UEFI.
The Pi 3B/3B+ is still a great platform to explore UEFI functionality, and it’s EBBR-compliant UEFI boot for Linux (that is, with device tree) is still way better than messing with config files. Plus you can do PXE and iSCSI. Isn’t that awesome? Or port Doom to it :-).
Courtesy of Pete Batard, a new release is out. Again, this is very early in development, so the usual caveats apply – not all OSes will behave as expected and there’s not much yet in terms of step-by-step instructions.
What’s inside this release?
- Add Genet MAC address population [tianocore/edk2-platforms@d1a3240, tianocore/edk2-platforms@885a686, tianocore/edk2-platforms@3f0d14b]
- Add Genet ACPI bindings [tianocore/edk2-platforms@cc7a0c6]
- Fix SDHC ACPI interrupts [tianocore/edk2-platforms@314c45b]
- Fix Serial Number population [tianocore/edk2-platforms@9369b01]
- Improve VideoCore firmware version reporting [tianocore/edk2-platforms@180c613]
- Automatically switch between PL011 and miniUART according to the overlay in config.txt [tianocore/edk2-platforms@bfe3483, tianocore/edk2-platforms@41c1d9b]
“GENET” refers to the on-board Gigabit Ethernet controller on the Raspberry Pi 4. The ACPI bindings for GENET will allow networking use under Linux. The upstream Linux enablement is still a work in progress, so see the relevant bcmgenet patches. For 5.x see https://lkml.kernel.org/lkml/?q=bcmgenet and for 4.19 see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950578.
rpi4-uefi.dev is now up as a basic WordPress blog! This is a landing page for the 64-bit Raspberry Pi 4B UEFI firmware effort by the shadowy PFTF collective. It’s anticipated that these pages will be a good way to keep track of progress, and eventually provide instructions for use by the general public.
The goal for the developed firmware is to make the Pi compatible with the heavily standardized 64-bit Arm servers from a firmware/OS perspective, aiming for SBBR compliance. This is 64-bit (AArch64) firmware for running 64-bit operating systems. In-depth description of the project’s goals and perspectives will be published soon in the About section.
Our main gathering point is the #rpi4-uefi-dev channel on the fine Developer-Ecosystem Discord server. This is a developer-oriented channel. Visitors are welcome and contributors are highly encouraged 😁.
In December 2019 I attended Packet’s IFX 2019 conference as part of VMware’s presence in the Hardware Petting Zoo area. Among many other interesting things, I had demonstrated a Raspberry Pi 4B running our in-development VMware ESXi hypervisor, booted of course with this very same ServerReady/SBBR UEFI firmware 😊.
I had also gave a presentation on the Pi 4 UEFI project, explaining not only why Edge Compute should be standards compliant and a homogeneous ecosystem, but be ServerReady compliant. Of course I primarily gave an update on the state of the Pi 4 support. Here is an awful video recording as well 🤣.