What is coreboot?

coreboot is an open source firmware alternative which aims to replace your standard BIOS or UEFI. The overall philosophy of coreboot is: Do as much as needed, then jump straight payload. But wait.. what actually is your firmware good for? And what is a payload? Let”s do a short recap before we jump straight into coreboot.

In the book “Embedded Firmware Solutions” by Jiming Sun, Marc Jones, and Vincent Zimmer, firmware is defined as following: “Firmware is the layer of software between hardware and the OS”.

Firmware in general is a piece of software that runs on a very low level. It is not encapsulated by any OS or framework. A lot of devices have firmware on it, like: HDDs, SSDs, Graphics Cards, Ethernet Cards, Remote Controls, Smart TVs and of course computers. In this series, we will focus on firmware for computers/embedded devices. Typically the firmware does the hardware initialization and then hands over the control to the operation system. Nowadays, this isn’t true anymore. Most of the time, parts of the firmware have to stay active in order to provide certain functionalities. We will not go into too much detail on this now(Taking notes that I have to write a much more detailed article about coreboot/firmware in general). Just remember for now: Firmware does the hardware initialization of the device.

When your hardware has been initialized, the firmware hands on the control to a so called payload. This payload can be anything that loads your OS, like GRUB, any other bootloader or a stripped-down Linux kernel which then loads your OS on your hard drive.

Getting started with coreboot

Now let”s get started with coreboot. First off, we have to install all the dependencies that we need. If you are running on a Linux system e.g. Ubuntu, this is straight forward:

sudo apt-get install -y bison build-essential curl flex git gnat libncurses5-dev m4 zlib1g-dev qemu

If you are running on mac, you most probably can install the packages via brew. Windows users might want to set up a VM where a proper OS like Linux runs.

Once we installed our dependencies, we can clone the coreboot repo into our working directory:

git clone https://review.coreboot.org/coreboot

coreboot uses git as their version control system. You can also find a mirror on Github. You can also download the lastest release on coreboot.org.But if you want to contribute to the project later on, you need to use the provided link above to their own git system.

Once you cloned the repository into your working directory, we can start building the coreboot toolchain. Type

make crossgcc-i386

and the toolchain will start building. But wait — what do we need a toolchain for? To circumvent the problem, that different distributions ship with different toolchains e.g. gcc versions, coreboot builds its own small toolchain. To be more specific, it builds a patched version of the gcc (version 8 by the time of writing) libraries, binutils, iasl, and checks for the required tool dependencies. Take a coffee — this might take a while.

coreboot Tree Structure

In the meantime, we can take a look at the structure of the source code and where to find what. The coreboot directory looks more or less like this:

Let’s go through the folders one by one.

• 3rdparty contains 3rdparty software like binaries you might need to initialize your hardware;
• In configs you can find predefined build configurations for coreboot;
• In Documentations — guess what: there is some special documentations about certain mainboards or other components;
• payloads includes everything you need to build the different payloads;
• util contains some utilities you do not need to worry about yet;
• The most important folder here is the src folder which contains all source code for coreboot.

Take some time and walk a little bit through the src/ tree. You will notice that it’s divided into components like mainboards, superio’s, soc’s, etc. This is common practice in coreboot. Each components goes into a certain directory. Later on, we will put everything together within the mainboard folder, just like a toolbox.

Back to coreboot: Once building the toolchain is finished, we can configure coreboot to run with QEMU. QEMU is a hosted virtual machine monitor, or let”s say: it emulates a processor and let you run coreboot on your computer within a virtual machine. So type

make menuconfig

in order to configure your coreboot build. As you can see, the configuration menu pops up.

We basically need to check two things here:

• Configure coreboot to be build for QEMU,
• Configure the payload and set it to coreinfo.

So first check if coreboot is configured correctly to be build for QEMU. Navigate to Mainboard, press Enter and it should look like this, if not change it accordingly.

So here we see for which Mainboard coreboot has been configured. In our case, we chose an Emulation board, the QEMU x86 i440fx. This shows us how to configure QEMU later on, so that we can start coreboot there. The ROM chip size can stay at 256 KB for now. We could increase it, QEMU would not care about it. If we would choose a real mainboard, the ROM chip size has to match the ROM chip size of the mainboard accordingly. The size of the CBFS (Coreboot Filesystem) determines, how much space coreboot should occupy on the ROM chip. Leave it as it is for now.

Next we need to adjust the payload. Hit ESC twice to go back to the main menu. Then navigate to Payload. The default setting should look like this:

SeaBIOS has been selected by default which is what we want. SeaBIOS is a open-source legacy BIOS implementation. We will use it to load a second payload called coreinfo. Navigate to Secondary Payload (at the very buttom), press Enter, and activate coreinfo as secondary payload by hitting space when the entry is marked.

Hit ESC multiple times to exit the menuconfig (save when exiting) and the type make into your console to build coreboot. You should see a lot of build messages. Once coreboot is finished building it will look like this:

coreboot will list the different regions it assembles together in the coreboot.rom file. You need not know (yet) what these regions are about. But you can see that there is one entry which is called “fallback/payload” which is your SeaBIOS payload + coreinfo.

Okay — now let’s run coreboot in QEMU.

qemu-system-x86_64 -bios build/coreboot.rom -serial stdio

and the magic happens. Congratulations! You just run coreboot for the first time within QEMU.

Awesome. What did just happen here?

Okay. So what did just happen here? A lot. But let”s go through it step by step. First your started an emulation environment called QEMU. QEMU emulates a processors and you told QEMU with the -bios flag, that it should use your coreboot.rom file you just build as it’s firmware. Next coreboot launched off. If you scroll upwards within your terminal window and go to the position right after the executes the qemu command, it looks like this:

When a processor starts up, it will always jump to the so called reset vector. This is were the coreboot bootblock resides. The bootblock is the first part of code that gets executed after the cpu powers up. After that, a whole lot of hardware will be initialized as you can see in the console output. After a while, you can observe, that coreboot handles over control to the payload:

You can observe within the first line, that coreboot jumps to a boot code at a certain address. This is exactly where SeaBIOS sits and it will be executed afterwards.

In the next step, coreinfo will be loaded by SeaBIOS. And you are done — Yeay!

If you want to get more involved in coreboot, check the website and the slack channel at slack.u-root.com. Thanks for reading!