Coreboot at Your Service!

As people started to build large computing clusters from ordinary PCs, the shortcomings of existing PC BIOSes for certain tasks became more obvious. Like any other computer, on occasion, a cluster's nodes need to be rebooted; however, most of the original PC BIOSes halted on boot if no keyboard was attached. Obviously, adding a keyboard and monitor to every node in a large cluster is not feasible. These days, this particular problem has been fixed by most PC BIOSes. They contain an option that tells the system to continue booting even if there is no keyboard. Other problems persist, of course, such as how to reboot and adjust the BIOS settings remotely.

One of the first people to try to fix these problems was Ron Minnich from Advanced Computing Lab, LANL, who in 1999 started the open-source BIOS project named LinuxBIOS. In 2008, the project's name was changed to coreboot.

The project has had three different phases: LinuxBIOS v1, LinuxBIOS v2 (or coreboot v2) and coreboot v3.

The first phase, LinuxBIOS v1, began in 1998–1999, and it became a “finished” product in 2000. At this point in the project, the BIOS consisted of some simple hardware initialization code, and the rest was a stripped-down version of the Linux kernel to do the real initialization. Because the Linux kernel does a lot of hardware initialization during its boot process (tests memory, sets up interrupts and so forth), it seemed like a reasonable choice to use the existing Linux kernel—hence the name LinuxBIOS.

The main problem in LinuxBIOS v1 was writing correct code so that the multitude of available motherboards were initialized properly. The code was far from “universal”. Among other things, each motherboard had its own unique memory initialization sequence, and most of the motherboard initialization code was written in assembly.

In the second phase, the developers took a new approach. They left the assembly code to enter protected mode untouched, but they rewrote everything else in C. There was a bit of a problem though. Normally, code generated by a C compiler assumes a stack is available, but because memory has not yet been initialized, there is no stack available. To get around this problem, Eric Biederman created a new C compiler called ROMCC. As you may have guessed, ROMCC generates machine code from C that uses only CPU registers—meaning machine code that needs no stack and, therefore, no initialized RAM! Plus, the CPU's cache is used as RAM. This technique is now known as CAR (Cache-As-RAM).

Although, LinuxBIOS v2 fixed some of the original design's problems, others remained. For instance, in order to add or remove a “payload”—the code that is actually responsible for loading the operating system—you had to recompile LinuxBIOS.

Around 2006, the developers refined their approach again. This, the current phase, is coreboot v3. Coreboot v3 uses the Kconfig facility to set all configuration settings—the same way you recompile a “normal” Linux kernel. The coreboot image is now an archive file that allows modules to be added to and/or removed from an image more easily. Also of note in coreboot v3 is the dropping of ROMCC—all code is compiled with gcc. Due to marketing reasons, the project's name was changed from LinuxBIOS to coreboot.

LinuxBIOS v1 supported 64 motherboards, and LinuxBIOS v2 supported about 120. The current version, coreboot v3, is still young, and at the time of this writing, it supports only 16 different motherboards.

My lab contains a VIA EPIA-M II for test purposes. It was manufactured a few years ago, but it's supported by coreboot. Let's take a look at how it is easy to replace its closed-source, proprietary BIOS with the open-sourced coreboot.

Because the EPIA-M II is not yet supported by coreboot v3, I'm going to cover installing v2 for this example. First, make sure you have GCC, binutils, Python, bash, pciutils-devel and subversion installed. Now, check out coreboot v2 code from the repository:

$ svn co svn://coreboot.org/repos/trunk/coreboot-v2

Next, fetch a payload:

$ svn co svn://coreboot.org/filo

I decided to use FILO, which is almost the same as LILO, but it uses no BIOS calls. You also may use GRUB2 if you like; it's completely compatible with coreboot.

You also need a special library named libpayload, because FILO depends on it. Check it out, and then run make, which first will run through the configuration:

$ svn co svn://coreboot.org/repos/trunk/payloads/libpayload
$ cd libpayload
$ make

Listing 1 shows the output from the configuration process. Simply press Enter for all options. The value chosen is the default, which is the capitalized value in square brackets [...] if it's a yes/no option; otherwise, it's the value in brackets.