coreboot Finally Lands on AMD Hardware: What Star Labs Getting There Means for Open Firmware

Star Labs has announced coreboot support for the AMD StarBook, completing a journey that Intel-based StarBook owners have enjoyed for several generations already. If you follow open firmware closely, you know this is not a trivial port. AMD hardware has historically been more resistant to coreboot than Intel, not because of political intransigence but because of deep architectural differences in how AMD processors initialize. Getting here took time, and it’s worth understanding why.

What Makes AMD Different

When coreboot came of age, the primary target was Intel. The coreboot project started life at Los Alamos National Laboratory as LinuxBIOS in 1999, and Intel’s architecture, though complex, was at least well-understood by the time the project matured. AMD presents a different set of constraints rooted in two interrelated systems: AGESA and the PSP.

AGESA, which stands for AMD Generic Encapsulated Software Architecture, is the proprietary firmware AMD uses to initialize its processors and memory controllers. Before your operating system loads, before coreboot’s own initialization code runs meaningful work, AGESA runs first. It trains DRAM, configures the memory fabric on Zen-era chips (which AMD calls the Infinity Fabric), brings up CPU cores, and configures platform power management. There is no practical way to replace it from outside AMD. Unlike Intel’s FSP (Firmware Support Package), which is also proprietary but has been integrated into coreboot for years across many platforms, AGESA blobs are larger, more opaque, and have historically been tightly coupled to vendor board designs.

The second complication is the Platform Security Processor, AMD’s embedded ARM Cortex-A5 security coprocessor baked into every Zen-era SoC. The PSP is AMD’s answer to Intel’s Management Engine. It holds keys, manages secure boot chains, provides the fTPM, and critically, it runs before any x86 code executes at all. On AMD platforms, the PSP owns early boot. It verifies its own firmware, initializes the x86 cores, and hands control to AGESA. You cannot simply replace the full firmware stack on AMD the way you theoretically could on very old hardware.

This is the environment Star Labs had to work within.

Chromebooks Showed It Was Possible

The existence proof for AMD coreboot at scale has been Chromebooks for years. Google has shipped Chromebooks based on AMD Picasso (Ryzen 3000-series), Cezanne (Ryzen 5000-series), Mendocino, and more recently Phoenix-based chips, all running coreboot. You can browse the Chromium OS firmware source and find AMD platform support going back several generations.

But Chromebooks represent a specific, controlled environment. Google works directly with AMD, obtains AGESA source under NDA, and integrates it. The resulting firmware ships locked down; users cannot change it without enabling developer mode, and even then there are constraints. The openness of Chromebook coreboot is real but bounded.

Star Labs needed something different: coreboot that ships on a general-purpose laptop, accepts arbitrary UEFI payloads, and can be reflashed by end users. That means using released AGESA binary blobs rather than source-level integration, and building a firmware stack that sits on top of them while remaining auditable and reproducible at the coreboot layer.

How AMD coreboot Actually Works in Practice

The coreboot build for AMD consumer hardware follows a pattern established by community contributors, primarily through work on platforms like the Lenovo ThinkPad X395 and various AMD Chromebook reference designs. The structure looks roughly like this:

[PSP firmware] → [AGESA blob] → [coreboot romstage] → [coreboot ramstage] → [payload (edk2/TianoCore)]

The PSP firmware and AGESA are extracted from official vendor firmware images or obtained through AMD’s distribution channels under specific license terms. They are not compiled from source by Star Labs or anyone outside AMD. Everything above that layer, coreboot’s own initialization code, the silicon initialization callbacks, the device tree, the payload integration, is open source and lives in the coreboot repository.

Star Labs uses edk2 (TianoCore) as their UEFI payload, which gives the firmware a standard UEFI interface that operating systems expect. This matters because while coreboot purists might prefer a minimal payload like SeaBIOS for legacy boot, modern Linux distributions, Windows, and firmware-dependent features like Secure Boot, NVRAM, and UEFI runtime services all require a proper UEFI environment.

The tradeoff is well-understood: you get an open, auditable build process for everything except the blobs you cannot replace. The PSP still runs. AGESA still runs. But the code that builds on top of them, the code that actually configures your hardware, sets up your boot environment, and presents the UEFI interface to your OS, is reviewable and reproducible.

Star Labs’ Firmware History

Star Labs has been shipping coreboot on Intel-based StarBooks since the Mk V generation. Their firmware repository on GitLab is public, and they’ve built a workflow where users can flash firmware updates directly through a utility or via fwupd on Linux. For Intel machines, the coreboot port was able to go further toward openness because Intel ME can be neutralized to varying degrees using me_cleaner, reducing the trusted computing base for users who care about that.

AMD’s PSP is harder to neutralize. Unlike Intel ME, where community research produced tools to reduce or disable large portions of the ME firmware, AMD’s PSP verification chain is tighter. The PSP verifies its own firmware signatures before doing anything else, and AMD does not publish the keys. For now, AMD coreboot ports accept the PSP as-is and focus their openness on the layers above it.

This is not a secret tradeoff; it’s the documented state of AMD open firmware. Star Labs has been transparent about it across their Intel firmware documentation, and presumably the AMD variant documentation follows the same pattern.

Why the Wait Was Worth It

The years between the AMD StarBook’s release and coreboot availability were not idle. AGESA stability for the specific AMD platform used in the StarBook had to mature. The coreboot community needed to build out support for the relevant AMD SoC family. Star Labs engineers needed to integrate that work, test it against their specific hardware configuration (embedded controller firmware, display panel initialization, thermal management, battery charging), and validate it against the range of operating systems their customers run.

Embedded controller firmware is often overlooked in firmware discussions. The EC manages keyboard, trackpad, battery, thermal sensors, and power button on most laptops. Star Labs developed their own open-source EC firmware, StarEC, and keeping that working across a new coreboot port adds another variable to validate.

Flashing bad firmware on a laptop is not like flashing bad firmware on a microcontroller you can unplug. If coreboot misconfigures memory training and the system fails to POST, recovery requires hardware-level intervention, often a CH341A programmer and physical access to the SPI flash chip. Star Labs includes a recovery method in their documentation, but the testing bar before shipping is necessarily high.

What This Port Means for the Ecosystem

The list of AMD laptops shipping coreboot outside the Chromebook ecosystem has been short. System76 has done extensive open firmware work, including coreboot on some of their AMD-based Thelio desktops and Pangolin laptops, but their focus has been on the EC and firmware tooling. Purism’s Librem lineup has remained Intel-only for precisely the PSP concerns mentioned above.

Star Labs adding AMD to their coreboot lineup matters because it normalizes the expectation that AMD consumer hardware can run open firmware. Every successful port builds community knowledge, documents the AGESA integration process more clearly, and makes the next port easier. The coreboot board status page for AMD platforms has been growing, and the StarBook port will likely contribute patches upstream.

For users, the practical benefits of coreboot on any modern laptop are real but not always dramatic. Boot times improve; on coreboot systems, POST can complete in under a second compared to several seconds on AMI or Insyde firmware. The firmware attack surface shrinks because coreboot’s codebase is significantly smaller than proprietary BIOS implementations. The build is reproducible, so you can verify that the binary you flash matches the source. And crucially for Linux users, coreboot tends to have better ACPI table quality because it’s written by people who use Linux and care whether suspend/resume works.

The firmware gap between AMD and Intel on developer-friendly hardware has been narrowing. Star Labs completing the AMD StarBook port is evidence that the gap is real, workable, and closing.