Announcing coreboot 4.14

coreboot 4.14 was released today, on May 10th, 2021.

Since 4.13 there have been 3660 new commits by 215 developers.
Of these, about 50 contributed to coreboot for the first time.
Welcome to the project!

These changes have been all over the place, so that there's no
particular area to focus on when describing this release: We had
improvements to mainboards, to chipsets (including much welcomed
work to open source implementations of what has been blobs before),
to the overall architecture.

Thank you to all developers who made coreboot the great open source
firmware project that it is, and made our code better than ever.

New mainboards
--------------

* AMD Bilby
* AMD Majolica
* GIGABYTE GA-D510UD
* Google Blipper
* Google Brya
* Google Cherry
* Google Collis
* Google Copano
* Google Cozmo
* Google Cret
* Google Drobit
* Google Galtic
* Google Gumboz
* Google Guybrush
* Google Herobrine
* Google Homestar
* Google Katsu
* Google Kracko
* Google Lalala
* Google Makomo
* Google Mancomb
* Google Marzipan
* Google Pirika
* Google Sasuke
* Google Sasukette
* Google Spherion
* Google Storo
* Google Volet
* HP 280 G2
* Intel Alderlake-M RVP
* Intel Alderlake-M RVP with Chrome EC
* Intel Elkhartlake LPDDR4x CRB
* Intel shadowmountain
* Kontron COMe-mAL10
* MSI H81M-P33 (MS-7817 v1.2)
* Pine64 ROCKPro64
* Purism Librem 14
* System76 darp5
* System76 galp3-c
* System76 gaze15
* System76 oryp5
* System76 oryp6

Removed mainboards
------------------

* Google Boldar
* Intel Cannonlake U LPDDR4 RVP
* Intel Cannonlake Y LPDDR4 RVP

Deprecations and incompatible changes
-------------------------------------

### SAR support in VPD for Chrome OS

SAR support in VPD has been deprecated for Chrome OS platforms for > 1
year now. All new Chrome OS platforms have switched to using SAR
tables from CBFS. For the next release, coreboot is updated to align
with the Chrome OS factory changes and hence SAR support in VPD is
deprecated in [CB:51483](https://review.coreboot.org/51483). Starting
with this release, anyone building coreboot for an already released
Chrome OS platform with SAR table in VPD will have to extract the
"wifi_sar" key from VPD and add it as a file to CBFS using following
steps:
 * On DUT, read SAR value using `vpd -i RO_VPD -g wifi_sar`
 * In coreboot repo, generate CBFS SAR file using:
    `echo ${SAR_STRING} > site-local/${BOARD}-sar.hex`
 * Add to site-local/Kconfig:
    ```
     config WIFI_SAR_CBFS_FILEPATH
       string
       default "site-local/${BOARD}-sar.hex"
    ```

### CBFS stage file format change

[CB:46484](https://review.coreboot.org/46484) changed the in-flash
file format of coreboot stages to prepare for per-file signature
verification. As described in the commit message in more details,
when manipulating stages in a CBFS, the cbfstool build must match the
coreboot image so that they're using the same format: coreboot.rom
and cbfstool must be built from coreboot sources that either both
contain this change or both do not contain this change.

Since stages are usually only handled by the coreboot build system
which builds its own cbfstool (and therefore it always matches
coreboot.rom) this shouldn't be a concern in the vast majority of
scenarios.

Significant changes
-------------------

### AMD SoC cleanup and initial Cezanne APU support

There's initial support for the AMD Cezanne APUs in the tree. This code
hasn't started as a copy of the previous generation, but was based on a
slightly modified version of the example/min86 SoC. During the cleanup
of the existing Picasso SoC code the common parts of the code were
moved to the common AMD SoC code, so that they could be used by the
Cezanne code instead of adding another slightly different copy.

### X86 bootblock layout

The static size C_ENV_BOOTBLOCK_SIZE was mostly dropped in favor of
dynamically allocating the stage size; the Kconfig is still available
to use as a fixed size and to enforce a maximum for selected chipsets.
Linker sections are now top-aligned for a reduced flash footprint and to
maintain the requirements of near jump from reset vector.

### ACPI GNVS framework

SMI handlers for APM_CNT_GNVS_UDPATE were dropped; GNVS pointer to SMM is
now passed from within SMM_MODULE_LOADER. Allocation and initialisations
for common ACPI GNVS table entries were largely moved to one centralized
implementation.

### Intel Xeon Scalable Processor support is now considered mature

Intel Xeon Scalable Processor (Xeon-SP) family [1] is designed
primarily to serve the needs of the server market.

coreboot support for Xeon-SP is in src/soc/intel/xeon_sp directory.
This release has support for SkyLake-SP (SKX-SP) which is the 2nd
generation, and for CooperLake-SP (CPX-SP) which is the 3rd generation
or the latest generation [2] on market.

With this release, the codebase for multiple generations of Xeon-SP
were unified and optimized:
* SKX-SP SoC code is used in OCP TiogaPass mainboard [3]. Support for
this board is in Proof Of Concept Status.
* CPX-SP SoC code is used in OCP DeltaLake mainboard. Support for
this board is in DVT (Design Validation Test) exit equivalent status.
Features supported, (performance/stability) test scopes, known issues,
features gaps are described in [4].


[1] https://www.intel.com/content/www/us/en/products/details/processors/xeon/scalable.html
[2] https://www.intel.com/content/www/us/en/products/docs/processors/xeon/3rd-gen-xeon-scalable-processors-brief.html
[3] ../mainboard/ocp/tiogapass.md
[4] ../mainboard/ocp/deltalake.md

On microcode

On microcodeThere has been one too many case of "I don't trust microcode, so I don't want microcode blobs in coreboot", so I felt the need for an answer. And since I don't like stuff to end up in silos, here's a copy.

Microcode vs. microcode updates

Let's get this out of the door first: The blobs that ship with coreboot, Linux, Windows, macOS etc aren't microcode but microcode updates. The CPU comes with microcode, so if you don't want microcode, choose a different vendor (good luck). The updates provide a way for the vendor to run a newer version of parts of the microcode on the CPU. Note that these updates aren't persistent: They need to be installed after power-on or you're back to the original state. This article will next discuss what microcode is, why there are updates, and what you miss out on if you don't install them.

What is microcode

CPUs have internal components for all kinds of operations that they support. But some parts of the (x86, but also most others) architecture are too complex to represent them directly as a distinct component. For these complex parts, microcode is used (starting in the 60s or 70s, a real long time ago! Home computers were a bit late but they always are): Small program snippets that represent a single instruction of the architecture as a whole bunch of instructions for the components that exist. A bit like "if the instruction says to exponentiate a to the power of b, multiply a by itself b times" (although CPUs generally don't have exponentiation, that would be a great example for a microcoded instruction: some complex operation can be solved by repeating simpler operations several times) Now, Intel (and the others) build both the internal components and everything that brings them together, some of them as real components, some of them microcoded.

Product cycles and some history

Like with all products, there isn't perfection: the product is developed, there's a quality bar that needs to be met, a time limit by which the product should be ready, and a budget that informs how many people can work on it. As soon as the chip is "good enough", it can be produced. Now, Intel had some really bad accidents with that strategy, the most famous and expensive being the fdiv bug: certain division operations miscalculated for certain values. Depending on who you ask, that one could have had the ability to take down Intel for good if they had to ship a replacement CPU to every customer (they didn't). With that experience, these days they provide some room in the CPU by which they can put on band-aids on certain parts of the operation. The details aren't well-known, but some educated guesses would be that they can update microcode programs for existing instructions (for example, if the exponentiation example above forgot to account for a^0 == 1, they could provide an update that takes care of that); and that they might put multiple variants of a basic component in a chip and allow the update to disable the new (and experimental) version if it is less reliable than intended, using an older (and probably slower) version instead.

The impact

When you don't install updates you mostly forgo whatever development happened on the CPU after some cut-off point in time that was chosen more-or-less arbitrarily by its product manager to get the product out of the door. Since that's when the majority of developers move on to the next project, these updates will likely fix significant issues: significant enough that somebody was assigned to look into an old product instead of working on the Next Big Thing. Something that might have an impact like "we run out of money if customers can sue us over this", something like failures in the CPU's security architecture (I don't expect there to be math problems anymore) For all we people outside Intel know (and we don't, really), any unpatched CPU for which there are updates has grave security issues that are trivially exploited. For all we know, there might be bad actors who know the issues in detail. Intel provides updates and even ensures that "typical" platforms (e.g. Windows, macOS, popular Linux distros) install them, so they're not liable anymore (like with the fdiv thing).

Announcing coreboot 4.12

coreboot 4.12 was released on May 12th, 2020.

Since 4.11 there were 2692 new commits by over 190 developers and of these, 59 contributed for the first time, which is quite an amazing increase.

Thank you to all developers who again helped made coreboot better than ever, and a big welcome to our new contributors!

Maintainers

This release saw some activity on the MAINTAINERS file, showing more persons, teams and companies declare publicly that they intend to take care of mainboards and subsystems.

To all new maintainers, thanks a lot!

Documentation

Our documentation efforts in the code tree are picking up steam, with some 70 commits in that general area. Everything from typo fixes to documenting mainboard support or coreboot APIs.

There’s still room to improve, but the contributions are getting more and better.

Hardware support

The removals due to the announced deprecations as well as the deduplication of boards into variants skew the stats a bit, so at a top level view this is a rare coreboot release in that it removes more boards (51) than it adds (49).

After accounting for the variant moves the numbers in favor of more hardware supported than the previous version. Besides a whole lot of Chrome OS devices (again), this release features a whole bunch of retrofits for devices originally shipping with non-coreboot OEM firmware, but also support for devices that come with coreboot right out of the box.

For that, a shout out to System76, Protectli, Libretrend and the Open Compute Project!

Cleanup

We simplified the header that comes at the top of every file: Instead of a lengthy reference to the license any given file is under, or even the license text itself, we opted for simple SPDX identifiers.

Since people also handled copyright lines differently, we now opt for collecting authors in AUTHORS and let git history tell the whole story.

While at it, the content-free "This file is part of this-and-that project" header was also dropped.

Besides that, there has also been more work to sort out the headers we include across the tree to minimize the code impacting every compilation unit.

Now that our board-variant mechanism matured, many boards that were individual models so far were converted into variants, making it easier to maintain families of devices.

Deprecations

For the 4.12 release a few features on x86 became mandatory. These are relocatable ramstage, postcar stage and C_ENVIRONMENT_BOOTBLOCK.

Relocatable ramstage

Relocatable stages are a feature implemented only on x86, where stages can be relocated at runtime. This is used to place ramstage in a better location that does not collide with memory the OS or the payload tends to use. The rationale behind making this mandatory is that you always want cbmem to be cached so it’s a good location to run ramstage from. It avoids using lower memory altogether so the OS can make use of it and no backing up needs to happen on S3 resume.

Postcar stage

With Postcar stage tearing down Cache-as-Ram is done in a separate stage. This means that romstage has a clean program boundary and that all variables in romstage can be accessed via their linked addresses without runtime resolution. There is no need to link global and static variables via the CAR_GLOBAL macro and no need to access them with car_set/get_var/ptr functions.

C_ENVIRONMENT_BOOTBLOCK

Historically the bootblock on x86 platforms has been compiled with romcc. This means that the generated code only uses CPU registers and therefore no stack. This 20K+ LOC compiler is limited and hard to maintain and so is the code that one has to write in that environment. A different solution is to set up Cache-as-Ram in the bootblock and run GCC compiled code in the bootblock. The advantages are increased flexibility and consistency with other architectures as well as other stages: e.g. printing to console is possible and VBOOT can run before romstage, making romstage updatable via RW FMAP regions.

Platforms dropped from master

The following platforms did not implement those feature are dropped from master to allow the master branch to move on:

  • AMDFAM10
  • all FSP1.0 platforms: BROADWELL_DE, FSP_BAYTRAIL, RANGELEY
  • VIA VX900

In particular on FSP1.0 it is impossible to implement POSTCAR stage. The reason is that FSP1.0 relocates the CAR region to the HOB before returning to coreboot. This means that after FSP returns to coreboot accessing variables via their original address is not possible. One way of obtaining that behavior would be to set up Cache-as-Ram again (but with open source code) and copy the relocated data from the HOB there. This solution is deemed too hacky. Maybe a lesson can be learned from this: blobs should not interfere with the execution environment, as this makes proper integration much harder.

4.11_branch

Given that some platforms supported by FSP1.0 are being produced and popular, the 4.11 release was made into a branch in which further development can happen.

Significant changes

SMMSTORE is now production ready

See smmstore for the documentation on the API, but note that there will be an update to it featuring a much-improved but incompatible API.

Unit testing infrastructure

Unit testing of coreboot is now possible in a more structured way, with new build subsystem and adoption of Cmocka framework. Tree has new directory tests/, which comprises infrastructure and examples of unit tests. See Unit testing coreboot for the design document.

Final Notes

Your favorite new feature or supported board didn’t make it to the release notes? They’re maintained collaboratively in the coreboot tree, so when you land something noteworthy don’t be shy, contribute to the upcoming release’s document in Documentation/releases!

Announcing coreboot 4.11

The coreboot project is proud to announce to have released coreboot 4.11.

This release cycle was a bit shorter to get closer to our regular schedule of releasing in spring and autumn.

Since 4.10 there were 1630 new commits by over 130 developers. Of these, about 30 contributed to coreboot for the first time.

Thank you to all contributors who made 4.11 what it is and welcome to the project to all new contributors!

Clean Up

The past few months saw lots of cleanup across the source tree:

The included headers in source files were stripped down to avoid reading unused headers, and unused code fragments, duplicate preprocessor symbols and configuration options were eliminated. Even ACPI got its share of attention, making our tables and bytecode more standards compliant than ever.

The code across Intel’s chipsets was unified some more into drivers for common function blocks, an effort we’re more confident will succeed now that Intel itself is driving it.

Chipset work

Most activity in the last couple months was on Intel support, specifically the Kaby Lake and Cannon Lake drivers were extended for the generations following them.

On ARM, the Mediatek 8173 chipset support saw significant work while the AMD side worked on getting Picasso support in.

But everything else also saw some action, the relatively old (e.g. Intel GM45, Via VX900), the tiny (RISC-V) and the obscure (Quark).

Verified Boot

The vboot feature that Chromebooks brought into coreboot was extended to work on devices that weren’t specially adapted for it: In addition to its original device family it’s now supported on various Lenovo laptops, Open Compute Project systems and Siemens industrial machines.

Eltan’s support for measured boot continues to be integrated with vboot, sharing data structures and generally working together where possible.

New devices

With 4.11 there’s the beginning of support for Intel Tiger Lake and Qualcomm’s SC7180 SoCs, while we removed the unmaintained support for Allwinner’s A10 SoC.

There are also 25 new mainboards in our tree:

  • AMD PADMELON
  • ASUS P5QL-EM
  • EMULATION QEMU-AARCH64
  • GOOGLE AKEMI
  • GOOGLE ARCADA CML
  • GOOGLE DAMU
  • GOOGLE DOOD
  • GOOGLE DRALLION
  • GOOGLE DRATINI
  • GOOGLE JACUZZI
  • GOOGLE JUNIPER
  • GOOGLE KAKADU
  • GOOGLE KAPPA
  • GOOGLE PUFF
  • GOOGLE SARIEN CML
  • GOOGLE TREEYA
  • GOOGLE TROGDOR
  • LENOVO R60
  • LENOVO T410
  • LENOVO THINKPAD T440P
  • LENOVO X301
  • RAZER BLADE-STEALTH KBL
  • SIEMENS MC-APL6
  • SUPERMICRO X11SSH-TF
  • SUPERMICRO X11SSM-F

In addition to the Cubieboard (which uses the A10 SoC), we also removed Google Hatch WHL.

Deprecations

Because there was only a single developer board (AMD Torpedo) using AGESA family 12h, and because there were multiple, unique Coverity issues with it, the associated vendorcode will be removed shortly after this release.

Support for the MIPS architecture will also be removed shortly after this release as the only board in the tree was a discontinued development board and no other work has picked up MIPS support, so it’s very likely broken already.

After more than a year of planning and following the announcement in coreboot 4.10, platforms not using relocatable ramstage, a C bootblock and, on systems using Cache as RAM, a postcar stage, won’t be supported going forward.

Significant changes

__PRE_RAM__ is deprecated

Preprocessor use of defined(__PRE_RAM__) have been mostly replaced with if (ENV_ROMSTAGE_OR_BEFORE) or the inverse if (ENV_RAMSTAGE).

The remaining cases and -D__PRE_RAM__ are to be removed soon after release.

__BOOTBLOCK__ et.al. are converted

This applies to all ENV_xxx definitions found in <rules.h>.

Write code without preprocessor directives whenever possible, replacing #ifdef __BOOTBLOCK__ with if (ENV_BOOTBLOCK)

In cases where preprocessor is needed use #if ENV_BOOTBLOCK instead.

CAR_GLOBAL is removed where possible

For all platform code with NO_CAR_GLOBAL_MIGRATION=y, any CAR_GLOBAL attributes have been removed. Remaining cases from common code are to be removed soon after release.

TSEG and cbmem_top() mapping

Significant refactoring has bee done to achieve some consistency across platforms and to reduce code duplication.

Build system amenities

The build system now has an all class of source files to remove the need to list source files for each and every source class (romstage, ramstage, …)

The site-local/ mechanism became more robust.

Stricter coding standards to improve security

The build now fails on variable length arrays (that make it way too easy to smash a stack) and case statements falling through without a note that it is intentional.

Shorter file headers

This project is still under way, but we started moving author information from individual files into the global AUTHORS file (and there’s the git history for more details).

In the future, we also want to replace the license headers (lots of lines) in each file with spdx identifiers (one line) and so we added a LICENSES/ directory that contains the full text of all the licenses that are used throughout our tree.

Variant creation scripts

To ease the creation of variant boards, util/mainboard/ now contains scripts to generate a new variant to a given board. These are still specific to google/hatch at this time, but they’re written with the idea of becoming more generally useful.

Payloads

Payload integration has been updated, coreinfo learned to cope with UPPER CASE commands and libpayload knows how to deal with USB3 hubs.

Added VBOOT support to the following platforms:

  • intel/gm45
  • intel/nehalem

Moved the following platforms to C_ENVIRONMENT_BOOTBLOCK:

  • intel/i945
  • intel/x4x
  • intel/gm45
  • intel/nehalem
  • intel/sandybridge
  • intel/braswell

libgfxinit

Most notable, dynamic CDClk configuration was added to libgfxinit, to support higher resolution displays without changes in the static configuration. It also received some fixes for better DP and eDP compatibility, better error recovery for Intel’s fickle GMBus and updated platform support:

  • Correct HDMI clock limit for G45.
  • DP support for Ibex Peak (Ironlake graphics).
  • Fixed scaling on eDP for Broadwell.
  • Support for ULX variants of Haswell and later.
  • Support for Kaby, Amber, Coffee and Whiskey Lake.

Other

  • Did cleanups around TSC timer
  • Improved automatic VR configuration on SKL/KBL
  • Filled additional fields in SMBIOS type 4
  • Removed magic value replay from Intel Nehalem/ibexpeak code base
  • Added OpenSBI on RISCV platforms
  • Did more preparations for Intel TXT support
  • Did more preparations for x86_64 stage support
  • Added SSDT generator for arbitrary SuperIO chips based on devicetree.cb

Announcing coreboot 4.10

The 4.10 release covers commit a2faaa9a2 to commit ae317695e3 There is a pgp signed 4.10 tag in the git repository, and a branch will be created as needed.

In nearly 8 months since 4.9 we had 198 authors commit 2538 changes to master. Of these, 85 authors made their first commit to coreboot: Welcome!

Between the releases the tree grew by about 11000 lines of code plus 5000 lines of comments.

Again, a big Thank You to all contributors who helped shape the coreboot project, community and code with their effort, no matter if through development, review, testing, documentation or by helping people asking questions on our venues like IRC or our mailing list.

What’s New

Most of the changes were to mainboards, and on the chipset side, lots of activity concentrated on x86. However compared to previous releases activity (and therefore interest, probably) increased in vboot and in non-x86 architectures. However it’s harder this time to give this release a single topic like the last: This release accumulates some of everything.

Clean Up

As usual, there was a lot of cleaning up going on, and there notably, a good chunk of this year’s Google Summer of Code project to clean out the issues reported by Coverity Scan is already in.

The only larger scale change that was registered in the pre-release notes was also about cleaning up the tree:

device_t is no more

coreboot used to have a data type, device_t that changed shape depending on whether it is compiled for romstage (with limited memory) or ramstage (with unlimited memory as far as coreboot is concerned). It’s an old relic from the time when romstage wasn’t operated in Cache-As-RAM mode, but compiled with our romcc compiler.

That data type is now gone.

Release Notes maintenance

Speaking of pre-release notes: After 4.10 we’ll start a document for 4.11 in the git repository. Feel free to add notable achievements there so we remember to give them a shout out in the next release’s notes.

Known Issues

Sadly, Google Cyan is broken in this release. It doesn’t work with the "C environment" bootblock (as compared to the old romcc type bootblock) which is now the default. Sadly it doesn’t help to simply revert that change because doing so breaks other boards.

If you want to use Google Cyan with the release (or if you’re tracking the master branch), please keep an eye on https://review.coreboot.org/c/coreboot/+/34304 where a solution for this issue is sought.

Deprecations

As announced in the 4.9 release notes, there are no deprecations after 4.10. While 4.10 is also released late and we target a 4.11 release in October we nonetheless want to announce deprecations this time: These are under discussion since January, people are working on mitigations for about as long and so it should be possible to resolve the outstanding issues by the end of October.

Specifically, we want to require code to work with the following Kconfig options so we can remove the options and the code they disable:

  • C_ENVIRONMENT_BOOTBLOCK
  • NO_CAR_GLOBAL_MIGRATION
  • RELOCATABLE_RAMSTAGE

These only affect x86. If your platform only works without them, please look into fixing that.

Added 28 mainboards:

  • ASROCK H110M-DVS
  • ASUS H61M-CS
  • ASUS P5G41T-M-LX
  • ASUS P5QPL-AM
  • ASUS P8Z77-M-PRO
  • FACEBOOK FBG1701
  • FOXCONN G41M
  • GIGABYTE GA-H61MA-D3V
  • GOOGLE BLOOG
  • GOOGLE FLAPJACK
  • GOOGLE GARG
  • GOOGLE HATCH-WHL
  • GOOGLE HELIOS
  • GOOGLE KINDRED
  • GOOGLE KODAMA
  • GOOGLE KOHAKU
  • GOOGLE KRANE
  • GOOGLE MISTRAL
  • HP COMPAQ-8200-ELITE-SFF-PC
  • INTEL COMETLAKE-RVP
  • INTEL KBLRVP11
  • LENOVO R500
  • LENOVO X1
  • MSI MS7707
  • PORTWELL M107
  • PURISM LIBREM13-V4
  • PURISM LIBREM15-V4
  • SUPERMICRO X10SLM-PLUS-F
  • UP SQUARED

Removed 7 mainboards:

  • GOOGLE BIP
  • GOOGLE DELAN
  • GOOGLE ROWAN
  • PCENGINES ALIX1C
  • PCENGINES ALIX2C
  • PCENGINES ALIX2D
  • PCENGINES ALIX6

Removed 3 processors:

  • src/cpu/amd/geode_lx
  • src/cpu/intel/model_69x
  • src/cpu/intel/model_6dx

Added 2 socs:

  • src/soc/amd/picasso
  • src/soc/qualcomm/qcs405

Toolchain

  • Update to gcc 8.3.0, binutils 2.32, IASL 20190509, clang 8

Announcing coreboot 4.9

coreboot 4.9 release notes

The 4.9 release covers commit 532b8d5f25 to commit 7f520c8fe6
There is a pgp signed 4.9 tag in the git repository, and a branch will
be created as needed.

In the little more than 7 months since 4.8.1 we had 175 authors commit 2610 changes to master. The changes were, for the most part, all over the place, touching every part of the repository: chipsets, mainboards, tools, build system, documentation.

In that time we also had 70 authors made their first commit to coreboot: Welcome and to many more!

Finally, a big Thank You to all contributors who helped shape the coreboot project, community and code with their effort, no matter if through development, review, testing, documentation or by helping people asking questions on our venues like IRC or our mailing list.

Clean up

If there’s any topic to give to this release, “clean up” might be the most appropriate: There was lots of effort to bring the codebase into compliance with our coding style, to remove old idioms that we’d like to retire like the overloaded device_t data type, and to let features percolate through the entire tree to bring more uniformity to its parts.

For example, during the coreboot 4.4 cycle, coreboot gained the notion of mainboard variants to avoid duplication of code in rather similar mainboards.

Back then, this feature was developed and used mostly for the benefit of Chrome OS devices, but more recently the code for various Lenovo Thinkpads was deduplicated in the same way.

Another part of cleaning up our tree is improving our tools that help developers follow coding style and avoid mistakes, as well as the infrastructure we have for automated build tests and we’ve seen quite some activity in that space as well.

Documentation

Since the last release we also moved the documentation into the repository. No need for a special wiki account to edit the documentation, and by colocating sources and documentation, it’s easier to keep the latter in sync with the code, too.

This effort is still under way, which is why we still host the old wiki (now read-only) in parallel to the new documentation site that is rendered from coreboot.git’s Documentation/ directory.

Blobs handling

Another big change is in our blobs handling: Given that Intel now provides a reasonably licensed repository with FSP binaries, we were able to mirror it to coreboot.org and integrate it in the build system. This makes it easier to have working images out of the box for devices that depend on Intel’s proprietary init code.

As usual the blobs aren’t part of the coreboot tree and only downloaded with the USE_BLOBS options.

Deprecations

One of the first changes to coreboot after the 4.8 release was to remove boards that didn’t support certain new features and were apparently unmaintained, as discussed in the release notes of coreboot 4.6.

We didn’t follow up on all plans made back then to deprecate boards more aggressively: The board status reporting mechanism is still rather raw and therefore places quite a burden on otherwise sympathetic contributors of build results.

Also, there will be no deprecations after 4.10: Due to its slipping schedule, coreboot 4.9 is released rather late, and as a result 4.10 will only see about 4 months of development. We considered that a rather short timeframe in which to bring old boards up to new standards, and so the next deprecation cycle may be announced with 4.10 to occur after 4.11 is released, in late 2019.

General changes

  • Various code cleanups
  • Removed device_t in favor of struct device* in ramstage code
  • Removed unnecessary include directives
  • Improved adherence to coding style
  • Deduplicated boards by using the variants mechanism
  • Expand use of the postcar stage
  • Add bootblock compression capability: on systems that copy the bootblock from very slow flash to SRAM, allow adding a stub that decompresses the bootblock into SRAM to minimize the amount of flash reads
  • Rename the POWER8 architecture port to PPC64 to reflect that it isn’t limited to POWER8
  • Added support for booting FIT (uImage) payloads on arm64
  • Added SPI flash write protection API
  • Implemented on Winbond
  • Implemented TCPA log for measured boot
  • Implemented GDB support for arm64 architecture in libpayload
  • Dropped support for unmaintained code paths
  • Measured boot support

Added 56 mainboards

  • ASROCK G41C-GS
  • ASROCK G41M-GS
  • ASROCK G41M-S3
  • ASROCK G41M-VS3 R2.0
  • ASROCK H81M-HDS
  • ASUS P5QC
  • ASUS P5QL-PRO
  • ASUS P5Q-PRO
  • ASUS P8H61-M-LX
  • ASUS P8H61-M-PRO
  • CAVIUM CN8100-SFF-EVB
  • FACEBOOK WATSON
  • FOXCONN D41S
  • GIGABYTE GA-H61M-S2PV
  • GOOGLE ALEENA
  • GOOGLE AMPTON
  • GOOGLE ARCADA
  • GOOGLE ASUKA
  • GOOGLE BOBBA
  • GOOGLE BUDDY
  • GOOGLE CAREENA
  • GOOGLE CAROLINE
  • GOOGLE CASTA
  • GOOGLE CAVE
  • GOOGLE DELAN
  • GOOGLE DRAGONEGG
  • GOOGLE FLEEX
  • GOOGLE HATCH
  • GOOGLE KARMA
  • GOOGLE KUKUI
  • GOOGLE LIARA
  • GOOGLE MEEP
  • GOOGLE RAMMUS
  • GOOGLE SARIEN
  • GOOGLE SENTRY
  • HEWLETT PACKARD HP COMPAQ 8200 ELITE SFF PC
  • INTEL COFFEELAKE RVP11
  • INTEL COFFEELAKE RVP8
  • INTEL COFFEELAKE RVPU
  • INTEL DG41WV
  • INTEL ICELAKE RVPU
  • INTEL ICELAKE RVPY
  • INTEL WHISKEYLAKE RVP
  • LENOVO T431S
  • LENOVO THINKCENTRE A58
  • LENOVO W500
  • LENOVO W530
  • OPENCELLULAR ELGON
  • OPENCELLULAR ROTUNDU
  • OPENCELLULAR SUPABRCKV1
  • SIEMENS MC-APL2
  • SIEMENS MC-APL3
  • SIEMENS MC-APL4
  • SIEMENS MC-APL5

Dropped 71 mainboards

  • AAEON PFM-540I REVB
  • AMD DB800
  • AMD DBM690T
  • AMD F2950
  • AMD MAHOGANY
  • AMD NORWICH
  • AMD PISTACHIO
  • AMD SERENGETI-CHEETAH
  • ARTECGROUP DBE61
  • ASROCK 939A785GMH
  • ASUS A8N-E
  • ASUS A8N-SLI
  • ASUS A8V-E DELUXE
  • ASUS A8V-E SE
  • ASUS K8V-X
  • ASUS KFSN4-DRE K8
  • ASUS M2N-E
  • ASUS M2V
  • ASUS M2V MX-SE
  • BACHMANN OT200
  • BCOM WINNETP680
  • BROADCOM BLAST
  • DIGITALLOGIC MSM800SEV
  • GIGABYTE GA-2761GXDK
  • GIGABYTE M57SLI
  • GOOGLE KAHLEE
  • GOOGLE MEOWTH
  • GOOGLE PURIN
  • GOOGLE ROTOR
  • GOOGLE ZOOMBINI
  • HP DL145-G1
  • HP DL145-G3
  • IEI PCISA LX-800 R10
  • IEI PM LX2-800 R10
  • IEI PM LX-800 R11
  • INTEL COUGAR-CANYON2
  • INTEL STARGO2
  • IWILL DK8 HTX
  • JETWAY J7F2
  • JETWAY J7F4K1G2E
  • JETWAY J7F4K1G5D
  • KONTRON KT690
  • LINUTOP LINUTOP1
  • LIPPERT HURRICANE LX
  • LIPPERT LITERUNNER LX
  • LIPPERT ROADRUNNER LX
  • LIPPERT SPACERUNNER LX
  • LOWRISC NEXYS4DDR
  • MSI MS7135
  • MSI MS7260
  • MSI MS9185
  • MSI MS9282
  • NVIDIA L1-2PVV
  • SIEMENS SITEMP-G1P1
  • SUNW ULTRA40
  • SUNW ULTRA40M2
  • SUPERMICRO H8DME
  • SUPERMICRO H8DMR
  • TECHNEXION TIM5690
  • TECHNEXION TIM8690
  • TRAVERSE GEOS
  • TYAN S2912
  • VIA EPIA-CN
  • VIA EPIA-M700
  • VIA PC2500E
  • VIA VT8454C
  • WINENT MB6047
  • WINENT PL6064
  • WINNET G170

CPU changes

  • cpu/intel/model_2065x,206ax,haswell: Switch to POSTCAR_STAGE
  • cpu/intel/slot_1: Switch to different CAR setup
  • Dropped support for the FSP1.0 sandy-/ivy-bridge bootpath

SoC changes

  • Added Cavium CN81xx, Intel Ice Lake and Mediatek MT8183
  • Dropped Broadcom Cygnus, Lowrisc and Marvell mvmap2315

Northbridge changes

  • Dropped AMD K8, VIA CN700, VIA CX700, VIA VX800 because they lack EARLY_CBMEM support
  • intel/e7505: Moved to EARLY_CBMEM
  • nb/intel/i945,e7505,pineview,x4x,gm45,i440bx: Moved to POSTCAR_STAGE
  • nb/intel/i440bx, e7505: Moved to RELOCATABLE_RAMSTAGE
  • intel/x4x: Add DDR3 support
  • nb/intel/pineview: Speed up fetching SPD
  • nb/intel/i945,gm45,x4x,pineview: Use TSEG in SMI

Southbridge changes

  • sb/intel/i82801{g,i,j}x, lynxpoint: Use the common ACPI pirq generator
  • sb/intel/i82801{g,i,j}x: Use common code to set up SMM and for the smihandler
  • Use common functions for PMBASE configuration

Payload changes

  • Support initrd in uImage/FIT to be placed above 4GiB
  • Added documentation for uImage/FIT payloads

Toolchain

  • Update to gcc 8.1.0, binutils 2.30, IASL 20180810, clang 6

UEFI memory mapping

Recently I got into UEFI (TianoCore) development. One of UEFI's properties is that a part of it survives the OS load and remains resident to provide a limited set of firmware services to the OS. Its predecessor, PCBIOS, provided software interrupt services that ran in real-mode - with the effect that every operating system since about 1994 had to switch back to that mode if it wanted to make use of these services. Most didn't, so they simply ignored them and implemented those features by themselves, which was usually faster and more robust, too. Instead of learning the lesson that nobody wants or needs firmware runtime services, UEFI Runtime Services were adapted to that new world: they're regular entry points into protected/long mode code. But these modes allow, or even require, page tables that can change the address under which code or data is found. How could the surviving UEFI code deal with that, not even knowing at which address itself is residing once the OS messed a bit with the memory map? UEFI doesn't walk the current page table. It also doesn't provide a way to convert from logical to physical addresses and back. Instead, the OS can send a partial memory map to UEFI once (and only once!) that must cover all memory regions UEFI claimed as its own (and only those regions!). This must happen before the new memory map is enabled, and UEFI triggers handlers that registered themselves for that event. In these handlers (and only then!) can code request address translations so it can fix up its data structures. Afterwards UEFI patches up all relocations to match the new memory map and returns. From then on, UEFI code can do no further address translation. The expectation is that the OS switches to a page table matching that memory map before next calling into UEFI (or the addresses would be all wrong), and that the UEFI addresses never change again since all later requests to update the memory map will be refused with an error code.

Announcing coreboot 4.3

The “Oh, has FOSDEM started?” release
Dear coreboot community,

today marks the release of coreboot 4.3, the third release on our time based release schedule.
Since the last release, 1030 commits by 114 authors added a net total of 17500 lines to the source code. Thank you to all who contributed!

The release tarballs are available at http://www.coreboot.org/releases/. There’s also a 4.3 tag and branch in the git repository.

Besides the usual addition of new mainboards (14) and chipsets (various), a big theme of the development since 4.2 was cleaning up the code: 20 mainboards were removed that aren’t on the market for years (and even hard to get on Ebay). For several parts of the tree, we established tighter controls, making errors out of what were warnings (and cleaning up the code to match) and provided better tests for various aspects of the tree, and in general tried to establish a more consistent structure across the code base.

Besides that, we had various improvements across the tree, each important when using the hardware, but to numerous for individual shout outs. Martin compiled a list that’s best posted verbatim. Thanks Martin!

Log of commit 529fd81f640fa514ea4c443dd561086e7c582a64 to commit 1bf5e6409678d04fd15f9625460078853118521c for a total of 1030 commits:

Mainboards

Added 14 mainboards

– asus/kfsn4-dre_k8: Native init Dual AMD K8 CPUs & Nvidia CK804 southbridge
– esd/atom15: Bay Trail SOC mainboard using Intel’s FSP
– gigabyte/ga-g41m-es2l: Intel Core 2 / Native init x4x NB / I82801GX SB
– google/guado: Intel Broadwell chromebox (Asus Chromebox CN62)
– google/oak: Mediatek MT8173 SoC chromebook
– google/tidus: Intel Broadwell chromebox (Lenovo ThinkCentre Chromebox)
– google/veyron_emile: Rockchip RK3288 SoC board
– intel/d510mo: Native init Intel Pineview with Intel I82801GX southbridge
– intel/littleplains: Intel Atom c2000 (Rangeley) SoC board
– intel/stargo2: Intel Ivy Bridge / Cave Creek usint Intel’s FSP
– lenovo/r400: Intel Core 2 / Native init GM45 NB / Intel I82801IX SB
– lenovo/t500: Intel Core 2 / Native init GM45 NB / Intel I82801IX SB
– purism/librem13: Intel Broadwell Laptop using Intel MRC
– sunw/ultra40m2: Native init Dual AMD K8 Processors & Nvidia MCP55 SB

Removed 20 mainboards

– arima/hdama
– digitallogic/adl855pc
– ibm/e325, e326
– intel/sklrvp
– iwill/dk8s2, dk8x
– newisys/khepri
– tyan/s2735, s2850, s2875, s2880, s2881 & s2882
– tyan/s2885, s2891, s2892, s2895, s4880 & s4882

Improvements to mainboards

– amd/bettong: fixes to Interrupts, Memory config, S4, EMMC, UARTS
– asus/kgpe-d16: IOMMU and memory fixes, Add CMOS options, Enable GART
– intel/strago: GPIO, DDR, & SD config, FSP updates, Clock fixes
– ACPI fixes across various platforms
– Many individual fixes to other mainboards

Continued updates for the Intel Skylake platform

– google/chell, glados, & lars: FSP & Memory updates, Add Fan & NHLT support
– intel/kunimitsu: FSP & GPIO updates, Add Fan & NHLT (audio) support

Build system

– Update build to use FMAP based firmware layout with multiple cbfs sections
– Enable Kconfig strict mode – Kconfig warnings are no longer allowed.
– Enable ACPI warnings are errors in IASL – warnings are no longer allowed.
– Tighten checking on toolchains and give feedback to users if there are issues
– Updates to get the ADA compiler to work correctly for coreboot
– Various improvements to Makefiles and build scripts
– Cleanup of CBFS file handling

Utilities

– cleanups and improvements to many of the utilities
– cbfstool: Many fixes and extensions to integrate with FMAP
– Add amdfwtool to combine AMD firmware blobs instead of using shell scripts.
– Toolchain updates: new versions of GMP & MPFR. Add ADA.
– Updates for building on NetBSD & OS X

Payloads

– SeaBIOS: Update stable release to 1.9.0
– coreinfo: fix date, hide cursor, use crosscompiler to build
– libpayload: updates for cbfs, XHCI and DesignWare HCD controllers

ARM

– Added 1 soc: mediatek/mt8173
– Various fixes for ARM64 platforms

X86

– Added 2 northbridges: intel/pineview & x4x
– Removed 1 northbridge: intel/i440lx
– Added 1 southbridge: intel/fsp_i89xx
– Removed 2 southbridge(s): intel/esb6300 & i82801cx
– Rename amd/model_10xxx to family_10h-family_15h.
– ACPI: fix warnings, Add functions for IVRS, DMAR I/O-APIC and HPET entries
– Work in many areas fixing issues compiling in 64-bit
– Numerous other fixes across the tree

Areas with significant work on updates and fixes

– cpu/amd/model_fxx
– intel/fsp1_x: Fix timestanps & postcodes, add native CAR & microcode
– nb/amd/amdfam10: Add S3, voltage & ACPI, speed fixes & MANY other changes
– nb/amd/amdmct: Add S3, mem voltage, Fix performance & MANY other changes
– nb/intel/sandybridge: Add IOMMU & ACPI DMAR support, Memory cleanup
– soc/intel/braswell: FSP & ACPI updates, GPIO & clock Fixes
– soc/intel/fsp_baytrail: GPIO, microcode and Interrupt updates.
– soc/intel/skylake: FSP, Power/Thermal & GPIO Updates, Add NHLT support
– sb/amd/sb700: Add ACPI & CMOS Setting support, SATA & clock Fixes

MIPS

– Imgtec Pistachio: Memory, PLL & I2C fixes, add reset

SuperIO

– Expand functionality for ite/it8718f & nuvoton/nct5572d superio devices

Added 3 SIOs

– intel/i8900
– winbond/w83667hg-a & wpcd376i

Removed 6 SIOs

– fintek/f71889
– ite/it8661f
– nsc/pc8374 & pc97307
– nuvoton/nct6776
– smsc/fdc37m60x

Lib

– Several updates for reading EDID tables

MISC

– Commonlib: continued updates for cbfs changes
– Work on getting license headers on all coreboot files
– Drop the third paragraph of GPL copyright header across all of coreboot

Submodules

3rdparty/blobs: Update to CarrizoPI 1.1.0.1 (Binary PI 1.5)

coreboot statistics

Total commits: 1030
Total authors: 114
New authors: 46
Total Reviewers: 41
Total lines added: 88255
Total lines removed: -70735
Total delta: 17520

coreboot changelog

The week leading up to November 15th has seen 132 commits (8bd1c36..3ca4116).
The leading themes were the removal of support for old mainboards, and the integration of more non-AGESA AMD support code for Family 10h to 15h that spans everything from fixes to memory configuration to workarounds to problems in the SATA controller, to new feature development, enabling CC6 power-state support and everything in-between.

Other chipset level contributions provided bug fixes to the drivers supporting Intel’s Skylake and AMD’s newer chipsets and mainboards (Kabini, Merlin Falcon, Mullins). Rockchip RK3288 now properly configures displays whether they’re connected through HDMI or DVI.

ARM/ARM64 saw some cleanup in its transition between stages to accommodate more processor configurations on ARM64 SoCs (that sometimes come with smaller 32bit cores for supporting purposes).

Also new is the Intel i8900 southbridge support that can be used with Sandy Bridge and Ivy Bridge, with an Intel reference board, the stargo2, and the SUNW Ultra40m2 board support.

The USB device mode driver for DesignWare’s USB2 controller (DWC2) in libpayload became more robust. The other notable field of work in libpayload is work with PDcurses’ upstream to synchronize their development and our copy.

In terms of the ongoing efforts to clean up old cruft across the entire tree, references to the getpir utility were dropped, after the tool was removed nearly two years ago. We also removed empty mainboard driver files that used to be required by the build system, even if the mainboard needed no special handling in its ramstage.
To help keep the quality bar high, automated testing now also covers intelvbttool. Another forward-looking addition is a clang-format specification of our coding style. It isn’t complete yet, but the hope is that we can eventually use it to simplify adhering to a consistent style and then enforce it.
The script to help organizing the commit log for release notes was pushed into util/release.

coreboot changelog

This changelog covers the week up to November 8th, spanning 63 commits (f6dc544..8bd1c36).

Last week’s code submissions gave us a lot of improvements pretty much everywhere, but the most user-visible change is probably the addition of ACPI S3 support to asrock/e350m1.

Speaking of ACPI, support for the DMAR tables used to report Intel IOMMU (VT-d) information to the operating system was significantly improved and is enabled on Sandy Bridge and Ivy Bridge.

Another user visible change is the rework of the fallback mechanism in our bootblock, making its CMOS-backed state handling more robust.

cbmem also saw some changes in that all its entries are now listed separately in cbtables (and util/cbmem uses that new structure) to cut down on what coreboot exposes as interface.

On the architectures side, ARM64 dropped its sec(urity) mon(itor) code in favor of using ARM Ltd’s Open Source arm-trusted-firmware, which we already import in 3rdparty.

The integration of commits to support AMD Fam15h CPUs with a non-AGESA implementation that integrates better with coreboot saw some progress. The AMD Binary PI side saw a number of bug fixes, too.

Boards based on Intel’s Skylake architecture also saw more development.

In addition to these targetted developments, there was also the usual set of bug fixes across the entire tree, providing some cleanups to the code and configuration system, some portability fixes for Windows and Mac OS X, deduplication of ACPI table generation on i945, and the removal of a Super IO that wasn’t used by any board (and thus isn’t even build tested).

The USB device mode driver in libpayload for the DesignWare USB2 controller works better under debugging, while the XHCI USB3 host controller driver gained a workaround for Intel XHCI controllers.

Finally, the board-status scripts that parse boot success reports into the list of supported motherboards on the wiki were modified to point out more clearly that the list on the wiki describes the current status. This became necessary because some users assumed that it’s outdated.
Since the i440bx mainboards that were at the top of the list may have contributed to that impression, desktop boards were moved down in favor of notebooks and server boards where most of the current development happens.