2022-10-17 02:53:10 +02:00
|
|
|
|
coreboot 4.18 release
|
2022-06-04 02:56:28 +02:00
|
|
|
|
========================================================================
|
2022-06-01 01:06:21 +02:00
|
|
|
|
|
2022-10-17 02:53:10 +02:00
|
|
|
|
The 4.18 release was quite late, but was completed on October 16, 2022.
|
2022-06-01 01:06:21 +02:00
|
|
|
|
|
2022-10-17 02:53:10 +02:00
|
|
|
|
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.
|
2022-06-01 01:06:21 +02:00
|
|
|
|
|
2022-06-04 02:56:28 +02:00
|
|
|
|
Welcome and thank you to all of our new contributors, and of course the
|
|
|
|
|
work of all of the seasoned contributors is greatly appreciated.
|
2022-06-01 01:06:21 +02:00
|
|
|
|
|
|
|
|
|
|
2022-06-04 02:56:28 +02:00
|
|
|
|
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)
|
|
|
|
|
|
2022-08-04 17:59:52 +02:00
|
|
|
|
coreboot uses TianoCore interchangeably with EDK II, and whilst the
|
2022-06-04 02:56:28 +02:00
|
|
|
|
meaning is generally clear, it's not the payload it uses.
|
|
|
|
|
Consequentially, TianoCore has been renamed to EDK II (2).
|
2022-06-01 01:06:21 +02:00
|
|
|
|
|
2022-10-12 11:38:14 +02:00
|
|
|
|
The option to use the already deprecated CorebootPayloadPkg has been
|
2022-08-04 17:59:52 +02:00
|
|
|
|
removed.
|
2022-06-01 01:06:21 +02:00
|
|
|
|
|
2022-06-04 02:56:28 +02:00
|
|
|
|
Recent changes to both coreboot and EDK means that UefiPayloadPkg seems
|
|
|
|
|
to work on all hardware. It has been tested on:
|
|
|
|
|
|
2022-08-04 17:59:52 +02:00
|
|
|
|
* 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
|
2022-06-01 01:06:21 +02:00
|
|
|
|
|
2022-08-04 17:59:52 +02:00
|
|
|
|
CorebootPayloadPkg can still be found [here](https://github.com/MrChromebox/edk2/tree/coreboot_fb).
|
2022-06-01 01:06:21 +02:00
|
|
|
|
|
2022-10-12 09:22:48 +02:00
|
|
|
|
The recommended option to use is `EDK2_UEFIPAYLOAD_MRCHROMEBOX` as
|
2022-10-12 11:38:14 +02:00
|
|
|
|
`EDK2_UEFIPAYLOAD_OFFICIAL` will no longer work on any SoC.
|
2022-06-01 01:06:21 +02:00
|
|
|
|
|
|
|
|
|
|
2022-06-04 02:56:28 +02:00
|
|
|
|
New Mainboards
|
|
|
|
|
--------------
|
2022-06-01 01:06:21 +02:00
|
|
|
|
|
2022-06-04 02:56:28 +02:00
|
|
|
|
* 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
|
2022-06-01 01:06:21 +02:00
|
|
|
|
|
|
|
|
|
|
2022-06-04 02:56:28 +02:00
|
|
|
|
Removed Mainboards
|
|
|
|
|
------------------
|
2022-06-01 01:06:21 +02:00
|
|
|
|
|
2022-06-04 02:56:28 +02:00
|
|
|
|
* Google Brya4ES
|
2022-06-01 01:06:21 +02:00
|
|
|
|
|
2022-10-10 23:31:32 +02:00
|
|
|
|
|
2022-06-04 02:56:28 +02:00
|
|
|
|
Updated SoCs
|
|
|
|
|
------------
|
2022-10-10 23:31:32 +02:00
|
|
|
|
|
2022-06-04 02:56:28 +02:00
|
|
|
|
* Added Intel Meteor Lake
|
|
|
|
|
* Added Mediatek Mt8188
|
|
|
|
|
* Renamed AMD Sabrina to Mendocino
|
|
|
|
|
* Added AMD Morgana
|
2022-10-10 23:31:32 +02:00
|
|
|
|
|
|
|
|
|
|
2022-06-04 02:56:28 +02:00
|
|
|
|
Plans for Code Deprecation
|
|
|
|
|
--------------------------
|
2022-10-10 23:31:32 +02:00
|
|
|
|
|
2022-06-01 01:06:21 +02:00
|
|
|
|
### LEGACY_SMP_INIT
|
|
|
|
|
|
|
|
|
|
Legacy SMP init will be removed from the coreboot master branch
|
|
|
|
|
immediately following this release. Anyone looking for the latest
|
2022-06-04 02:56:28 +02:00
|
|
|
|
version of the code should find it on the 4.18 branch or tag.
|
2022-06-01 01:06:21 +02:00
|
|
|
|
|
|
|
|
|
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.
|
2022-06-04 02:56:28 +02:00
|
|
|
|
|
|
|
|
|
|
2022-12-31 00:13:19 +01:00
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
2022-06-04 02:56:28 +02:00
|
|
|
|
### 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
|
|
|
|
|
|
|
|
|
|
|
2022-10-17 02:53:10 +02:00
|
|
|
|
Statistics from commit d2d9021543 to f4c97ea131
|
|
|
|
|
-----------------------------------------------
|
2022-06-04 02:56:28 +02:00
|
|
|
|
|
2022-10-17 02:53:10 +02:00
|
|
|
|
- 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
|
2022-06-04 02:56:28 +02:00
|
|
|
|
- Average lines removed per commit: 18.58
|
2022-10-17 02:53:10 +02:00
|
|
|
|
- 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.
|