The latest release of PureBoot, Release 27, now boots memtest86+, Debian netinst, and other OSes that rely on framebuffer output! We worked with the Heads team to implement this change upstream, and it is now in our latest release. Update your firmware with our update instructions! If you’ve ever tried to boot from PureBoot, and […] The post PureBoot Framebuffer Boot Support appeared first on Purism.

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

We are thrilled to announce that 9elements has joined forces with AMD to enable systems using their new 4th Gen EPYC CPUs to run with open-source firmware. This groundbreaking collaboration marks a pivotal milestone in the open-source firmware movement and paves the way for new industry standards. As part of our collaboration, AMD developed a revolutionary library called AMD openSIL, which is responsible for the silicon initialization of their cutting-edge server systems. In contrast to Intel's Firmware Support Package (FSP) - a binary that coreboot calls into - openSIL is open-source and can be directly linked into coreboot. This offers substantial benefits for the open-source community, as they can now build upon and connect to the open-source code directly, rather than relying on unknown binary blobs that lack transparency.

What is AMD openSIL?

Before we dive deeper, let's first clarify what openSIL is. openSIL, or open-source Silicon Initialization Library, is a library designed to enable host firmware solutions to boot modern AMD server platforms seamlessly across the product market segments at scale. AMD's openSIL is committed to becoming entirely open-source and provides an interface for the host firmware to call into, initializing the AMD silicon and booting up as a Proof-of-Concept on 4th Gen AMD EPYC CPU based platforms.

9elements' Involvement

Over the past months, 9elements and AMD have collaborated closely to support AMD openSIL development. In addition, 9elements has assisted AMD in developing a host firmware solution based on coreboot. At the OCP Regional Summit, 9elements will showcase the AMD openSIL demo, where coreboot+AMD openSIL+LinuxBoot boots an AMD EPYC CPU-based platform.

coreboot Support on Modern Server Platforms

This remarkable progress demonstrates the industry's shift towards open-source firmware. In the server market, it is now possible to boot all major SoCs - AMD, Intel, and Ampere - with open-source firmware. While coreboot nowadays support Intel and AMD SoCs, Ampere SoC currently rely on EDKII/TianoCore only. However, Dong Wei, Lead Standards Architect and Fellow at ARM, announced at ByteDance's Cloud FW Event in March that ARM is exploring solutions to have coreboot + LinuxBoot running on ARM-based systems. We anticipate more developments from ARM at the OCP Global Summit and the Open-Source Firmware Conference. In summary, the collaboration between 9elements and AMD represents a monumental development for the open-source firmware movement. The open-sourcing of AMD openSIL and its integration into coreboot will not only benefit AMD and 9elements but the entire open-source community. The shift towards open-source firmware solutions promises to usher in a new era of transparency and security within the industry, and this partnership is a significant stride towards realizing that vision. AMDs announcement: https://community.amd.com/t5/business/empowering-the-industry-with-open-system-firmware-amd-opensil/ba-p/599644

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
449	ThinkPad T440p fail to start, continuous beeping & LED blinking
448	Thinkpad T440P ACPI Battery Value Issues
446	Optiplex 9010 No Post
445	Thinkpad X200 wifi issue
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 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.