# coreboot: replacing the proprietary BIOS, and what the build actually involves

> coreboot is a GPL-2.0 firmware project that initializes hardware and hands control to a payload. This review covers what it replaces, how the build works, where it stops, and how it differs from libreboot.

**coreboot/coreboot** — Read-only mirror of https://review.coreboot.org/coreboot.git. Synced every hour. We don't handle Pull Requests.

- Repository: https://github.com/coreboot/coreboot
- Website: https://coreboot.org
- Stars: 2,795 · Forks: 659
- Language: C
- License: GPL-2.0
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/coreboot-coreboot

## What coreboot replaces, and who it is written for

Most machines ship with a proprietary BIOS or UEFI implementation that runs before the operating system. coreboot is a Free Software project aimed at replacing that firmware. It performs the hardware initialization needed to configure the system, then passes control to a separate executable the project calls the payload. In most deployments the payload's job is to boot the operating system.

The audience is narrow by design. coreboot is written in C and lives in a git tree with a Gerrit review instance, so the people who get value from it are firmware developers, board porters, and engineers building appliances where the boot path must be inspectable. The README frames the split between hardware initialization and later boot logic as the reason the project fits specialized applications: running code directly in firmware, booting an OS from flash, loading a custom bootloader, or implementing firmware standards such as PC BIOS services or UEFI. That flexibility is also a constraint. You choose what goes in, which means you also choose what is missing.

## Hardware initialization, then a payload you pick

The architecture is a two-stage handoff. coreboot brings the chipset, memory and board up, then jumps to a payload. The README points to the payloads documentation for the supported list rather than enumerating them itself, so the set of payloads is a moving target that lives outside the README.

What matters for an adoption decision is that the payload determines what the user sees. A firmware standard implementation gives you a familiar boot environment; a minimal loader gives you a fast path to the kernel and nothing else. The project's position is that this lets a system include only the features the target application needs, reducing both code size and flash space. That is a real engineering trade-off, not marketing: every feature you leave out is one fewer component to audit, and one fewer thing that can fail before your OS starts.

The build side reflects the same philosophy. The top-level Makefile drives a Kconfig-based configuration system, with the config output split across several generated files under the build directory: an autoconfig, a C header, a tristate file, and split config fragments. Configuration strictness is turned up, with unknown-symbol warnings enabled and a warning-as-error setting applied to Kconfig. In practice this means a stale or misspelled config option surfaces at build time instead of silently doing nothing.

## Installing coreboot and getting a first build

The README does not give a step-by-step install. It says the build, associated utilities and payloads require many additional tools and packages, that the binary is typically built with a coreboot-controlled toolchain for reproducibility, and that building directly with your system toolchain is possible but not recommended. The list of requirements per Linux distribution and the getting-started instructions live in the Starting from scratch tutorial, which also covers booting the result under QEMU.

Getting the source is the one command the README spells out. The GitHub repository is a read-only mirror synced hourly, and the project does not handle pull requests there, so clone from the review host if you intend to contribute:

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

The Makefile requires the main directory path to contain no spaces, and it errors out immediately if it does. It also defines the build output directory, defaulting to build, and the location of the cross compiler description file generated during the build. The README directs you to the tutorial for the actual build steps rather than listing them itself, so the tutorial is the authority on configuring a mainboard and building. Expect the first build to spend most of its time producing the toolchain rather than compiling coreboot itself.

One caution about the tree you clone: the Makefile references a vboot source path under 3rdparty and a host build directory under the build output, so submodules are part of a normal build rather than an optional extra.

## Board support is the real gate, and it is not uniform

The README is explicit that coreboot supports a wide range of architectures, chipsets, devices and mainboards, and equally explicit that not all of these are documented. For the specific boards it supports, it points to mainboard-specific documentation and the Board Status pages rather than promising coverage in the README.

That gap is the single biggest practical limitation. A board appearing in the tree is not the same as a board someone has recently built and booted. The board status pages exist precisely because the supported set is uneven, and the README does not claim otherwise. If you are choosing hardware for a coreboot deployment, the documentation is telling you to check status per board before you buy, not to assume that an architecture being supported means your specific laptop is.

There is a second limitation in the release model. Releases are made quarterly, and the README states they are best considered snapshots of the codebase and do not currently guarantee any sort of extra stability. If you need a firmware image with a stability commitment attached, the quarterly archive is not that. It is a fixed point in the tree, which is useful for reproducibility and not the same thing as a supported product branch.

## coreboot versus libreboot: same base, different promise

libreboot is the comparison people reach for, and the difference is in what each project takes responsibility for. coreboot is a firmware project: it initializes hardware and hands off to a payload, and the README leaves payload selection and board enablement to the adopter. libreboot is a distribution built on top of coreboot that ships prebuilt images and makes its own commitments about which machines are supported and what the resulting firmware contains.

The practical consequence is where the work sits. With coreboot you are the integrator: you pick the payload, you configure the board, you build the toolchain, and you own the result. That is exactly what makes it suitable for appliances and custom boot paths, and exactly what makes it a poor first firmware project for someone who wants a download-and-flash experience. The README does not position coreboot as an end-user distribution, and reading it as one is the most common mistake.

Coreboot's own licensing structure is also worth noting here, since it is more layered than "GPL-2.0" suggests. The project is licensed the same way as the Linux kernel, GPL version 2, and the resulting coreboot image is licensed under GPLv2. Individual files carry various licenses, all compatible with GPLv2, and source files are expected to carry an SPDX identifier. Files under src/commonlib/bsd are BSD-3-clause, many dual-licensed GPL-2.0-only or GPL-2.0-or-later, specifically so they can be shared with libpayload or other BSD-licensed projects. Documentation under Documentation/ is CC-BY 4.0, with the exception that files with a history older than 2017-05-24 might be under different terms. The README also carves out uncopyrightable files, including binary or text configuration data such as .vbt graphics configuration, .apcb AMD firmware parameters and SPD memory configuration files, treating them as public domain and excluding them from the project's general license even though they may end up in a final binary. The README directs licensing questions to the project mailing list; this is a description of what the files say, not legal advice.

## Maintenance cost and what a quarterly upgrade actually means

The repository is a read-only mirror on GitHub, synced every hour, and the project does not accept pull requests there. Contributions go through the Gerrit instance at review.coreboot.org. If your team's workflow assumes GitHub pull requests, that assumption has to change before anything else does.

Upgrade cost follows from the release model. Because releases are quarterly snapshots, moving to a newer one is closer to rebasing onto a moving tree than applying a patch release. The build requirements are not fixed either: the README says operating systems and distributions ship an unknown variety of system tools, which is why it declines to list every required package and instead documents requirements for a few Linux distributions in the tutorial. A build that worked on one distribution can need different packages on another.

The toolchain is the part that ages least gracefully. coreboot builds with its own controlled toolchain for reproducibility, and the README notes the project keeps all packages required to build the toolchains at coreboot.org in case upstream sites change or specific packages disappear. That is a deliberate hedge against supply problems, and it also means your first build and periodic clean builds are heavier than a normal C project's.

## Where coreboot is the wrong tool

coreboot is not a general-purpose firmware replacement you install on arbitrary hardware. If your machine's board is not in the supported set, or is in the tree but not covered by the board status pages, there is no documented path for you. The README's own framing, that not all supported hardware is documented, is a warning rather than a footnote.

It is also the wrong choice if you need a signed, vendor-supported firmware update channel. The release notes describe snapshots, not supported branches. And it is the wrong choice if you cannot afford a failed flash on the target machine: the README does not document a rollback procedure, so recovery planning has to come from your own board knowledge, not from this project's documentation.

Finally, coreboot is not a bootloader in the sense most people mean. It is firmware that hands off to a payload, and the payload is what boots the OS. Treating coreboot as the thing that loads your kernel conflates two stages the project deliberately separates.

## Conclusion

coreboot suits engineers who need firmware they can read, modify and rebuild for a specific board, and who accept that they must confirm their mainboard is listed in the board status pages before buying hardware. It is the wrong tool if you want one image that boots on any machine, if you need a vendor warranty path, or if you cannot recover from a failed flash: the README does not document rollback. Before adopting it, verify three things in this order: that your exact mainboard appears in the board status pages, that you can build the toolchain from the Starting from scratch tutorial on your distribution, and that the release you intend to use is the quarterly snapshot you expect, since the README states releases are snapshots and do not guarantee extra stability.

## FAQ

### What does coreboot mean?

coreboot is the name of a Free Software project aimed at replacing the proprietary BIOS or UEFI firmware found in most computers. It performs hardware initialization and then passes control to a payload.

### Is coreboot or libreboot better?

The README does not compare the two. What it does say is that coreboot initializes hardware and hands off to a payload of your choosing, so the choice depends on whether you want to be the integrator or want a distribution that makes those choices for you.

### Which laptops support coreboot?

The README does not list specific laptops. It directs readers to the mainboard-specific documentation and the Board Status pages, and notes that not all supported hardware is documented.

### How do I install coreboot?

The README gives no install procedure. It points to the Starting from scratch tutorial for build requirements and getting started, and notes the binary is typically built with a coreboot-controlled toolchain rather than your system toolchain.

### Is coreboot a BIOS?

It is a replacement for the proprietary BIOS or UEFI firmware, not a BIOS itself. The README describes it as performing hardware initialization and then passing control to a payload, which can implement firmware standards such as PC BIOS services or UEFI.

### Is coreboot open source?

Yes. The README states coreboot is licensed the same way as the Linux kernel, under GNU General Public License version 2, and that the resulting coreboot image is licensed under GPLv2.

## Sources

- [coreboot/coreboot on GitHub](https://github.com/coreboot/coreboot)
- [License: GPL-2.0](https://github.com/coreboot/coreboot/blob/main/LICENSE)
- [Project website](https://coreboot.org)
- [README](https://github.com/coreboot/coreboot/blob/main/README.md)
- [Releases](https://github.com/coreboot/coreboot/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/coreboot-coreboot