# oreboot: coreboot's firmware rebuilt in Rust

> oreboot is a downstream fork of coreboot that keeps the payload model but replaces the C implementation with Rust, and it currently plans to support only LinuxBoot payloads. It suits people who want to work on firmware in a memory safe language, and it comes with an explicit position on how much driver code a bootloader should contain.

**oreboot/oreboot** — oreboot is a fork of coreboot, with C removed, written in Rust.

- Repository: https://github.com/oreboot/oreboot
- Stars: 1,801 · Forks: 114
- Language: Rust
- License: GPL-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/oreboot-oreboot

## coreboot without the C

oreboot is a downstream fork of coreboot, and the project puts the relationship in the most compressed form it can, oreboot is coreboot without the c.

That means the payload model survives. A coreboot platform is firmware that initialises a small amount of hardware and then hands control to a payload, an operating system or a boot manager, and the interface between the two is the part that has to stay compatible. Keeping that interface and replacing everything behind it with Rust is what the fork does.

The implementation language is Rust with assembly where needed, which is the normal shape for a project that has to talk to memory mapped registers and cannot express that in safe code. The licence is GPL-2.0.

The scope statement is short and important: oreboot currently only plans to support LinuxBoot payloads. oreboot's log output shows it decompressing a payload and checking that it looks like a Linux image before handing over.

The demos section shows the state of the thing in practice, with a recording of oreboot for ARM in QEMU and one for RISC-V on the HiFive Unleashed in QEMU. Being able to watch the whole boot in an emulator without hardware is what makes a firmware project approachable, and both demos are asciinema recordings rather than screenshots, so you can see the timing as well as the output.

## What a real boot looks like

The README includes a captured output sample from oreboot on an Allwinner D1, and it is the most informative thing in the document.

The early lines are hardware bring-up: the CPU clock and AXI configuration, the peripheral control registers being locked and reprogrammed, and then DDR3 running at 792 megahertz. A test passes, the memory size is reported, and the NOR flash is identified.

Then the firmware loads itself. Three blocks are loaded to three addresses, and each one is drawn as a progress bar made of arrows, which is a small thing that makes a serial console log readable.

The interesting part is what follows. The RustSBI banner appears, and then the firmware prints the platform CSRs, sets up the extension CSRs, and initialises the timer, the reset and the inter-processor interrupt. It then checks the device tree and reports that it looks fine, decompresses the payload, checks again, and announces that the payload looks like a Linux image.

The handover is explicit. It says it is handing over to the SBI and will continue at the supervisor entry address, and then the Linux kernel starts and detects the SBI specification version, the SBI implementation and its extensions.

Reading that log end to end tells you the architecture of the project: there is a RustSBI implementation providing the supervisor interface, the firmware loads and decompresses a payload, the device tree is validated, and the payload is a Linux image that boots as a normal Linux kernel. The last lines show the kernel reading a command line with two consoles, an early console and a logging level.

## The Rust Embedded model, and what vendors owe

oreboot builds on the abstractions of the Rust Embedded Working Group, using its model with its crates and traits, as detailed in the project's book, and the README shows the model diagram.

The practical consequence of that choice is the vendor support section, and it is a section written for hardware vendors. SoC vendors are expected to provide documentation for their cores, peripherals and other blocks, and their SVD files, so that the peripheral access crate and the hardware abstraction layer crates can be generated, and ideally the vendor should provide and maintain those crates as well.

Vendors are encouraged to get in touch, and to look at the Embedonomicon, which guides you through enabling Rust support for a SoC. The Rust Embedded book also offers design patterns and implementation guidelines for the hardware abstraction layer, and a glossary for understanding the structure.

This is a meaningful difference from a project that writes its own register definitions by hand. Generated peripheral access crates mean the register map comes from a machine readable file that the vendor supplies, so the firmware does not carry a hand maintained copy of the hardware, and the risk of a firmware bug caused by a stale register definition is pushed back to the vendor.

It also means the project is partly waiting on the ecosystem. A new SoC is supported to the extent that someone provides the documentation and the SVD, which is a different kind of dependency from a C project that can read a datasheet and write the accessors in an afternoon.

## The dilemma of drivers, and separating firmware from the OS

There is a section of the README called the dilemma of drivers, and it states a position rather than describing a feature list.

The position is that oreboot does not aim to turn into its own operating system, and that the amount and functionality of drivers is therefore kept low. But by the design of SoCs, something has to be implemented in order to load code, and the section walks through the options with their trade-offs.

SPI flash, SD cards and eMMC are rather simple to load from, but they require special mechanisms and tools to write to the storage. USB and ethernet are more flexible for development, since they allow code to be loaded from another machine, but they are more complex to implement. UART is simple for data transfer but very slow for larger payloads, such as a Linux kernel.

Then the recommendation. In many cases no full driver is needed, because only reading from storage is required and no rich file systems are needed. To avoid colliding with the needs and specifics of an operating system, the project recommends clearly separating the storage parts that hold the firmware and the operating system respectively, and gives the example of putting the firmware in a SPI flash and the operating system on an NVMe SSD.

That advice is the interesting part, because it is a statement about how to use the system rather than about how to build it. A bootloader that has to share a file system with the operating system has to implement enough of that file system to be correct, and then it is maintaining a driver that the operating system also maintains. Splitting the devices sidesteps the whole question.

## The build: a Cargo workspace with a size first release profile

The repository is a Cargo workspace, and the member list is the architecture of the project.

```toml
[workspace]
members = [
  "src/arch",
  "src/cpu",
  "src/lib/*",
  "src/mainboard/*/*/*",
  "src/soc",
  "xtask",
]
default-members = ["xtask"]
resolver = "2"
```

There is a crate per architecture, a crate per CPU family, a set of library crates, a crate per SoC, a mainboard tree three levels deep, and the xtask crate that holds the build automation. The default member is xtask, so a bare cargo invocation runs the tooling rather than trying to build every target.

The release profile is the one to notice.

```toml
[profile.release]
opt-level = 'z' # Optimize for size.
lto = true
# Leave debug symbol information on release compilation mode
# That's okay, these symbols won't appear on flash binary
debug = true
```

Size is the goal, opt-level z and link time optimisation, with debug information left on and a comment explaining that the symbols do not appear in the flash binary anyway. The development profile is the opposite trade, with opt-level 1, overflow checks disabled and link time optimisation on, which is a sensible split for firmware.

The embedded-hal dependencies are pinned to exact versions with the equality operator, which is the right call for a project where a patch release of a hardware abstraction trait can change the generated code.

Around that, the Makefile installs the host tooling, with a pinned Rust version, a pinned cargo-binutils and a pinned dprint for formatting, prepares a Debian system with the device tree compiler and QEMU, and provides the mainboard build, clippy with warnings denied, format and check targets, and a test target that runs the layout flash package and the xtask package.

## How to get it, and what it is not

Getting the source is the usual two lines, and the prerequisites are the usual embedded set: the device tree compiler, pkg-config, libssl and rustup, with a make target to install them on Debian based systems.

```sh
git clone https://github.com/oreboot/oreboot.git
cd oreboot
```

The community channels are the OSFW Slack channel and a Matrix room, which is the arrangement you would expect for a project hosted under an open source foundation's infrastructure.

As for what oreboot is not, three things stand out.

It is not a general bootloader. Only LinuxBoot payloads are planned, so if you need to boot another operating system, another payload format or a diagnostic environment, oreboot is a fork of coreboot rather than a replacement for it.

It is not an operating system. The driver dilemma section says so explicitly, and the position is that firmware and the operating system should live on separate storage so that the bootloader does not have to grow a file system driver.

And it is not a drop-in for every board. The support is per SoC, and it depends on the vendor providing documentation and the register descriptions that the generated crates come from.

What it is, then, is a working reimplementation of the coreboot idea in a memory safe language, with a payload model that lets a Linux kernel boot directly, and with the ambition of being a place where people who write Rust can contribute to firmware. The QEMU demos and the captured boot log are the evidence that it runs, and the boot flow documentation is where to start reading the code.

## Conclusion

Adopt oreboot if you want to contribute to firmware in Rust, or if you are bringing up a RISC-V or ARM board where a Linux payload is the goal, because the fork inherits coreboot's payload interface and replaces only the implementation. Do not adopt it if you need the breadth of coreboot's payload support, since oreboot currently plans for LinuxBoot payloads only, and expect a smaller driver surface by design. Before you build, read the boot flow documentation and the driver discussion, because the storage layout you choose determines whether the firmware and the operating system can share a device.

## FAQ

### What is oreboot?

oreboot is a downstream fork of coreboot, described as coreboot without the c. It is mostly written in Rust with assembly where needed, keeps coreboot's payload model, is licensed under GPL-2.0, and currently plans to support only LinuxBoot payloads.

### Which platforms does oreboot support?

The workspace is organised per architecture, per CPU family, per SoC and per mainboard, and the demos show oreboot for ARM in QEMU and oreboot for RISC-V on the HiFive Unleashed in QEMU. Support for a new SoC depends on the vendor providing documentation and SVD files so the peripheral access and hardware abstraction crates can be generated.

### How much driver code does oreboot implement?

The project states that oreboot does not aim to become an operating system and that the amount and functionality of drivers is kept low. SPI flash, SD cards and eMMC are simple to load from but need special mechanisms to write to, USB and ethernet are more flexible for development but more complex, and UART is simple but slow for large payloads. The recommendation is to separate firmware and operating system storage, for example firmware on SPI flash and the OS on an NVMe SSD.

### What are the prerequisites for building oreboot?

In general the device-tree-compiler, pkg-config, libssl and rustup, with a make target that installs the system packages on Debian based systems. The Makefile also pins the host Rust version, cargo-binutils and dprint, and provides targets for formatting, clippy, the per-mainboard builds and the test suite.

## Sources

- [Issues](https://github.com/oreboot/oreboot/issues)
- [License: GPL-2.0](https://github.com/oreboot/oreboot/blob/main/LICENSE)
- [oreboot/oreboot on GitHub](https://github.com/oreboot/oreboot)
- [README](https://github.com/oreboot/oreboot/blob/main/README.md)

---

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