coreboot crosses the no-RAM gap one stage at a time

A coreboot development table at the Denver 2008 summit, crowded with open laptops, bare motherboards, cables, and programming hardware. The photograph catches firmware as the article describes it: board-specific work performed close to the machine. Unmodified photograph by wardv, CC BY-SA 2.0, via Wikimedia Commons.[8]

On a coreboot platform that uses cache-as-RAM, the processor enters coreboot without ordinary DRAM, an operating system, or a forgiving place to put temporary state. The first useful architectural fact is therefore a constraint: before firmware can initialize memory, it must somehow run the code that initializes memory.

Coreboot solves that circular problem as a sequence of deliberately unequal stages. Each stage assumes only the machinery its predecessor has made trustworthy, performs a bounded part of hardware initialization, and hands a more capable execution environment to the next. The path can include bootblock, an optional verified-boot verstage, romstage, postcar, ramstage, and finally a payload. Those names describe changing resource conditions, not arbitrary chapters in one large program.[1]

The cover photograph shows contributors at coreboot's Denver summit in 2008, when the project was still commonly associated with its earlier LinuxBIOS name. Open laptops, loose boards, and programming cables fill the table. That physical scene matters: the stage model may be reusable, but every successful boot still depends on exact knowledge of a real board.[8]

The first workspace is borrowed from the CPU cache

After CPU reset, the bootblock establishes enough of a C environment for later code to be practical. On x86 platforms following this path, that can include applying microcode, initializing a timer, moving from 16-bit real mode into 32-bit protected mode, setting a stack pointer, clearing the BSS, and loading the next stage. The awkward part is the heap and stack: DRAM is not ready, because teaching the memory controller how to use the installed modules belongs to a later step.[1]

Cache-as-RAM, or CAR, supplies the temporary answer on platforms that use it. Platform-specific instructions put part of the CPU cache into a non-evicting mode so early C code can treat it like SRAM. bootblock, romstage, verstage, and postcar can work inside that provisional address space. This is a useful way to read the architecture: coreboot does not pretend the final resource exists early. It creates the smallest substitute that lets the next uncertainty be resolved.[1]

If verified boot is enabled, bootblock can enter verstage before romstage. Verstage begins from the assumption that its code and public key cannot be rewritten in the field, then installs checks on files loaded from the coreboot filesystem and on partitions before access. That puts verification near the front of the chain, while the system still has few mutable parts. It does not make every later component open or correct; it establishes which later bytes are authorized to run.[1]

On this CAR-based path, romstage performs early device work and brings up DRAM. When a separate postcar stage is used, it has one narrow job once regular memory is usable: dismantle the cache-as-RAM environment and load ramstage into DRAM. The transition is easy to overlook, yet it prevents an important category error. Temporary memory is not silently treated as permanent memory; a named stage changes the execution contract.[1]

CBFS carries code; CBMEM carries continuity

Two similarly named mechanisms keep the handoffs coherent. CBFS, the coreboot filesystem inside the firmware image, holds the pieces that may need to be found and loaded: stages, a payload, raw files, and other platform data. The build system records each item with a type such as stage, payload, raw, or flat-binary, plus placement, alignment, and compression choices. Coreboot's architecture documentation lists none, LZ4, and LZMA as stage-compression options; the bootblock is normally left uncompressed, while larger late stages can be compressed and expanded into the memory now available.[1][2]

CBFS is thus the supply cabinet for the boot. It lets the early code locate a specific next component rather than link every possible behavior into one continuously resident binary. It also makes the final ROM an inspectable composition: build configuration decides which board code, stage binaries, payload, and auxiliary files occupy the flash image.[2]

CBMEM solves the opposite problem. Once DRAM exists, coreboot reserves a stable memory region for information that must outlive the stage that produced it. Entries can hold console output, timestamps, memory information, ACPI and SMBIOS tables, the coreboot table, a stage cache, and other platform data. Before CBMEM is fully available, early console and timing state can live in provisional storage; during the transition, that state is copied into the durable CBMEM entries.[3]

That distinction—files waiting in flash versus state surviving in memory—is the spine of the boot. CBFS answers “what code or data should run next?” CBMEM answers “what has the machine already learned?” It also gives some failures a history. The cbmem utility can expose the collected console with cbmem -c and stage timestamps with cbmem -t after Linux starts, so a slow or intermittent handoff that still reaches Linux—or whose data survives a warm reboot—can be investigated without reducing the boot to one total duration or one last error line.[3]

Ramstage turns discovered hardware into a handoff

With DRAM established, ramstage can perform the broad device work that was too expensive or impossible earlier. It initializes PCI and on-chip devices, may initialize graphics, handles CPU facilities such as System Management Mode on x86, and initializes the TPM if verstage did not. It also applies late security locks, including write protection for boot media and relevant registers.[1]

The output is more than initialized devices. Ramstage writes the descriptions that its successor needs in order to understand the machine: ACPI and SMBIOS tables on x86, coreboot tables, or devicetree updates on Arm. In other words, it converts board-specific knowledge into a handoff format. The next program should not need to rediscover every GPIO choice, reserved range, or device relationship from first principles.[1]

This is where board code becomes inseparable from architecture. A mainboard port identifies the processor and chipset path, memory topology, embedded controller, non-discoverable devices, and platform policies that generic code cannot infer safely. Coreboot's own support guidance tells users to inspect the src/mainboard tree or the Mainboard menu rather than assume that a familiar CPU makes an arbitrary laptop compatible. Intel Boot Guard can make replacement firmware difficult or impossible, and a failed flash demands a tested recovery path.[6]

The current release offers a compact example of how ports mature. Coreboot 26.06, published June 25, 2026, recorded 1,163 commits from 101 authors, including 22 new contributors. Its Nova Lake work landed through separate bootblock, romstage, and ramstage changes, followed by Intel FSP-M and FSP-S integration and board support. The same release note explicitly says that DDR5 support is not complete. “Supports Nova Lake” is therefore too coarse to be an engineering claim; stage reached, board variant, memory path, payload, and tested behavior all matter.[5]

The payload chooses what “boot” means next

Coreboot ends by executing a payload stored in CBFS. That payload is selected when the image is built rather than from a runtime chooser inside coreboot. The separation keeps hardware initialization distinct from later boot policy. SeaBIOS can supply a traditional PC BIOS interface, edk2 can provide a UEFI environment, GRUB2 can act directly as the bootloader, and a small Linux payload can use familiar drivers and userspace tools before handing off with kexec.[1][4]

This is not merely a menu of brands. Each payload moves complexity to a different place. SeaBIOS is useful when option ROMs and the historical PC BIOS contract matter. A Linux payload can move storage, networking, and recovery behavior into a kernel and userland that an operations team already knows. Heads combines coreboot with Linux and security-oriented tools, but supports only a limited set of mainboards. Payload choice therefore follows the appliance's recovery, compatibility, and trust requirements; it is not an interchangeable cosmetic layer.[4]

An independent LWN account of Chrome OS firmware in 2013 captured both sides of this seam. Coreboot's payload model let Chrome OS use U-Boot for its verified-boot policy, while Intel reference code and other closed components still remained elsewhere in the firmware stack. The architecture can make responsibilities smaller and more visible, but it cannot manufacture source code for silicon initialization that a vendor exposes only as a binary.[7]

That boundary remains practical today. A coreboot build can be mostly inspectable while still invoking an Intel Firmware Support Package, carrying microcode, coexisting with management-engine firmware, or relying on an embedded controller with its own code. Conversely, replacing the boot firmware does not by itself alter every neighboring component that shares the flash chip or motherboard. Coreboot's FAQ is unusually direct on this point: its presence says nothing by itself about the operational state of Intel's Management Engine.[1][6]

Read the stage chain when something fails

The architecture becomes most useful when a machine does not reach the payload. No serial output may indicate trouble before the console exists. Logs ending in romstage point toward memory training or early platform setup. A transition into ramstage followed by missing devices shifts attention toward enumeration, resources, ACPI construction, or board configuration. A clean coreboot handoff followed by a failed disk or network boot belongs first to the payload and its policy. CBMEM console and timestamp data make those hypotheses testable when the platform exposes them.[1][3]

The same staging improves change review. A patch that alters cache-as-RAM setup has a different blast radius from one that adds a ramstage device callback; a CBFS layout change differs from a CBMEM handoff change; a new payload does not automatically require a new DRAM path. The seams do not guarantee safety, but they give reviewers a vocabulary for asking which resources exist, which state persists, and which component owns the next decision.

On the CAR-based path examined here, coreboot's deepest architectural move is to make scarcity explicit. It starts with almost no writable memory and little verified knowledge, borrows a workspace, initializes DRAM, preserves what it has learned, describes the hardware, locks what should stop changing, and then leaves. The boot succeeds because no stage claims capabilities that belong to the next one.

cronfeed.work