Before trying to understand what the vendor firmware does I first wanted to dump as much information as possible from a working system. 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. 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.

For that I used the usual coreboot tools. inteltool gives a good overview of PCI configuration space as well as pretty much all northbridge and southbridge registers. lspci is still useful as a quick sanity check of how Linux sees the machine. For ACPI I dumped the tables with acpidump, split them with acpixtract and decompiled them with iasl -d. That gives a readable view of how the vendor firmware describes devices, power management and EC methods to the OS. ectool was useful to look at EC RAM and behaviour, since ThinkPads tend to hide a lot of board-specific details there. I also saved the CPU information and the HDA codec information, because those are easy to lose track of while staring at firmware code.

The x61 uses a Phoenix BIOS, so the first step was to split the image into separate modules with bios_extract. After that I gave the AI agent a few tools it could use directly. 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. I also used a radare2 skill, because radare2 is quite pleasant for the older 16 bit real mode parts of the firmware.

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. For that part ghidra-cli worked much better, because the original code was probably C and the decompiler output was actually useful. For the surrounding glue code radare2 was often what the AI agent had better success with.

One thing that surprised me was finding at least 3 versions of raminit in the image. My guess is that this is some kind of A/B layout with a read-only recovery copy. The RO copy skips a lot of the normal raminit flow and is probably only intended to recover the machine far enough to reflash the rest of the BIOS. This matches documented Lenovo ThinkPad behaviour where the top 64K of the flash is write-protected for recovery purposes.

The previous section was a complete lie.

The model needed a ton of hand-holding. I have rather deep knowledge in similar platforms and have intimate knowledge of all of the details that are required to boot both the next (x200) as well as the previous gen (x60). This was crucial for this endeavor to have succeeded. I wrote down on paper the over 20 items where I had to steer the model based on prior work for the purpose of this blog post. Good intentions only get you halfway there as I lost the paper… So here is my recollection of a subset of what was needed:

• The ThinkPad x61 has a GPIO mux for SMBUS on GPIO42, so only SPD or EEPROM is visible. When the OS is booted only the EEPROM is visible, not the SPD.
• The memory controller supports DDR2 533MT/s and 666MT/s, not 666MT/s and 800MT/s, and decoding the hardware registers accordingly is important
• The GMCH FSB frequency needs to be read from a MCHBAR register, not from some PCI register
• A lot of wrongly sized register read/writes: writing a 32bit value to a 16bit register might trash the upper 16bit that needed to remain untouched
• CAS semantics of how we encode it typically in coreboot vs how MRC does it, the model got confused about this a lot
• The multiple raminits in firmware also confused the model a lot
• … things that will only be known by garbage collection people assuming they read whatever they collect (unlikely)

Just like regular human reverse engineering, doing thing like traces and dumps of values and comparing them with was useful in tracking down a lot of the issues. Here the prior work by Lubomir Rintel who traced the raminit with SerialICE also turned to be useful (somehow getting SerialICE to work is not easy), here is an example of raminit trace.

Needless to say this didn't boot on first try. My setup to be able to test and flash was the following: the board has a docking station with an RS232 UART connector that the ThinkPad x60 is also compatible with. The code to get that working is identical. It's the white connector on the picture.

To flash it I would take the board out of the docking station and attach a clip to the flash that is on the bottom of the board. Note that the chip is SOIC8 not SOIC16 like the clip would suggest (the larger pins conveniently work for smaller chips). This board also features Intel descriptor, GBE, and ME regions. I didn't touch this for the time being. Use flashprog with the following flags to do that.

flashprog -p ch341a_spi --ifd -i bios -w build/coreboot.rom

Note that like ich9 and ich10 it should be possible to reduce this to just the IFD + GBE and of course BIOS regions (so drop ME). This would result in more space being available for coreboot. disable ME firmware on ich9 laptops should roughly apply to X61.

Jokes aside, the goal of this was to test the reverse engineering capabilities of LLMs. I actually first downloaded the vendor firmware and only later bought the device because I was so impressed by the results that I had to try if it worked. The result is that it turns months of hard reverse engineering work into something that can be done in a few weeks. Note that this effort was done in a naive and inefficient way. For instance pointing the agent to existing code for register semantics as well as providing it with datasheets would have improved the quality dramatically and made the review process much smoother.

Now the real upshot here is that reverse engineering firmware which was previously a hard and time-consuming task becomes feasible. One area that I can think where this would be interesting is Intel FSP. No one likes it… Before it was too much effort to reverse engineer, with not enough positive upsides to justify the effort. Now that is no longer the case. FSP is 32bit PE code which ghidra is good at understanding and there are even plugins for UEFI FD images. Sure, USA citizens are not allowed to reverse engineer but EU citizens are explicitly allowed by law to do this. IANAL so take this however you like except as solid legal advice. So who knows? Maybe silicon vendors lose all incentives to do closed binary-only firmware as people will just figure it out regardless?