coreboot 4.22 & 4.22.01 have been released

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 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:

Payload-specific issues

Bug #Subject
499edk2 boot fails with RESOURCE_ALLOCATION_TOP_DOWN enabled
496Missing malloc check in libpayload
484No USB keyboard support with secondary payloads
414X9SAE-V: No USB keyboard init on SeaBIOS using Radeon RX 6800XT

Platform-specific issues

Bug #Subject
509SD Card hotplug not working on Apollo Lake
507Windows GPU driver fails on Google guybrush & skyrim boards
506APL/GML don’t boot OS when CPU microcode included “from tree”
505Harcuvar CRB – 15 of 16 cores present in the operating system
499T440p – EDK2 fails with RESOURCE_ALLOCATION_TOP_DOWN enabled
495Stoney Chromebooks not booting PSPSecureOS
478X200 booting Linux takes a long time with TSC
474X200s crashes after graphic init with 8GB RAM
457Haswell (t440p): CAR mem region conflicts with CBFS_SIZE > 8mb
453Intel HDMI / DP Audio not present in Windows after libgfxinit
449ThinkPad T440p fail to start, continuous beeping & LED blinking
448Thinkpad T440P ACPI Battery Value Issues
446Optiplex 9010 No Post
439Lenovo X201 Turbo Boost not working (stuck on 2,4GHz)
427x200: Two battery charging issues
412x230 reboots on suspend
393T500 restarts rather than waking up from suspend
350I225 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:
  • Downloads:
  • Source control:
  • Documentation:
  • Issue tracker:
  • Donations:

Updating LZ4 during my GSoC


In this blog post, I will give an insight into my Google Summer of Code project, where I worked on coreboot. My target goals were updating compression and decompression algorithms LZ4 and LZMA to their newest version.

In the whole process, I learned a lot about coreboot as an open-source community, and about GSoC, which could help students considering applying for a GSoC themselves.

This blog won’t be addressing technical details, there will be a section at the end about my work and the results of it, but the rest of the blog will be a bit more meta.

What did I learn about open-source communities?

Before this project, I never contributed to any open-source project. My studies don’t involve much programming, therefore I’m not that professional, my programming skills are homebrewed. Now open source communities, especially as big as coreboot, really intimidated me (they still do somehow). There are many people, all of them probably better programmers than me, having more knowledge of the project as well. How could I help them with anything useful at all? And what if I push my first patch and it’s just embarrassing? Having a mentor helped, I think without someone to talk to, I would have never stuck my nose into any big open-source project.

And all the people I met were very kind and helpful if needed. And I learned that critics, especially in text form, may sound harsher in my head than they are meant to.

Thoughts about Google’s Summer of Code

GSoC is a really good opportunity to get a feeling for working on open source. If you are a student searching for insight into open source, guided by a mentor, a GSoC project can be just right for you.

But something I underestimated, was, how time-intensive such a project (even a medium one) is. I probably was too naive, but beforehand, I just talked myself into “Yeah this won’t be a problem, I can just work around two days a week for this, just shift stuff to other days.” Well, it turns out, that’s not how workload and mental load work. For me at least. I do work besides my studies and in the first weeks of GSoC, I was overwhelmed by the combination. Besides having fewer hours to do other things, just having more things to think about can be quite stressful under some conditions.

GSoC allows you to stretch your project, so there is less work per week. In total, the project hours stay the same. This opportunity really helped me because I underestimated the load the weekly hours would apply.

If I were to apply to GSoC again, I would double-check if such a commitment in terms of work is feasible for me. And that I would recommend to everyone thinking about applying. GSoC can be interesting and fun, but you need to be able to provide the time needed for the project.

What did I do and achieve?

I started my project by updating LZ4 code in coreboot. After that, I planned to move on to another compression algorithm, LZMA. My hopes were to increase the decompression speed and the compression ratio at the same time. Looking at the release notes for LZ4 since the version currently used by coreboot (spanning 8 years of releases), they stated an increase in speed and compression factor.

To get an overview, I first searched for all places where LZ4 was used and checked the version which the code was from. I found out, that there are five files containing code from the LZ4 repository, where every file contains another subset of functions from the original file. 3 of these files were imported from LZ4 wrapper files.

Then I fetched LZ4 code from the newest LZ4 release and merged it into the files where old LZ4 code was used. After merging, there were many LZ4 functions never used in our use case. Therefore I searched for each source file through each wrapper file to find out which functions were used and which I could remove. This way I could ensure there was no unused code in these files, providing a better overview

After that, there still were many errors that needed to be resolved. That took the most time, being more complicated than I assumed. In the end, all tests passed, and building a rom and running it with QEMU worked just fine, my last ToDo was to test how much the new version was faster than the old if it was at all.

Release notes stated many speed improvements, so I hoped this would show up after my work.

The whole process took longer than I thought. Therefore I will miss the goal of updating LZMA. As I am writing this, my patch is open for review and I am in the process of creating statistics that may show that there is a speed improvement. If there is not, maybe there is no good reason to change to a newer LZ4 version. As one comment states, coreboot does require safe in-place decompression, which may be a problem with the new version and thus would have to be checked.

My work is public on the coreboot Gerrit under this link I do hope my patch will be merged, as I want to contribute to this project. But even if a merge may be rejected, that is part of open-source work too. I’ll try to improve on my next patch. This is my first open source contribution and it’s not perfect, but it certainly won’t be my last.

What could be done in the future?

As stated in a comment on my patch, in-place decompression is important for coreboot. There is a merged pull request from 2016 resolving that issue, but its functionality may have been lost in further development. Therefore, the new LZ4 version has to be checked for in-place safety.

To tweak compression/decompression speeds and compression factor one might want to edit compression parameters. One could do this using a Kconfig entry.

Also, it occurred that after building coreboot (running make in coreboot dictionary), when memory regions and sizes of the coreboot.rom are printed, there is no compression listed for the payload, even when it certainly has been compressed.


I tested this on my laptop with KVM and QEMU, on an AMD® Ryzen 5 5500u. I changed my system’s CPU affiliation, to make 2 of my cores unused (they still got used, but not much, usually ~1%). Then I assigned these 2 CPUs to my VM to make different runs more comparable. Still, different runs got different timings, so I made 6 runs for the old LZ4 and the new LZ4 version each.

Avg ramstage decompression timeRamstage decompression time std devAvg payload decompression timePayload decompression time std dev
Current version420µs54µs229µs64µs
Updated version520µs113µs219µs4µs
Ramstage compression ratioPayload compression ratio
Current version1,5071,452
Updated version1,511,454

These values indicate that there is a very small improvement in the compression ratio. Regarding decompression time, most tests have a relatively high standard deviation, which makes the results less statistically relevant. Ramstage decompression seems to have slowed down (~24%) while average payload decompression got 4-5% faster.

All in all, these results are everything but exciting to me. Although a newer version may have other advantages, it seems that there is no decompression time improvement as I hoped and compression ratio improvements are so small, that they might not be noticeable.


"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. comment count unavailable comments

Improving the boot times of IT servers with a custom BIOS

One of the big challenges with the use of IT hardware such as computer servers in broadcasting is excessively long boot times of up to ten minutes. In reactive broadcasting environments this may cause problems or be frustrating for operators. Most of the boot time in a server consists of the BIOS boot time plus the boot time of the Operating System. In our case the boot time of the OS is relatively small compared to the BIOS so this article will focus on BIOS changes. A computer BIOS (or something more modern like UEFI) is doing a very complex job setting up hardware and doing things like memory training. However, most BIOSes on servers are written by third-party vendors and arguably there is an incentive for third-party BIOS vendors to add features (that some would see as unnecessary complexity) to their BIOSes which increases boot time. This is where coreboot comes in. Coreboot is an Open Source BIOS implementation (and so much more) with a substantially smaller footprint compared to vendor BIOSes. This allows for faster boot times amongst many other benefits. But its downside is that every motherboard must be added manually, quite a challenge for a company with lots of different motherboards in use. It also only supports entry-level servers for the time being. Servers with Xeon Scalable CPUs are not supported owing to limitations from Intel. Coreboot thankfully supported the X11 series from Supermicro, and we had a similar old server in our lab, although we had an X11SSW-F, a model that was not supported. As these motherboards are similar, after some work understanding the differences between PCI Express (PCIe) slots and USB ports compared to other boards it was possible to write a patch that booted successfully. There was an obvious difference in boot time but it was time to measure. This was done by a cronjob running every five minutes and logging the date of reboot and logging the first message from the Linux kernel in syslog. Note that we were only measuring “warm” boot times and the test was run 15 times.
Vendor BIOS boot time Coreboot BIOS boot time
83±10s 38±5s
Twice as fast! It’s likely there are possible settings changes to both the Vendor BIOS and Coreboot to reduce boot time further. The bigger issue is that in both BIOSes a substantial amount of time is spent in the closed Intel Firmware Support Package that can’t be modified. We also need to check that Coreboot doesn’t affect functionality of servers, so we wrote a script to reboot the server and start up an 8-channel decoder every 30 minutes. After 730 reboots (around two weeks nonstop!), we saw from logs that every single reboot was successful and the decoders started successfully. We also have plans to add coreboot support to more modern motherboards and roll this out to customers on request. Coreboot also has some benefits for debugging PCIe related issues, but more on that another day.

coreboot version 4.21 released

The coreboot 4.21 release was tagged on August 21st, 2023.

In the past quarter year, the coreboot project has gotten over 1250 new patches from around 140 authors, 21 of whom contributed for the first time.

Thank you to all of our donors, the code contributors, the people who take time to review all of those patches and all of the people who care about the coreboot project. There have been a number of new companies starting to use coreboot recently, and we appreciate all of the contributions and support.

Upcoming switch from master branch to main branch

Historically, the initial branch that was created in a new git repository was named ‘master’. In line with many other projects, coreboot has decided to switch away from this name and use the name ‘main’ instead. You can read about the initial reasoning on the SFC’s website:

At some point before the 4.22 release, coreboot will be switching from the master branch to the main branch. This shouldn’t be a difficult change for most people, as everyone will just have to rebase on top of a different branch name.

We have already created the main branch, and it is currently synced with the master branch. Please update any scripts to point to main instead of master.

At the point of the changeover, we will move all patches in gerrit to the main branch and disable pushes to the master branch.

After the switch, we will sync the main branch to the master branch for a while to give people a little more time to update any scripts that are currently pointed at the master branch. Note that this update will probably be done just once per day, and the frequency of updates will be decreased over time. We plan to stop updating the master branch following the 4.22 release.

Significant or interesting changes

lib: Support localized text of memory_training_desc in ux_locales.c

Most of the text in coreboot is for logging, and does not use localization. There are however, some bits of text that can be presented to the user, and this patch supplies a method to localize them.

To support the localized text, we need to get the locale id by vboot APIs and read raw string content file: preram_locales located at either RO or RW.

The preram_locales file follows the format:

[string_name_1] [\x00]
[locale_id_1] [\x00] [localized_string_1] [\x00]
[locale_id_2] [\x00] [localized_string_2] ...
[string_name_2] [\x00] ...

This code will search for the correct localized string that its string name is memory_training_desc and its locale ID matches the ID vb2api returns. If no valid string found, we will try to display in English (locale ID 0).

Improved bootsplash support

The JPEG decoder, that was added many years ago to display a bootsplash in coreboot, has a few quirks. People used to do some voodoo with GIMP to convert images to the right format, but we can also achieve the same with ImageMagick’s convert. The currently known constraints are:

  • The framebuffer’s color format is ignored,
  • only YCC 4:2:0 color sampling is supported, and
  • width and height have to be a multiple of 16 pixels.

Beside that, we can only display the bootsplash if it completely fits into the framebuffer. As the latter’s size is often decided at runtime, we can’t do much more than offering an option to set a specific size.

The build system has been extended so that the necessary adjustments to the picture can be done by it and several options have been added to Kconfig.

libpayload/uhci: Re-write UHCI RH driver w/ generic_hub API

This is a complete rewrite of the UHCI root-hub driver, based on the xHCI one. We are doing things by the book as far as possible. One special case is uhci_rh_reset_port() which does the reset sequencing that usually the hardware would do.

This abandons some quirks of the old driver:

  • Ports are not disabled/re-enabled for every attachment anymore.
  • We solely rely on the Connect Status Change bit to track changes.
  • Further status changes are now deferred to the next polling round.

linux_trampoline: Handle coreboot framebuffer & 64-bit addresses

Translate the coreboot framebuffer info from coreboot tables to the Linux zero page.

To support full 64-bit addresses, there is a new field ext_lfb_base since Linux 4.1. It is unclear, however, how a loader is supposed to know if the kernel is compatible with this. Filling these previously reserved bits doesn’t hurt, but an old kernel would probably ignore them and not know that it’s handling a clipped, invalid address. So we play safe, and only allow 64-bit addresses for kernels after the 2.15 version bump of the boot protocol.

arch/x86: Don’t allow hw floating point operations

Even though coreboot does not allow floating point operations, some compilers like clang generate code using hw floating point registers, e.g. SSE %XMMx registers on 64bit code by default. Floating point operations need to be enabled in hardware for this to work (CR4). Also in SMM we explicitly need to save and restore floating point registers for this reason. If we instruct the compiler to not generate code with FPU ops, this simplifies our code as we can skip that step.

With clang this reduces the binary size a bit. For instance ramstage for emulation/qemu-q35 drops by 4 kB from from 216600 bytes decompressed to 212768 bytes.

Since we now explicitly compile both ramstage and smihandler code without floating point operations and associated registers we don’t need to save/restore floating point registers in SMM.

The EFER MSR is in the SMM save state and RSM properly restores it. Returning to 32bit mode was only done so that fxsave was done in the same mode as fxrstor, but this is no longer done.

Caching of PCIe 5.0 HSPHY firmware in SPI flash

This adds the ability to cache the PCIe 5.0 HSPHY firmware in the SPI flash. A new flashmap region is created for that purpose. The goal of caching is to reduce the dependency on the CSME (Converged Security and Management Engine) and the HECI (Host Embedded Controller Interface) IP LOAD command which may fail when the CSME is disabled, e.g. soft disabled by HECI command or HAP (High Assurance Platform mode). By caching that firmware, this allows the PCIe 5.0 root ports to keep
functioning even if CSME/HECI is not functional.

Extracting of TPM logs using cbmem tool

CBMEM can contain logs in different forms (at most one is present):

  • coreboot-specific format (CBMEM_ID_TPM_CB_LOG exported as
  • TPM1.2 format (CBMEM_ID_TCPA_TCG_LOG)
  • TPM2 format (CBMEM_ID_TPM2_TCG_LOG)

The last two follow specifications by Trusted Computing Group, but until now cbmem couldn’t print them.

These changes make the cbmem utility check for existence of TPM1.2/TPM2 logs in CBMEM and add code necessary for parsing and printing of their entries.

cbmem -L for CONFIG_TPM1=y case

TCPA log:
	Specification: 1.21
	Platform class: PC Client
TCPA log entry 1:
	PCR: 2
	Event type: Action
	Digest: 5622416ea417186aa1ac32b32c527ac09009fb5e
	Event data: FMAP: FMAP

cbmem -L for CONFIG_TPM2=y case

TPM2 log:
	Specification: 2.00
	Platform class: PC Client
TPM2 log entry 1:
	PCR: 2
	Event type: Action
		 SHA256: 68d27f08cb261463a6d004524333ac5db1a3c2166721785a6061327b6538657c
	Event data: FMAP: FMAP

soc/amd: read domain resource window configuration from hardware

Read the MMIO and IO decode windows for the PCI root complex and the PCI bus number range decoded to the PCI root complex from the data fabric registers and pass the information to the resource allocator so it has the correct constraints to do its job. Also generate the corresponding ACPI resource producers in the SSDT so that the OS knows about this too. This is required for the upcoming USB 4 support.

Additional coreboot changes

  • Added SPDX headers to more files to help automated license checking. The linter has been enabled to check the Makefiles as well.
  • Cleaned up Kconfig files and source code.
  • Enabled acpigen to generate tables for SPCR (Serial Port Console Redirection) and GTDT (Generic Timer Description Table).
  • The resource allocation above the 4GiB boundary has been improved.
  • Most of the code has been adjusted to make use of C99 flexible arrays instead of one-element or zero-length arrays.
  • Additional Dockerfiles based on Arch and Alpine Linux have been added to build-test with alternate build environments, including musl-libc. They are very basic at the moment and not equal to the coreboot-sdk. They will be extended in the future.
  • Added support for ITE IT8784E to superiotool.
  • Added support for Intel 700 chipset series to inteltool and a build issue with musl-libc has been fixed.
  • Added support for Intel 800 chipset series to ifdtool.
  • The coreboot-sdk container has been extended so that it allows extracting the MRC binary from Haswell-based ChromeOS firmware images.
  • From now on POST code preprocessor macros should have a POSTCODE
    prefix following the name of the POST code.
  • The NASM compiler provided by the coreboot toolchain wasn’t properly integrated into xcompile and thus it wasn’t used by the build system. Instead, it was required to install NASM on the host in order to use it. This has been fixed.
  • The time measurement done in abuild got improved and also an issue has been fixed when the variant name contains hyphens.
  • The RISC-V code was enabled to build with Clang.
  • Initial work has been done to transform Camelcase options to Snakecase.
  • The buildgcc script is now able to just fetch the tarballs if desired, which is needed for reproducible build environments for example.

Changes to external resources


  • binutils
    • Added binutils-2.40_stop_losing_entry_point_when_LTO_enabled.patch
  • Upgrade IASL from 20221020 to 20230628
  • Upgrade LLVM from 15.0.7 to 16.0.6
  • Upgrade NASM from 2.15.05 to 2.16.01
    • Added nasm-2.16.01_handle_warning_files_while_building_in_a_directory.patch
  • Upgrade CMake from 3.26.3 to 3.26.4
  • Upgrade GCC from 11.3.0 to 11.4.0
    • Added gcc-11.4.0_rv32iafc.patch

Git submodule pointers


  • amd_blobs: Update from commit id 1cd6ea5cc5 to 6a1e1457af (5 commits)
  • arm-trusted-firmware: Update from commit id 4c985e8674 to 37366af8d4 (851 commits)
  • blobs: Update from commit id 01ba15667f to a8db7dfe82 (14 commits)
  • fsp: Update from commit id 6f2f17f3d3 to 3beceb01f9 (24 commits)
  • intel-microcode: Update from commit id 2be47edc99 to 6f36ebde45 (5 commits)
  • libgfxinit: Update from commit id 066e52eeaa to a4be8a21b0 (18 commits)
  • libhwbase: Update from commit id 8be5a82b85 to 584629b9f4 (2 commits)
  • qc_blobs: Update from commit id 33cc4f2fd8 to a252198ec6 (4 commits)
  • vboot: Update from commit id 35f50c3154 to 0c11187c75 (83 commits)


  • goswid: Update from commit id bdd55e4202 to 567a1c99b0 (5 commits)
  • nvidia/cbootimage: Update from commit id 65a6d94dd5 to 80c499ebbe (1 commit)

External payloads

  • Update the depthcharge payload from commit ID 902681db13 to c48613a71c
  • Upgrade EDK2-MrChromebox from version 202304 to version 202306
  • Upgrade SeaBIOS from version 1.16.1 to version 1.16.2
  • Update tint from version 0.05 to version 0.07
  • Update U-Boot from version 2021.07 to version v2023.07

Added mainboards

  • ByteDance: bd_egs
  • Google: Craaskov
  • Google: Expresso
  • Google: Karis
  • Google: Karis4ES
  • Google: Pirrha
  • Google: Ponyta
  • Google: Screebo4ES
  • Google: Ovis
  • Google: Ovis4ES
  • Google: Rex EC ISH
  • Google: Rex4ES
  • HP: Compaq Elite 8300 USDT
  • HP: EliteBook 820 G2
  • IBM: SBP1
  • Intel: Raptorlake silicon with Alderlake-P RVP
  • Inventec: Transformers
  • MSI: PRO Z790-P (WIFI)
  • MSI: PRO Z790-P (WIFI) DDR4
  • Star Labs: StarBook Mk VI (i3-1315U and i7-1360P)
  • System76: addw3
  • System76: bonw15
  • System76: darp9
  • System76: galp7
  • System76: gaze17 3050
  • System76: gaze17 3060-b
  • System76: gaze18
  • System76: lemp12
  • System76: oryp11
  • System76: serw13

Removed Mainboards

  • Intel: Galileo

Updated SoCs

  • Removed src/soc/intel/quark

Statistics from the 4.20 to the 4.21 release

  • Total Commits: 1253
  • Average Commits per day: 12.60
  • Total lines added: 318136
  • Average lines added per commit: 253.90
  • Number of patches adding more than 100 lines: 87
  • Average lines added per small commit: 36.23
  • Total lines removed: 261145
  • Average lines removed per commit: 208.42
  • Total difference between added and removed: 56991
  • Total authors: 143
  • New authors: 21

Significant Known and Open Issues

These are the significant issues in the 4.21 release, but note that most of these are for individual platforms. In the 4.22 release, we’re going to separate these into two categories – coreboot-wide issues and issues for individual platforms.

Issues from the coreboot bugtracker:

  • 506 – Apollolake/Geminilake boards don’t boot when microcode built “from tree”
  • 505 – Intel Harcuvar CRB only 15 of 16 cores showing up
  • 499 – edk2 boot 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 device not showing up 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
  • 414 – X9SAE-V: No USB keyboard init on SeaBIOS using Radeon RX 6800XT
  • 412 – x230 reboots on suspend
  • 393 – T500 restarts rather than waking up from suspend
  • 350 – I225 PCIe device not detected on Harcuvar
  • 327 – OperationRegion (OPRG, SystemMemory, ASLS, 0x2000) causes BSOD