So, the Pi 3A+ is finally documented as being supported. It involved no code changes and is the cheapest Pi you can run the 64-bit UEFI firmware on.
But there’s more – the work to automatically support booting via PL011 and miniUART serial ports, done by Pete Batard on the UEFI side and Andre Przywara for TF-A, finally means we can boot on boards where PL011 is used to expose the serial port. The Pi 2B (v1.2) is one such board – the slowest member of the 64-bit UEFI for Pi family. It’s basically a Pi 3 without WiFi, BT and worse heat dissipation, so it is clocked down.
And after fixing a small eMMC support regression, we even support the compute module variant of the Pi 3. To be fair, I didn’t test the CM3L (the one without eMMC), but it should be working. Let me know if it doesn’t. Also, CM3+ (which just has better heat dissipation) should work but is not validated.
And in case you’re a fan of the amazing cluster carrier board from our friends over at miniNodes…
Those last two fixed regressions seen on Windows 10 after some ACPI restructuring to properly describe DMA constraints on VideoCore-attached devices. The regressions affected Pi 3, but the fix should equally apply to Pi 4.
TF-A is the Arm secure firmware, providing services such as platform power off/reset and secondary CPU manipulation. The improvements to UART detection mean that TF-A firmware, just like UEFI, will honor config.txt selection of the UART (e.g. via overlay, although it’s really done by the VPU firmware). This is more developer oriented, and means not losing logging/initialization messages. Unrelated to Pi 4 itself, it paves the way for proper (transparent) Pi 3 UEFI support for Compute Module variants and that 64-bit variant of the Pi 2 (rev 1.2).
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.
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.
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.
This release mostly improves on the logic added to v1.4 release for switching between 3GB/4GB modes on the 4GB Pi 4.
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.
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:
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.