ESP support. This means that you can now place your Pi 4 boot files into a EFI System Partition, and have the UEFI firmware launch as expected, regardless of whether you are using an MBR or GPT ESP, or even of the ESP resides on a USB or SD. Of course, this feature doesn’t really come from the UEFI firmware itself, that has always supported it, but from the firmware archive containing an updated start4.elf from the Raspberry Pi Foundation, where ESP boot support has finally been added.
Note that booting from USB or from ESP does require a recent-enough version of the Pi EEPROM.
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.
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).