Flashing Coreboot with Flashrom

Hello! Welcome back to the "Hardware Surgery" module.

In our previous lessons, you've acted with the precision of a surgeon: you've assembled your tools, confirmed a stable connection to the patient, and, most critically, taken a perfect backup of the original firmware—our insurance policy. Now, with all preparations complete, we arrive at the climax of the operation. It's time to perform the transplant.

Introduction

This lesson is the point of no return. You will use flashrom to permanently overwrite the proprietary Lenovo BIOS with the custom, ME-neutralized Coreboot image you built. This is the single most critical step in taking ownership of your hardware at its most fundamental level.

We will proceed with caution, executing the flash in a deliberate sequence and understanding the verification process that confirms success. This is the practical culmination of all the theory we've covered on firmware security.

This lesson directly addresses the learning outcome: Flash the custom, neutralized Coreboot image onto the BIOS chip using 'flashrom'.

• Estimated time to complete: 60 minutes.
• Brief recap: You have a compiled coreboot.rom file from Module 3. You have created and verified multiple backups of your original 8MB and 4MB firmware chips. In the last lesson, you used flashrom to successfully test your Raspberry Pi and SOIC8 clip setup, confirming you can communicate with both chips.

---

1. Preparing the Image for Transplant (15 minutes)

Our Coreboot build process produced a single, monolithic 12MB coreboot.rom file. However, your x230's firmware is physically stored on two separate chips: a larger 8MB chip (bottom) and a smaller 4MB chip (top). Before we can flash, we must split our single file into two corresponding parts.

From your systems design background, you can think of this as de-multiplexing a single logical image into the physical storage segments it maps to. The bottom 8MB contains the Intel Firmware Descriptor (IFD), the Gigabit Ethernet (GBE) firmware, and our neutralized Management Engine (ME) region. The top 4MB contains the core of Coreboot itself and its payload (SeaBIOS).

Activity: Splitting the ROM

On the computer where you built Coreboot (not the Raspberry Pi), navigate to the coreboot/build directory where your coreboot.rom file is located. Use the dd command-line utility to perform the split.

1. Create the 8MB bottom image: This command copies the first 8 megabytes from coreboot.rom into a new file called bottom.rom.

   dd if=coreboot.rom of=bottom.rom bs=1M count=8
   

2. Create the 4MB top image: This command skips the first 8 megabytes of coreboot.rom and copies the remaining 4 megabytes into top.rom.

   dd if=coreboot.rom of=top.rom bs=1M skip=8
   

• if/of: input file / output file
• bs=1M: sets the block size to 1 Megabyte for convenience.
• count=8: copies 8 blocks.
• skip=8: skips the first 8 blocks of the input file.

This process is clearly outlined in the resource below.

Thinkpad X230 Coreboot & ME_cleaner - LUGS (Flash New Images)

3. Transfer the files: Use scp or your preferred method to copy bottom.rom and top.rom to your Raspberry Pi's home directory.

---

2. The Write Operation: flashrom -w (25 minutes)

The -w (write) flag is the most powerful option in flashrom. When you execute a write command, flashrom performs a three-stage process that is analogous to a transactional database commit:

1. Erase: The target sectors of the flash memory chip are erased. Flash memory cannot be overwritten directly; it must be erased first.
2. Write: The contents of your specified .rom file are written to the erased sectors.
3. Verify: flashrom reads the data it just wrote back from the chip and compares it, byte-for-byte, against the source file.

This final verification step is our confirmation of a successful write.

Activity: Flashing the Chips

We will now flash each chip in sequence. Make sure your x230 is still powered by the AC adapter (with the battery removed) and your Raspberry Pi is ready.

A Note on Strategy: Some guides recommend flashing the top chip first, reassembling, and testing before flashing the bottom chip. This is a sound, incremental debugging strategy. However, given that our build is standard and your setup is tested, we will follow a more efficient path: flash the bottom chip, move the clip, and immediately flash the top chip. The grand test will come in the next lesson.

Step 1: Final Pre-flight Check

Before every write operation, it's excellent practice to run a quick read-test to ensure your clip connection is still solid. This is the "Are you sure?" prompt before making an irreversible change.

Step 2: Flash the Bottom (8MB) Chip

1. Attach the SOIC8 clip to the bottom (8MB) chip, ensuring Pin 1 is correctly aligned.
2. On the Raspberry Pi, run a final connection test:

   flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=512 -c "MX25L6406E/MX25L6408E"
   

   If it exits cleanly, proceed.
3. This is the moment. Execute the write command:

   sudo flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=512 -c "MX25L6406E/MX25L6408E" -w bottom.rom
   

Step 3: Flash the Top (4MB) Chip

1. Carefully remove the clip from the bottom chip and attach it to the top (4MB) chip, again ensuring correct alignment.
2. Run the connection test for this chip:

   flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=512 -c "MX25L3206E/MX25L3208E"
   

3. Execute the final write command:

   sudo flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=512 -c "MX25L3206E/MX25L3208E" -w top.rom
   

The following resources provide the exact commands and context for this process. The video is for an x220, but the flashrom procedure is identical and provides a great visual for what to expect.

• Commands Reference: Corebooting my x230 | My awesome title1 (Flashing the images to the chips)
• Video Walkthrough: Watch the section from 24:44 to 28:59 in the video below. The presenter performs the final connection check and then executes the write command, narrating the "point of no return."

---

3. Verification and Troubleshooting (15 minutes)

During the write process, you will see flashrom report its progress: erasing the chip, writing the new data, and finally, verifying.

The message you are looking for is:
Verifying flash... VERIFIED.

If you see this for both chips, congratulations. The hardware surgery is a success.

What if it Fails?

It is not uncommon to see Verifying flash... FAILED. Do not panic. This can happen for several reasons, and your system is almost certainly recoverable.

1. Signal Integrity: The most common cause is that the read-back during the verification step was corrupted by noise (due to long wires, etc.), even if the write itself was successful.
   • First Action: Simply run the exact same write command again. Often, the second attempt will succeed.
   • Second Action: If it fails again, try lowering the speed: spispeed=256.
2. Bad Connection: The clip may have shifted slightly during the process.
   • Action: Power down the Pi, carefully reseat the clip, and try again.
3. Catastrophic Failure (Power Loss Mid-Write): This is the scenario your backups were made for. If the chip is left in a corrupted state, you can simply use the same -w command with your original backup files (backup_bottom.rom and backup_top.rom) to restore the machine to its factory state. This is your disaster recovery plan.

The presenter in the "Installing Coreboot on a Thinkpad X220" video mentions this exact FAILED scenario in a quick but important side note at 00:28:00.

---

Conclusion

You have successfully executed the most critical phase of this project. By splitting the compiled ROM and using flashrom to write it to the two physical chips, you have replaced the machine's foundational code. You've taken a system that was fundamentally opaque and controlled by its manufacturer and replaced its brain with one that is open and under your control.

Key Takeaways:

• A single 12MB coreboot.rom must be split using dd into 8MB bottom.rom and 4MB top.rom files to match the physical chips.
• The flashrom -w command executes a three-stage erase, write, and verify process.
• The Verifying flash... VERIFIED. message is the definitive confirmation of a successful flash.
• A FAILED verification is not a cause for panic and can often be resolved by retrying the flash, lowering the SPI speed, or checking the connection.
• Your original firmware backups are the ultimate safety net, allowing you to restore the system to its factory state if necessary.

Next Lesson

The surgery is complete. The patient is stable. In the next lesson, "Re-assemble the x230 hardware, ensuring all internal connectors are properly seated," we will put everything back together and prepare for the moment of truth: the first boot.