News #1: Signs of Life

This is Anchorboot News #1, a semi-regular update post about the state of the project. Not as much progress as I would’ve liked to get done, in part because I was busy with DebConf 23 for most of September. Then I had to do some urgent maintenance on my workstation, and fell into a bout of low-energy. Anyway, here’s the interesting new bits related to the project:

Hardware

In the last news post I mentioned that I’d been talking to Googlers about getting proper debug hardware, and that package indeed arrived a few days after then. So now I have a Servo Micro for most of my boards that don’t support closed-case debugging (“CCD”), a SuzyQable for those that support CCD, and a Servo v4.1 for even more complex testing and debugging over CCD or Servo Micro.

Out of the boards I have, the following are those which don’t support CCD, but use a Servo header for the Servo Micro to connect to:

• HP Chromebook 14 G3 (“blaze”)
• Medion Chromebook S2015 (“mighty”)
• Lenovo 300e Chromebook 2nd Gen MTK (“hana”)
• Samsung Chromebook Plus (“kevin”)

They didn’t actually have the header, just had the pads to solder one to. I had already bought the headers, so I took them to an electronics repair shop and got them soldered on the boards.

The Samsung Chromebook XE303C12 (“snow”) and Samsung Chromebook 2 11” XE503C12 (“pit”) have different connectors. I don’t have the proper debug hardware for those, so will need to come up with a less capable ad-hoc solution. The Acer Chromebook 314 CB314-2H (“cozmo”) does have a Servo header, but it already supports CCD so I saw no need to get one soldered.

Debugging

I started exploring how to work these Servo debug hardware. As a first step I set up a ChromiumOS development chroot to be able to use the corresponding software tools, and tried to work on my “kevin” board since I actually have something other than the stock firmware that somewhat works as firmware replacement.

Most importantly, I have been interested in accessing the serial console since it’s the best way of knowing what problems may come up in early firmware stages, and writing the system firmware with less effort and risk. I have managed to learn that much and other simple things like powering on, resetting, and shutting down the board.

U-Boot

I worked a bit more on the video damage tracking and QEMU ramfb support series to address the upstream reviews, but there are still things I need to figure out before I can send what I have as new versions. Especially about how partial display updates would interact with how EFI wants to use the frame buffer, and how U-Boot would modify the device-tree QEMU provides at runtime to make itself use ramfb drivers.

Other than those, I noticed the display stopped working on the “kevin” board on v2023.10, and tracked it down to reference counting support for regulators. Luckily, other people had already sent fixes for enabling video-related regulators, which were just recently merged upstream.

Coreboot

I’m still working on adding display support for coreboot for ARM QEMU virtual machines in a way that doesn’t break x86 cases. Coreboot does seems to do more stuff for x86 than U-Boot, like support for Cirrus display device and VGA text mode. Those might not be applicable to ARM systems and I think I’ll try to split them out as x86-only parts while keeping the Bochs display driver arch-independent.

Libreboot

In case you haven’t noticed: I also contribute to Libreboot, which happens to include my initial proof-of-concept for this project, namely using U-Boot as a coreboot payload on ARM systems. I have updated their U-Boot sources to v2023.10, rebased their patches, added fixes, improved board configurations.