1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
|
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.
### 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.
|