Coreboot

What is its job?

Unfortunately, booting a computer is not as simple as: apply power -> start operating system. Before control can be passed to the operating system, hardware needs to be initialized. Typically the BIOS checks for custom settings, does a Power On Self Test (POST), initialization of various parts (processor, RAM, GPU, hard drives, etc.), and handing off control to the operating system.

First off, the BIOS checks for custom settings. Typically this is CPU and memory clock settings. These are necessary, as these devices have to be initialized at the right speed typically.

Next, interrupt handlers and device drivers are loaded. The device drivers are needed at this stage, as after this point, specific hardware will have to be accessible by the BIOS.

The POST is ran to verify various things, such as the integrity of the BIOS, that RAM is installed (and determine its size), the presence of some kind of display device, etc. The purpose of this is to make sure that the computer is able to boot successfully (as it can't boot without RAM), along with making sure that some other basic parts are working properly (like DMA, timer, interrupt controller, etc).

Assuming that the POST determines that the computer is in a very basic, working order (it'll probably beep and turn off if not), the BIOS will check for "option ROMs" in other devices. Option ROMs are essentially other BIOS's in other hardware of your machine. For example, RAID controller cards commonly have another BIOS built in, so that the RAID controller can initialize all of the data storage devices connected to it, and construct the virtual data storage device.

After all of the option ROMs have completed, the BIOS looks at the boot devices, determines which ones are bootable, and loads the first device in its priority list. This allows the computer to still boot to an operating system even if the main drive fails by booting from PXE, USB, or other devices.

Once the BIOS determines which device to boot from, it sets the first instruction for the processor to boot when interrupt 19H (typically called INT 19H) is called, and proceeds to call the interrupt to start the operating system.

If you want to learn more about INT 19H, and other BIOS interrupt handlers, look into General Software, Inc's Embedded BIOS 4.1 document located here: ftp://ftp.embeddedarm.com/old/saved-downloads-manuals/EBIOS-UM.PDF

Coreboot

Now that we've gotten the simplified explanation of the BIOS out of the way, we can dive into what coreboot is.

Coreboot is a complete alternative to BIOS. The goal of the project is to start a machine as quickly as possible.

At first thought, it seems like the best way to boot quickly is to assume that the machine works, and skip the POST entirely. However, they've come up with many more ways to optimize the boot cycle.

Since coreboot's goal is to boot as quickly as possible, there are some main things that absolutely must be done including:

1. 1. Configure the processor settings, and get it into 32 or 64 bit mode
   2. Initialize DRAM controllers and DRAM
   3. Enumerate the devices, assign resources, create an ACPI table, and run SMM code
   4. Begin loading the "payload" (typically an OS)

The most important part of step one is getting the processor into 32 or 64 bit mode. This is because when the CPU initially receives power, it starts in 16 bit mode, and must be explicitly instructed to switch to 32 or 64 bit mode. Feel free to look into how an old version of coreboot accomplished this in just 10 instructions here (it's commented really well): https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/coreboot-v3/arch/x86/geodelx/stage0.S

Initializing DRAM controllers and DRAM is necessary next in the process. This is because until the DRAM controllers and DRAM is initialized, the RAM is completely unavailable for use. This is really interesting, as coreboot has to start its process with no RAM available. This likely sounds odd, as processors use RAM to store data for temporary use in most situations. Coreboot manages to accomplish starting without RAM being available by using the CPU registers as the RAM until RAM actually is available. They've developed a C compiler that uses the CPU registers for temporary storage called "romcc".

In order for the DRAM and it's controllers to become available for use, the drivers for it must be loaded. Unfortunately, the drivers for these are proprietary, so coreboot can't just get them from the manufacturer. This means that the developers have reverse engineered how the drivers work, so that the drivers can be rewritten with a free, open source license.

For the device enumeration, coreboot finds all hardware attached to the machine (internal and external), and loads the drivers for them, so that the devices are usable. Resource assignments must also be made at this stage, as integrated graphics requires a RAM allocation for the integrated GPU. Power management also becomes possible at this stage, as the "Advanced Configuration and Power Interface" (ACPI) becomes available as well.

As the last part of this step, the processor is put into system management mode (SMM or Ring -2), which allows access to many protected parts of the computer. I'm not going to dive into that topic more in this post, as that's a complicated subject by itself.

Finally, the payload stage handles passing control of the machine over to the operating system. This can be done much more efficiently than a standard BIOS, as coreboot is compiled with the payload built in. For this reason, coreboot already knows where the first instruction of the OS is, which allows it to immediately start the operating system without having to search for bootable drives.