Coreboot

Coreboot is a free and opensource firmware which aims to be fast, secure and flexible replacement for UEFI. It supports multiple payloads, ranging from a BIOS implementation (SeaBIOS), to a GRUB2 install, to a complete linux kernel. This guide will show how to install coreboot with a SeaBIOS payload on supported devices, handling of userspace tools and the use of flashrom.

Supported Hardware
There are different types of architectures and supported hardware. The fully up-to-date table is available at the following link. In the table below are some well supported devices which are more or less recently released. If an older device is being used, it may be possible to remove all proprietary binary blobs. For this, use the libreboot guide.

The Basics
In general, the flash chip must be found on the board of the selected hardware. This is important, as the vendor usually locks the flash chip via soft lockdown. Guides for locating the chip will generally be on the coreboot wiki. This guide assumes the device contains an SPI flash chip, which requires a clip to connect up to the flasher.

Flasher
As a flasher, a Raspberry Pi can easily be used. Any model and revision will do, but be warned that the earlier ones do not have enough RAM to compile coreboot by themselves. If using one of these, make sure to copy the dump of the flash chip onto a more powerful computer. If the flash chip is SPI based, make sure to get a Pomona SOIC-8 testclip for £15. But there also many other programmers. Make sure to get some debug wires, too.

SPI flash
There are different types of SPI chips (list). The most common package for these chips is SOIC-8 which can be flashed via testclip. Sometimes these chips are in a WSON-8 package; in which case the WSON-8 chip needs to be desoldered, and resoldered with a new SOIC-8. If you need help with soldering ask hackerspaces near your location. SPI chips are common in sizes from 2MB - 16MB. Often vendors solder two chips to save money.

flashrom
flashrom is most commonly used to dump and write to flash chips. This must be installed on the flasher, or on the machine that the flasher is connected to.

It is useful to install flashrom on the system that will be flashed to, as once coreboot is flashed initially, it can be reflashed internally, without disassembly or use of a flasher.

Now, the machine needs to be disassembled. Follow the manual, or an online guide until the flash chip is accessible, and then attach the clip and wire it to the flasher.

Once the flash chip is connected to a flasher, use flashrom to dump the flash chip's contents.

It's important to take multiple dumps, in case there is a connection error. Once a proper dump is obtained, it is safe to disconnect the flasher for now if so desired. Remember, if running on a Raspberry Pi v1, it will not have enough RAM to compile, so at this point the dump should be transferred to a different machine. It's possible to use the computer that the flash chip was dumped from, although this will require reassembly and another disassembly later.

Dumping and Compiling Tools
Now, the coreboot git repository needs to be cloned to a working directory, as it contains tools required to carry on. Directories must also be created for the specific manufacturer and model.

Replace and with your manufacturer and model respectively (e.g. lenovo/x220).

The next step is to extract regions of the flash dump. Regions are similar to partitions, and are a flash chip contains a flash descriptor that can be seen as a partition table for the SPI flash with some additional properties. This descriptor is read by a program called ifdtool, which will be used to gain the individual partitions.

First, ifdtool must be compiled. Its source is contained under coreboot's, so cd into the directory where coreboot was cloned to.

It's a good idea to install globally, but not necessary.

Then, cd back to wherever flash.bin is.

This will print a partition table, and extract some blobs. A standard partition table may look like this:

Intel ME and Gigabit Ethernet Configuration Data
Notice how the above table contains ME and GbE. These are binary blobs that initialise parts of the computer (In this case, Intel Management Engine and Gigabit Ethernet). On older devices, these can be safely removed with libreboot, but on Sandy Bridge and newer, they are required for the computer to run properly. Since Intel ME is required on these boards, it must be extracted. However, coreboot can drastically reduce the size of it, removing its network and system resource access. This is recommended, as not only does it improve security, it also leaves more space on the flash chip for other payloads. The Gigabit Ethernet configuration data is specific to each machine, and as such, must also be extracted from the flash chip.

At this point, the working directory should contain four new files, which follow the format flashregion_*.bin. These should map to the table that was printed. As previously mentioned, the descriptor, Intel ME and the GbE blobs are needed. Rename these to descriptor.bin, me.bin and gbe.bin respectively, and copy them to coreboot/3rdparty/blobs/mainboard/ / /; the directory that was created earlier.

Configuring and Compiling Coreboot
Now, coreboot must be configured for the specific machine. It's best to check the coreboot wiki page for the given device, in case there are any certain requirements. As such, this page will attempt to only detail the settings which must be set across the majority of installs. This cannot be guaranteed, and some settings may cause conflicts with the machine.

First, you must enter the configuration. This is performed in a similar manner to configuring a kernel.

Alternatively, one could use menuconfig, or even edit the config file manually (once it has been generated by nconfig/menuconfig).

General Setup
I recommend enabling the following: For a Sandy Bridge or later device: And if you've previously compiled coreboot, you can reduce further compile times by enabling:
 * Use CMOS for configuration values
 * Compress ramstage with LZMA
 * Include the coreboot .config file into the ROM image
 * Create a table of timestamps collected during boot
 * Build the ramstage to be relocatable in 32-bit address space.
 * Allow use of binary-only repository
 * Update existing coreboot.rom image

Mainboard
Here, the vendor and model must be selected. Make sure the exact model is entered, if derivatives are available (e.g X220/X220t). The ROM chip size should also be selected. This should have been outputted by flashrom, but if not can be determined by checking the filesize of flash.bin.

Chipset
This menu contains chipset specific options, and also the locations for the binary blobs extracted earlier. since this is largely machine specific, there are only certain options that should be enabled across the board. I recommend enabling: These will allow easier debugging if you have a bad flash. They can be disabled once a known working configuration is created.
 * Enable VMX for virtualization
 * Set lock bit after configuring VMX
 * Beep on fatal error
 * Flash LEDs on fatal error

Next, paths must be provided under Intel Firmware. Enable these options: Options for paths should now appear. They should match to the names used previously, but if not, correct them so that they do.
 * Add Intel descriptor.bin file
 * Add Intel ME/TXE firmware
 * Strip down the Intel ME/TXE firmware
 * Add gigabit ethernet firmware

Devices
This area largely concerns graphics, especially in the context of laptops. Personally, I have Graphics Initialisation set to 'Use native graphics init', and Display/Framebuffer Mode set to 'Linear "high-resolution" framebuffer'. The rest of these options should be set already for the machine. If the specific device requires a VGA BIOS image, follow the coreboot wiki.

Generic Drivers
I often enable: If the device has an Intel PCIe WiFi card, enable the option
 * PS/2 keyboard init
 * Support Intel PCI-e WiFi adapters

Security
I often leave this alone, as it currently only contains Verified Boot options, but if support for this is required, enable it.

Console
This section contains options about debugging consoles. It may be useful to enable certain options, especially if issues are occuring. I have enabled:
 * Squelch AP CPUs from early console.
 * Send console output to a CBMEM buffer
 * Show POST codes on the debug console

System Tables
Enable Generate SMBIOS tables, the only option here.

Payloads
In this section, the payload can be chosen. This page will detail how to set up SeaBIOS, as it has the largest compatibility with operating systems, but it is also possible to use GRUB2 for faster booting, or even place a kernel on the flash chip (if there is enough space).

Select the following for a proper SeaBIOS setup: One may also wish to enable some secondary payloads. These can be used for debugging, and changing options. A recommended option is nvramcui, which acts in a similar way to a standard BIOS options menu.
 * Add a payload > SeaBIOS
 * SeaBIOS version > master
 * Hardware init during option ROM execution
 * Use LZMA compression for payloads

Debugging
These options are largely for development. Regular users need not enable anything in this submenu.

Compiling
Now that the config is done, coreboot must be compiled. First, the cross-compiler must be built.

This requires dev-lang/gnat-gpl to be installed, otherwise many functions will not work properly. Once this is done, compile IASL.

And finally, compile coreboot

Flashing coreboot.rom
This should produce a file in the build/ directory called coreboot.rom. This is the final image which needs to be flashed. Copy this to the flasher, if not already on it, disassemble the target device and attach the flasher to the flash chip.

On the flasher, use flashrom to flash:

The second command should return VERIFIED. If so, coreboot has been successfully flashed to the device.

Flashing via internal
Once coreboot has been flashed initially, it can later be flashed internally, without need of an external flashing device. To do this, once a new coreboot.rom has been compiled, simply do the following:

Coreboot isn't booting (Broken build)
If coreboot is not booting, then it usually means that it either isn't configured properly, or is missing a payload. Ensure that a proper payload was selected that is compiled correctly, and properly configured itself.

It's also possible that coreboot is working correctly, but the graphical component isn't. This may be caused by using native gfx init. Try dumping a VGA BIOS and using that instead. It could also be the other way around; try switching from a VGA BIOS to native gfx init. As a final resort, try using the Legacy VGA text mode for the framebuffer mode under Devices/Display.

Nothing is booting anymore (aka SPI chip bricked)
This is usually caused by leaving the machine powered on while dumping or flashing with an external flasher. If the machine does not turn on at all (No lights, fans, or display turn on at boot), this may mean that the machine is bricked. It may be possible to repair by purchasing a new flash chip (Make sure it's compatible - try to use the same manufacturer and model for best results) and flashing this with either the original BIOS or the coreboot ROM. This often requires very delicate soldering, and is not for the feint of heart. It may mean that a new machine must be purchased, or at least a new motherboard.