News #2: Just for a Day

This is Anchorboot News #2, a semi-regular update post about the state of the project. I’ve been continuing my bad habit of multi-tasking with other Chromebook work like adding support for MT8173 and MT8183 SoCs to Debian, improving ALSA UCM support in PulseAudio and PipeWire, and contributing to postmarketOS release testing.

In the scope of the project, I’ve mostly worked on coreboot this time. Continued trying to get graphics working on QEMU in a general way and working out issues with QEMU-related coreboot code. I still need to clean up some of the patches before I’d feel comfortable posting them, but that’s almost done.

Here’s the bits and pieces relevant to the project:

QEMU Bochs Display

I’ve managed to get the Bochs display to work on other architectures (ARMv7, ARM64 and RISC-V) in a more generic way, without breaking it on x86. However, testing on QEMU virtual machines for other architectures revealed some issues.

One problem is, the “qemu-armv7” mainboard used by coreboot is intended for the Arm Versatile Express (vexpress-a9) platform, instead of the “virt” generic virtual platform that I’m used to running QEMU with. The former doesn’t support PCI (among other things) which is necessary to add a Bochs display device, but at least it has a PL111 display instead that works with coreboot.

ARMv7 “virt” mainboard

I ended up creating a new mainboard for the ARMv7 “virt” platform, mostly based on the existing “qemu-aarch64” one. Comparing the latter with the upstream “qemu-armv7”. This allows a lot more peripherals that will mostly be useful for the OS that would eventually run on the VM, but the relevant thing here is that it enables testing the Bochs driver on ARMv7. However it also revealed another issue with detecting how much RAM the virtual machine has.

This is mostly complete as a standalone mainboard, but I’m thinking it might be possible and better to integrate it as a “variant” of the “qemu-armv7” mainboard, which would reduce code duplication.

RAM Detection on QEMU

To detect how much RAM a QEMU virtual machine has, coreboot tries accessing potentially out-of-RAM regions and checks if the data it wrote is discarded. QEMU 2.11 started raising data aborts instead of silently discarding data, which breaks this detection mechanism.

This doesn’t happen on the vexpress-a9 board, because QEMU falls back to the old behaviour as a per-board quirk. On the coreboot side, the issue is worked around on ARM64 with exception handlers, and reported with a similar fix on RISC-V which didn’t get merged yet. I tried to replicate the exception handler mechanism on my ARMv7 virt port, but ended up with corruption that I don’t know how to resolve.

I managed to get it done via QEMU’s Firmware Configuration (fw_cfg) device, but it’s a hack. Arm is trying to standardize ARM64 firmware space, and there’s a QEMU “sbsa-ref” platform intended for developing specification-compliant firmware which we might want to switch to. That doesn’t have the fw_cfg device as it’s meant to look like real hardware, but it provides memory details over Devicetree. So probably the best answer here is to parse that to get RAM details.

QEMU Firmware Configuration Driver

QEMU can report various details via a Firmware Configuration device that we can access from coreboot, and there is already an x86-specific driver implemented for it as part of the “qemu-i440fx” mainboard. One of the things we can access on this device is the RAM size, so I decided to try to get it working on ARMv7 to help fix the issue above.

I trimmed the driver down to its basics on my ARMv7 “virt” port, and managed to get it working enough to read data from QEMU. It is supposed to have the RAM size as a ram_size configuration file, but this is missing on ARM platforms, as seen by running a QEMU ARMv7 VM with an additional --trace "fw_cfg*" argument.

While trying to figure that out, I noticed an etc/smbios/smbios-tables in the list of files the device has. SMBIOS has the necessary memory information, so I wrote a makeshift parser to extract what we need out of that, solving the RAM issue. But I don’t think that is the right way.

I need to work on merging my ARMv7-specific modifications into the x86-board-specific driver and making it usable from others as well.

PCIe Support on QEMU RISC-V

While comparing the “qemu-aarch64” mainboard to the “qemu-armv7” one, I figured out what’s necessary for PCIe support (through generic ECAM mechanisms) that we need for a Bochs display device. Knowing it’s applicable to RISC-V as well, I got it working there too.

Bootsplash Troubles

Coreboot upstream also has replaced their JPEG decoder with Wuffs’, which causes a minor hiccup for running QEMU with our bootsplash. It needs quite a bit of space on the heap, and the defaults are too small. I’ll try to figure out a nice value to increase it to when a boot splash is enabled, I don’t know if it depends on the image size or content.