Platform firmware distribution for ARM-based ChromeOS devices

View the Project on GitHub

21 June 2024

News #4: Definitely Maybe

by Alper Nebi Yasak

This is Anchorboot News #4, a semi-regular update post about the state of the project. I haven’t been able to work for a long time, but am recovering well.

QEMU Display Drivers

I have tried to clean up and submit relevant patches from my VGA Text Mode post. The port I/O functions that I needed to access PCI I/O space (to use -device VGA on non-x86 virtual machines) have been merged after some discussion.

After that, I built another test build of coreboot and U-Boot to check if I can use these devices as a backend for the “corebootfb” device in U-Boot. While experimenting I saw that U-Boot re-assigned the PCI memory regions for the devices to a different address, which invalidates the framebuffer addresses we get from coreboot.

So, I have decided to also write a driver for the QEMU ramfb device, which does not rely on PCI but instead uses the QEMU-specific firmware configuration device.

RAM Detection on QEMU

Previously, I had managed to write an ad-hoc parser to get memory information from the flat device-tree binary to help fix RAM detection on QEMU boards. In the meantime, other people have written more FDT helper functions in coreboot. I have refactored my patch to build on top of theirs, and it is merged now. A followup that uses it on RISC-V QEMU VMs has been merged, but the ARM64 counterpart isn’t.

U-Boot for QEMU ARM64

So far I have been using a psuedo-coreboot build of U-Boot based on the QEMU code, and running it on QEMU to test. Currently, I am working on removing the QEMU-specific parts in it, and porting existing coreboot code to work on it. It’s not done yet, but I could get a few things like the memory map and corebootfb working. Here’s a teaser:

U-Boot running on a corebootfb display

tags: news