Documentation/releases/coreboot-4.18-relnotes.md

   1 coreboot 4.18 release
   2 ========================================================================
   3
   4 The 4.18 release was quite late, but was completed on October 16, 2022.
   5
   6 In the 4 months since the 4.17 release, the coreboot project has merged
   7 more than 1800 commits from over 200 different authors. Over 50 of those
   8 authors submitted their first patches.
   9
  10 Welcome and thank you to all of our new contributors, and of course the
  11 work of all of the seasoned contributors is greatly appreciated.
  12
  13
  14 Significant or interesting changes
  15 ----------------------------------
  16
  17 ### sconfig: Allow to specify device operations
  18
  19 Currently we only have runtime mechanisms to assign device operations to
  20 a node in our devicetree (with one exception: the root device). The most
  21 common method is to map PCI IDs to the device operations with a `struct
  22 pci_driver`. Another accustomed way is to let a chip driver assign them.
  23
  24 For very common drivers, e.g. those in soc/intel/common/blocks/, the PCI
  25 ID lists grew very large and are incredibly error-prone. Often, IDs are
  26 missing and sometimes IDs are added almost mechanically without checking
  27 the code for compatibility. Maintaining these lists in a central place
  28 also reduces flexibility.
  29
  30 Now, for onboard devices it is actually unnecessary to assign the device
  31 operations at runtime. We already know exactly what operations should be
  32 assigned. And since we are using chipset devicetrees, we have a perfect
  33 place to put that information.
  34
  35 This patch adds a simple mechanism to `sconfig`. It allows us to speci-
  36 fy operations per device, e.g.
  37
  38 device pci 00.0 alias system_agent on
  39         ops system_agent_ops
  40 end
  41
  42 The operations are given as a C identifier. In this example, we simply
  43 assume that a global `struct device_operations system_agent_ops` exists.
  44
  45
  46 ### Set touchpads to use detect (vs probed) flag
  47
  48 Historically, ChromeOS devices have worked around the problem of OEMs
  49 using several different parts for touchpads/touchscreens by using a
  50 ChromeOS kernel-specific 'probed' flag (rejected by the upstream kernel)
  51 to indicate that the device may or may not be present, and that the
  52 driver should probe to confirm device presence.
  53
  54 Since release 4.18, coreboot  supports detection for i2c devices at
  55 runtime when creating the device entries for the ACPI/SSDT tables,
  56 rendering the 'probed' flag obsolete for touchpads. Switch all touchpads
  57 in the tree from using the 'probed' flag to the 'detect' flag.
  58
  59 Touchscreens require more involved power sequencing, which will be done
  60 at some future time, after which they will switch over as well.
  61
  62
  63 ### Add SBOM (Software Bill of Materials) Generation
  64
  65 Firmware is typically delivered as one large binary image that gets
  66 flashed. Since this final image consists of binaries and data from a
  67 vast number of different people and companies, it's hard to determine
  68 what all the small parts included in it are. The goal of the software
  69 bill of materials (SBOM) is to take a firmware image and make it easy to
  70 find out what it consists of and where those pieces came from.
  71
  72 Basically, this answers the question, who supplied the code that's
  73 running on my system right now? For example, buyers of a system can use
  74 an SBOM to perform an automated vulnerability check or license analysis,
  75 both of which can be used to evaluate risk in a product. Furthermore,
  76 one can quickly check to see if the firmware is subject to a new
  77 vulnerability included in one of the software parts (with the specified
  78 version) of the firmware.
  79
  80 Further reference:
  81 https://web.archive.org/web/20220310104905/https://blogs.gnome.org/hughsie/2022/03/10/firmware-software-bill-of-materials/
  82
  83 - Add Makefile.inc to generate and build coswid tags
  84 - Add templates for most payloads, coreboot, intel-microcode,
  85   amd-microcode. intel FSP-S/M/T, EC, BIOS_ACM, SINIT_ACM,
  86   intel ME and compiler (gcc,clang,other)
  87 - Add Kconfig entries to optionally supply a path to CoSWID tags
  88   instead of using the default CoSWID tags
  89 - Add CBFS entry called SBOM to each build via Makefile.inc
  90 - Add goswid utility tool to generate SBOM data
  91
  92
  93 Additional coreboot changes
  94 ---------------------------
  95
  96 The following are changes across a number of patches, or changes worth
  97 noting, but not needing a full description.
  98
  99 * Allocator v4 is not yet ready, but received significant work.
 100 * Console: create an [smbus console driver](https://doc.coreboot.org/technotes/console.html)
 101 * pciexp_device: Numerous updates and fixes
 102 * Update checkpatch to match Linux v5.19
 103 * Continue updating ACPI to ASL 2.0 syntax
 104 * arch/x86: Add a common romstage entry point
 105 * Documentation: Add a list of [acronyms](https://doc.coreboot.org/acronyms.html)
 106 * Start hooking up ops in devicetree
 107 * Large amounts of general code cleanup and improvement, as always
 108 * Work to make sure all files have licenses
 109
 110
 111 Payloads
 112 --------
 113
 114 ### EDK II (TianoCore)
 115
 116 coreboot uses TianoCore interchangeably with EDK II, and whilst the
 117 meaning is generally clear, it's not the payload it uses.
 118 Consequentially, TianoCore has been renamed to EDK II (2).
 119
 120 The option to use the already deprecated CorebootPayloadPkg has been
 121 removed.
 122
 123 Recent changes to both coreboot and EDK means that UefiPayloadPkg seems
 124 to work on all hardware. It has been tested on:
 125
 126 * Intel Core 2nd, 3rd, 4th, 5th, 6th, 7th, 8th, 8th, 9th, 10th,
 127   11th and 12th generation processors
 128 * Intel Small Core BYT, BSW, APL, GLK and GLK-R processors
 129 * AMD Stoney Ridge and Picasso
 130
 131 CorebootPayloadPkg can still be found [here](https://github.com/MrChromebox/edk2/tree/coreboot_fb).
 132
 133 The recommended option to use is `EDK2_UEFIPAYLOAD_MRCHROMEBOX` as
 134 `EDK2_UEFIPAYLOAD_OFFICIAL` will no longer work on any SoC.
 135
 136
 137 New Mainboards
 138 --------------
 139
 140 * AMD Birman
 141 * AMD Pademelon renamed from Padmelon
 142 * Google Evoker
 143 * Google Frostflow
 144 * Google Gaelin4ADL
 145 * Google Geralt
 146 * Google Joxer
 147 * Google Lisbon
 148 * Google Magikarp
 149 * Google Morthal
 150 * Google Pujjo
 151 * Google Rex 0
 152 * Google Shotzo
 153 * Google Skolas
 154 * Google Tentacruel
 155 * Google Winterhold
 156 * Google Xivu
 157 * Google Yaviks
 158 * Google Zoglin
 159 * Google Zombie
 160 * Google Zydron
 161 * MSI PRO Z690-A WIFI DDR4
 162 * Siemens MC APL7
 163
 164
 165 Removed Mainboards
 166 ------------------
 167
 168 * Google Brya4ES
 169
 170
 171 Updated SoCs
 172 ------------
 173
 174 * Added Intel Meteor Lake
 175 * Added Mediatek Mt8188
 176 * Renamed AMD Sabrina to Mendocino
 177 * Added AMD Morgana
 178
 179
 180 Plans for Code Deprecation
 181 --------------------------
 182
 183 ### LEGACY_SMP_INIT
 184
 185 Legacy SMP init will be removed from the coreboot master branch
 186 immediately following this release. Anyone looking for the latest
 187 version of the code should find it on the 4.18 branch or tag.
 188
 189 This also includes the codepath for SMM_ASEG. This code is used to start
 190 APs and do some feature programming on each AP, but also set up SMM.
 191 This has largely been superseded by PARALLEL_MP, which should be able to
 192 cover all use cases of LEGACY_SMP_INIT, with little code changes. The
 193 reason for deprecation is that having 2 codepaths to do the virtually
 194 the same increases maintenance burden on the community a lot, while also
 195 being rather confusing.
 196
 197
 198 ### Intel Icelake SoC & Icelake RVP mainboard
 199
 200 Intel Icelake is unmaintained. Also, the only user of this platform ever
 201 was the Intel CRB (Customer Reference Board). From the looks of it the
 202 code was never ready for production as only engineering sample CPUIDs
 203 are supported. This reduces the maintanence overhead for the coreboot
 204 project.
 205
 206 Intel Icelake code will be removed with release 4.19 and any maintenence
 207 will be done on the 4.19 branch. This consists of the Intel Icelake SoC
 208 and Intel Icelake RVP mainboard.
 209
 210
 211 ### Intel Quark SoC & Galileo mainboard
 212
 213 The SoC Intel Quark is unmaintained and different efforts to revive it
 214 failed.  Also, the only user of this platform ever was the Galileo
 215 board.
 216
 217 Thus, to reduce the maintanence overhead for the community, support for
 218 the following components will be removed from the master branch and will
 219 be maintained on the release 4.20 branch.
 220
 221   * Intel Quark SoC
 222   * Intel Galileo mainboard
 223
 224
 225 Statistics from commit d2d9021543 to f4c97ea131
 226 -----------------------------------------------
 227
 228 - Total Commits: 1822
 229 - Average Commits per day: 13.38
 230 - Total lines added: 150578
 231 - Average lines added per commit: 82.64
 232 - Number of patches adding more than 100 lines: 128
 233 - Average lines added per small commit: 38.44
 234 - Total lines removed: 33849
 235 - Average lines removed per commit: 18.58
 236 - Total difference between added and removed: 116729
 237 - Total authors: 202
 238 - New authors: 52
 239
 240
 241 Known Issues
 242 ------------
 243
 244 A couple of issues were discovered immediately following the release
 245 that will be fixed in a follow-on point release in the upcoming weeks.
 246
 247 A pair of changes ([CB:67754](https://review.coreboot.org/67754) and
 248 [CB:67662](https://review.coreboot.org/67662)) which merged shortly
 249 before the 4.18 release have created an issue on Intel Apollo Lake
 250 platform boards which prevents SMM/SMI from functioning; this affects
 251 only Apollo Lake (but not Gemini Lake) devices.
 252 See [CB:68599](https://review.coreboot.org/68599) for the fix.
 253
 254 Another issue applies to all Intel-based boards with onboard I2C TPMs
 255 when verified boot is not enabled. The I2C buses don’t get initialized
 256 until after the TPM, causing timeouts, TPM initialization failures, and
 257 long boot times.  See [CB:68550](https://review.coreboot.org/68550) for
 258 the fix.