The open source alternative to BIOS and UEFI, coreboot is often praised for its speed and security [1]. However, just as important is the accessibility of its firmware. According to the coreboot website, "The architecture of coreboot is designed to have an unbrickable update process. Updating firmware should be no more dangerous than installing your favorite app on your mobile phone." As the major result of this goal, users can choose to customize their own firmware. Much like customizing the Linux kernel, the process is lengthy but mostly a matter of following instructions in the thorough documentation. Although the documentation is oriented towards Debian, it can easily be transposed to other distributions, the main difference being the occasional difference in the names of some of the necessary packages.

You may want to build your own firmware for several reasons. You might want to install coreboot on a machine that already has its own BIOS or UEFI. If your machine already uses coreboot, you might want to tweak it to better suit your needs. For example, you may prefer to turn off virtualization support in order to get every bit of performance from your machine. Sometimes, too, an unsupported mainboard might be usable with a few experimental tweaks. Perhaps the main reason is that building coreboot firmware can satisfy your curiosity about a technology that is still unfamiliar to most Linux users.

Despite the project's goals, some chance exists that you could brick your machine. Should that happen, another attempt at coreboot customization or the manufacturer's firmware may restore functionality. All the same, before flashing your custom firmware, you should make sure you have a current backup and thoroughly research what you are doing before you begin.

Preparing to Build

A work in progress, coreboot must be tailored to each mainboard. While several hundred mainboards are supported, you should check that your mainboard is supported before you build your own firmware. The project claims that its list of supported boards is current to within the last hour [2], and some hardware manufacturers maintain their own documentation. Some entries have an upstream link to an existing version of the firmware you can work with, following coreboot's documentation [3].

You will also need the tools to build the firmware. On Debian, run the command:

apt-get install git build-essential gnat flex bison libncurses5-dev wget zlib1g-dev

This collection of packages includes the necessary compiler and other tools needed to build the firmware. You will also need Git to access coreboot's files. You may also want to install Doxygen in order to read package documentation. If you have a compiler preference, GCC, G++, or gcc-multilib can replace gnat. If you use Clang or LLVM as a compiler, you should also add CMake. Similarly, if your hardware uses Advance Configuration and Power Interface (ACPI) for power management, add iasl. If you want a better graphical display when building, add ncurses-dev. For many users, the command above should be all you need. With other distributions, you may have to search for slightly different names.

Build Steps

You can build coreboot on any machine. The process will not alter your machine until you flash the resulting firmware. To begin the build, clone the coreboot files and switch to the directory created for them:

git clone https://review.coreboot.org/coreboot
cd coreboot
git submodule update --init --checkout

The last command checks out a sub-repository for your use (Figure 1).

Figure 1: Coreboot's source code is stored on Git.

The final preparation stage is to build the toolchain. This step is necessary because different distributions include different toolchains. To prevent any problems, coreboot creates its own patched version of GCC, including all dependencies. Enter:

make crossgcc-i386

The process can take 10-15 minutes, depending on the machine (Figure 2).

Figure 2: Coreboot smoothes the build process by providing its own toolchain.

Building Custom Firmware

To build efficiently, you most likely need your hardware's specifications. If you no longer have the specifications or cannot find them online, you can still attempt to build, although success may take several tries. For practice, you might want to follow one of the online tutorials for the Qemu emulator, which requires fewer configuration choices [4].

From the directory with the source code, enter make menuconfig to display a text-based interface (Figure 3). Alternatively, if ncurses is installed, enter make nconfig for a more user-friendly menu. Detailed instructions are available in the coreboot documentation, although for some settings you may be able to accept the defaults. For a system with native graphics, follow the generic instructions in Figure 4, entering the information for your hardware. For non-native graphics, enter the information in Figure 5. Note that for some Intel and AMD boards, you may need to provide files from the vendor. These vendor files are most likely necessary for older hardware, because manufacturers are increasingly cooperating with the coreboot project.

Figure 3: A text-based interface is used for configuring firmware. © http://www.coreboot.com/

Figure 4: A generic guide to required firmware options for machines with on-board graphics. © http://www.coreboot.com/

Figure 5: Machines without on-board graphics require two additional options.

The payload is the code that loads an operating system in the final stage of starting a machine with coreboot. You can use the default payload SeaBIOS or one of the other payloads [5]. Increasingly, hardware vendors like System76 and Star Labs provide their own payloads, which may be necessary in order to use some of their utilities or apps. However, you can build successfully with other payloads as well.

When you have made all your choices, press Esc to exit the menu and save your choices. Then enter make from the directory that contains coreboot and any vendor or payload files (Figure 6). At the end of the build process, make indicates success or failure, listing errors that you can correct with some research before making another attempt. Only flash a successful result, never a failed one.

Figure 6: Compiling firmware: Only flash files that are successfully built.