Framework advances Coreboot support for Intel Laptop 13 mainboards

Framework engineers have added Coreboot support for the 13-inch Framework Laptop 13 with Intel Core Ultra Series 1, also known as Meteor Lake, and have started downstream work for the coming Core Ultra Series 3 Panther Lake model.

The upstream Coreboot tree now includes Marigold, Framework’s board name for the Meteor Lake Laptop 13. Framework’s downstream repository also gained Sakura, the board name for the Panther Lake Laptop 13. Michael Larabel reported the Coreboot activity Monday on Phoronix, citing the recent upstream merge and Framework’s downstream work.

The Meteor Lake support gives Coreboot builders a base target for a current Framework Intel laptop, though Framework engineers still have firmware work to finish before users should treat it like a drop-in replacement for vendor firmware.

Product

Framework built its reputation around repairable laptops, replaceable mainboards and published service paths. Coreboot support fits that model because firmware controls the lowest layer of the machine: silicon init, memory training handoff, ACPI tables, embedded controller integration and early boot policy.

Coreboot support also matters for homelab users who keep laptops in service after a mainboard swap. A Framework Laptop 13 can move from a daily driver into a low-power build server, router lab node or CI runner. Open firmware gives those users more visibility into platform behavior than a sealed firmware stack.

The new upstream target covers the Framework Laptop 13 with Intel Core Ultra Series 1. Intel launched Meteor Lake with tiled silicon, an integrated NPU, updated graphics and a power-management model that leans on platform firmware. That makes Coreboot support more complex than older laptop ports because the firmware must coordinate with Intel silicon packages, the embedded controller, ACPI and operating-system drivers.

Framework’s Panther Lake work sits downstream for now. That matters because Panther Lake has not reached the same public hardware maturity as Meteor Lake, yet Framework engineers have begun board enablement ahead of broad user availability.

Firmware status

Framework engineers have Marigold in upstream Coreboot, with build notes and support status documented in the project’s tree. The reported working set covers much of the boot path, but several laptop-specific interfaces still need validation or additional ACPI work.

Area	Meteor Lake Marigold status
Coreboot target	Upstream support merged
Embedded controller ACPI	Required for remaining input and power features
Built-in keyboard	Needs correct EC ACPI code
Touchpad and PS/2 emulation	Needs correct EC ACPI code
cros_ec OS driver	Needs correct EC ACPI code
Battery and AC reporting	Needs correct EC ACPI code
Thunderbolt 4 and USB4	Test status open
s0ix low-power idle	Test status open

The unresolved items concentrate around laptop integration rather than basic board bring-up. Keyboard, touchpad, battery state and AC state depend on ACPI tables that describe hardware behavior to the operating system. Linux can boot on a board and still feel incomplete if those tables fail to expose input devices or power data in the expected form.

Thunderbolt 4 and USB4 need separate attention because those ports mix high-speed I/O, hotplug, security policy and firmware handoff. A user can run a laptop without Thunderbolt validation, but a workstation dock, external GPU enclosure or high-speed storage setup will expose flaws fast.

s0ix also deserves measurement. Intel’s modern standby path can make or break laptop battery life. A machine that boots and runs benchmarks can still drain a pack overnight if firmware, the kernel and device drivers fail to enter the right idle states.

Performance data

Framework and Coreboot contributors have not published benchmark numbers for the Marigold port in the report. That limits direct performance claims. Firmware can affect boot time, idle power, thermal behavior and device availability, but CPU throughput should stay close to stock firmware after the operating system takes control and applies the same power limits.

A useful test plan for this port should cover three buckets:

Test	Why builders should measure it
Cold boot to bootloader	Coreboot can change platform init time
Idle package power	ACPI and s0ix quality show up in battery drain
Dock and USB4 storage throughput	Thunderbolt policy and hotplug can expose firmware gaps

For a homelab builder, the most useful first benchmark would compare stock firmware against Coreboot on the same Framework Laptop 13 mainboard with the same SSD, memory and Linux kernel. The run should log wall power at the adapter, Intel RAPL package power, battery discharge rate, suspend residency and boot time.

A simple Linux test stack could use systemd-analyze, turbostat, powertop, fwts and stress-ng. A USB4 storage test could use fio with the same enclosure and cable on both firmware builds. Dock tests should include display output, USB devices, Ethernet and hotplug after resume.

Power data matters more than peak CPU scores for this firmware work. Meteor Lake systems can post strong short-burst numbers under many firmware stacks, but bad idle behavior punishes laptop users across hours. A Coreboot build that saves seconds at boot yet loses s0ix residency would make a poor daily-driver firmware.

Compatibility

Coreboot support does not remove the platform’s dependence on Intel firmware components. Modern Intel laptops still need silicon initialization pieces and management firmware paths that open-source developers cannot replace in full. Coreboot can reduce the proprietary surface and improve auditability, but users should expect blobs in the build chain for a current Intel mobile platform.

The embedded controller also anchors Framework’s input and power reporting path. The report names the cros_ec OS driver, keyboard, touchpad, battery and AC state as areas that depend on correct EC ACPI code. That points to a familiar laptop firmware problem: the CPU can start Linux, yet the machine needs careful ACPI descriptions before it behaves like a laptop.

Framework’s modular expansion-card system adds another compatibility layer. USB-C ports, display adapters, storage cards and docks need test coverage across suspend, resume and hotplug. Builders who rely on a specific dock should wait for validation or prepare to test it themselves.

Build recommendations

Developers and firmware testers can treat the Meteor Lake target as a starting point. Daily-driver users should wait until Framework or Coreboot maintainers document the open input, power and s0ix items as tested.

A practical test machine should have recovery options before any firmware flash. Keep a known-good firmware image, a hardware programmer path and a second computer ready. Framework’s repairable design helps here, but firmware recovery still demands care.

Linux users should pair the Coreboot build with a current kernel and recent linux-firmware package. Meteor Lake platform support improved across recent kernel releases, and older distributions may hide firmware bugs behind missing driver support.

Coreboot builders should track the Coreboot documentation and Framework’s public source work, then compare the board status against their own hardware revision. A Laptop 13 board name matters; Marigold points to Meteor Lake, and Sakura points to Panther Lake.

For now, Framework’s work gives firmware developers a credible path into modern Intel Laptop 13 support. The next meaningful milestones are input-device completion, battery and AC reporting, USB4 validation and measured s0ix behavior. Those pieces will decide whether Coreboot on these laptops stays a developer project or becomes a firmware option that power users trust.