A new post titled "Announcing coreboot 4.6" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2017/05/08/announcing-coreboot-4-6/

We are happy to announce the April 2017 release of coreboot, version 4.6.

The 4.6 release covers commit e74f5eaa to commit db508565

Since the last release in October 2016, the coreboot project had 1708 commits by 121 authors.
The release tarballs and gpg signatures are available in the usual place at https://www.coreboot.org/downloads

There is a pgp signed 4.6 tag in the git repository, and a branch will be created as needed.

Changes: Past, ongoing, and future

CBMEM console development and the Linux Kernel

Our cbmem debug console was updated with some nice features. The cbmem console now persists between reboots and is able to be used on some platforms via late init. Also there is a new Linux kernel driver which removes the need for the old cbmem tool to read from the cbmem area. You can find the patch here https://patchwork.kernel.org/patch/9641997/ and it can be enabled via GOOGLE_MEMCONSOLE_COREBOOT kconfig option in your kernel – Note that this name may change going forward.

Critical bugs in TPM 1.2 support

coreboot currently has issues with the TPM 1.2 LPC driver implementation. This leads to a misbehavior in SeaBIOS where the TPM gets temporarily deactivated. We plan to publish the bugfix release 4.6.1 when we have these issues sorted out.

Native graphics and ram init improvements

The native graphics was reworked a while ago and should finally support Windows. Numerous bug fixes and EDID support is also now available. Finally, the native ram initialization for sandybridge/ivybridge platforms got patched and supports more RAM modules.

New and fresh payloads

SeaBIOS, FiLO, and iPXE were all recently updated to the latest versions. Https downloads are the default for all payloads now. We provide the libpayload project which is used for writing own payloads from scratch. The library is MOSTLY licensed under BSD and recently received new functionality in order to prepare for the upcoming replacement for the old nvramcui payload. This new payload is called cbui and is based on the nuklear graphics library including keyboard and mouse support. The cbui payload is currently expected to be merged into the main coreboot tree before the next release.  The upstream repository is here: https://github.com/siro20/coreboot/tree/cbui/payloads/cbui

UEFI support: A long road to go

coreboot can be used with the Tianocore EDK2 UEFI implementation which is open source and available at Github. Sadly it is not currently integrated into the coreboot build. This has several reasons:

We started to make progress with the integration into our sources and the hope is that by the end of the summer, we finally support the EDK2 payload out-of-the-box. See the current patch state at http://review.coreboot.org/#/c/15057/

Fighting blobs and proprietary HW components

coreboot’s ultimate goal would be to replace any closed source firmware stack with free software components. Unfortunately this is not always possible due to signed binaries such as the Intel ME firmware, the AMD PSP and microcode. Recently, a way was discovered to let the Intel ME run in a functional error state and reduce it from 1.5/5MB to 80KB. It’s not perfect but it works from Nehalem up to Skylake based Intel systems. The tool is now integrated into the coreboot build system. The upstream repository is https://github.com/corna/me_cleaner

Another ongoing improvement is the new utility blobtool. It is currently used for generating the flash descriptor and GbE configuration data on older mainboard which are known to be free software. It can easily be extended for different binaries with well-defined specifications.

Did you say Ada?

coreboot now supports Ada, and a lot work was done integrating Ada into our toolchain. At the moment only the support for formal verification is missing and will be soon added. At that point, we can prove the absence of runtime errors in our Ada code. In short, everybody can start developing Ada code for our project.

The existing Ada code which can be used from now on is another native graphics initialization which will replace in the long term the current implementation. The native graphics code supports all Intel platforms up to skylake. We offer support for HDMI, VGA, DVI and DP external interfaces as well and is ready to be integrated into our mainboard implementations.

Toolchain updates

A new coreboot toolchain is out. The major toolchain change was going from GCC version 5.3.0 to 6.3.0. There were also minor version updates to GMP, MPFR, Binutils, GDB, IASL, and Clang.

Deprecation policy for boards

Starting with this release there will be a policy for deprecating unmaintained boards. See the end of this announcement for details.

Change Summary

Build system (20 commits)

Codebase cleanup (94 commits)

Documentation (6 commits)

ACPI & acpigen library

EC (26 commits)

TPM (41 commits)

Devices (24 commits)

Lib (28 commits)

Commonlib (11 commits)

Drivers (29 commits)

SPI interface

Include (17 commits)

SuperIO (12 commits)

Vboot (23 commits)

RISC-V (25 commits)

ARM (16 commits)

RockChip RK3399 & platforms (46 commits)

X86 Intel (193 commits)

sandybridge/raminit

soc/intel/common

Apollolake (183 commits)

Quark & platforms (14 commits)

ga-g41m-es2l, x4x northbridge & LGA775 (23 commits)

Skylake / Kabylake (208 commits)

X86 amd (116 commits)

AMD: vendorcode, AGESA, binaryPI (72 commits)

amd/mct:

Mainboards (198 commits)

Payloads (53 commits)

Toolchain (19 commits)

Utilities: (145 commits)

Changes in chips

Added 1 processor & northbridge:

Added 1 soc:

Removed 1 northbridge:

Added 2 sios:

Mainboard changes

Added 52 mainboards and variants:

Removed 10 mainboard variants:

Utilities

Added 2 new utilities:

Submodules

Updated 5 submodules

Tested boards

The following boards were tested recently:

coreboot statistics from e74f5eaa43 to db508565d2

Code removal after the 4.6 release

The only platform currently scheduled for removal is the bifferos/bifferboard & soc/rdc/r8610. This platform is one of two that still uses romcc to compile romstage and doesn’t have cache-as-ram in romstage – the others were all removed long ago. Additionally, it seems to be impossible to buy, so as far as it can be determined, no testing has been done recently.

Code removal after the 4.7 release

One of the things that the coreboot project has struggled with is how to maintain the older platforms while still moving the rest of the platforms forward. Currently there are numerous platforms in the codebase which have not been well maintained.

Starting with the 4.7 release in October, the coreboot leadership is going to set standards that platforms are expected to meet to remain in the active codebase. These will generally be announced 3 – 6 months in advance to give time to get changes in. The expectation is not necessarily even that all work to meet the goal will be completed, but it is expected that a reasonable effort has started to meet the goal at the time of the release. Regardless of the work that’s been done, platforms which have not met the goal by the following release will be removed.

The next expectation that will need to be met for all platforms is cbmem in romstage. This currently affects numerous platforms, including most, if not all of AMD’s platforms. Work to update many of these platforms has started, but there are others that have not made any progress towards this goal. A list of the platforms that are affected by this will be sent to the mailing list shortly.

Code removal after the 4.8 release

To further clean things up, starting with the 4.8 release, any platform that does not have a successful boot logged in the board_status repo in the previous year (that is, within the previous two releases) will be removed from the maintained coreboot codebase. Chips that do not have any associated boards will also be removed. These platforms will be announced before the release so that there is time for people to test if desired.

This is not meant to be a high bar, but as a measure to clean up the codebase and eliminate boards and chips that are actually no longer being used. The cleanup will happen just after the release, so the removed platforms will still be available in the release branch if desired. If there is still interest, developers can bring back old chips and boards by porting them to the new tree (and bringing them to current standards).

This gives everyone until April 2018 to get any boards that they care about tested before the first removal.

All the code removal information will also be sent to the mailing list along with additional details.