Hot on the heels of v1.1, Pete has a new release for you.
What’s inside this release?
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.
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?
“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 🤣.