Documentation/releases/coreboot-4.18-relnotes.md

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](https://doc.coreboot.org/technotes/console.html)
* 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](https://doc.coreboot.org/acronyms.html)
* 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](https://github.com/MrChromebox/edk2/tree/coreboot_fb).

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.


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
[CR:43603](https://review.coreboot.org/c/coreboot/+/43603) 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.


### 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](https://review.coreboot.org/67754) and
[CB:67662](https://review.coreboot.org/67662)) which 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.
See [CB:68599](https://review.coreboot.org/68599) for the fix.

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.  See [CB:68550](https://review.coreboot.org/68550) for
the fix.