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:  https://sfconservancy.org/news/2020/jun/23/gitbranchname/

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:

[PRERAM_LOCALES_VERSION_BYTE (\x01)]
[string_name_1] [\x00]
[locale_id_1] [\x00] [localized_string_1] [\x00]
[locale_id_2] [\x00] [localized_string_2] ...
[\x01]
[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
    LB_TAG_TPM_CB_LOG)
  • 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
	Digests:
		 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

Toolchain

  • 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

/3rdparty

  • 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)

/util

  • 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: https://ticket.coreboot.org/

  • 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

coreboot versions 4.20 and 4.20.1 have been released

coreboot 4.20

The 4.20 release was done on May 15, 2023. Unfortunately, a licensing issue was found immediately after the release was completed, and it was decided to hold the release until that was fixed. The 4.20.1 release contains 4.20 plus that single additional fix.

Please do not use the 4.20 tag, and use the 4.20.1 git tag instead. The 4.20_branch will contain all code for 4.20, 4.20.1, and any further changes required for this release.

The tarballs for the 4.20.1 release may be downloaded from https://coreboot.org/downloads.html. The original 4.20 tarballs are not available due to the incorrect licensing text.

The coreboot community has done a tremendous amount of work on the codebase over the last three and a half months. We’ve had over 1600 commits in that time period, doing ongoing cleanup and improvement.

It can be hard to remember at times how much the codebase really has improved, but looking back at coreboot code from previous years, it’s really impressive the changes that have happened. We’d like to thank everyone who has been involved in these changes. It’s great to work with everyone involved, from the people who make the small cleanup patches and review all of the incoming changes to the people working on new chipsets and SoCs. We’d additionally like to thank all of those individuals who make the effort to become involved and report issues or push even a single patch to fix a bug that they’ve noticed.

Many thanks to everyone involved!

We plan to get the 4.21 release done in mid August, 2023.

Significant or interesting changes

cpu/mp_init.c: Only enable CPUs once they execute code

On some systems the BSP cannot know how many CPUs are present in the system. A typical use case is a multi socket system. Setting the enable flag only on CPUs that actually exist makes it more flexible.

cpu/x86/smm: Add PCI resource store functionality

In certain cases data within protected memory areas like SMRAM could be leaked or modified if an attacker remaps PCI BARs to point within that area. Add support to the existing SMM runtime to allow storing PCI resources in SMRAM and then later retrieving them.

This helps prevent moving BARs around to get SMM to access memory in areas that shouldn’t be accessed.

acpi: Add SRAT x2APIC table support

For platforms using X2APIC mode add SRAT x2APIC table generation. This allows the setup of proper SRAT tables.

drivers/usb/acpi: Add USB _DSM method to enable/disable USB LPM per port

This patch supports projects to use _DSM to control USB3 U1/U2 transition per port.

More details can be found in https://web.archive.org/web/20230116084819/https://learn.microsoft.com/en-us/windows-hardware/drivers/bringup/usb-device-specific-method—dsm-

The ACPI and USB driver of linux kernel need corresponding functions to support this feature. Please see https://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git/log/?h=port_check_acpi_dsm

drivers/efi: Add EFI variable store option support

Add a driver to read and write EFI variables stored in a region device. This is particularly useful for EDK2 as payload and allows it to reuse existing EFI tools to set/get options used by the firmware.

The write implementation is fault tolerant and doesn’t corrupt the variable store. A faulting write might result in using the old value even though a ‘newer’ had been completely written.

Implemented basic unit tests for header corruption, writing existing data and append new data into the store.

Initial firmware region state: Initially the variable store region isn’t formatted. Usually this is done in the EDK2 payload when no valid firmware volume could be found. It might be useful to do this offline or in coreboot to have a working option store on the first boot or when it was corrupted.

Performance improvements: Right now the code always checks if the firmware volume header is valid. This could be optimised by caching the test result in heap. For write operations it would be good to cache the end of the variable store in the heap as well, instead of walking the whole store. For read operations caching the entire store could be considered.

Reclaiming memory: The EFI variable store is append write only. To update an existing variable, first a new is written to the end of the store and then the previous is marked invalid. This only works on PNOR flash that allow to clear set bits, but keep cleared bits state. This mechanisms allows a fault tolerant write, but it also requires to “clean” the variable store from time to time. This cleaning would remove variables that have been marked “deleted”. Such cleaning mechanism in turn must be fault tolerant and thus must use a second partition in the SPI flash as backup/working region. For now, cleaning is done in coreboot.

Fault checking: The driver should check if a previous write was successful and if not mark variables as deleted on the next operation.

drivers/ocp/ewl: Add EWL driver for EWL type 3 error handling

Add EWL (Enhanced Warning Log) driver which handles Intel EWL HOB and prints EWL type 3 primarily associated with MRC training failures.

Toolchain updates

  • Upgrade MPC from version 1.2.1 to 1.3.1
  • Upgrade MPFR from version 4.1.1 to 4.2.0
  • Upgrade CMake from version 3.25.0 to 3.26.3
  • Upgrade LLVM from version 15.0.6 to 15.0.7
  • Upgrade GCC from version 11.2.0 to 11.3.0
  • Upgrade binutils from version 2.37 to 2.40

Additional coreboot changes

  • Remove Yabits payload. Yabits is deprecated and archived.
  • Add DDR2 support to Intel GM45 code.
  • Fix superiotool compilation issues when using musl-libc.
  • Drop the Python 2 package from the coreboot-sdk.
  • Drop the Zephyr SDK from coreboot-sdk since the packaged version was quite old and wasn’t really used.
  • Add inteltool support for the Intel “Emmitsburg” PCH.
  • Work to improve cache hit percentage when rebuilding using ccache.
  • Adding Sound-Open-Firmware drivers to chromebooks to enable audio on non-chrome operating systems.
  • Improve and expand ACPI generation code.
  • Fix some issues for the RISC-V code.
  • Continue upstreaming the POWER9 architecture.
  • Add documentation for SBOM (Software Bill of Materials).
  • Add SimNow console logging support for AMD.
  • Do initial work on Xeon SPR
  • CMOS defaults greater than 128 bytes long now extend to bank 1.

New Mainboards

  • Asrock: B75M-ITX
  • Dell: Latitude E6400
  • Google: Aurash
  • Google: Boxy
  • Google: Constitution
  • Google: Gothrax
  • Google: Hades
  • Google: Myst
  • Google: Screebo
  • Google: Starmie
  • Google: Taranza
  • Google: Uldren
  • Google: Yavilla
  • HP: EliteBook 2170p
  • Intel: Archer City CRB
  • Intel: DQ67SW
  • Protectli: VP2420
  • Protectli: VP4630/VP4650
  • Protectli: VP4670
  • Siemens: MC EHL4
  • Siemens: MC EHL5
  • System76: lemp11
  • System76: oryp10
  • System76: oryp9

Removed Mainboards

  • Intel Icelake U DDR4/LPDDR4 RVP
  • Intel Icelake Y LPDDR4 RVP
  • Scaleway TAGADA

Updated SoCs

  • Removed soc/intel/icelake

Plans to move platform support to a branch

Intel Quark SoC & Galileo mainboard

The SoC Intel Quark is unmaintained and different efforts to revive it have so far failed. The only user of this SoC ever was the Galileo board.

Thus, to reduce the maintenance overhead for the community, support for the following components will be removed from the master branch and will be maintained on the release 4.20 branch.

  • Intel Quark SoC
  • Intel Galileo mainboard

Statistics from the 4.19 to the 4.20 release

  • Total Commits: 1630
  • Average Commits per day: 13.72
  • Total lines added: 102592
  • Average lines added per commit: 62.94
  • Number of patches adding more than 100 lines: 128
  • Average lines added per small commit: 37.99
  • Total lines removed: 34824
  • Average lines removed per commit: 21.36
  • Total difference between added and removed: 67768
  • Total authors: ~170
  • New authors: ~35

Significant Known and Open Issues

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

Bug #Subject
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 device not showing up 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
414X9SAE-V: No USB keyboard init on SeaBIOS using Radeon RX 6800XT
412x230 reboots on suspend
393T500 restarts rather than waking up from suspend
350I225 PCIe device not detected on Harcuvar
327OperationRegion (OPRG, SystemMemory, ASLS, 0x2000) causes BSOD

Announcing coreboot release 4.19

coreboot 4.19 release

The 4.19 release was completed on the 16th of January 2023.

Since the last release, the coreboot project has merged over 1600 commits from over 150 authors. Of those authors, around 25 were first-time committers to the coreboot project.

As always, we are very grateful to all of the contributors for helping to keep the project going. The coreboot project is different from many open source projects in that we need to keep constantly updating the codebase to stay relevant with the latest processors and technologies. It takes constant effort to just stay afloat, let alone improve the codebase. Thank you very much to everyone who has contributed, both in this release and in previous times.

The 4.20 release is planned for the 20th of April, 2023.

Significant or interesting changes

Show all Kconfig options in saved config file; compress same

The coreboot build system automatically adds a ‘config’ file to CBFS that lists the exact Kconfig configuration that the image was built with. This is useful to reproduce a build after the fact or to check whether support for a specific feature is enabled in the image.

This file has been generated using the ‘savedefconfig’ Kconfig command, which generates the minimal .config file that is needed to produce the required config in a coreboot build. This is fine for reproduction, but bad when you want to check if a certain config was enabled, since many options get enabled by default or pulled in through another option’s ‘select’ statement and thus don’t show up in the defconfig.

Instead coreboot now includes a larger .config instead. In order to save some space, all of the comments disabling options are removed from the file, except for those included in the defconfig.

We can also LZMA compress the file since it is never read by firmware itself and only intended for later re-extraction via cbfstool, which always has LZMA support included.

Toolchain updates

  • Upgrade LLVM from 15.0.0 to 15.0.6
  • Upgrade CMake from 3.24.2 to 3.25.0
  • Upgrade IASL from 20220331 to 20221020
  • Upgrade MPFR from 4.1.0 to 4.1.1

Finished the conversion to ASL 2.0 syntax

Until recently, coreboot still contained lots of code using the legacy ASL syntax. However, all ASL code was ported over to make use of the ASL 2.0 syntax and from this point on new ASL code should make use of it.

Additional coreboot changes

  • Significant work was done to enable and build-test clang builds.
  • Added touchscreen power sequencing and runtime detection.
  • A number of patches were added to clean up and improve SMBIOS.
  • Work is in progress to unify and extend coreboot post codes.
  • Clean up for header includes is in progress with help from IWYU.
  • IOAPIC code has been reworked.
  • Support was added to superiotool for the NCT6687D-W chip.
  • Work is progressing to switch return values to enum cb_err instead of bool or other pass/fail indicators.
  • Clang builds are now working for most boards and are being build-tested.
  • 64-bit coreboot support is in progress and is working on a number ofplatforms.
  • A driver for EC used on various Clevo laptops was added.
  • Native Intel Lynxpoint code was added to replace the MRC.bin.
  • Work continued for the process of adding ops structures to the devicetree.
  • The crossgcc tool can now download the source packages, which are needed to build the coreboot toolchain, from coreboot’s own mirror if desired.
  • A document with useful external resources related to firmware development was added at Documentation/external_docs.md.

New Mainboards

  • AMD: Mayan for Phoenix SoC
  • GIGABYTE: GA-H61M-DS2
  • Google: Crystaldrift
  • Google: Gladios
  • Google: Dibbi
  • Google: Gaelin
  • Google: Marasov
  • Google: Markarth
  • Google: Omnigul
  • Google: Voltorb
  • Intel: Meteorlake-P RVP
  • MSI: PRO Z690-A (WIFI)
  • Siemens: MC_EHL3
  • Star Labs: StarBook Mk VI (i3-1220P and i7-1260P)
  • System76: darp8
  • System76: galp6

Removed Mainboards

  • AMD: Inagua
  • AMD: Olive Hill
  • AMD: Parmer
  • AMD: Persimmon
  • AMD: Southstation
  • AMD: Thatcher
  • AMD: Unionstation
  • ASROCK: E350M1
  • ASROCK: IMB-A180
  • ASUS: A88XM-E
  • ASUS: AM1I-A
  • ASUS: F2A85-M
  • ASUS: F2A85-M LE
  • ASUS: F2A85-M PRO
  • BAP: ODE_e20xx
  • Biostar: A68N-5200
  • Biostar: AM1ML
  • ELMEX: pcm205400
  • ELMEX: pcm205401
  • GizmoSphere: Gizmo
  • GizmoSphere: Gizmo2
  • Google: Morthal
  • HP: ABM
  • HP: Pavilion m6 1035dx
  • Jetway: NF81_T56N_LF
  • Lenovo: AMD G505s
  • LiPPERT: FrontRunner-AF aka ADLINK CoreModule2-GF
  • LiPPERT: Toucan-AF aka cExpress-GFR (+W83627DHG SIO)
  • MSI: MS-7721 (FM2-A75MA-E35)
  • PC Engines: APU1

Updated SoCs

  • Added soc/amd/glinda
  • Renamed soc/amd/morgana to soc/amd/phoenix
  • Removed cpu/amd/agesa/family14
  • Removed cpu/amd/agesa/family15tn
  • Removed cpu/amd/agesa/family16kb

Updated Chipsets

  • Removed northbridge/amd/agesa/family14
  • Removed northbridge/amd/agesa/family15tn
  • Removed northbridge/amd/agesa/family16kb
  • Removed southbridge/amd/agesa/hudson
  • Removed southbridge/amd/cimx/sb800

Payloads

  • Updated GRUB from 2.04 to 2.06
  • Updated SeaBIOS 1.16.0 to 1.16.1

Plans to move platform support to a branch

Intel Icelake SoC & Icelake RVP mainboard

Intel Icelake is unmaintained and the only user of this platform ever was the Intel CRB (Customer Reference Board). From the looks of the code, it was never ready for production as only engineering sample CPUIDs are supported.

Intel Icelake code will be removed following 4.19 and any maintenance will be done on the 4.19 branch. This consists of the Intel Icelake SoC and Intel Icelake RVP mainboard.

Intel Quark SoC & Galileo mainboard

The SoC Intel Quark is unmaintained and different efforts to revive it failed. Also, the only user of this platform ever was the Galileo board.

Thus, to reduce the maintenance overhead for the community, support for the following components will be removed from the master branch and will be maintained on the release 4.20 branch.

  • Intel Quark SoC
  • Intel Galileo mainboard

Statistics from the 4.18 to the 4.19 release

  • Total Commits: 1608
  • Average Commits per day: 17.39
  • Total lines added: 93786
  • Average lines added per commit: 58.32
  • Number of patches adding more than 100 lines: 80
  • Average lines added per small commit: 38.54
  • Total lines removed: 768014
  • Total difference between added and removed: -674228

Significant Known and Open Issues

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

#Subject
449ThinkPad T440p fail to start, continuous beeping & LED blinking
448Thinkpad T440P ACPI Battery Value Issues
446Optiplex 9010 No Post
445Thinkpad X200 wifi issue
439Lenovo X201 Turbo Boost not working (stuck on 2,4GHz)
427x200: Two battery charging issues
414X9SAE-V: No USB keyboard init on SeaBIOS using Radeon RX 6800XT
412x230 reboots on suspend
393T500 restarts rather than waking up from suspend
350I225 PCIe device not detected on Harcuvar
327OperationRegion (OPRG, SystemMemory, ASLS, 0x2000) causes BSOD

Announcing coreboot 4.18

coreboot 4.18 release

The 4.18 release was quite late, but was completed on October 16, 2022.

In the 4 months since the 4.17 release, the coreboot project has merged more than 1800 commits from over 200 different authors. Over 50 of those authors submitted their first patches.

Welcome and thank you to all of our new contributors, and of course the work of all of the seasoned contributors is greatly appreciated.

Significant or interesting changes

sconfig: Allow to specify device operations

Currently we only have runtime mechanisms to assign device operations to a node in our devicetree (with one exception: the root device). The most common method is to map PCI IDs to the device operations with a struct pci_driver. Another accustomed way is to let a chip driver assign them.

For very common drivers, e.g. those in soc/intel/common/blocks/, the PCI ID lists grew very large and are incredibly error-prone. Often, IDs are missing and sometimes IDs are added almost mechanically without checking the code for compatibility. Maintaining these lists in a central place also reduces flexibility.

Now, for onboard devices it is actually unnecessary to assign the device operations at runtime. We already know exactly what operations should be assigned. And since we are using chipset devicetrees, we have a perfect place to put that information.

This patch adds a simple mechanism to sconfig. It allows us to speci- fy operations per device, e.g.

device pci 00.0 alias system_agent on ops system_agent_ops end

The operations are given as a C identifier. In this example, we simply assume that a global struct device_operations system_agent_ops exists.

Set touchpads to use detect (vs probed) flag

Historically, ChromeOS devices have worked around the problem of OEMs using several different parts for touchpads/touchscreens by using a ChromeOS kernel-specific ‘probed’ flag (rejected by the upstream kernel) to indicate that the device may or may not be present, and that the driver should probe to confirm device presence.

Since release 4.18, coreboot supports detection for i2c devices at runtime when creating the device entries for the ACPI/SSDT tables, rendering the ‘probed’ flag obsolete for touchpads. Switch all touchpads in the tree from using the ‘probed’ flag to the ‘detect’ flag.

Touchscreens require more involved power sequencing, which will be done at some future time, after which they will switch over as well.

Add SBOM (Software Bill of Materials) Generation

Firmware is typically delivered as one large binary image that gets flashed. Since this final image consists of binaries and data from a vast number of different people and companies, it’s hard to determine what all the small parts included in it are. The goal of the software bill of materials (SBOM) is to take a firmware image and make it easy to find out what it consists of and where those pieces came from.

Basically, this answers the question, who supplied the code that’s running on my system right now? For example, buyers of a system can use an SBOM to perform an automated vulnerability check or license analysis, both of which can be used to evaluate risk in a product. Furthermore, one can quickly check to see if the firmware is subject to a new vulnerability included in one of the software parts (with the specified version) of the firmware.

Further reference: https://web.archive.org/web/20220310104905/https://blogs.gnome.org/hughsie/2022/03/10/firmware-software-bill-of-materials/

  • Add Makefile.inc to generate and build coswid tags
  • Add templates for most payloads, coreboot, intel-microcode, amd-microcode. intel FSP-S/M/T, EC, BIOS_ACM, SINIT_ACM, intel ME and compiler (gcc,clang,other)
  • Add Kconfig entries to optionally supply a path to CoSWID tags instead of using the default CoSWID tags
  • Add CBFS entry called SBOM to each build via Makefile.inc
  • Add goswid utility tool to generate SBOM data

Additional coreboot changes

The following are changes across a number of patches, or changes worth noting, but not needing a full description.

  • Allocator v4 is not yet ready, but received significant work.
  • Console: create an smbus console driver
  • pciexp_device: Numerous updates and fixes
  • Update checkpatch to match Linux v5.19
  • Continue updating ACPI to ASL 2.0 syntax
  • arch/x86: Add a common romstage entry point
  • Documentation: Add a list of acronyms
  • Start hooking up ops in devicetree
  • Large amounts of general code cleanup and improvement, as always
  • Work to make sure all files have licenses

Payloads

EDK II (TianoCore)

coreboot uses TianoCore interchangeably with EDK II, and whilst the meaning is generally clear, it’s not the payload it uses. Consequentially, TianoCore has been renamed to EDK II (2).

The option to use the already deprecated CorebootPayloadPkg has been removed.

Recent changes to both coreboot and EDK means that UefiPayloadPkg seems to work on all hardware. It has been tested on:

  • Intel Core 2nd, 3rd, 4th, 5th, 6th, 7th, 8th, 8th, 9th, 10th, 11th and 12th generation processors
  • Intel Small Core BYT, BSW, APL, GLK and GLK-R processors
  • AMD Stoney Ridge and Picasso

CorebootPayloadPkg can still be found here.

The recommended option to use is EDK2_UEFIPAYLOAD_MRCHROMEBOX as EDK2_UEFIPAYLOAD_OFFICIAL will no longer work on any SoC.

New Mainboards

  • AMD Birman
  • AMD Pademelon renamed from Padmelon
  • Google Evoker
  • Google Frostflow
  • Google Gaelin4ADL
  • Google Geralt
  • Google Joxer
  • Google Lisbon
  • Google Magikarp
  • Google Morthal
  • Google Pujjo
  • Google Rex 0
  • Google Shotzo
  • Google Skolas
  • Google Tentacruel
  • Google Winterhold
  • Google Xivu
  • Google Yaviks
  • Google Zoglin
  • Google Zombie
  • Google Zydron
  • MSI PRO Z690-A WIFI DDR4
  • Siemens MC APL7

Removed Mainboards

  • Google Brya4ES

Updated SoCs

  • Added Intel Meteor Lake
  • Added Mediatek Mt8188
  • Renamed AMD Sabrina to Mendocino
  • Added AMD Morgana

Plans for Code Deprecation

LEGACY_SMP_INIT

Legacy SMP init will be removed from the coreboot master branch immediately following this release. Anyone looking for the latest version of the code should find it on the 4.18 branch or tag.

This also includes the codepath for SMM_ASEG. This code is used to start APs and do some feature programming on each AP, but also set up SMM. This has largely been superseded by PARALLEL_MP, which should be able to cover all use cases of LEGACY_SMP_INIT, with little code changes. The reason for deprecation is that having 2 codepaths to do the virtually the same increases maintenance burden on the community a lot, while also being rather confusing.

Intel Icelake SoC & Icelake RVP mainboard

Intel Icelake is unmaintained. Also, the only user of this platform ever was the Intel CRB (Customer Reference Board). From the looks of it the code was never ready for production as only engineering sample CPUIDs are supported. This reduces the maintanence overhead for the coreboot project.

Intel Icelake code will be removed with release 4.19 and any maintenence will be done on the 4.19 branch. This consists of the Intel Icelake SoC and Intel Icelake RVP mainboard.

Intel Quark SoC & Galileo mainboard

The SoC Intel Quark is unmaintained and different efforts to revive it failed. Also, the only user of this platform ever was the Galileo board.

Thus, to reduce the maintanence overhead for the community, support for the following components will be removed from the master branch and will be maintained on the release 4.20 branch.

  • Intel Quark SoC
  • Intel Galileo mainboard

Statistics from commit d2d9021543 to f4c97ea131

  • Total Commits: 1822
  • Average Commits per day: 13.38
  • Total lines added: 150578
  • Average lines added per commit: 82.64
  • Number of patches adding more than 100 lines: 128
  • Average lines added per small commit: 38.44
  • Total lines removed: 33849
  • Average lines removed per commit: 18.58
  • Total difference between added and removed: 116729
  • Total authors: 202
  • New authors: 52

Known Issues

A couple of issues were discovered immediately following the release that will be fixed in a follow-on point release in the upcoming weeks.

A pair of changes (CB:67754 + CB:67662) merged shortly before the 4.18 release have created an issue on Intel Apollo Lake platform boards which prevents SMM/SMI from functioning; this affects only Apollo Lake (but not Gemini Lake) devices. A fix has been identified and tested and will be available soon.


Another issue applies to all Intel-based boards with onboard I2C TPMs when verified boot is not enabled. The I2C buses don’t get initialized until after the TPM, causing timeouts, TPM initialization failures, and long boot times.

Announcing coreboot 4.17

coreboot 4.17

The coreboot 4.17 release was done on June 3, 2022.

Since the 4.16 release, we’ve had over 1300 new commits by around 150 contributors. Of those people, roughly 15 were first-time contributors.

As always, we appreciate everyone who has contributed and done the hard work to make the coreboot project successful.

Major Bugfixes in this release

New Mainboards

  • Clevo L140MU / L141MU / L142MU
  • Dell Precision T1650
  • Google Craask
  • Google Gelarshie
  • Google Kuldax
  • Google Mithrax
  • Google Osiris
  • HP Z220 CMT Workstation
  • Star Labs LabTop Mk III (i7-8550u)
  • Star Labs LabTop Mk IV (i3-10110U and i7-10710U)
  • Star Labs Lite Mk III (N5000)
  • Star Labs Lite Mk IV (N5030)

Removed Mainboards

  • Google Deltan
  • Google Deltaur

Significant or interesting changes

These changes are a few that were selected as a sampling of particularly interesting commits.

CBMEM init hooks changed

Instead of having per stage x_CBMEM_INIT_HOOK, we now have only 2 hooks:

  • CBMEM_CREATION_HOOK: Used only in the first stage that creates cbmem, typically romstage. For instance code that migrates data from cache as ram to dram would use this hook.
  • CBMEM_READY_HOOK: Used in every stage that has cbmem. An example would be initializing the cbmem console by appending to what previous stages logged. The reason for this change is improved flexibility with regards to which stage initializes cbmem.

Payloads

  • SeaBIOS: Update stable release from 1.14.0 to 1.16.0
  • iPXE: Update stable release from 2019.3 to 2022.1
  • Add “GRUB2 atop SeaBIOS” aka “SeaGRUB” option, which builds GRUB2 as a secondary payload for SeaBIOS with GRUB2 set as the default boot entry. This allows GRUB2 to use BIOS callbacks provided by SeaBIOS as a fallback method to access hardware that the native GRUB2 payload cannot access.
  • Add option to build SeaBIOS and GRUB2 as secondary payloads
  • Add new coreDOOM payload. See commit message below.

payloads/external: Add support for coreDOOM payload

coreDOOM is a port of DOOM to libpayload, based on the doomgeneric source port. It renders the game to the coreboot linear framebuffer, and loads WAD files from CBFS.

cpu/x86/smm_module_load: Rewrite setup_stub

This code was hard to read as it did too much and had a lot of state to keep track of.

It also looks like the staggered entry points were first copied and only later the parameters of the first stub were filled in. This means that only the BSP stub is actually jumping to the permanent smihandler. On the APs the stub would jump to wherever c_handler happens to point to, which is likely 0. This effectively means that on APs it’s likely easy to have arbitrary code execution in SMM which is a security problem.

Note: This patch fixes CVE-2022-29264 for the 4.17 release.

cpu/x86/smm_module_loader.c: Rewrite setup

This code is much easier to read if one does not have to keep track of mutable variables.

This also fixes the alignment code on the TSEG smihandler setup code. It was aligning the code upwards instead of downwards which would cause it to encroach a part of the save state.

cpu/x86/smm: Add sinkhole mitigation to relocatable smmstub

The sinkhole exploit exists in placing the lapic base such that it messes with GDT. This can be mitigated by checking the lapic MSR against the current program counter.

cpu/x86/64bit: Generate static page tables from an assembly file

This removes the need for a tool to generate simple identity pages. Future patches will link this page table directly into the stages on some platforms so having an assembly file makes a lot of sense.

This also optimizes the size of the page of each 4K page by placing the PDPE_table below the PDE.

cpu/x86/smm,lib/cbmem_console: Enable CBMEMC when using DEBUG_SMI

This change will allow the SMI handler to write to the cbmem console buffer. Normally SMIs can only be debugged using some kind of serial port (UART). By storing the SMI logs into cbmem we can debug SMIs using ‘cbmem -1’. Now that these logs are available to the OS we could also verify there were no errors in the SMI handler.

Since SMM can write to all of DRAM, we can’t trust any pointers provided by cbmem after the OS has booted. For this reason we store the cbmem console pointer as part of the SMM runtime parameters. The cbmem console is implemented as a circular buffer so it will never write outside of this area.

security/tpm/crtm: Add a function to measure the bootblock on SoC level

On platforms where the bootblock is not included in CBFS anymore because it is part of another firmware section (IFWI or a different CBFS), the CRTM measurement fails.

This patch adds a new function to provide a way at SoC level to measure the bootblock. Following patches will add functionality to retrieve the bootblock from the SoC related location and measure it from there. In this way the really executed code will be measured.

soc/amd/common/block/psp: Add platform secure boot support

Add Platform Secure Boot (PSB) enablement via the PSP if it is not already enabled. Upon receiving psb command, PSP will program PSB fuses as long as BIOS signing key token is valid. Refer to the AMD PSB user guide doc# 56654, Revision# 1.00. Unfortunately this document is only available with NDA customers.

drivers/intel/fsp2_0: Add native implementation for FSP Debug Handler

This patch implements coreboot native debug handler to manage the FSP event messages.

‘FSP Event Handlers’ feature introduced in FSP to generate event messages to aid in the debugging of firmware issues. This eliminates the need for FSP to directly write debug messages to the UART and FSP might not need to know the board related UART port configuration. Instead FSP signals the bootloader to inform it of a new debug message. This allows the coreboot to provide board specific methods of reporting debug messages, example: legacy UART or LPSS UART etc.

This implementation has several advantages as:

  1. FSP relies on XIP ‘DebugLib’ driver even while printing FSP-S debug messages, hence, without ROM being cached, post ‘romstage’ would results into sluggish boot with FSP debug enabled. This patch utilities coreboot native debug implementation which is XIP during FSP-M and relocatable to DRAM based resource for FSP-S.
  2. This patch simplifies the FSP DebugLib implementation and remove the need to have serial port library. Instead coreboot ‘printk’ can be used for display FSP serial messages. Additionally, unifies the debug library between coreboot and FSP.
  3. This patch is also useful to get debug prints even with FSP non-serial image (refer to ‘Note’ below) as FSP PEIMs are now leveraging coreboot debug library instead FSP ‘NULL’ DebugLib reference for release build.
  4. Can optimize the FSP binary size by removing the DebugLib dependency from most of FSP PEIMs, for example: on Alder Lake FSP-M debug binary size is reduced by ~100KB+ and FSP-S debug library size is also reduced by ~300KB+ (FSP-S debug and release binary size is exactly same with this code changes). The total savings is ~400KB for each FSP copy, and in case of Chrome AP firmware with 3 copies, the total savings would be 400KB * 3 = ~1.2MB.

Note: Need to modify FSP source code to remove ‘MDEPKG_NDEBUG’ as compilation flag for release build and generate FSP binary with non-NULL FSP debug wrapper module injected (to allow FSP event handler to execute even with FSP non-serial image) in the final FSP.fd.

security/tpm: Add vendor-specific tis functions to read/write TPM regs

In order to abstract bus-specific logic from TPM logic, the prototype for two vendor-specific tis functions are added in this patch. tis_vendor_read() can be used to read directly from TPM registers, and tis_vendor_write() can be used to write directly to TPM registers.

arch/x86: Add support for catching null dereferences through debug regs

This commit adds support for catching null dereferences and execution through x86’s debug registers. This is particularly useful when running 32-bit coreboot as paging is not enabled to catch these through page faults. This commit adds three new configs to support this feature: DEBUG_HW_BREAKPOINTS, DEBUG_NULL_DEREF_BREAKPOINTS and DEBUG_NULL_DEREF_HALT.

drivers/i2c/generic: Add support for i2c device detection

Add ‘detect’ flag which can be attached to devices which may or may not be present at runtime, and for which coreboot should probe the i2c bus to confirm device presence prior to adding an entry for it in the SSDT.

This is useful for boards which may utilize touchpads/touchscreens from multiple vendors, so that only the device(s) present are added to the SSDT. This relieves the burden from the OS to detect/probe if a device is actually present and allows the OS to trust the ACPI _STA value.

util/cbmem: Add FlameGraph-compatible timestamps output

Flame graphs are used to visualize hierarchical data, like call stacks. Timestamps collected by coreboot can be processed to resemble profiler-like output, and thus can be feed to flame graph generation tools.

Generating flame graph using https://github.com/brendangregg/FlameGraph:

   cbmem -S > trace.txt
   FlameGraph/flamegraph.pl --flamechart trace.txt > output.svg

src/console/Kconfig: Add option to disable loglevel prefix

This patch adds an option to disable loglevel prefixes. This patch helps to achieve clear messages when low loglevel is used and very few messages are displayed on a terminal. This option also allows to maintain compatibility with log readers and continuous integration systems that depend on fixed log content.

If the code contains: printk(BIOS_DEBUG, “This is a debug message!\n”) it will show as: [DEBUG] This is a debug message! but if the Kconfig contains: CONFIG_CONSOLE_USE_LOGLEVEL_PREFIX=n the same message will show up as This is a debug message!

util/cbmem: add an option to append timestamp

Add an option to the cbmem utility that can be used to append an entry to the cbmem timestamp table from userspace. This is useful for bookkeeping of post-coreboot timing information while still being able to use cbmem-based tooling for processing the generated data.

-a | --add-timestamp ID: append timestamp with ID\n

Additional changes

The following are changes across a number of patches, or changes worth noting, but not needing a full description.

  • As always, general documentation, code cleanup, and refactoring
  • Remove doxygen config files and targets
  • Get clang compile working for all x86 platforms
  • Work on updating checkpatch to match the current Linux version
  • Timestamps: Rename timestamps to make names more consistent
  • Continue updating ACPI code to ASL 2.0
  • Remove redundant or unnecessary headers from C files
  • arch/x86/acpi_bert_storage.c: Use a common implementation
  • Postcar stage improvements
  • arch/x86/acpi: Consolidate POST code handling
  • intel/common: Enable ROM caching in ramstage
  • vendorcode/amd/agesa: Fix improper use of .data (const is important)
  • sandybridge & gm45: Support setting PCI bars above 4G

Plans for Code Deprecation

Intel Icelake

Intel Icelake is unmaintained. Also, the only user of this platform ever was the CRB board. From the looks of it the code never was ready for production as only engineering sample CPUIDs are supported.

Thus, to reduce the maintanence overhead for the community, it is deprecated from this release on and support for the following components will be dropped with the release 4.19.

  • Intel Icelake SoC
  • Intel Icelake RVP mainboard

LEGACY_SMP_INIT

As of release 4.18 (August 2022) we plan to deprecate LEGACY_SMP_INIT. This also includes the codepath for SMM_ASEG. This code is used to start APs and do some feature programming on each AP, but also set up SMM. This has largely been superseded by PARALLEL_MP, which should be able to cover all use cases of LEGACY_SMP_INIT, with little code changes. The reason for deprecation is that having 2 codepaths to do the virtually the same increases maintenance burden on the community a lot, while also being rather confusing.

No platforms in the tree have any hardware limitations that would block migrating to PARALLEL_MP / a simple !CONFIG_SMP codebase.

Statistics

  • Total Commits: 1305
  • Average Commits per day: 13.42
  • Total lines added: 51422
  • Average lines added per commit: 39.40
  • Number of patches adding more than 100 lines: 59
  • Average lines added per small commit: 24.73
  • Total lines removed: 66206
  • Average lines removed per commit: 50.73
  • Total difference between added and removed: -14784
  • Total authors: 146
  • New authors: 17

coreboot accepted for GSoC 2022

Hello coreboot community,

We have great news: The coreboot project has been accepted for this year’s Google Summer of Code! Thanks to everyone who made this possible!

You can find our GSoC organization page here [1] (unfortunately, newlines were removed from the description, but that’s true for all of the accepted orgs).

Looking at the GSoC timeline [2], this means the next step is discussing our exciting projects. We have about a month for this, from now until April 3rd, when the application phase starts.

We’re still looking for mentors! If you are interested, please have a look at the mail that Felix Singer, GSoC 2022 admin, sent earlier [3]. You also can help with code reviews or working out a project (writing description, defining project scope and tasks, …). Every bit of help counts.

For people interested in being GSoC candidates, we have set up a page [4] with all kinds of information and documentation. Please have a look at this, it’s really worth reading it 🙂

We have also prepared a list of projects [5] and started brainstorming more project ideas [6]. No matter whether you want to participate as a GSoC contributor or mentor, if you are interested, please let us know. Also, in case you have your own project idea, feel free to reach out.

We are excited to have great discussions with you!

Your Org Admins,

Felix Singer, Martin Roth, David Hendricks

[1] https://summerofcode.withgoogle.com/programs/2022/organizations/coreboot
[2] https://developers.google.com/open-source/gsoc/timeline#march_7_-_april_3
[3] https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/message/PGKTAPC3UEPG722JBUBZYIQQ2UZSGRNA/
[4] https://doc.coreboot.org/contributing/gsoc.html
[5] https://doc.coreboot.org/contributing/project_ideas.html
[6] https://docs.google.com/document/d/1LU8CTITfqhJU_G_XHwvSkHAQQWed0_FLWPPoBfcplAQ

P.S. The Flashrom project, which has been included as a part of coreboot in past GSoC programs has also been accepted as a separate GSoC 2022 participating organization. Congratulations!

Announcing coreboot 4.16

coreboot 4.16 release

coreboot's first quarterly release in a number of years, version 4.16 was tagged on February 25th, 2022.

Since 4.15 there have been more than 1770 new commits by more than 170
developers.  Of these, more than 35 contributed to coreboot for the
first time.

Welcome to the project!

Thank you to all the developers who continue to make coreboot the
great open source firmware project that it is.

New mainboards:
---------------
* Acer Aspire VN7-572G
* AMD Chausie
* ASROCK H77 Pro4-M
* ASUS P8Z77-M
* Emulation QEMU power9
* Google Agah
* Google Anahera4ES
* Google Banshee
* Google Beadrix
* Google Brya4ES
* Google Crota
* Google Dojo
* Google Gimble4ES
* Google Herobrine_Rev0
* Google Kingler
* Google Kinox
* Google Krabby
* Google Moli
* Google Nereid
* Google Nivviks
* Google Primus4ES
* Google Redrix4ES
* Google Skyrim
* Google Taeko4ES
* Google Taniks
* Google Vell
* Google Volmar
* Intel Alderlake-N RVP
* Prodrive Atlas
* Star Labs Star Labs StarBook Mk V (i3-1115G4 and i7-1165G7)
* System76 gaze16 3050
* System76 gaze16 3060
* System76 gaze16 3060-b

Removed mainboards:
-------------------
* Google ->  Corsola
* Google ->  Nasher
* Google ->  Stryke

Added processors:
-----------------
* src/cpu/power9
* src/soc/amd/sabrina

Submodule Updates
-----------------
* /3rdparty/amd_blobs (6 commits)
* /3rdparty/arm-trusted-firmware (965 commits)
* /3rdparty/blobs (30 commits)
* /3rdparty/chromeec (2212 commits)
* /3rdparty/intel-microcode (1 commits)
* /3rdparty/qc_blobs (13 commits)
* /3rdparty/vboot (44 commits)

Plans to move platform support to a branch:
-------------------------------------------
After the 4.18 release in November 2022, we plan to move support for any
boards still requiring RESOURCE_ALLOCATOR_V3 to the 4.18 branch.  V4 was
introduced more than a year ago and with minor changes most platforms
were able to work just fine with it. A major difference is that V3 uses
just one continuous region below 4G to allocate all PCI memory BAR's. V4
uses all available space below 4G and if asked to, also above 4G too.
This makes it important that SoC code properly reports all fixed
resources.

Currently only AGESA platforms have issues with it. On Gerrit both
attempts to fix AMD AGESA codebases to use V4 and compatibility modes
inside the V4 allocator have been proposed, but both efforts seem
stalled. See the (not yet merged) documentation
CB:43603 [1] on it's
details. It looks like properly reporting all fixed resources is the
issue.

At this point, we are not specifying which platforms this will include
as there are a number of patches to fix these issues in flight.
Hopefully, all platforms will end up being migrated to the v4 resource
allocator so that none of the platforms need to be supported on the
branch.

Additionally, even if the support for the platform is moved to a branch,
it can be brought back to ToT if they're fixed to support the v4
allocator.

Plans for Code Deprecation
--------------------------
As of release 4.18 (November 2022) we plan to deprecate LEGACY_SMP_INIT.
This also includes the codepath for SMM_ASEG. This code is used to start
APs and do some feature programming on each AP, but also set up SMM.
This has largely been superseded by PARALLEL_MP, which should be able to
cover all use cases of LEGACY_SMP_INIT, with little code changes. The
reason for deprecation is that having 2 codepaths to do the virtually
the same increases maintenance burden on the community a lot, while also
being rather confusing.

A few things are lacking in PARALLEL_MP init:
- Support for !CONFIG_SMP on single core systems. It's likely easy to
  extend PARALLEL_MP or write some code that just does CPU detection on
  the BSP CPU.
- Support SMM in the legacy ASEG (0xa0000 - 0xb0000) region. A POC
  showed that it's not that hard to do with PARALLEL_MP CB:58700 [2]

No platforms in the tree have any hardware limitations that would block
migrating to PARALLEL_MP / a simple !CONFIG_SMP codebase.

Significant changes
-------------------
This is, of course, not a complete list of all changes in the 4.16
coreboot release, but a sampling of some of the more interesting and
significant changes.

### Option to disable Intel Management Engine
Disable the Intel (Converged Security) Management Engine ((CS)ME) via
HECI based on Intel Core processors from Skylake to Alder Lake. State is
set based on a CMOS value of `me_state`. A value of `0` will result in a
(CS)ME state of `0` (working) and value of `1` will result in a (CS)ME
state of `3` (disabled). For an example CMOS layout and more info, see
[cse.c](../../src/soc/intel/common/block/cse/cse.c).


### Add AMD apcb_v3_edit tool
apcb_v3_edit.py tool edits APCB V3 binaries. Specifically it will inject
up to 16 SPDs into an existing APCB. The APCB must have a magic number
at the top of each SPD slot.


### Allow enable/disable ME via CMOS
Add .enable method that will set the CSME state. The state is based on
the new CMOS option me_state, with values of 0 and 1. The method is very
stable when switching between different firmware platforms.

This method should not be used in combination with USE_ME_CLEANER.

State 1 will result in:
ME: Current Working State   : 4
ME: Current Operation State : 1
ME: Current Operation Mode  : 3
ME: Error Code              : 2

State 0 will result in:
ME: Current Working State   : 5
ME: Current Operation State : 1
ME: Current Operation Mode  : 0
ME: Error Code              : 0


### Move LAPIC configuration to MP init
Implementation for setup_lapic() did two things -- call enable_lapic()
and virtual_wire_mode_init().

In PARALLEL_MP case enable_lapic() was redundant as it was already
executed prior to initialize_cpu() call.  For the !PARALLEL_MP case
enable_lapic() is added to AP CPUs.


### Add ANSI escape sequences for highlighting
Add ANSI escape sequences to highlight a log line based on its loglevel
to the output of "interactive" consoles that are meant to be displayed
on a terminal (e.g. UART). This should help make errors and warnings
stand out better among the usual spew of debug messages. For users whose
terminal or use case doesn't support these sequences for some reason (or
who simply don't like them), they can be disabled with a Kconfig.

While ANSI escape sequences can be used to add color, minicom (the
presumably most common terminal emulator for UART endpoints?) doesn't
support color output unless explicitly enabled (via -c command line
flag), and other terminal emulators may have similar restrictions, so in
an effort to make this as widely useful by default as possible I have
chosen not to use color codes and implement this highlighting via
bolding, underlining and inverting alone (which seem to go through in
all cases). If desired, support for separate color highlighting could be
added via Kconfig later.


### Add cbmem_dump_console
This function is similar to cbmem_dump_console_to_uart except it uses
the normally configured consoles. A console_paused flag was added to
prevent the cbmem console from writing to itself.


### Add coreboot-configurator
A simple GUI to change CMOS settings in coreboot's CBFS, via the
nvramtool utility.  Testing on Debian, Ubuntu and Manjaro with coreboot
4.14+, but should work with any distribution or coreboot release that
has an option table. For more info, please check the
README [3].


### Update live ISO configs to NixOS 21.11
Update configs so that they work with NixOS 21.11. Drop `iasl` package
since it was replaced with `acpica-tools`.


### Move to U-Boot v2021.10
Move to building the latest U-Boot.


### Support systems with >128 cores
Each time the spinlock is acquired a byte is decreased and then the
sign of the byte is checked. If there are more than 128 cores the sign
check will overflow. An easy fix is to increase the word size of the
spinlock acquiring and releasing.


### Add [samsung] sx9360 [proximity sensor] driver
Add driver for setting up Semtech sx9360 SAR sensor.
The driver is based on sx9310.c. The core of the driver is the same, but
the bindings are slightly different.

Registers are documented in the kernel tree. [4]
Documentation/devicetree/bindings/iio/proximity/semtech,sx9360.yaml


### Add driver for Genesys Logic [SD Controller] GL9750
The device is a PCIe Gen1 to SD 3.0 card reader controller to be
used in the Chromebook. The datasheet name is GL9750S and the revision
is 01.

The patch disables ASPM L0s.


### Add support for Realtek RT8125
The Realtek RT8168 and RT8125 have a similar programming interface,
therefore add the PCI device ID for the RT8125 into driver for support.


### Add Fibocom 5G WWAN ACPI support
Support PXSX._RST and PXSX.MRST._RST for warm and cold reset.
PXSX._RST is invoked on driver removal.

build dependency:
  soc/intel/common/block/pcie/rtd3

This driver will use the rtd3 methods for the same parent in the device
tree. The rtd3 chip needs to be added on the same root port in the
devicetree separately.


### Fix bug in vr_config
The `cpu_get_power_max()` function returns the TDP in milliwatts, but
the vr_config code interprets the value in watts. Divide the value by
1000 to fix this.

This also fixes an integer overflow when `cpu_get_power_max()` returns
a value greater than 65535 (UINT16_MAX).


### Make mixed topology work
When using a mixed memory topology with DDR4, it's not possible to boot
when no DIMMs are installed, even though memory-down is available. This
happens because the DIMM SPD length defaults to 256 when no DIMM SPD is
available. Relax the length check when no DIMMs are present to overcome
this problem.


### Add FSP 2.3 support
FSP 2.3 specification introduces following changes:

1. FSP_INFO_HEADER changes
   Updated SpecVersion from 0x22 to 0x23
   Updated HeaderRevision from 5 to 6
   Added ExtendedImageRevision
   FSP_INFO_HEADER length changed to 0x50

2. Added FSP_NON_VOLATILE_STORAGE_HOB2

Following changes are implemented in the patch to support FSP 2.3:

- Add Kconfig option
- Update FSP build binary version info based on ExtendedImageRevision
  field in header
- New NV HOB related changes will be pushed as part of another patch


### Join hash calculation for verification and measurement
This patch moves the CBFS file measurement when CONFIG_TPM_MEASURED_BOOT
is enabled from the lookup step into the code where a file is actually
loaded or mapped from flash. This has the advantage that CBFS routines
which just look up a file to inspect its metadata (e.g. cbfs_get_size())
do not cause the file to be measured twice. It also removes the existing
inefficiency that files are loaded twice when measurement is enabled
(once to measure and then again when they are used). When CBFS
verification is enabled and uses the same hash algorithm as the TPM, we
are even able to only hash the file a single time and use the result for
both purposes.


### Skip FSP Notify APIs
Alder Lake SoC deselects Kconfigs as below:
- USE_FSP_NOTIFY_PHASE_READY_TO_BOOT
- USE_FSP_NOTIFY_PHASE_END_OF_FIRMWARE
to skip FSP notify APIs (Ready to boot and End of Firmware) and make
use of native coreboot driver to perform SoC recommended operations
prior booting to payload/OS.

Additionally, created a helper function `heci_finalize()` to keep HECI
related operations separated for easy guarding again config.

TODO: coreboot native implementation to skip FSP notify phase API (post
pci enumeration) is still WIP.


### Add support for PCIe Resizable BARs
Section 7.8.6 of the PCIe spec (rev 4) indicates that some devices can
indicates support for "Resizable BARs" via a PCIe extended capability.

When support this capability is indicated by the device, the size of
each BAR is determined in a different way than the normal "moving
bits" method. Instead, a pair of capability and control registers is
allocated in config space for each BAR, which can be used to both
indicate the different sizes the device is capable of supporting for
the BAR (powers-of-2 number of bits from 20 [1 MiB] to 63 [8 EiB]), and
to also inform the device of the size that the allocator actually
reserved for the MMIO range.

This patch adds a Kconfig for a mainboard to select if it knows that it
will have a device that requires this support during PCI enumeration.
If so, there is a corresponding Kconfig to indicate the maximum number
of bits of address space to hand out to devices this way (again, limited
by what devices can support and each individual system may want to
support, but just like above, this number can range from 20 to 63) If
the device can support more bits than this Kconfig, the resource request
is truncated to the number indicated by this Kconfig.

[1] https://review.coreboot.org/c/coreboot/+/43603
[2] https://review.coreboot.org/c/coreboot/+/58700
[3] https://web.archive.org/web/20220225194308/https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/util/coreboot-configurator/README.md
[4] https://web.archive.org/web/20220225182803/https://patchwork.kernel.org/project/linux-iio/patch/20211213024057.3824985-4-gwendal@chromium.org/

coreboot 4.15 to 4.16 visualized

Announcing coreboot 4.8 & 4.8.1

coreboot 4.8 was released on May 15, 2018.  An issue with payloads was found immediately after the release was complete, requiring the release of an updated version, 4.8.1.  The release tarballs and gpg signatures are available in the usual place at https://www.coreboot.org/downloads.html

coreboot 4.8 & 4.8.1 release notes

The 4.8.1 release contains 2 commits: 5f0b80b880 and 6794ce02d4. This minor release fixes an issue with adding payloads. The 4.8 release covers commit 6dd2f69878 to commit ebdeb4d07d Since the last release, the coreboot project had 1198 commits by 124 authors.

There are PGP signed 4.8 and 4.8.1 tags in the git repository. A branch for 4.8 releases (4.8_branch) has been created.

A big thank you to everyone involved in making this release happen. We couldn’t have done this without the 35 new commit authors, the experienced developers, the many reviewers, documentation writers and the fantastic community supporting users on both the mailing list and the IRC channel.

In general, this has been a calm release cycle. Several old devices were removed from the master branch early in the release, as they hinder development and nobody stepped up doing the porting effort or was willing to test coreboot on them. If there is the desire to get a board back, it isn’t lost as it’s still in the git history.

Intel i945 platform

  • On Intel 945 devices, native graphics initialization is now skipped saving around 100 ms during resume from S3. The OS drivers need to be able to handle that. Linux’ i915 driver is able to handle it, but not the frame buffer driver.

AMD Stoney Ridge

  • Significant cleanup from older AGESA based platforms
  • Fixes to get S3 working
  • Updates to GPIO code to match other modern coreboot chips
  • AGESA interface cleanup – Use native coreboot functions when possible

Lenovo mainboards

  • Started integration of VBT (Video Bios Table) binary files to support native graphics initialisation

Internal changes

  • Rename of payload type ‘payload’ to ‘simple_elf’
  • Progress in removing typedef device_t
  • Migrated all Intel platforms to a common VBT codebase
  • Ongoing cleanup of whitespace, spelling and formatting
  • Support for PCI in ramstage on non-x86
  • Ongoing Intel platform code deduplication

Console changes

  • Reduce default loglevel to DEBUG
  • Introduce a way for mainboard to override the loglevel
  • Restrict console messages to after console initialization

Fixed Bugs

  • qemu-i440fx: Fix ACPI checksum corruption
  • intelmetool: Fix crash, support ME11+ platforms, fix bootguard detection
  • tpm: Fix TPM software stack vulnerability in tlcl_read() for TPM 1.2 (https://github.com/nccgroup/TPMGenie)
  • asrock/b75pro3-m: Fixed HDMI
  • Intel/ibexpeak: Fix missing ACPI PIRQ entries
  • Intel/nehalem: Fix freeze during chipset lockdown

Payloads

  • Bumped SeaBIOS to 1.11.1
  • Improved TianoCore integration

Security

  • Start of refactoring the TPM software stack
  • Introduced coreboot security section in kconfig
  • VBoot & TPM code moved into src/security

Intelmetool

  • Add Intel Boot Guard status support

Documentation

Added 17 mainboards

  • Asus MAXIMUS_IV_GENE_Z Intel Sandybridge
  • Google ATLAS Intel Kabylake
  • Google BIP Intel Geminilake
  • Google CHEZA Qualcomm SDM845
  • Google NOCTURNE Intel Kabylake
  • Google OCTOPUS Intel Geminilake
  • Google PHASER Intel Geminilake
  • Google YORP Intel Geminilake
  • HP 8770W Intel Ivybridge
  • HP FOLIO_9470M Intel Ivybridge
  • Intel KBLRVP8 Intel Skylake
  • Lenovo W520 Intel Sandybridge
  • OCP MONOLAKE Intel Broadwell DE
  • OCP WEDGE100S Intel Broadwell DE
  • Purism Librem 15 v2 Intel Broadwell
  • Scaleway TAGADA Intel Denverton
  • SiFive HIFIVE_UNLEASHED SiFive FU540

Removed 39 mainboards

  • Abit BE6_II_V2_0
  • AMD DINAR
  • AMD RUMBA
  • Asus DSBF
  • Asus MEW_AM
  • Asus MEW_VM
  • A-trend ATC_6220
  • A-trend ATC_6240
  • AZZA PT_6IBD
  • Biostar M6TBA
  • Compaq DESKPRO_EN_SFF_P600
  • DMP EX
  • ECS P6IWP_FE
  • Gigabyte GA_6BXC
  • Gigabyte GA_6BXE
  • HP E_VECTRA_P2706T
  • Intel D810E2CB
  • Intel EAGLEHEIGHTS
  • Intel MTARVON
  • Intel TRUXTON
  • Iwave RAINBOW_G6
  • Lanner EM8510
  • Lippert FRONTRUNNER
  • Mitac 6513WU
  • MSI MS_6119
  • MSI MS_6147
  • MSI MS_6156
  • MSI MS_6178
  • NEC POWERMATE_2000
  • Nokia IP530
  • RCA RM4100
  • Soyo SY_6BA_PLUS_III
  • Supermicro H8QGI
  • Supermicro H8SCM
  • Supermicro X7DB8
  • Thomson IP1000
  • Tyan S1846
  • Tyan S8226
  • Wyse S50

Added 2 socs

  • Qualcomm sdm845
  • SiFive fu540

Removed 2 socs

  • DMP vortex86ex
  • Intel sch

Removed 5 processors

  • AMD agesa-family15
  • AMD geode-gx2
  • Intel ep80579
  • Intel model-f0x
  • Intel model-f1x

Statistics

  • Total commits: 1198
  • Average Commits per day: 9.85
  • Total authors: 124
  • New authors: 35
  • Total lines added: 386113
  • Total lines removed: 291201
  • Total lines difference: 94912

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:

  • EDK2 only supports GCC 4.8 profile. coreboot is now running on GCC 6.3.0.
  • Incompatibilities with code inside the EDK2 which has not been updated.

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)

  • Clean up Kconfig
  • Show more useful error messages

Codebase cleanup (94 commits)

  • Many fixes for files to pass checkpatch. Lots more to do here.
  • Remove commented out code
  • Updates to transition away from device_t
  • Work to get rid of included C files

Documentation (6 commits)

  • Start adding technotes/Design docs
  • Add Kconfig documentation

ACPI & acpigen library

  • Add GPIO macros
  • Clean up and add more functions to ACPIGEN library

EC (26 commits)

  • Add roda/it8518 embedded controller

TPM (41 commits)

  • Cleanup
  • Update ACPI ASL, Runtime generate ACPI table for TPM driver
  • Make SPI TPM driver CAR-safe
  • Update TPM init sequence

Devices (24 commits)

  • Add a new SPI device type
  • Allow devicetree accesses in postcar stage
  • PCIEXP_ASPM: Unify code with other PCI-e tuning

Lib (28 commits)

  • Add option to use Ada code in ramstage
  • bootstate: add arch specific hook at coreboot exit
  • cbfs: Add API to locate a file from specific region
  • Add library to handle SPD data in CBFS or DIMM
  • Add region file support
  • Turn CBMEM console into a ring buffer that can persist across reboots

Commonlib (11 commits)

  • Add xmalloc, xzmalloc and dma routines
  • Add input and output buffer helpers

Drivers (29 commits)

  • i2c: Pass in i2c_generic_config into i2c_generic_fill_ssdt
  • i2c/alps: Add support for ALPS Touchpad driver
  • i2c/generic: Add support for GPIO IRQ
  • i2c/generic: Enable support for adding PowerResource for device
  • i2c/hid: Add generic I2C HID driver
  • i2c/max98927: add i2c driver for Maxim 98927 codec
  • i2c/wacom_ts: Add support for WCOM touchscreen device driver
  • pc80/rtc: Check cmos checksum BEFORE reading cmos value
  • regulator: Add driver for handling GPIO-based fixed regulator
  • storage: Add SD/MMC/eMMC driver based upon depthcharge

SPI interface

  • Significant cleanup and refactoring

Include (17 commits)

  • cpu/intel: Add MSR to support enabling turbo frequency
  • elog: Add all EC event codes

SuperIO (12 commits)

  • Updates for ITE SIOs
  • Add 2 new chips
  • Consolidate code to use common routines

Vboot (23 commits)

  • Add support for recovery hash space in TPM

RISC-V (25 commits)

  • Add lowRISC System On Chip support
  • Cbmem patches, move to common architectural code

ARM (16 commits)

  • Init new serial struct variables for samsung exynos5420 & allwinner a10
  • Fix verstage to use proper assembly versions of mem*()

RockChip RK3399 & platforms (46 commits)

  • Memory, I2C, USB, SD & Display fixes

X86 Intel (193 commits)

  • Broadwell/Sata: Add support for setting IOBP registers for Ports 2 and 3.
  • cpu/intel/common: Add/Use common function to set virtualization
  • drivers/intel/fsp1_1: Fix boot failure for non-verstage case
  • drivers/intel/fsp2_0: Reset on invalid stage cache.
  • drivers/intel/gma: Add textmode using libgfxinit & use scaling to simplify config
  • drivers/intel/mipi_camera: Add MIPI CSI camera SSDT generator
  • broadwell_de: Add SMM code
  • intelblocks/msr: Move intel x86 MSR definition into common location
  • intel/broadwell: Use the correct SATA port config for setting IOBP register
  • intel/wifi: Create ACPI objects for wifi SAR configuration
  • lynxpoint bd82x6x: Enable PCI-to-PCI bridge
  • mrc: Add support for separate training cache in recovery mode
  • nb/i945/early_init.c: Add FSB800 and 1067 to Egress Port Virtual Channel
  • nb/i945/raminit: Add fixes for 800MHz & 1067MHz FSB CPUs
  • nb/intel/gm45: Fix panel-power-sequence clock divisor
  • nb/intel/i945: Fix PEG port on 945gc & sdram_enhanced_addressing for channel1
  • nb/intel/pineview: Move to early cbmem
  • nb/pineview/raminit: Skip Jedec init on resume, fix hot reset path
  • nb/intel/sandybridge/gma: Always initialize DP buffer translation
  • sb/ich7: Use common/gpio.h to set up GPIOs
  • sb/intel/bd82x6x: Add TCO_Lock in finalize step
  • sb/intel/common/gpio: Support ICH9M and prior
  • sb/intel/i82801gx: Add i2c_block_read to smbus.h

sandybridge/raminit

  • Fix CAS Write Latency, disable_channel, normalize_training & odt stretch
  • Separate Sandybridge and Ivybridge
  • Reset internal state on fallback attempts
  • Find CMD rate per channel

soc/intel/common

  • Add common routines for HECI, ITSS, PCR, RTC, systemagent, UART, XHCI, & LPSS
  • Save Memory DIMM Information in SMBIOS table

Apollolake (183 commits)

  • Switch to common routines for LPSS, RTC, ITSS, UART, XHCI, & PCR
  • Enable turbo
  • Add save/restore variable MRC cache
  • Allow ApolloLake SoC to use FSP CAR Init
  • Allow USB2 eye pattern configuration in devicetree

Quark & platforms (14 commits)

  • Fix I2c & Serial port config
  • Add vboot support

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

  • Memory fixes
  • Add S3 suspend/resume

Skylake / Kabylake (208 commits)

  • Add devicetree settings for acoustic noise mitigation
  • Perform CPU MP Init before FSP-S Init
  • Add support for GSPI controller & add GSPI controller get_config support
  • Enable Systemagent IMGU
  • Add USB Port Over Current support & Expand USB OC pins support PCH-H
  • Extract DIMM Information from FSP MEM INFO HOB
  • Add support for eSPI SMI events
  • Update ACPI & various methods

X86 amd (116 commits)

  • ACPI S3: Remove HIGH_MEMORY_SAVE where possible
  • AMD fam10 binaryPI: Remove invalid PCI ops on CPU domain
  • binaryPI platforms: Drop ACPI S3 support
  • sb/amd/sb700: Disable LPC ROM mapping when SPI Flash is used
  • southbridge/amd: Add LPC bridge acpi path for Family14 and SB800
  • arch/x86: remove CAR global migration when postcar stage is used
  • x86/acpi: Add VFCT table

AMD: vendorcode, AGESA, binaryPI (72 commits)

  • Cleanup & consolidate duplicate code
  • Fork for new cache-as-ram init code & Fix binaryPI cache-as-ram
  • Refactor S3 support functions and Delay ACPI S3 backup until ramstage loader

amd/mct:

  • Fix CsMux45 configuration, maximum read latency, & DQ mask calculation

Mainboards (198 commits)

  • asus/f2a85-m_le: Activate IOMMU support
  • lenovo/h8: Add USB Always On
  • google/oak: Enable dual DSI for rowan and the BOE 8-lane MIPI/DSI panel
  • google/parrot: Fix keyboard interrupts, DSDT
  • google/veyron: Work around RAM code strapping error
  • lenovo/t400: Rewrite dock from t60
  • intel/d510mo: enable ACPI resume from S3
  • intel/d945gclf: Fix resume from S3 suspend
  • lenovo/t400: Implement hybrid graphic in romstage
  • Enable libgfxinit on lenovo/t420 & x230, kontron/ktqm77, google/slippy
  • lenovo/x60,t60: Move EC CMOS parameters in checksummed space
  • mc_tcu3: Do not abort initialization of PTN3460 when HW-ID is missing
  • mc_tcu3: Swap LVDS even and odd lanes for a certain hardware
  • purism/librem13: Enable support for M.2 NVMe & Fix M.2 issues

Payloads (53 commits)

  • Update FILO, SeaBIOS, & iPXE versions
  • Many libpayload fixes and updates

Toolchain (19 commits)

  • Update GCC, Binutils, GMP, MPFR, GDB, IASL and LLVM

Utilities: (145 commits)

  • abuild: Build saved config files and print failed builds at the end
  • autoport: Create superiotool logs and fix romstage generator
  • board-status: Update bucketize script and add README file
  • cbfstool: Add cbfs-compression-tool and enable adding precompressed files
  • cbmem: Add custom aligned memcpy() implementation
  • ectool: Fix timeout on sending EC command and support OpenBSD
  • ifdtool: Fix ICH Gbe unlock
  • intelmetool: Add support for Wildcat Point LP, fix segfault on edge cases
  • inteltool: Add support for CH6-10, ICH10, Wildcat Point-LP and fix ICH SPIBAR
  • sconfig: Add a new SPI device type
  • superiotool: Add new chips – IT8783E/F, W83627DHG, W83627EHG, F71808A

Changes in chips

Added 1 processor & northbridge:

  • amd/pi/00670F00

Added 1 soc:

  • lowrisc/lowrisc

Removed 1 northbridge:

  • intel/e7501

Added 2 sios:

  • fintek/f71808a
  • ite/it8783ef

Mainboard changes

Added 52 mainboards and variants:

  • AMD Gardenia – AMD Stoney Ridge
  • Asus F2A85_M_PRO – AMD Family 15h Trinity
  • Asus P5GC_MX – Intel Socket LGA775
  • Gigabyte GA_945GCM_S2L & GA_945GCM_S2C variant – Intel Socket LGA775
  • Google Auron variants: Yuna, Gandof, Lulu – Intel Broadwell
  • Google Beltino variants: McCloud, Monroe, Tricky, Zako – Intel Haswell
  • Google Eve – Intel Kabylake
  • Google Fizz – Intel Kabylake
  • Google Gru variants: Bob, Scarlet – RockChip RK3399
  • Google Oak variants: Hana, Rowan – MediaTek MT8173
  • Google Poppy & Soraka variant – Intel Kabylake
  • Google Rambi variants: Banjo, Candy, Clapper, Glimmer, Gnawty, Heli, Kip, Orco, Quawks, Squawks, Sumo, Swanky, & Winky – Intel Baytrail
  • Google Reef variants: Sand, Snappy, Nasher – Intel Apollolake
  • Google Slippy variants: Leon, Wolf – Intel Haswell
  • Intel KBLRVP3 & KBLRVP7 – Intel Kabylake
  • Intel LEAFHILL – Intel Apollolake
  • Intel MINNOW3 – Intel Apollolake
  • Lenovo L520: Intel Sandybridge
  • Lenovo S230U: Intel Ivybridge
  • Lenovo X1 Carbon GEN1 – Intel Sandybridge
  • lowRISC NEXYS4DDR – RiscV
  • MSI MS7721 – AMD Bulldozer
  • PC Engines APU2 – AMD Jaguar
  • RODA RV11 & RW11 variant – Intel Ivybridge
  • Sapphire Pure Platinum H61 – Intel Socket LGA1155
  • Siemens MC_APL1 – Intel Apollolake

Removed 10 mainboard variants:

  • Google Auron (Still available as a base-board for variants)
  • Google Veyron Chromeboxes: Brain, Danger, Emile, Romy
  • Google Veyron Test Projects: Gus, Nicky, Pinky, Shark, Thea

Utilities

Added 2 new utilities:

  • blobtool
  • me_cleaner

Submodules

Updated 5 submodules

  • 3rdparty/blobs (10 commits)
  • 3rdparty/arm-trusted-firmware (172 commits)
  • 3rdparty/vboot (158 commits)
  • 3rdparty/chromeec/ (810 commits)
  • util/nvidia/cbootimage (2 commits)

Tested boards

The following boards were tested recently:

  • emulation qemu-q35            4.6-1
  • asus kgpe-d16                         4.6-1
  • asus kfsn4-dre                        4.6-1
  • asus p5gc-mx                          4.6-1
  • lenovo x60                               4.5-1681 / 4.6-7
  • lenovo x230                             4.5-1674 / 4.6-27
  • asrock e350m1                        4.5-1662 / 4.6-7
  • lenovo t420                              4.5-1640
  • lenovo x200                             4.5-1598 / 4.6-33
  • sapphire pureplatinumh61  4.5-1575
  • gigabyte ga-945gcm-s2l         4.5-1568
  • lenovo t400                              4.5-1564
  • lenovo t60                                4.5-1559
  • gigabyte m57sli                      4.5-1526
  • purism librem13                    4.5-1503
  • gigabyte ga-g41m-es2l           4.5-1444
  • google slippy                           4.5-1441
  • intel d510mo                           4.5-1341

coreboot statistics from e74f5eaa43 to db508565d2

  • Total Commits: 1708
  • Average Commits per day: 8.75
  • Total authors: 121
  • New authors: 34
  • Total Reviewers: 72
  • Total Submitters: 19
  • Total lines added: 177576
  • Total lines removed: – 107460
  • Total difference: 70116

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.

Results of the coreboot “Mailing List vs Forum” poll

A little while back, there were a few requests to switch from the mailing list format to a web-based forum for our official communication channel.  The coreboot leadership wanted to see what the actual preferences of the coreboot community was, so I posted a poll.  The poll was publicized in IRC and on the mailing list itself, so should have been communicated to the people who would be most directly affected by any change.

Poll results

Here are the overall results from all responses:

Hate Mailing List:1, Prefer Forum: 6, Don't care: 2, Prefer Mailing list: 21, Hate Forum: 26
All_responses

We had a total of 60 valid responses, and I think the overall results pretty clearly indicate that the coreboot project should NOT move away from the mailing list.

One suggestion was to split the communication into the mailing list for Developers, and a forum for non-developers. To see what the various groups thought, I made a few more charts:

Developer preferences:

Prefer Forum: 1, Prefer Mailing list: 16, Hate Forum: 15, Other: 3
Developer Responses

So not unexpectedly, the coreboot developers even more overwhelmingly prefer the mailing list to the general results

Non-developer preferences:

Hate Mailing list: 1, Prefer Forum: 5, Don't care: 2, Prefer Mailing list: 5, Hate Forum: 11, Other: 1
Non-developer Responses

So even within the non-developer group, there was a definite preference for the mailing list format.

Finally, I broke the Non-developer group down into the group that said they were coreboot users, as opposed to those that mainly read the mailing list.

coreboot users (non-developers):

 

Hate Mailing list: 1, Prefer Forum: 4, Prefer Mailing list: 4, Hate Forum: 5
coreboot Users (Non-Developers)

That group had the highest percentage of people who preferred the forum, but it was still well under 40%.

Suggestions

We also asked people what we should do to improve the mailing list.  Here’s a summary of the suggestions:

  • Show people how to set up their (or a different) email client to make reading the mailing list easier.
  • Have people be more polite.
  • Add a FAQ showing previously asked question and answers.
  • A netiquette should be established like on the Linux kernel mailing list.
  • Several suggestions to improve the coreboot mailing list archive at https://www.coreboot.org/pipermail/coreboot/
    • Fix the archive so that long threads aren’t spread into different sections by months.
    • Add a search function to the archive
    • Create monthly archives that can be downloaded (This exists.)
    • Update from Pipermail to a more modern archiver like Hyperkitty – https://pypi.python.org/pypi/HyperKitty

Since it doesn’t look like we’re going to switch to a forum, I’m not going to list the suggestions that people had for that.

Follow-up

Over the upcoming weeks, we’ll look at our options, and discuss our options and plans in the bi-weekly coreboot community meetings.

 

My coreboot mug filled with Lefthand Milk stout Nitro.
cheers!