News #0: Silent Alarm

This is Anchorboot News #0, the first of semi-regular update posts about the state of the project. It’s technically an announcement post since there hasn’t been a formal one yet – hence the number zero.

I’ve been supposed to be focusing on this project for about two months now… Most of that time went to loosely-related work instead. Oh well. Nevertheless, there is some progress on the project.

Website

The Anchorboot.org website is up and running now, hastily prepared and lazily hosted on GitHub Pages. You are probably reading this post there now. It can and will be improved.

Logo

I have designed a logo. It’s an anchor with a power button symbol instead of the ring. Smooth lines, colored white to contrast with a black screen during boot, placed over a steelblue disk with shadow to give three dimensional effect. Replacing the background disk with a hazard pattern gives a nice version for development builds.

U-Boot

In general, I ended up working on improvements and fixes that would’ve needed to be done for the project eventually anyway:

The default EFI variable buffer size was too small, which was being exhausted as U-Boot was trying to run Debian’s ARM64 secure-boot shim. Increased the default size, and found and fixed another size calculation bug along with it.

I have tried to improve support for RK3288-based Chromebooks in U-Boot by enabling SPI ROM images, Winbond SPI flash support, and various other options that are enabled in some boards but not all of them. I’ve also attempted a port to the “mighty” board I have, but that is still untested.

Inspired by another series extending Bochs emulated display support to non-x86 U-Boot builds and enabling it for RISC-V QEMU virtual machines, I have enabled Bochs emulated display support for ARM QEMU virtual machines to have an easier time testing video-related work on U-Boot with QEMU.

Furthermore, I have updated and extended an existing video damage tracking series that make text consoles significantly faster, and likewise extended a QEMU ramfb support series which enables another way to have an emulated display to test U-Boot with. These need further work before being merged upstream.

Coreboot

I have tried to investigate why the “kevin” Chromebook wasn’t properly powering off with the coreboot and U-Boot combination. Disabling ARM TrustedFirmware-A’s coreboot integration in the coreboot build happens to work around it, so I’m thinking it’s an issue due to the lack of integration between U-Boot and coreboot.

Inspired by the Bochs display support series for U-Boot, I managed to get it working on coreboot builds for ARM QEMU virtual machines. But it needs cleaning up before it can be sent upstream.

Coreboot with U-Boot

I had already implemented a proof-of-concept of using U-Boot as a coreboot payload for the “kevin” board, and I worked on reimplementing that on QEMU. I managed to copy enough from the QEMU-support in U-Boot to new coreboot-arm and coreboot-arm64 build targets that can be launched from coreboot as payloads and happen to work on QEMU.

Still, this is with no integration between the two at all, and full of QEMU-specific code and assumptions that needs to be undone to run on actual coreboot-supporting hardware.

Hardware

I have been buying Chromebooks to work on as part of this project:

• Samsung Chromebook XE303C12 (“snow”)
• Samsung Chromebook 2 11” XE503C12 (“pit”)
• HP Chromebook 14 G3 (“blaze”)
• Medion Chromebook S2015 (“mighty”)
• Lenovo 300e Chromebook 2nd Gen MTK (“hana”)
• Acer Chromebook 314 CB314-2H (“cozmo”)

Those are in addition to a Samsung Chromebook Plus (“kevin”) that I’ve been working on for years. That feels like a broad enough collection for now.

I have also acquired some better hardware to flash SOIC8 chips, the connectors for Servo debug headers on some of those devices, and had a simpler version of a ChromeOS debug cable made.

Other than that, I’ve been talking to Googlers about getting proper debug hardware from them, and it looks like that will arrive in just a few days.