Year: 2025

Announcing the coreboot release 25.06

coreboot 25.06

The coreboot project is pleased to announce the release of coreboot 25.06, another milestone in our work promoting the use of open-source firmware. This release incorporates almost 900 commits from more than 120 contributors, including 28 first time contributors. It brings enhanced boot splash screen capabilities, improved build tooling support, and expanded wireless power management features. Along with these headline improvements, we’ve delivered numerous stability enhancements and infrastructure updates that strengthen coreboot’s foundation across all supported platforms.

As always, the coreboot project extends our appreciation to everyone who contributed to this release. From seasoned developers submitting complex patches to newcomers providing valuable feedback and testing, your collective efforts make each coreboot release better than the last. The continued growth of our contributor base demonstrates the strength and vitality of the open firmware community.

The next coreboot release, 25.09, is scheduled for the end of September 2025.

Project Updates

  • In the past several months, the coreboot project has worked to help groups who can’t always push their code directly to the main development branch, offering to host separate branches and separate repositories for this work. A document wirh more details will be uploaded shortly.
  • The coreboot project has had bi-weekly leadership meetings where project issues are discussed for a number of years, but they’ve always been at a time which makes it difficult for people in Asia to attend. We are going to start a second meeting on the same day as the existing meeting, but at a better time for Asia. Check the coreboot calendar for details: https://www.coreboot.org/calendar.html
  • After many years, the coreboot mascot finally has a name: Blitz, the corebunny. This is a reference to the boot speed which can be achieved through using the coreboot project, and reflects the design intent of the logo, a European Brown Hare, which is very adaptable and runs at speeds of up to 72 km/h (45 mph).

Significant or interesting changes

{lib, drivers/intel}: Enhanced boot splash screen framework

A comprehensive overhaul of the boot splash screen infrastructure introduces support for multiple logo types and improved rendering capabilities. The new framework adds bmp_load_logo_by_type() function (be5609bdaf, 4373eea5d8) to enable platform-specific logo selection, while introducing splash screen footer support for better brand presentation.

The enhanced system includes horizontal logo alignment controls (dfeaead9f2) and configurable footer bottom margins (97f92d5c69), providing OEMs with greater flexibility in customizing the boot experience. Additionally, the framework now tracks splash screen rendering completion (4c446751c6) through commonlib, enabling better coordination between firmware phases and payload handoff.

Low-battery mode detection has been integrated into the splash screen system, automatically suppressing OEM footers when battery levels are critical (d309a9dfa8). This ensures essential power information takes precedence during low-power boot scenarios, improving user experience on battery-powered devices.

util/cbfstool: Multi-ELF support for advanced payload configurations

The cbfstool utility has been extended with multi-ELF support (0dcea61e7c), enabling more sophisticated payload packaging and deployment scenarios. This enhancement allows firmware developers to bundle multiple ELF binaries within a single CBFS entry, facilitating complex boot scenarios where multiple components need to be loaded simultaneously.

The implementation provides better flexibility for hypervisor deployments, multi-stage bootloaders, and security-enhanced boot configurations where isolation between components is critical. This feature particularly benefits platforms requiring trusted execution environments or compartmentalized boot processes.

drivers/wifi/generic: Advanced Power Reduction Features

Implementation of both Wi-Fi and Bluetooth Power Reduction Request (PRR) DSM functions (d92b6163e7, efa24540b0) significantly improves power management capabilities for wireless subsystems. These ACPI methods enable operating systems to request aggressive power savings during idle periods or when specific wireless functions are not required.

The PRR implementation follows Microsoft’s Modern Standby specifications, allowing Windows and other operating systems to achieve deeper sleep states by coordinating with wireless hardware. This results in improved battery life on mobile platforms and better thermal management on passively cooled systems.

security/vboot: Enhanced boot phase integrity management

The vboot subsystem now includes CMOS data backup during later boot phases (bf330f2dd0), providing additional protection against unexpected power events during firmware execution. This change ensures that critical configuration data remains consistent even if power is lost during complex initialization sequences.

A new VBOOT_EC_SYNC_ESOL Kconfig option (ac4503d0dd) has been introduced to provide finer control over Embedded Controller synchronization behavior. This allows platforms to optimize EC update procedures based on their specific hardware requirements and boot time constraints.

Additionally, MRC cache measurements as runtime data (b5581d556b) have been integrated into the trusted boot chain, ensuring that memory training data integrity is verified as part of the overall system attestation process.

Build system improvements: GCC 15 compatibility and toolchain updates

Comprehensive work has been completed to ensure compatibility with GCC 15, including fixes for the new -Werror=unterminated-string-initialization warning (73cc8a413a). The build system now properly handles modern compiler requirements while maintaining backward compatibility with existing toolchain versions.

The crossgcc build system has been enhanced with RISC-V ISA specification support (89e4fff2d3), enabling more precise control over RISC-V target architectures. This improvement allows developers to build optimized firmware for specific RISC-V implementations while ensuring compatibility across the diverse RISC-V ecosystem.

Submodule management has been significantly improved with better path handling (c4eb645a0b) and enhanced logging (f2310ab35e), making it easier for developers to track third-party component updates and maintain consistent build environments.

Enhanced SoC support: Emerald Rapids and Panther Lake

Support for Intel’s 5th Generation Xeon Scalable Processors (Emerald Rapids) has been added (9d878fc6c0), bringing coreboot to Intel’s latest server and workstation platforms. This implementation includes support for the expanded feature set and improved power management capabilities of the Emerald Rapids architecture.

Panther Lake support continues to evolve with new SKU additions (b879342fe6) and VR Fast Vmode threshold optimizations (e58883aace). The refactored SoC configuration (cf5696834b) provides a cleaner foundation for supporting the full range of Panther Lake variants as they become available.

Documentation: Clarification of contributor responsibilities and AI tool usage

A significant policy clarification has been added to the project documentation (9ddc9cbfc9) addressing contributor responsibilities, particularly in the context of modern development practices including the use of AI-assisted tools. This addition reinforces that submitters bear full responsibility for ensuring their contributions meet coreboot’s quality standards and comply with all applicable licensing requirements, regardless of how the code was generated or authored.

The new documentation explicitly states that contributors must have all necessary rights to submit their work under coreboot’s licenses, and that violations of third-party rights will result in code removal or replacement. This policy applies universally, encompassing contributions created through various means including generative AI tooling, ensuring the project maintains clear legal standing and quality expectations.

This clarification provides important guidance to the growing coreboot community as development practices evolve, establishing clear expectations while allowing contributors the flexibility to use whatever tools help them create high-quality firmware code.

Additional coreboot changes

  • Exposed ALWAYS_ALLOW_ABOVE_4G_ALLOCATION in Kconfig for x86 to fix Resizable BAR support on modern GPUs.
  • Enhanced PCI support with SR-IOV Virtual Function BAR resource assignment capabilities
  • Improved SPI driver support for forced 4-byte address mode operation via 0xB7 command sequences
  • Numerous MediaTek MT8189 and MT8196 platform enhancements including eDP, DDP, and AUXADC driver improvements
  • Enhanced memory initialization support across multiple Intel platforms with improved timing and reliability
  • Expanded superio support with addition of Fintek f81966d controller
  • Improved ELOG handling for later boot phase operations
  • Enhanced SMMSTORE driver with 64-bit MMIO address support
  • Comprehensive timing infrastructure improvements with early chip initialization timestamps
  • Libpayload updates focused on ARM64 DMA and MMU fixes, build system improvements, and support for large USB mass storage devices.
  • Add documentation on devicetree, sconfig, cbmem and device operations.
  • Contributor guides updated with new commit message policy, Gerrit instructions, and collaboration details.

Changes to external resources

Toolchain updates

  • Fix GMP build on GCC 15
  • Add a RISCV_ISA_SPEC variable to the toolchain build script to allow for specifying the RISC-V ISA version.

Git submodule pointers

  • arm-trusted-firmware: Update from commit id e5a1f4abee to 9109143417 (523 commits)
  • fsp: Update from commit id 86c9111639 to cc36ae2b57 (9 commits)
  • intel-microcode: Update from commit id 8a62de41c0 to eeb93b7a81 (1 commit)

External payloads

  • edk2: Update default branch for MrChromebox repo to 2025-02

Platform Updates

Added mainboards:

  • ASUS H61M-A/USB3
  • CWWK CW-ADL-4L-V1.0
  • CWWK CW-ADLNTB-1C2L-V3.0
  • Google Anakin
  • Google Baze
  • Google Bluey
  • Google Brox RTK EC
  • Google Epic
  • Google Fatcat4ES
  • Google Fatcatite4ES
  • Google Fatcatnuvo4ES
  • Google Felino4ES
  • Google Kaladin
  • Google Kinmen
  • Google Obiwan
  • Google Ocelot4ES
  • Google Ocelotite
  • Google Ocelotite4ES
  • Google Ocelotmchp
  • Google Ocelotmchp4ES
  • Google Pujjocento
  • Google Pujjolo
  • Google Quenbi
  • Google Yoda
  • Intel Google Chrome EC
  • MiTAC Computing R520G6SB
  • MiTAC Computing SC513G6
  • NovaCustom V540TNx (14″)
  • NovaCustom V560TNx (16″)
  • Siemens MC RPL1
  • Star Labs Byte Mk III (N355)
  • System76 darp11
  • System76 lemp13

Updated SoCs

  • Added qualcomm/x1p42100

Statistics from the 25.03 to the 25.06 release

  • Total Commits: 882
  • Average Commits per day: 9.85
  • Total lines added: 73906
  • Average lines added per commit: 83.79
  • Number of patches adding more than 100 lines: 85
  • Average lines added per small commit: 40.39
  • Total lines removed: 15766
  • Average lines removed per commit: 17.88
  • Total difference between added and removed: 58140
  • Total authors: 128
  • New authors: 34

Expanding Collaboration: New Ways to Engage with the coreboot Project

The coreboot project has always thrived on community contributions and collaboration. As the open-source firmware ecosystem continues to grow, we’re introducing several new initiatives to make it easier for companies, organizations, and individuals to engage with our project. Whether you’re a seasoned firmware developer or new to the coreboot community, we want to lower the barriers to participation and create more flexible pathways for contribution.

New Collaboration Models

We are offering these to facilitate work on coreboot done by various groups. There are obviously rules and expectations between the parties associated with these hosting options which will be fully documented as we work more closely with groups to implement these.

Private Development Repositories

We understand that not every organization is ready to develop in the open from day one. To accommodate this reality while still encouraging eventual open-source contributions, we’re now offering private git repositories hosted by the coreboot project. These repositories provide a space for companies or groups to develop coreboot implementations before they’re ready for public release.

A few important notes about this offering:

  • These repositories are intended to be relatively short-lived, with the expectation that work will eventually be merged back into the main coreboot repository.
  • While we’ll do our best to maintain privacy, contributors are ultimately responsible for any data posted to these repositories. We cannot provide absolute guarantees of privacy.
  • This approach allows organizations to become familiar with coreboot’s codebase and development practices in a controlled environment.

These can be useful when different groups are collaborating on a project, making it difficult to host the project somewhere that one group or another can’t access.

Public Development Branches

For organizations ready to work in the open but wanting more flexibility, we’re introducing the ability for companies to create public branches in the main coreboot git repository. These branches offer several advantages:

  • Like working in the private repos, this helps with familiarity with coreboot’s processes while allowing for faster development cycles
  • Flexibility in workflow: branches can either use or bypass gerrit code review
  • Optional Jenkins test integration
  • No binary files allowed, maintaining our source-only approach
  • As with private repositories, the end goal is integration with the main coreboot branch

This option provides an excellent middle ground between fully independent development and direct contribution to the master branch, allowing organizations to work at their own pace while still being part of the public coreboot ecosystem.

Enhanced Community Engagement

Beyond code repositories, we’re implementing several initiatives to strengthen relationships between the coreboot project and various stakeholders:

Direct Communication Channels

We’re offering to set up one-time or ongoing public meetings with companies, groups, or individuals interested in coreboot development. These meetings can serve multiple purposes:

  • Technical discussion of specific implementations
  • Strategic planning for collaborative projects
  • Community outreach and education
  • Addressing specific challenges or obstacles

Leadership Representation

To ensure that industry perspectives are well-represented in project governance, we’re adding “Official” company representatives to the coreboot leadership meetings. This gives organizations a direct voice in project direction while maintaining our community-driven approach.

Collaborative Content Development on the coreboot Blog

We’re eager to work with companies and individuals to create blog posts about upcoming projects and initiatives. This helps communicate plans to the wider community, generates anticipation for new features, and provides visibility for contributors.

Looking Ahead: How Can We Help You?

These initiatives represent our current efforts to make coreboot more accessible and collaborative, but we recognize that there may be other ways we can support the community. We want to hear from you: What else can the coreboot project do to help you engage with our community and contribute to open-source firmware development?

Whether you’re a large hardware manufacturer, a small group of enthusiasts, or an individual developer, we’re committed to finding ways to support your involvement with coreboot. Reach out to us with your ideas, challenges, and suggestions.

Getting Started

If you’re interested in any of these collaboration options, please contact the coreboot project leadership team or post to the coreboot mailing list. We’ll work with you to determine the best approach for your specific needs and objectives. See the coreboot website for contact details.

The future of open-source firmware depends on active participation from diverse contributors. With these new engagement pathways, we hope to welcome even more participants into the coreboot ecosystem, ultimately advancing our shared goal of free, open, and secure firmware for everyone.

coreboot 25.03 has been released!

The coreboot project is pleased to announce the release of coreboot 25.03, marking another milestone in our ongoing work to delivering open-source firmware. This release brings important improvements to display handling, USB debugging capabilities, and CPU topology management, along with various other enhancements that further improve the reliability and performance of coreboot across supported platforms.

We extend our sincere thanks to all contributors who have made this release possible. Your expertise and collaborative efforts continue to propel the coreboot project forward. As always, we value the participation of everyone in the community, from long-time developers to those new to the project.

The next coreboot release, 25.06, is scheduled for the end of June 2025.

Significant or interesting changes

drivers/intel/fsp2_0: Enable panel-orientation aware bitmap rotation

Implement logo bitmap rotation within fsp_convert_bmp_to_gop_blt() to support devices with portrait-oriented displays. The rotation is driven by the panel framebuffer orientation, allowing the logo to be displayed correctly regardless of physical panel orientation.

This resolves issues where the logo was displayed incorrectly on portrait-oriented displays.

Additionally, discard the display orientation change if the LID is closed aka built-in display is not active. This will ensure that display orientation is proper when extended display is attached w/o any display rotation.

util/find_usbdebug: Fix lsusb -t parsing for usbutils v016 and newer

Commit e24294ff9ade (“lsusb -t: print ports and buses and devices with same width”) [1] in the usbutils repository changed the format of the lsusb -t output, breaking the find_usbdebug.sh script. This commit is present in usbutils version 016 and later.

Use the output of lsusb -V to set the parsing patterns based on the version in order to maintain compatibility with older versions of usbutils. A simple integer comparison of the version number is used for this, which will not work with versions older than v001 as those use a 0.nn version number format. However, since v001 was released in late 2010, it is probably safe to assume that no one will be using a version of usbutils older than that. Usbutils v016 was released in late 2023 so there could still conceivably be systems using older versions, such as Ubuntu 22.04 LTS which is on v014.

[1] https://github.com/gregkh/usbutils/commit/e24294ff9ade6dafcd1909763e888d97b377c841

cpu/x86/topology: Fix FSP-S crash caused by shared core ID

This resolves a crash issue observed on Meteor Lake and introduced by commit 70bdd2e1fad9fe89835aab240ed4b41a02f15078 (“cpu/x86/topology: Simplify CPU topology initialization”). This commit simplifies the code and provides more detailed CPU topology information by generalizing the use of the Extended Topology Enumeration Leaves 0x1f. As a result, the coreboot APIC core_id field does not provide the fully detailed path information.

It turns out that the topology core identifier is used by the coreboot MP service mp_get_processor_info() implementation. But the MP Service EFI_CPU_PHYSICAL_LOCATION data structure only captures information about the package, core, and thread. The core identifier returned to the MP service caller must incorporate the full hierarchical path (die group, die, module, tile, module and core).

This commit adds a new field to the cpu topology structure to represent the core ID within the package.

For reference, here is that signature of the crash:

   LAPIC 0x40 in X2APIC mode.
   CPU Index 2 - APIC 64 Unexpected Exception:13 @ 10:69f3d1e4 - Halting
   Code: 0 eflags: 00010046 cr2: 00000000
   eax: 00000001 ebx: 69f313e8 ecx: 0000004e edx: 00000000
   edi: 69f38018 esi: 00000029 ebp: 69aeee0c esp: 69aeedc0
   [...]

The crash occurred when FSP attempted to lock the Protected Processor Inventory Number Enable Control MSR (IA32_PPIN_CTL 0x4e).

   69f3d1d3:	8b 43 f4            	mov	-0xc(%ebx),%eax
   69f3d1d6:	89 4d c4            	mov	%ecx,-0x3c(%ebp)
   69f3d1d9:	89 45 dc            	mov	%eax,-0x24(%ebp)
   69f3d1dc:	8b 55 c4            	mov	-0x3c(%ebp),%edx
   69f3d1df:	8b 45 c0            	mov	-0x40(%ebp),%eax
   69f3d1e2:	8b 4d dc            	mov	-0x24(%ebp),%ecx
   69f3d1e5:	0f 30               	wrmsr
   69f3d1e7:	e9 ee fd ff ff      	jmp	0xfffffe39

FSP experiences issues due to attempting to lock the same register multiple times for a single core. This is caused by an inconsistency in the processor information data structure, where multiple cores share the same identifier. This is not permitted and triggers a General Protection Fault Exception.

{drivers, lib}: Move low-battery user notification logic outside FSP

This patch refactors low-battery user notification logic (Kconfig, APIs to check if low-battery rendering is required, low-battery shutdown is required) outside FSP driver code to ensure in future non-FSP platforms might still be able to leverage this feature/logics to render the low-battery indicator icon during boot.

Specifically, it:

  • Moves Kconfig options related to low-battery notifications from drivers/intel/fsp to lib/
  • Relocates the low-battery check and shutdown APIs drivers/intel/fsp to bootsplash.h
  • Adjusts the vendor driver to utilize the new APIs for low-battery rendering decisions.
  • Drop the unwanted header file “fsp/api.h” from bmp_logo.c

This change avoids tight coupling of low-battery functionality to FSP, promoting code reusability across platforms.

soc/intel/cannonlake: Use common ACPI code for SRAM and HECI

Use the newly-created ACPI devices in common/acpi, and adjust the SoC ACPI name for the CSE/HECI device to match.

lib: Introduce early power off support Kconfig option

This commit introduces the HAVE_EARLY_POWEROFF_SUPPORT Kconfig option and the platform_do_early_poweroff() API.

The Kconfig option enables platform-specific early power off support, which is often required on Intel platforms. The corresponding API allows platforms to implement the necessary hardware operations for early power off, typically before memory initialization.

Additional coreboot changes

  • Numerous changes to Haswell open source ram init
  • Numerous additions to intelp2m tool
  • Enhanced power management and thermal control across multiple platforms
  • Improved USB Type-C and Thunderbolt support
  • Added support for early power off and low battery detection
  • Enhanced display and graphics support across multiple platforms
  • Improved memory initialization and training
  • Added support for various new memory parts and configurations
  • Enhanced ACPI support and device handling
  • Improved security features and TPM support
  • Enhanced EC (Embedded Controller) support across platforms
  • Added support for various new touch panels and input devices
  • Refactored and improved code organization across multiple subsystems
  • Enhanced build system and toolchain support
  • Improved documentation and testing infrastructure
  • Added support for RISC-V architecture improvements
  • Enhanced debugging and logging capabilities
  • Improved error handling and recovery mechanisms
  • Added 7500 MT/s support for DDR5

Changes to external resources

Toolchain updates

  • Update CMake from 3.30.2 to 3.31.3
  • Update ACPICA from 20230628 to 20241212

Git submodule pointers

  • arm-trusted-firmware: Update from commit id 15e5c6c91d to e5a1f4abee (608 commits)
  • blobs: Update from commit id 14f8fcc1b4 to a0726508b8 (10 commits)
  • fsp: Update from commit id 851f7105d8 to 86c9111639 (30 commits)
  • intel-microcode: Update from commit id 8ac9378a84 to 8a62de41c0 (1 commits)
  • vboot: Update from commit id f1f70f46dc to 3f94e2c7ed (49 commits)

Platform Updates

Added mainboards:

  • AMD Crater for Renoir SoC
  • ASROCK Z87 Extreme3
  • ASROCK Z87 Extreme4
  • ASROCK Z87M Extreme4
  • ASROCK Z87 Pro4
  • ASUS P8H67-I DELUXE
  • Google Dirks
  • Google Guren
  • Google Meliks
  • Google Moxie
  • Google Ocelot
  • Google Pujjoniru
  • Google Quandiso2
  • Google Wyrdeer
  • HP Pro 3400 Series
  • Intel Ptlrvp
  • Lenovo ThinkCentre M900
  • NovaCustom V540TU (14″)
  • NovaCustom V560TU (16″)
  • StarLabs StarLite Mk V Smart Battery (N200)
  • StarLabs StarBook Mk VII (165H)
  • StarLabs StarBook Mk VII (N200)

Updated SoCs

  • Added src/soc/xilinx/zynq7000

Statistics from the 24.12 to the 25.03 release

  • Total Commits: 1001
  • Average Commits per day: 10.05
  • Total lines added: 88158
  • Average lines added per commit: 88.07
  • Number of patches adding more than 100 lines: 97
  • Average lines added per small commit: 40.48
  • Total lines removed: 22900
  • Average lines removed per commit: 22.88
  • Total difference between added and removed: 65258
  • Total authors: 131
  • New authors: 29

Significant Known and Open Issues

coreboot-wide or architecture-wide issues

  • 519: make gconfig – could not find glade file
  • 518: make xconfig – g++: fatal error: no input files

Payload-specific issues

  • 577: SeaBIOS/EDK2 Windows 10 BSOD “UNSUPPORTED PROCESSOR”
  • 552: X201 not booting with edk2 payload
  • 549: SeaBIOS Windows 10/11 BSOD “ACPI BIOS ERROR” (Thinkpad W530)
  • 499: edk2 boot fails with RESOURCE_ALLOCATION_TOP_DOWN enabled
  • 496: Missing malloc check in libpayload
  • 484: No USB keyboard support with secondary payloads
  • 414: X9SAE-V: No USB keyboard init on SeaBIOS using Radeon RX 6800XT

Platform-specific issues

  • 579: MAC address set by coreboot to RTL8111F does not persist
  • 565: Wifi card not recognized on Lenovo M700 tiny
  • 563: tty doesn’t show on external display using edk2 on W530
  • 548: Lenovo X201 Fails To Recognize Upgraded WiFi Card
  • 538: x230: Dock Causes Internal Display to “Permanently” Malfunction
  • 535: T420: Power light stays off after reboot
  • 528: Building qemu-i440fx with CONFIG_CBFS_VERIFICATION fails
  • 524: X2APIC Options cause Linux to crash on emulation/qemu-i440fx
  • 517: lenovo x230 boot stuck with connected external monitor
  • 509: SD Card hotplug not working on Apollo Lake
  • 506: APL/GML don’t boot OS when CPU microcode included “from tree”
  • 505: Harcuvar CRB – 15 of 16 cores present in the operating system
  • 499: T440p – EDK2 fails with RESOURCE_ALLOCATION_TOP_DOWN enabled
  • 495: Stoney Chromebooks not booting PSPSecureOS
  • 478: X200 booting Linux takes a long time with TSC
  • 474: X200s crashes after graphic init with 8GB RAM
  • 457: Haswell (t440p): CAR mem region conflicts with CBFS_SIZE > 8mb
  • 453: Intel HDMI / DP Audio not present in Windows after libgfxinit
  • 449: ThinkPad T440p fail to start, continuous beeping & LED blinking
  • 448: Thinkpad T440P ACPI Battery Value Issues
  • 446: Optiplex 9010 No Post
  • 439: Lenovo X201 Turbo Boost not working (stuck on 2,4GHz)
  • 427: x200: Two battery charging issues
  • 412: x230 reboots on suspend
  • 393: T500 restarts rather than waking up from suspend
  • 350: I225 PCIe device not detected on Harcuvar