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.

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

coreboot Links and Contact Information

• Main Web site: https://www.coreboot.org
• Downloads: https://coreboot.org/downloads.html
• Source control: https://review.coreboot.org
• Documentation: https://doc.coreboot.org
• Issue tracker: https://ticket.coreboot.org/projects/coreboot
• Donations: https://coreboot.org/donate.html

Recently there was a blog post by MALIBAL, a disgruntled laptop vendor who attempted to port coreboot to their rebranded white label laptop. The cause of the kerfuffle they describe is that they failed in their own attempt to port coreboot to their laptop, then approached a few of our consultants and community members claiming the code was “80+%” complete and that they just needed help with “debugging.”

Each attempt was terminated in the evaluation phase, however, as the consultants and vendor disagreed on the amount of remaining effort and the supplied hardware had problems (flash read/write problems, UART access barely possible) which could not be resolved easily. Additionally, this person’s attitude and communication style was, to put it mildly, very off-putting.

We won’t do a point-by-point rebuttal of their screed since others have already done so in various other forums. However, it is important to emphasize that aside from NDAs which are common for new product development, no contracts or statements of work were signed and no money changed hands. Any suggestion from this vendor’s blog that a coreboot consultant failed to deliver on work they were hired or paid to do is false and defamatory.

Our consultants have a strong track record of delivering for their customers on a variety of platforms including embedded systems, laptops and desktops, networking equipment, and servers. They’re also very friendly and will be happy to help scope out your next product needing simple, fast, and secure firmware.

Update: 9elements Cybersecurity has posted their side of the story here: https://9esec.io/blog/response-to-recent-malibal-blog-post-regarding-9elements/

We are pleased to announce the release of coreboot 24.08, another significant milestone in our ongoing commitment to delivering open-source firmware solutions. This release includes over 900 commits, contributed by more than 130 dedicated individuals from our global community. The updates in 24.08 bring various enhancements, optimizations, and new features that further improve the reliability and performance of coreboot across supported platforms.

We extend our sincere thanks to the patch authors, reviewers, and everyone involved in the coreboot community for their hard work and dedication. Your contributions continue to advance and refine coreboot with each release. As always, thank you for your support and collaboration in driving the future of open-source firmware.

The next coreboot release, 24.11 is planned for mid-November.

You can find the release on the coreboot downloads site:
https://coreboot.org/downloads.html

Significant or interesting changes

Introduce region_create() functions

We introduce two new functions to create region objects. They allow us to check for integer overflows (region_create_untrusted()) or assert their absence (region_create()).

This fixes potential overflows in region_overlap() checks in SMI handlers, where we would wrongfully report MMIO as not overlapping SMRAM.

Also, two cases of strtol() in parse_region() (cbfstool), where the results were implicitly converted to size_t, are replaced with the unsigned strtoul().

FIT payload support is left out, as it doesn’t use the region API (only the struct).

Ticket: https://ticket.coreboot.org/issues/522
Review: https://review.coreboot.org/79905

lib/device_tree: Add some FDT helper functions

This adds some helper functions for FDT (Flattened Device Tree) , since more and more mainboards seem to need FDT nowadays. For example our QEMU boards need it in order to know how much RAM is available. Also all RISC-V boards in our tree need FDT.

This also adds some tests in order to test said functions.

Review: https://review.coreboot.org/c/coreboot/+/81081

device_tree: Add function to get top of memory from a FDT blob

coreboot needs to figure out top of memory to place CBMEM data. On some non-x86 QEMU virtual machines, this is achieved by probing the RAM space to find where the VM starts discarding data since it’s not backed by actual RAM. This behavior seems to have changed on the QEMU side since then, VMs using the “virt” model have started raising exceptions/errors instead of silently discarding data (likely [1] for example) which has previously broken coreboot on these emulation boards.

The qemu-aarch64 and qemu-riscv mainboards are intended for the “virt” models and had this issue, which was mostly fixed by using exception handlers in the RAM detection process [2][3]. But on 32-bit RISC-V we fail to initialize CBMEM if we have 2048 MiB or more of RAM, and on 64-bit RISC-V we had to limit probing to 16383 MiB because it can run into MMIO regions otherwise.

The qemu-armv7 mainboard code is intended for the “vexpress-a9” model VM which doesn’t appear to suffer from this issue. Still, the issue can be observed on the ARMv7 “virt” model via a port based on qemu-aarch64.

QEMU docs for ARM and RISC-V “virt” models [4][5] recommend reading the device tree blob it provides for device information (incl. RAM size). Implement functions that parse the device tree blob to find described memory regions and calculate the top of memory in order to use it in mainboard code as an alternative to probing RAM space. ARM64 code initializes CBMEM in romstage where malloc isn’t available, so take care to do parsing without unflattening the blob and make the code available in romstage as well.

[1] https://lore.kernel.org/qemu-devel/1504626814-23124-1-git-send-email-peter.maydell@linaro.org/T/#u
[2] https://review.coreboot.org/c/coreboot/+/34774
[3] https://review.coreboot.org/c/coreboot/+/36486
[4] https://qemu-project.gitlab.io/qemu/system/arm/virt.html
[5] https://qemu-project.gitlab.io/qemu/system/riscv/virt.html

Review: https://review.coreboot.org/c/coreboot/+/80322

drivers/wifi: Support Bluetooth Regulator Domain Settings

The ‘Bluetooth Increased Power Mode – SAR Limitation’ feature provides ability to utilize increased device Transmit power capability for Bluetooth applications in coordination with Wi-Fi adhering to product SAR (Specific Absorption Rate) limit when Bluetooth and Wi-Fi run together.

This commit introduces a `bluetooth_companion’ field to the generic Wi-Fi drivers chip data. This field can be set in the board design device tree to supply the bluetooth device for which the BRDS function must be created.

The implementation follows document 559910 Intel Connectivity Platforms BIOS Guideline revision 8.3 specification.

Review: https://review.coreboot.org/c/coreboot/+/83200

acpigen_ps2_keybd: Support Do Not Disturb & Accessibility Keys

These commits add support for a Do Not Disturb key and an Accessibility key.

HUTRR94 added support for a new usage titled “System Do Not Disturb” which toggles a system-wide Do Not Disturb setting.

HUTRR116 added support for a new usage titled “System Accessibility Binding” which toggles a system-wide bound accessibility UI or command.

HUTRR94: https://www.usb.org/sites/default/files/hutrr94_-_system_do_not_disturb.pdf
HUTRR116: https://www.usb.org/sites/default/files/hutrr116-systemaccessbilitybinding_2.pdf

Review: https://review.coreboot.org/c/coreboot/+/82997
Review: https://review.coreboot.org/c/coreboot/+/82996

superio/ite/common: Add common driver for GPIO and LED configuration

Add a generic driver to configure GPIOs and LEDs on common ITE SuperIOs. The driver supports most ITE SuperIOs, except Embedded Controllers. The driver allows configuring every GPIO property with pin granularity.

Verified against datasheets of all ITE SIOs currently supported by coreboot, except IT8721F (assumed to be the same as IT8720F), IT8623E and IT8629E.

Review: https://review.coreboot.org/c/coreboot/+/83355

util/cbfstool: Fix linux_trampoline.c generation

linux_trampoline.c generation is broken with latest crossgcc-i386 toolchain. Fix the issue to enable the building.

../cbfstool/linux_trampoline.S: Assembler messages:
../cbfstool/linux_trampoline.S:100: Error: no instruction mnemonic
	suffix given and no register operands; can't size instruction
<builtin>: recipe for target '../cbfstool/linux_trampoline.o' failed

Review: https://review.coreboot.org/c/coreboot/+/82704

Add LeanEFI payload

This adds another external payload to coreboot. The payload has been heavily based on u-boots UEFI implementation.

The LeanEFI payload is basically a translator from coreboot to UEFI. It takes the coreboot tables and transforms them into UEFI interfaces. Although it can potentially load any efi application that can handle the minimized interface that LeanEFI provides, it has only been tested with LinuxBoot (v6.3.5) as a payload. It has been optimized to support only those interfaces that Linux requires to start.

Among other LeanEFI does not support:

• efi capsule update (also efi system resource table)
• efi variables
• efi text input protocol (it can only output)
• most boot services. mostly memory services are left (e.g. alloc/free)
• all runtime services (although there is still a very small runtime footprint that is planned to be removed in the near future)
• TCG2/TPM (although that is mostly because of laziness) The README.md currently provides more details on why.

The payload currently only supports arm64 and has only been tested on emulation/simulator targets. The original motivation was to get ACPI on arm64 published to the OS without using EDK2. It is however also possible to supply the LeanEFI with a FDT that is published to the OS. At that point one would however probably use coreboot only instead of this shim layer on top. It would be way nicer to have Linux support something other than UEFI to propagate the ACPI tables, but it requires getting the Linux maintainer/community on board. So for now this shim layer circumvents that.

LBBR Test:

1. dump FDT from QEMU like mentioned in aarch64 coreboot doc
2. compile u-root however you like (aarch64)
3. compile Linux (embed u-root initramfs via Kconfig)
4. copy Linux kernel to payloads/leanefi/Image
5. copy following coreboot defconfig to configs/defconfig:

CONFIG_BOARD_EMULATION_QEMU_AARCH64=y
CONFIG_PAYLOAD_NONE=n
CONFIG_PAYLOAD_LEANEFI=y
CONFIG_LEANEFI_PAYLOAD=y
CONFIG_LEANEFI_PAYLOAD_PATH="[path-to-linux]/arch/arm64/boot/Image"
CONFIG_LEANEFI_FDT=y
CONFIG_LEANEFI_FDT_PATH="[path-to-dumped-DTB]"

6. compile coreboot:
   make defconfig
make -j$(nproc)
7. run qemu like mentioned in coreboot doc (no FIT)
8. say hello to u-root and optionally kexec into the next kernel

Review: https://review.coreboot.org/c/coreboot/+/78913

Additional coreboot changes

• Dropped ChromeEC as a submodule.
• Numerous updates to autoport tool, including Haswell support.
• Upgrade to Wuffs 0.4.0-alpha.8
• Add x86_64 (64-bit) support to LibPayload
• Add hda-decoder utility that dumps decoded HDA default configuration registers
• Add SBMIOS tables for arm64 platforms
• cpu/x86/lapic: Always have LAPIC enabled
• arch/arm64: Support calling a trusted monitor
• drivers/wifi: Support Wi-Fi 7 11be Enablement
• drivers/wifi: Support Radio Frequency Interference Mitigation

Changes to external resources

Toolchain updates

• Upgrade CMake from 3.28.3 to 3.29.3
• Upgrade nasm from 2.16.01 to 2.16.03
• Upgrade LLVM from 17.0.6 to 18.1.6
• Upgrade GCC from 13.2 to 14.1.0

Git submodule pointers

• /3rdparty/amd_blobs: Update from commit ae5fc7d277 to 26c572974b (2 commits)
• /3rdparty/arm-trusted-firmware: Update from commit 48f1bc9f52 to c5b8de86c8 (430 commits)
• /3rdparty/fsp: Update from commit cc6399e8c7 to 800c85770b (23 commits)
• /3rdparty/intel-microcode: Update from commit 41af345005 to 5278dfcf98 (2 commits)
• /3rdparty/libgfxinit: Update from commit a4be8a21b0 to 17cfc92f40 (5 commits)
• /3rdparty/vboot: Update from commit 09fcd2184f to f1f70f46dc (69 commits)

Platform Updates

New mainboards:

• Acer Q45T-AM
• AOOSTAR WTR R1
• ASROCK Fatal1ty Z87 Professional
• ASROCK Z87E-ITX
• ASROCK Z87M OC Formula
• ASROCK Z97E-ITX/ac
• CWWK CW-ADL-4L-V1.0
• Dell Inc. Latitude E6430
• Dell Inc. Latitude E7240
• Dell Inc. XPS 8300
• Emulation QEMU sbsa
• GIGABYTE GA-H61M-S2P-R3
• Google Awasuki
• Google Brox TI PDC
• Google Domika
• Google Fatcat
• Google Jubilant
• Google Orisa
• Google Rauru
• Google Rex 64
• Google Teliks
• Google Tereid
• HP EliteBook 8560w
• Intel Avenue City CRB
• Intel Beechnut City CRB
• Protectli VP6630/VP6650/VP6670
• Star Labs Star Labs Lite Mk V (N200)
• System76 addw4
• System76 darp10
• System76 darp10-b
• System76 oryp12

Updated SoCs & socket definitions

• Added src/cpu/intel/socket_LGA1700
• Added src/cpu/intel/socket_LGA3647_1
• Added src/cpu/intel/socket_LGA4189
• Added src/cpu/intel/socket_LGA4677
• Added src/soc/intel/pantherlake
• Added src/soc/mediatek/mt8196

Statistics from the 24.05 to the 24.08 release

• Total Commits: 897
• Average Commits per day: 8.81
• Total lines added: 107580
• Average lines added per commit: 119.93
• Number of patches adding more than 100 lines: 101
• Average lines added per small commit: 37.57
• Total lines removed: 18893
• Average lines removed per commit: 21.06
• Total difference between added and removed: 88687
• Total authors: 136
• New authors: 33

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

• 552 – X201 not booting with edk2 payload
• 549 – SeaBIOS Windows 10/11 BSOD “ACPI BIOS ERROR” (Thinkpad W530)
• 499 – EDK 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

• 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
• 507 – Windows GPU driver fails on Google guybrush & skyrim boards
• 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

coreboot Links and Contact Information

• Main Web site: https://www.coreboot.org
• Downloads: https://coreboot.org/downloads.html
• Source control: https://review.coreboot.org
• Documentation: https://doc.coreboot.org
• Issue tracker: https://ticket.coreboot.org/projects/coreboot
• Donations: https://coreboot.org/donate.html

The coreboot project is pleased to announce the release of coreboot version 24.05. This update represents three months of hard work and commitment from our community. With over 20 new members and contributions from more than a hundred fifty other people in coding, reviewing patches, and other areas, this release showcases the strength of our collaborative efforts.

With this release, coreboot has expanded its support, adding 25 new platforms or variants and 2 new processors, further demonstrating our dedication to offering flexible and adaptable firmware solutions. From laptops and servers to embedded devices, coreboot 24.05 is designed to enhance a variety of hardware platforms with its strong features.

We are grateful to all the contributors who have made this release possible. Your expertise and collaborative efforts continue to propel the coreboot project forward. We value the participation of everyone in the community, from long-time developers to those new to the project, and encourage you to explore the new opportunities that coreboot 24.05 offers.

Our next release will be 24.08, scheduled for mid-August.

You can find the release on the coreboot downloads site:
https://coreboot.org/downloads.html

Significant or interesting changes

Mark 64-bit support as stable

A significant amount of work has gone into fully supporting 64-bit coreboot builds. There are still additional pieces that are happening, but with SMM holding page tables itself, we can consider SMM support stable and safe enough for general use.

security/tpm: support compiling in multiple TPM drivers

Previously, boards could only be built with code supporting TPM 1.x or TPM 2.x specifications. This has been updated with code allowing both to be built in simultaneously, allowing the system to query the TPM. For systems with soldered-down TPMs or firmware TPM solutions, it’s still possible to specify a single TPM version so that the code for the other version isn’t included.

// Add entries for future releases here.
const releaseList = [
{ version: ‘24.05’, date: ’14. May 2024′ },
{ version: ‘24.02.01’, date: ’29. February 2024′ },
{ version: ‘4.22.01’,date: ’24. November 2023′ },

Previously, boards could only be built with code supporting TPM 1.x or TPM 2.x specifications. This has been updated with code allowing both to be built in simultaneously, allowing the system to query the TPM. For systems with soldered-down TPMs or firmware TPM solutions, it’s still possible to specify a single TPM version so that the code for the other version isn’t included.

arch/arm64: Add EL1/EL2/EL3 support for arm64

Previously, arch/arm64 required coreboot to run on EL3 due to EL3 register access. This might be an issue when, for example, one boots into TF-A first and drops into EL2 for coreboot afterwards.

This patch aims at making arch/arm64 more versatile by removing the current EL3 constraint and allowing arm64 coreboot to run on EL1, EL2 and EL3.

The strategy is to add a Kconfig option (ARM64_CURRENT_EL) which allows us to specify coreboot’s EL upon entry. Based on that, we access the appropriate ELx registers. So, for example, when running coreboot on EL1, we would not access vbar_el3 or vbar_el2 but instead vbar_el1. This way, we don’t generate faults when accessing higher-EL registers.

Additional coreboot changes

• util/smmstoretool: support processing ROMs
• cpu/x86: Link page tables in stage if possible
• lib/lzmadecode: Allow for 8 byte reads on 64bit to speed up decompression
• mb/lenovo/*: Set VR12 PSI to fix crash
• Numerous fixes for clang support
• Ongoing code cleanup
• Docs: Replace Recommonmark with MyST Parser. For changes, see the commit message in https://review.coreboot.org/73158

Changes to external resources

Toolchain updates

• util/kconfig: Uprev to Linux 6.8’s kconfig
• crossgcc: Upgrade CMake from 3.27.7 to version 3.28.3
• util/crossgcc: Update LLVM from 16.0.6 to 17.0.6
• crossgcc: Upgrade binutils from 2.41 to 2.42
• util/crossgcc/buildgcc: Use Intel mirror for ACPICA

Git submodule pointers

• amd_blobs: Update from commit id 64cdd7c8ef to ae5fc7d277 (1 commits)
• arm-trusted-firmware: Update from commit id 17bef2248d to 48f1bc9f52 (517 commits)
• cmocka: Update from commit id 8931845c35 to 8be3737209 (32 commits)
• fsp: Update from commit id 507ef01cce to cc6399e8c7 (14 commits)
• intel-microcode: Update from commit id ece0d294a2 to 41af345005 (1 commit)
• vboot: Update from commit id 3d37d2aafe to 09fcd2184f (27 commits)

External payloads

• payloads/U-Boot: Upgrade from U-Boot v2023.07 to v2024.4
• payloads/edk2: Add Kconfig options for LAPIC timer & UFS support
• payloads/Kconfig: Add flat binary as payload option

Platform Updates

Added mainboards:

• AMD BirmanPlus for Glinda SoC
• AMD BirmanPlus for Phoenix SoC
• ASROCK Z97 Extreme6
• Dell OptiPlex 7020/9020 MT
• Dell OptiPlex 7020/9020 SFF
• Framework Azalea (Framework 13 AMD 7040)
• Google Brox EC ISH
• Google Bujia
• Google Glassway
• Google Greenbayupoc
• Google Kyogre
• Google Lotso
• Google Nova
• Google Pujjoga
• Google Riven
• Google Skitty
• Google Squirtle
• Google Sundance
• Google Tivviks
• Google Trulo
• Google Veluza
• Google Wugtrio
• Google Yavista
• HP Pro 3500 Series
• Lenovo ThinkCentre M700 / M900 Tiny
• Lenovo ThinkCentre M710s
• Raptor Computing Systems Talos II
• SiFive HiFive Unmatched

Removed Mainboards

• Intel Alderlake-M RVP
• Intel Alderlake-M RVP with Chrome EC

Updated SoCs

• Added src/soc/ibm/power9
• Added src/soc/sifive/fu740

Statistics from the 24.02 to the 24.05 release

• Total Commits: 722
• Average Commits per day: 8.55
• Total lines added: 302523
• Average lines added per commit: 419.01
• Number of patches adding more than 100 lines: 57
• Average lines added per small commit: 37.80
• Total lines removed: 16089
• Average lines removed per commit: 22.28
• Total difference between added and removed: 286434
• Total authors: 131
• New authors: 23

Significant Known and Open Issues

coreboot-wide or architecture-wide issues

• 522 – ‘region_overlap()’ issues due to an integer overflow.
• 519 – make gconfig – could not find glade file
• 518 – make xconfig – g++: fatal error: no input files

Payload-specific issues

• 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

• 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
• 507 – Windows GPU driver fails on Google guybrush & skyrim boards
• 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

coreboot Links and Contact Information

• Main Website: https://www.coreboot.org
• Downloads: https://coreboot.org/downloads.html
• Source control: https://review.coreboot.org
• Documentation: https://doc.coreboot.org
• Issue tracker: https://ticket.coreboot.org/projects/coreboot
• Donations: https://coreboot.org/donate.html

The coreboot project is happy to announce our release for February 2024. Over the past three months, our contributors have focused on refining the coreboot codebase, generally prioritizing cleanup and quality enhancements. We extend our gratitude to all the contributors who have dedicated their time and expertise. Thank you for your invaluable contributions to this vital phase of maintenance and optimization.

The next release is scheduled for mid-May.

Release number format update

The previous release was the last to use the incrementing 4.xx release name scheme. For this and future releases, coreboot has switched to a Year.Month.Sub-version naming scheme. As such, the next release, scheduled for May of 2024 will be numbered 24.05, with the sub-version of 00 implied. If we need to do a fix or incremental release, we’ll append the values .01, .02 and so on to the initial release value.

The master branch is being deleted

The coreboot project changed from master to main roughly 6 months ago, and has been keeping the two branches in sync since then to ease the transition. As of this release, we are getting rid of the master branch completely. Please make sure any scripts you’re using that reference the ‘master’ branch have been switched to ‘main’.

Release 24.02.1

lib/rtc: Fix off-by-one error in February day count in leap year

The month argument passed to rtc\_month\_days is 0-based, not 1-based. This results in the RTC being reverted to the build date constantly on 29th February 2024.

Significant or interesting changes

acpi: Add Arm IO Remapping Table structures

Input Output Remapping Table (IORT) represents the IO topology of an Arm based system.

Document number: ARM DEN 0049E.e, Sep 2022

acpi: Add PPTT support

This patch adds code to generate Processor Properties Topology Tables (PPTT) compliant to the ACPI 6.4 specification.

• The ‘acpi_get_pptt_topology’ hook is mandatory once ACPI_PPTT is selected. Its purpose is to return a pointer to a topology tree, which describes the relationship between CPUs and caches. The hook can be provided by, for example, mainboard code.

Background: We are currently working on mainboard code for qemu-sbsa and Neoverse N2. Both require a valid PPTT table. Patch was tested against the qemu-sbsa board.

acpi: Add support for WDAT table

This commit lays the groundwork for implementing the ACPI WDAT (Watchdog Action Table) table specification. The WDAT is a special ACPI table introduced by Microsoft that describes the watchdog for the OS.

Platforms that need to implement the WDAT table must describe the hardware watchdog management operations as described in the specification. See “Links to ACPI-Related Documents” (http://uefi.org/acpi) under the heading “Watchdog Action Table”.

lib/jpeg: Replace decoder with Wuffs’ implementation

To quote its repo[0]: Wuffs is a memory-safe programming language (and a standard library written in that language) for Wrangling Untrusted File Formats Safely. Wrangling includes parsing, decoding and encoding.

It compiles its library, written in its own language, to a C/C++ source file that can then be used independently without needing support for the language. That library is now imported to src/vendorcode/wuffs/.

This change modifies our linters to ignore that directory because it’s supposed to contain the wuffs compiler’s result verbatim.

Nigel Tao provided an initial wrapper around wuffs’ jpeg decoder that implements our JPEG API. I further changed it a bit regarding data placement, dropped stuff from our API that wasn’t ever used, or isn’t used anymore, and generally made it fit coreboot a bit better. Features are Nigel’s, bugs are mine.

This commit also adapts our jpeg fuzz test to work with the modified API. After limiting it to deal only with approximately screen sized inputs, it fuzzed for 25 hours CPU time without a single hang or crash. This is a notable improvement over running the test with our old decoder which crashes within a minute.

Finally, I tried the new parser with a pretty-much-random JPEG file I got from the internet, and it just showed it (once the resolution matched), which is also a notable improvement over the old decoder which is very particular about the subset of JPEG it supports.

In terms of code size, a QEmu build’s ramstage increases from 128060 bytes decompressed (64121 bytes after LZMA) to 172304 bytes decompressed (82734 bytes after LZMA).

[0] https://github.com/google/wuffs

Additional coreboot changes

• Rename Makefiles from .inc to .mk to better identify them
• SPI: Add GD25LQ255E and IS25WP256D chip support
• device: Add support for multiple PCI segment groups
• device: Drop unused multiple downstream link support
• device: Rename bus and link_list to upstream and downstream
• Updated devicetree files for modern Intel platforms to use chipset.cb
• Updated xeon-sp to use the coreboot allocator

Changes to external resources

Toolchain updates

• Add buildgcc support for Apple M1/M2 devices
• Upgrade GCC from 11.4.0 to 13.2.0
• Update CMake from 3.26.4 to 3.27.7
• Uprev to Kconfig from Linux 6.7

Git submodule pointers

• 3rdparty/amd_blobs: Update from commit id e4519efca7 to 64cdd7c8ef (5 commits)
• 3rdparty/arm-trusted-firmware: Update from commit id 88b2d81345 to 17bef2248d (701 commits)
• 3rdparty/fsp: Update from commit id 481ea7cf0b to 507ef01cce (16 commits)
• 3rdparty/intel-microcode: Update from commit id 6788bb07eb to ece0d294a2 (1 commit)
• 3rdparty/vboot: Update from commit id 24cb127a5e to 3d37d2aafe (121 commits)

External payloads

• payload/grub2: Update from 2.06 to 2.12
• payload/seabios: Update from 1.16.2 to 1.16.3

Platform Updates

Added mainboards

• Google: Dita
• Google: Xol
• Lenovo: ThinkPad X230 eDP Mod (2K/FHD)

Removed mainboards

• Google -> Primus4ES

Statistics from the 4.22 to the 24.02 release

• Total Commits: 815
• Average Commits per day: 8.63
• Total lines added: 105433
• Average lines added per commit: 129.37
• Number of patches adding more than 100 lines: 47
• Average lines added per small commit: 41.34
• Total lines removed: 16534
• Average lines removed per commit: 20.29
• Total difference between added and removed: 88899
• Total authors: 111
• New authors: 19

Significant Known and Open Issues

• AMD chromebooks will not work with the signed PSP_verstage images and the version of verstage used in coreboot 24.02.

Issues from the coreboot bugtracker: ticket.coreboot.org

coreboot-wide or architecture-wide issues

#	Subject
522	‘region_overlap()’ issues due to an integer overflow.
519	make gconfig – could not find glade file
518	make xconfig – g++: fatal error: no input files

Payload-specific issues

#	Subject
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

#	Subject
517	lenovo x230 boot stuck with connected external monitor
509	SD Card hotplug not working on Apollo Lake
507	Windows GPU driver fails on Google guybrush & skyrim boards
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

coreboot Links and Contact Information

• Main Web site: https://www.coreboot.org
• Downloads: https://coreboot.org/downloads.html
• Source control: https://review.coreboot.org
• Documentation: https://doc.coreboot.org
• Issue tracker: https://ticket.coreboot.org/projects/coreboot
• Donations: https://coreboot.org/donate.html

The next release is planned for the 19th of February, 2024

These notes cover the latest updates and improvements to coreboot over the past three months. A big thank you to the returning contributors as well as the 14 individuals who committed code for the first time. We greatly appreciate everyone’s dedication and expertise. As with past releases, this one reflects a commitment to open source innovation, security enhancements, and expanding hardware support.

4.22.01 release

The week between tagging a release and announcing it publicly is used to test the tagged version and make sure everything is working as we expect. This is done instead of freezing the tree and doing release candidates before the release.

For the 4.22 release cycle we found an uninitialized variable error on the sandybridge/ivybridge platforms and rolled that into the 4.22.01 release package.

coreboot version naming update

This release is the last release to use the incrementing 4.xx release name scheme. For future releases, coreboot is switching to a Year.Month.Sub-version naming scheme. As such, the next release, scheduled for February of 2024 will be numbered 24.02, with the sub-version of 00 implied. If we need to do a fix or future release of the 24.02 release, we’ll append the values .01, .02 and so on to the initial release value.

coreboot default branch update

Immediately after the 4.21 release, the coreboot project changed the default git branch from ‘master’ to ‘main’. For the first couple of months after the change, The master branch was synced with the main branch several times a day, allowing people time to update any scripts. As of 2023-11-01, the sync rate has slowed to once a week. This will continue until the next release, at which time the master branch will be removed.

Significant or interesting changes

x86: support .data section for pre-memory stages

x86 pre-memory stages did not support the .data section and as a result developers were required to include runtime initialization code instead of relying on C global variable definitions.

Other platforms do not have that limitation. Hence, resolving it helps to align code and reduce compilation-based restrictions (cf. the use of ENV_HAS_DATA_SECTION compilation flag in various places of coreboot code).

There were three types of binary to consider:

1. eXecute-In-Place pre-memory stages
2. bootblock stage is a bit different as it uses Cache-As-Ram but the memory mapping and its entry code different
3. pre-memory stages loaded in and executed from Cache-As-RAM (cf. CONFIG_NO_XIP_EARLY_STAGES).

eXecute-In-Place pre-memory stages (#1) rely on a new ELF segment as the code segment Virtual Memory Address and Load Memory Address are identical but the data needs to be linked in cache-As-RAM (VMA) to be stored right after the code (LMA).

bootblock (#2) also uses this new segment to store the data right after the code and it loads it to Cache-As-RAM at runtime. However, the code involved is different.

Not eXecute-In-Place pre-memory stages (#3) did not need any special work other than enabling a .data section as the code and data VMA / LMA translation vector is the same.

Related important commits:

• c9cae530e5 (“cbfstool: Make add-stage support multiple ignore sections”)
• 79f2e1fc8b (“cbfstool: Make add-stage support multiple loadable segments”)
• b7832de026 (“x86: Add .data section support for pre-memory stages”)

x86: Support CBFS cache for pre-memory stages and ramstage

The CBFS cache scratchpad offers a generic way to decompress CBFS files through the cbfs_map() function without having to reserve a per-file specific memory region.

CBFS cache x86 support has been added to pre-memory stages and ramstage.

1. pre-memory stages: The new PRERAM_CBFS_CACHE_SIZE Kconfig can be used to set the pre-memory stages CBFS cache size. A cache size of zero disables the CBFS cache feature for all pre-memory stages. The default value is 16 KiB which seems a reasonable minimal value enough to satisfy basic needs such as the decompression of a small configuration file. This setting can be adjusted depending on the platform’s needs and capabilities. Note that we have set this size to zero for all the platforms without enough space in Cache-As-RAM to accommodate the default size.
2. ramstage: The new RAMSTAGE_CBFS_CACHE_SIZE Kconfig can be used to set the ramstage CBFS cache size. A cache size of zero disables the CBFS cache feature for ramstage. Similarly to pre-memory stages support, the default size is 16 KiB. As we want to support the S3 suspend/resume use case, the CBFS cache memory cannot be released to the operating system and therefore cannot be an unreserved memory region. The ramstage CBFS cache scratchpad is defined as a simple C static buffer as it allows us to keep the simple and robust design of the static initialization of the cbfs_cache global variable (cf. src/lib/cbfs.c). However, since some AMD SoCs (cf. SOC_AMD_COMMON_BLOCK_NONCAR Kconfig) already define a _cbfs_cache region we also introduced a POSTRAM_CBFS_CACHE_IN_BSS Kconfig to gate the use of a static buffer as the CBFS cache scratchpad.

Allow romstage to be combined into the bootblock

Having a separate romstage is only desirable:

• with advanced setups like vboot or normal/fallback
• boot medium is slow at startup (some ARM SOCs)
• bootblock is limited in size (Intel APL 32K)

When this is not the case there is no need for the extra complexity that romstage brings. Including the romstage sources inside the bootblock substantially reduces the total code footprint. Often the resulting code is 10-20k smaller.

This is controlled via a Kconfig option.

soc/intel/cmn/gfx: Add API to report presence of external display

This implements an API to report the presence of an external display on Intel silicon. The API uses information from the transcoder and framebuffer to determine if an external display is connected.

For example, if the transcoder is attached to any DDI ports other than DDI-A (eDP), and the framebuffer is initialized, then it is likely that an external display is present.

This information can be used by payloads to determine whether or not to power on the display, even if eDP is not initialized.

device/pci_rom: Set VBIOS checksum when filling VFCT table

AMD’s Windows display drivers validate the checksum of the VBIOS data in the VFCT table (which gets modified by the FSP GOP driver), so ensure it is set correctly after copying the VBIOS into the table if the FSP GOP driver was run. Without the correct checksum, the Windows GPU drivers will fail to load with a code 43 error in Device Manager.

Additional coreboot changes

• Move all ‘select’ statements from Kconfig.name files to Kconfig
• acpigen now generates variable-length PkgLength fields instead of a fixed 3-byte size to improve compatibility and to bring it in line with IASL
• Work to allow Windows to run on more Chromebooks
• General cleanup and reformatting
• Add initial AMD openSIL implementation
• Add ACPI table generation for ARM64
• Stop resetting CMOS during s3 resume even if marked as invalid
• Comply with ACPI specification by making _STR Unicode strings
• Fix SMM get_save_state calculation, which was broken when STM was enabled
• SNB+MRC boards: Migrate MRC settings to devicetree
• Work on chipset devicetrees for all platforms

Changes to external resources

Toolchain updates

• Upgrade GMP from 6.2.1 to 6.3.0
• Upgrade binutils from 2.40 to 2.41
• Upgrade MPFR from 4.2.0 to 4.2.1

Git submodule pointers

• amd_blobs: Update from commit id 6a1e1457af to e4519efca7 (16 commits)
• arm-trusted-firmware: Update from commit id 37366af8d4 to 88b2d81345 (214 commits)
• fsp: Update from commit id 3beceb01f9 to 481ea7cf0b (15 commits)
• intel-microcode: Update from commit id 6f36ebde45 to 6788bb07eb (1 commit)
• vboot: Update from commit id 0c11187c75 to 24cb127a5e (24 commits)
• genoa_poc/opensil: New submodule updated to 0411c75e17 (41 commits)

External payloads

• U-Boot: Use github mirror and the latest version
• edk2: Update default branch for MrChromebox repo to 2023-09

Platform Updates

Added 17 mainboards

• AMD Onyx
• Google: Anraggar
• Google: Brox
• Google: Chinchou
• Google: Ciri
• Google: Deku
• Google: Deku4ES
• Google: Dexi
• Google: Dochi
• Google: Nokris
• Google: Quandiso
• Google: Rex4ES EC ISH
• Intel: Meteorlake-P RVP with Chrome EC for non-Prod Silicon
• Purism Librem 11
• Purism Librem L1UM v2
• Siemens FA EHL
• Supermicro X11SSW-F

Added 1 SoC

• src/soc/amd/genoa

Statistics from the 4.21 to the 4.22 release

• Total Commits: 977
• Average Commits per day: 10.98
• Total lines added: 62993
• Average lines added per commit: 64.48
• Number of patches adding more than 100 lines: 60
• Average lines added per small commit: 37.55
• Total lines removed: 30042
• Average lines removed per commit: 30.75
• Total difference between added and removed: 32951
• Total authors: 135
• New authors: 14

Significant Known and Open Issues

Issues from the coreboot bugtracker: https://ticket.coreboot.org/

Payload-specific issues

Bug #	Subject
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

Bug #	Subject
509	SD Card hotplug not working on Apollo Lake
507	Windows GPU driver fails on Google guybrush & skyrim boards
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

Plans for the next release

• Finish adding chipset device trees for all SOCs
• Improve code for options/setup
• Start reformatting C files with clang-format
• Add warning/error step for Makefiles at the end

coreboot Links and Contact Information

• Main Website: https://www.coreboot.org
• Downloads: https://coreboot.org/downloads.html
• Source control: https://review.coreboot.org
• Documentation: https://doc.coreboot.org
• Issue tracker: https://ticket.coreboot.org/projects/coreboot
• Donations: https://coreboot.org/donate.html

"Why does ACPI exist" - - the greatest thread in the history of forums, locked by a moderator after 12,239 pages of heated debate, wait no let me start again. Why does ACPI exist? In the beforetimes power management on x86 was done by jumping to an opaque BIOS entry point and hoping it would do the right thing. It frequently didn't. We called this Advanced Power Management (Advanced because before this power management involved custom drivers for every machine and everyone agreed that this was a bad idea), and it involved the firmware having to save and restore the state of every piece of hardware in the system. This meant that assumptions about hardware configuration were baked into the firmware - failed to program your graphics card exactly the way the BIOS expected? Hurrah! It's only saved and restored a subset of the state that you configured and now potential data corruption for you. The developers of ACPI made the reasonable decision that, well, maybe since the OS was the one setting state in the first place, the OS should restore it. So far so good. But some state is fundamentally device specific, at a level that the OS generally ignores. How should this state be managed? One way to do that would be to have the OS know about the device specific details. Unfortunately that means you can't ship the computer without having OS support for it, which means having OS support for every device (exactly what we'd got away from with APM). This, uh, was not an option the PC industry seriously considered. The alternative is that you ship something that abstracts the details of the specific hardware and makes that abstraction available to the OS. This is what ACPI does, and it's also what things like Device Tree do. Both provide static information about how the platform is configured, which can then be consumed by the OS and avoid needing device-specific drivers or configuration to be built-in. The main distinction between Device Tree and ACPI is that Device Tree is purely a description of the hardware that exists, and so still requires the OS to know what's possible - if you add a new type of power controller, for instance, you need to add a driver for that to the OS before you can express that via Device Tree. ACPI decided to include an interpreted language to allow vendors to expose functionality to the OS without the OS needing to know about the underlying hardware. So, for instance, ACPI allows you to associate a device with a function to power down that device. That function may, when executed, trigger a bunch of register accesses to a piece of hardware otherwise not exposed to the OS, and that hardware may then cut the power rail to the device to power it down entirely. And that can be done without the OS having to know anything about the control hardware. How is this better than just calling into the firmware to do it? Because the fact that ACPI declares that it's going to access these registers means the OS can figure out that it shouldn't, because it might otherwise collide with what the firmware is doing. With APM we had no visibility into that - if the OS tried to touch the hardware at the same time APM did, boom, almost impossible to debug failures (This is why various hardware monitoring drivers refuse to load by default on Linux - the firmware declares that it's going to touch those registers itself, so Linux decides not to in order to avoid race conditions and potential hardware damage. In many cases the firmware offers a collaborative interface to obtain the same data, and a driver can be written to get that. this bug comment discusses this for a specific board) Unfortunately ACPI doesn't entirely remove opaque firmware from the equation - ACPI methods can still trigger System Management Mode, which is basically a fancy way to say "Your computer stops running your OS, does something else for a while, and you have no idea what". This has all the same issues that APM did, in that if the hardware isn't in exactly the state the firmware expects, bad things can happen. While historically there were a bunch of ACPI-related issues because the spec didn't define every single possible scenario and also there was no conformance suite (eg, should the interpreter be multi-threaded? Not defined by spec, but influences whether a specific implementation will work or not!), these days overall compatibility is pretty solid and the vast majority of systems work just fine - but we do still have some issues that are largely associated with System Management Mode. One example is a recent Lenovo one, where the firmware appears to try to poke the NVME drive on resume. There's some indication that this is intended to deal with transparently unlocking self-encrypting drives on resume, but it seems to do so without taking IOMMU configuration into account and so things explode. It's kind of understandable why a vendor would implement something like this, but it's also kind of understandable that doing so without OS cooperation may end badly. This isn't something that ACPI enabled - in the absence of ACPI firmware vendors would just be doing this unilaterally with even less OS involvement and we'd probably have even more of these issues. Ideally we'd "simply" have hardware that didn't support transitioning back to opaque code, but we don't (ARM has basically the same issue with TrustZone). In the absence of the ideal world, by and large ACPI has been a net improvement in Linux compatibility on x86 systems. It certainly didn't remove the "Everything is Windows" mentality that many vendors have, but it meant we largely only needed to ensure that Linux behaved the same way as Windows in a finite number of ways (ie, the behaviour of the ACPI interpreter) rather than in every single hardware driver, and so the chances that a new machine will work out of the box are much greater than they were in the pre-ACPI period. There's an alternative universe where we decided to teach the kernel about every piece of hardware it should run on. Fortunately (or, well, unfortunately) we've seen that in the ARM world. Most device-specific simply never reaches mainline, and most users are stuck running ancient kernels as a result. Imagine every x86 device vendor shipping their own kernel optimised for their hardware, and now imagine how well that works out given the quality of their firmware. Does that really seem better to you? It's understandable why ACPI has a poor reputation. But it's also hard to figure out what would work better in the real world. We could have built something similar on top of Open Firmware instead but the distinction wouldn't be terribly meaningful - we'd just have Forth instead of the ACPI bytecode language. Longing for a non-ACPI world without presenting something that's better and actually stands a reasonable chance of adoption doesn't make the world a better place. comments