Founder of the community UEFI firmware project for Raspberry Pi and tech lead for #esxionarm in VMware CPBU, conducting advanced development of vSphere hypervisor technology for the 64-bit Arm architecture. Andrei works in a wide range of directions pertaining to Arm enablement and strategy, ranging from low-level hypervisor design and implementation, to product definition and partner and ecosystem engagement.
This is a minor release, but the asset tag functionality is pretty cool. This let’s you set a custom string to be reported via SMBIOS to the booted OS, which you could use for inventory or provisioning requirements.
The tag can also be set programmatically or via the UEFI Shell command line.
The 8GiB variant changes the board layout a bit, dropping the SPI EEPROM containing the xHCI (USB3 controller) microcode, which required the relevant code to be added to UEFI to load it during boot. The good news is that the same approach is harmless on the other (1GiB, 2GiB and 4GiB Pies).
Like the 4GiB variant, UEFI will default to booting with only 3GiB to deal with OSes that can’t process the ACPI-reported DMA limits.
Of course, without the 3GiB limit, you get the full 8GiB (minus the gpu_mem amount anyway).
Booting to UEFI Shell should be a bit less awkward now, now that it is permanent to the Boot Manager menu.
A recurring topic is Windows drivers for the Raspberry Pi 3 and 4 series.
MCCI DesignWare USB2 driver
This is for the front USB ports on Pi 3 and only the Type-C port on the Pi 4.
MCCI Corporation has made their TrueTask USB host stack available to the Raspberry Pi WoA community for non-commercial, evaluation purposes. MCCI did the original work for the 32-bit Windows IoT Core. It is available courtesy of Terrill Moore, CEO of MCCI, who graciously spent time in early 2019 to get it building and validated with the 64-bit Pi 3 UEFI.
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).
This doc is for the SoC in the Pi 4B. I personally haven’t read through it yet, but glancing at the table of contents I see there are many goodies here. Hooray for not having to look at Pi 4B DTS (device tree) sources as documentation! 😇