[prev in list] [next in list] [prev in thread] [next in thread]
List: linuxbios
Subject: [coreboot] New on blogs.coreboot.org: Announcing coreboot 4.18
From: "blogs.coreboot.org via coreboot" <coreboot () coreboot ! org>
Date: 2022-10-18 20:15:01
Message-ID: 20221018201502.32936222FB () coreboot ! org
[Download RAW message or body]
[Attachment #2 (text/html)]
A new post titled "Announcing coreboot 4.18" has been published on the coreboot blog. \
Find the full post at \
https://blogs.coreboot.org/blog/2022/10/18/announcing-coreboot-4-18/
<h1>coreboot 4.18 release</h1>
<p>The 4.18 release was quite late, but was completed on October 16, 2022.</p>
<p>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.</p>
<p>Welcome and thank you to all of our new contributors, and of course the work of \
all of the seasoned contributors is greatly appreciated.</p>
<h2>Significant or interesting changes</h2>
<h3>sconfig: Allow to specify device operations</h3>
<p>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 <code>struct pci_driver</code>. \
Another accustomed way is to let a chip driver assign them.</p>
<p>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.</p>
<p>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.</p>
<p>This patch adds a simple mechanism to <code>sconfig</code>. It allows us to \
speci- fy operations per device, e.g.</p>
<p>device pci 00.0 alias system_agent on ops system_agent_ops end</p>
<p>The operations are given as a C identifier. In this example, we simply assume that \
a global <code>struct device_operations system_agent_ops</code> exists.</p>
<h3>Set touchpads to use detect (vs probed) flag</h3>
<p>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.</p>
<p>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.</p>
<p>Touchscreens require more involved power sequencing, which will be done at some \
future time, after which they will switch over as well.</p>
<h3>Add SBOM (Software Bill of Materials) Generation</h3>
<p>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.</p>
<p>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.</p>
<p>Further reference: <a \
href="https://web.archive.org/web/20220310104905/https://blogs.gnome.org/hughsie/2022/ \
03/10/firmware-software-bill-of-materials/">https://web.archive.org/web/20220310104905 \
/https://blogs.gnome.org/hughsie/2022/03/10/firmware-software-bill-of-materials/</a></p>
<ul><li>Add Makefile.inc to generate and build coswid tags</li><li>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)</li><li>Add Kconfig \
entries to optionally supply a path to CoSWID tags instead of using the default \
CoSWID tags</li><li>Add CBFS entry called SBOM to each build via \
Makefile.inc</li><li>Add goswid utility tool to generate SBOM data</li></ul>
<h2>Additional coreboot changes</h2>
<p>The following are changes across a number of patches, or changes worth noting, but \
not needing a full description.</p>
<ul><li>Allocator v4 is not yet ready, but received significant \
work.</li><li>Console: create an <a \
href="https://doc.coreboot.org/technotes/console.html">smbus console \
driver</a></li><li>pciexp_device: Numerous updates and fixes</li><li>Update \
checkpatch to match Linux v5.19</li><li>Continue updating ACPI to ASL 2.0 \
syntax</li><li>arch/x86: Add a common romstage entry point</li><li>Documentation: Add \
a list of <a href="https://doc.coreboot.org/acronyms.html">acronyms</a></li><li>Start \
hooking up ops in devicetree</li><li>Large amounts of general code cleanup and \
improvement, as always</li><li>Work to make sure all files have licenses</li></ul>
<h2>Payloads</h2>
<h3>EDK II (TianoCore)</h3>
<p>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).</p>
<p>The option to use the already deprecated CorebootPayloadPkg has been removed.</p>
<p>Recent changes to both coreboot and EDK means that UefiPayloadPkg seems to work on \
all hardware. It has been tested on:</p>
<ul><li>Intel Core 2nd, 3rd, 4th, 5th, 6th, 7th, 8th, 8th, 9th, 10th, 11th and 12th \
generation processors</li><li>Intel Small Core BYT, BSW, APL, GLK and GLK-R \
processors</li><li>AMD Stoney Ridge and Picasso</li></ul>
<p>CorebootPayloadPkg can still be found <a \
href="https://github.com/MrChromebox/edk2/tree/coreboot_fb">here</a>.</p>
<p>The recommended option to use \
is <code>EDK2_UEFIPAYLOAD_MRCHROMEBOX</code> as <code>EDK2_UEFIPAYLOAD_OFFICIAL</code> will \
no longer work on any SoC.</p>
<h2>New Mainboards</h2>
<ul><li>AMD Birman</li><li>AMD Pademelon renamed from Padmelon</li><li>Google \
Evoker</li><li>Google Frostflow</li><li>Google Gaelin4ADL</li><li>Google \
Geralt</li><li>Google Joxer</li><li>Google Lisbon</li><li>Google \
Magikarp</li><li>Google Morthal</li><li>Google Pujjo</li><li>Google Rex \
0</li><li>Google Shotzo</li><li>Google Skolas</li><li>Google \
Tentacruel</li><li>Google Winterhold</li><li>Google Xivu</li><li>Google \
Yaviks</li><li>Google Zoglin</li><li>Google Zombie</li><li>Google Zydron</li><li>MSI \
PRO Z690-A WIFI DDR4</li><li>Siemens MC APL7</li></ul>
<h2>Removed Mainboards</h2>
<ul><li>Google Brya4ES</li></ul>
<h2>Updated SoCs</h2>
<ul><li>Added Intel Meteor Lake</li><li>Added Mediatek Mt8188</li><li>Renamed AMD \
Sabrina to Mendocino</li><li>Added AMD Morgana</li></ul>
<h2>Plans for Code Deprecation</h2>
<h3>LEGACY_SMP_INIT</h3>
<p>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.</p>
<p>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.</p>
<h3>Intel Icelake SoC & Icelake RVP mainboard</h3>
<p>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.</p>
<p>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.</p>
<h3>Intel Quark SoC & Galileo mainboard</h3>
<p>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.</p>
<p>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.</p>
<ul><li>Intel Quark SoC</li><li>Intel Galileo mainboard</li></ul>
<h2>Statistics from commit d2d9021543 to f4c97ea131</h2>
<ul><li>Total Commits: 1822</li><li>Average Commits per day: 13.38</li><li>Total \
lines added: 150578</li><li>Average lines added per commit: 82.64</li><li>Number of \
patches adding more than 100 lines: 128</li><li>Average lines added per small commit: \
38.44</li><li>Total lines removed: 33849</li><li>Average lines removed per commit: \
18.58</li><li>Total difference between added and removed: 116729</li><li>Total \
authors: 202</li><li>New authors: 52</li></ul>
<p></p>
<h2>Known Issues</h2>
<p>A couple of issues were discovered immediately following the release that will be \
fixed in a follow-on point release in the upcoming weeks.<br /></p>
<p>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.</p>
<p><br />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.</p>
<p></p>
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-leave@coreboot.org
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic