Porting the ThinkPad x61 to coreboot | Arthur's blogArthur's blog

Emacs

Theme<br>Porting the ThinkPad x61 to coreboot<br>2026-06-0411 min read (2292 words)coreboot<br>thinkpad<br>firmware<br>reverse-engineering<br>llm

Table of Contents

An introduction to my IBM/Lenovo ThinkPad addiction<br>Over 10 years ago I got my first ThinkPad x60. I got interested in free software by reading the about GNU page in the GNU Emacs editor.<br>Free software back then and certainly now is quite usable, typically without much closed-source software.<br>One area where free software is lacking is firmware and this led me to want to try libreboot on that ThinkPad x60.<br>A few years forward and I became a coreboot contributor and eventually got a job at 9elements because of this.<br>In that journey I amassed quite a hefty ThinkPad collection.<br>I wanted something that was speedier and 64-bit so I got a ThinkPad x200 which I ran for a few years.<br>I got a ThinkPad x220 a few years later, as the Sandy Bridge chip is substantially faster than the Core 2 Duo inside the x200.<br>To port or improve existing coreboot ports I received a ThinkPad x201 and R500.<br>A few years back someone figured out a way to get past Boot Guard (deguard<br>) on Intel Skylake/Kabylake, so I got myself a ThinkPad t480 and I'm very happy with it.<br>Does anyone know a good rehab center for this kind of addiction?Along that ThinkPad hoarding journey one generation was missing: the ThinkPad x61. It has a GM965 northbridge and an ICH8 southbridge.<br>The northbridge is somewhat similar to GM45 (supported on ThinkPad x200) except being DDR2-only and the ICH8 southbridge is somewhat similar to the already supported ICH9.<br>There are no leaked docs out there on this platform so reverse engineering would be the only way.<br>Some people attempted this in the past using tools like SerialICE which runs the firmware in QEMU and forwards IO and MMIO to the actual hardware, but they didn't manage to produce a working coreboot port.<br>So my dream was to eventually port it.

AI assisted reverse engineering<br>In March I was experimenting with using LLM technology more in my workflow.<br>For quickly prototyping ideas it works rather well, but I was wondering how well it would fare with reverse engineering.<br>Note that I was using Anthropic's Claude Opus 4.6 which was the state of the art at the time.<br>It turns out they are a great tool at speeding up the process.<br>Normally reverse engineering requires quite some dedication.<br>3-6 months for porting this whole platform (gm965/ich8 for x61) is not out of the question.<br>That's time I for sure don't have for this purpose.<br>TL;DR I tried it out on a downloaded vendor BIOS, the results looked great.<br>After that I bought the device and got it working. The following explains the process of how that went.<br>Traditional dumping of information from the vendor BIOS<br>Before trying to understand what the vendor firmware does I first wanted to dump as much information as possible from a working system.<br>Known good values are extremely valuable when something does not work as intended: when DRAM does not train or USB suddenly stops working it is very useful to have a reference to compare against.<br>It also gives good hints for parts of the platform, like the EC settings, ACPI tables, PCI configuration, GPIO pinout and the HDA verb tables.<br>For that I used the usual coreboot tools.<br>inteltool gives a good overview of PCI configuration space as well as pretty much all northbridge and southbridge registers.<br>lspci is still useful as a quick sanity check of how Linux sees the machine.<br>For ACPI I dumped the tables with acpidump, split them with acpixtract and decompiled them with iasl -d.<br>That gives a readable view of how the vendor firmware describes devices, power management and EC methods to the OS.<br>ectool was useful to look at EC RAM and behaviour, since ThinkPads tend to hide a lot of board-specific details there.<br>I also saved the CPU information and the HDA codec information, because those are easy to lose track of while staring at firmware code.

Setting up the AI agent tools and some firmware findings<br>The x61 uses a Phoenix BIOS, so the first step was to split the image into separate modules with bios_extract.<br>After that I gave the AI agent a few tools it could use directly.<br>The most useful one was ghidra-cli, together with its SKILL.md, so it could ask Ghidra questions without me driving the GUI all the time.<br>I also used a radare2 skill, because radare2 is quite pleasant for the older 16 bit real mode parts of the firmware.<br>This distinction mattered because most of the firmware is 16 bit real mode code, but the raminit itself is a PE32 module that looks like it came from Intel MRC, the Memory Reference Code.<br>For that part ghidra-cli worked much better, because the original code was probably C and the decompiler output was actually useful.<br>For the surrounding glue code radare2 was often what the AI agent had better success with.<br>One thing that surprised me was finding at least 3 versions of raminit in the...