Logbook

16K page size compatibility for Pi5 software

I have a Pi5 on order (since October 3, 2023). I am patient about waiting for it to arrive.

In the meantime I have been reading about what to expect, and the most interesting discovery from the software side is that the hardware now supports 16K page sizes and defaults to that. You can back down to a 4K page size by setting a line in the kernel config.

https://www.raspberrypi.com/documentation/computers/config_txt.html#kernel

The consequence of this new page size should be improved performance on a number of memory-intensive operations, roughly speaking because the operating system can grab bigger chunks of memory in one go. Performance will depend on your use case, but I have seen reports of 15% improvements on kernel build times for 16K vs 4K pages.

With the change comes a challenge, of software that has baked in dependencies either on the 4K page size itself, or a naive assumption that the system you are building on has the same page size as the system you are running on.

There is a working list of Pi5 software that is not currently working with 16K pages maintained by @theofficialgman .

https://github.com/raspberrypi/bookworm-feedback/issues/107

It's derived from an earlier list from the Asahi Linux team, whose builds for Apple Silicon see a very similar set of issues.

https://github.com/AsahiLinux/docs/wiki/Broken-Software

The most common library that has issues is jemalloc, which has deeply built in assumptions and optimizations built on page size. The tracking issue for the page size bug there has perhaps a longer list of incompatibilities as packages dependent on this memory allocator discover crashes on new hardware.

https://github.com/jemalloc/jemalloc/issues/467

Fedora on Raspberry Pi 5: whole lot of patches needed

Peter Robinson has been looking at supporting Fedora on the Pi 5, and shares his early observations here in a message to the Fedora Project's "fedora-arm" mailing list of Saturday, 18 November 2023.

https://lists.fedoraproject.org/archives/list/[email protected]/message/ER5R4CSDCZENQSVSPULNGSAFK63SQZDK/

So the long story short is ATM nothing will work with vanilla upstream kernel yet unless you could serial console and display. I'm hoping that various kernel people will start to poke around and get pieces upstream, the biggest individual piece of work is definitely the PCIe end point to AXI bridge driver piece as without that nothing on the RP1 chip will work.

Kernel subsystems that will need a fair bit of work include everything that will touch the new RP1 peripheral handling chip. Peter again:

The vast majority of everything else hangs of the RP1 chip which is a uses a weird PCIe-EP to AXI bus bridge thing which AFAICT needs a MFD driver to be upstreamed to unlock the fairly generic IP that provides the rest.

Fortunately for us mortals who are happy enough running the official supported distribution, there is a Raspberry Pi OS based on Debian Bookworm. There are still changes there - Wayland, PipeWire and NetworkManager are new components - but the Pi folks have done the necessary kernel-mucking in their distro to support the new hardware.

https://www.raspberrypi.com/news/bookworm-the-new-version-of-raspberry-pi-os/

Small Arm-based single-board computers have a very long track record of not booting a vanilla upstream kernel, in part due to weird custom boot loaders, in part due to the slow process of upstreaming component support. The Pi has been easier to use than most due to a huge amount of users and a steady base of support for old models, but (in general) you can't treat any of these little boards like it was an off-the-shelf server and plug in and boot a standard distribution off of USB.

(Yes, I have a Pi 5 on order, it's going to run the official OS. I am not your kernel hacker.)