v1.5 release available

Posted on by Andrei Warkentin

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.

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.