v1.7 – yes, only a day after v1.6.

I hadn’t even finished writing up the 1.6 related artifacts when Pete pushed the button on the new release. Huge thanks both to Pete for getting this out there so soon and to Ard Biesheuvel for reviewing and approving the edk2-platforms fixes.

https://github.com/pftf/RPi4/releases/tag/v1.7

What’s inside this release?

The ACPI fixes will mean improved hardware support in OSes, although today that mostly means improved NetBSD support. We definitely need some volunteers to help with enabling Pi 4 support with ACPI in upstream Linux – see the issue tracker.

Big shout-out to Jeremy Linton for the PPTT implementation (Processor Properties Topology Table) – a new ACPI 6.3 table describing the relation between CPUs and caches. Yes, that’s not a typo – our PPTT is the 2nd revision variant introduced in ACPI 6.3, whereas PPTT was first introduced in 6.2.

Note: the matching Pi 3 UEFI release (v1.19) combines the fixes for the Pi 4 v1.6 and v1.7 releases.

As always, read the release notes and usual caveats.

v1.6 out

A few more goodies…

https://github.com/pftf/RPi4/releases/tag/v1.6

What’s inside this release?

Biggest change here is that your Pi will now boot at the default (Pi Foundation-recommended) frequency, instead of the 600MHz minimum. One less configuration option to change on every upgrade!

IMPORTANT: HTTP(S) boot, like PXE and iSCSI, will not currently work with the internal network card, because the GENET driver has not been upstreamed yet. This means you need a supported USB interface (Ax88772b) to use this feature.

As always, read the release notes and usual caveats.

More GENET work

Our UEFI firmware already supports certain USB-based network adapters for network booting (or other purposes), but that requires an additional adapter, which becomes even more awkward if you want to use a PoE HAT. NetBSD Arm platform guru Jared McNeill has been working on something, that Pi 4 UEFI users are going to find pretty cool. Dongle-less PXE and iSCSI is coming to a Pi 4 near you, because we’re getting native support for GENET networking soon! 😍🔥

This is being implemented as a Simple Network Protocol driver, so it will be usable by any UEFI driver or application.

v1.5 release available

A quick follow-up to v1.4, this release brings some important fixes.

Don’t stop me now (’cause I’m having a good time)
Don’t stop me now (yes, I’m havin’ a good time)
I don’t want to stop at all

Queen – Jazz

https://github.com/pftf/RPi4/releases/tag/v1.5

What’s inside this release?

This release mostly improves on the logic added to v1.4 release for switching between 3GB/4GB modes on the 4GB Pi 4.

Now, when you have 3GiB mode selected (which is the default), you will see 3GiB being reflected in the UEFI setup screen.

The fix for external .dtb is worth diving into. Many of our readers will know, that Raspberries traditionally boot operating systems with Device Tree, instead of ACPI. A dated overview can be found on the official Pi site. Long story short, if you want to boot an 64-bit Linux, NetBSD or FreeBSD today on the Pi with full I/O support, you still need the Device Tree that the VPU firmware prepares based on your config.txt settings (dtparams, overlays, etc).

The Pi 4 support for Device Tree is exactly like the Pi 3 support. At the time, UEFI relied on the Device Tree being placed in RAM after the UEFI image itself, basically overlaying itself on a section of the UEFI image. Recently, new VideoCore firmware broke this approach (which I really shouldn’t have come up with in the first place!) by switching the load ordering – now the Device Tree was loaded before the UEFI image, and since the two images overlapped, the Device Tree blob was getting overwritten. You can read more about it here and here. Anyway, it’s fixed now. The same fix needs to be made to the Pi 3 build. That’s still TBD.

If you want to boot an OS using Device Tree, don’t forget to enable it. By default the Pi 4 will boot in ACPI mode.

Be mindful that the fix involved changing the load address for the Device Tree in a way that wouldn’t overlap the UEFI image. The new values are:

  • device_tree_address=0x1f0000
  • device_tree_end=0x200000

While looking at the above regression, we were also able to regain 2MiB of memory, as the Trusted Firmware footprint for Pi 4 is much smaller than on the Pi 3.

As always, read the release notes and usual caveats.

Momentum is Building

In the past few days, there has been a lot of progress and a lot of publicity for this project, which shows the ecosystem’s desire and demand for lowering the barrier to entry on booting Arm SBC’s, in this case the Raspberry Pi 4 of course.

Tweets, LinkedIn posts, CNX Software replies, and Hackster comments all tell the same story: Allowing users to power on a single board computer, install the operating system of their choice using “normal” boot media, and proceed through an install process just like they are used to a typical PC is a missing piece in the Arm ecosystem. Without the ability for “regular” users to start to explore Arm hardware and get up and running in a way they are used to, Arm Servers will remain a niche product.

So, join us on the Discord Server, help contribute patches and code if you can, or simply spread awareness of the project on your Social Media channels!

v1.4 release already out

Pete’s on a roll! Some significant improvements have landed in the latest and greatest release.

https://github.com/pftf/RPi4/releases/tag/v1.4

What’s inside this release?

Assuming you have a 4GiB Pi, you can now boot with with the entire 4GiB available if you run NetBSD-current (generic 64-bit image), which already supports the ACPI interfaces required to make the Pi USB3 controller work with the full 4GiB RAM. Those living on the edge can try this Linux patch.

Note: upstreaming the Linux patch would be a great way to help this project.

Additionally, there’s been some improvements to the setup option layout:

Reorder forms in the order they are most likely to be queried.
Rename Chipset Configuration, making CPU settings more prominent.
New Advanced Configuration. 3GB limit setting is grayed out on 1GB/2GB boards.
Grouping all SD/MMC settings together.

As always, read the release notes and usual caveats.

v1.3 release

This is a minor follow-up to v1.2 for Pi 4, intended to do some soak testing on the ongoing ACPI clean-up and factorization changes.

https://github.com/pftf/RPi4/releases/tag/v1.3

What’s inside this release?

As always, read the release notes and usual caveats.

V1.2 RELEASE IS OUT!

Hot on the heels of v1.1, Pete has a new release for you.

https://github.com/pftf/RPi4/releases/tag/v1.2

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.

BSD-licensed GENET code!

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.

Crossing the Chasm

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.