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 Plans to move platform support to a branch:
 199 -------------------------------------------
 200 After the 4.18 release in November 2022, we plan to move support for any
 201 boards still requiring RESOURCE_ALLOCATOR_V3 to the 4.18 branch.  V4 was
 202 introduced more than a year ago and with minor changes most platforms
 203 were able to work just fine with it. A major difference is that V3 uses
 204 just one continuous region below 4G to allocate all PCI memory BAR's. V4
 205 uses all available space below 4G and if asked to, also above 4G too.
 206 This makes it important that SoC code properly reports all fixed
 207 resources.
 208
 209 Currently only AGESA platforms have issues with it. On Gerrit both
 210 attempts to fix AMD AGESA codebases to use V4 and compatibility modes
 211 inside the V4 allocator have been proposed, but both efforts seem
 212 stalled. See the (not yet merged) documentation
 213 [CR:43603](https://review.coreboot.org/c/coreboot/+/43603) on it's
 214 details. It looks like properly reporting all fixed resources is the
 215 issue.
 216
 217 At this point, we are not specifying which platforms this will include
 218 as there are a number of patches to fix these issues in flight.
 219 Hopefully, all platforms will end up being migrated to the v4 resource
 220 allocator so that none of the platforms need to be supported on the
 221 branch.
 222
 223 Additionally, even if the support for the platform is moved to a branch,
 224 it can be brought back to ToT if they're fixed to support the v4
 225 allocator.
 226
 227
 228 ### Intel Icelake SoC & Icelake RVP mainboard
 229
 230 Intel Icelake is unmaintained. Also, the only user of this platform ever
 231 was the Intel CRB (Customer Reference Board). From the looks of it the
 232 code was never ready for production as only engineering sample CPUIDs
 233 are supported. This reduces the maintanence overhead for the coreboot
 234 project.
 235
 236 Intel Icelake code will be removed with release 4.19 and any maintenence
 237 will be done on the 4.19 branch. This consists of the Intel Icelake SoC
 238 and Intel Icelake RVP mainboard.
 239
 240
 241 ### Intel Quark SoC & Galileo mainboard
 242
 243 The SoC Intel Quark is unmaintained and different efforts to revive it
 244 failed.  Also, the only user of this platform ever was the Galileo
 245 board.
 246
 247 Thus, to reduce the maintanence overhead for the community, support for
 248 the following components will be removed from the master branch and will
 249 be maintained on the release 4.20 branch.
 250
 251   * Intel Quark SoC
 252   * Intel Galileo mainboard
 253
 254
 255 Statistics from commit d2d9021543 to f4c97ea131
 256 -----------------------------------------------
 257
 258 - Total Commits: 1822
 259 - Average Commits per day: 13.38
 260 - Total lines added: 150578
 261 - Average lines added per commit: 82.64
 262 - Number of patches adding more than 100 lines: 128
 263 - Average lines added per small commit: 38.44
 264 - Total lines removed: 33849
 265 - Average lines removed per commit: 18.58
 266 - Total difference between added and removed: 116729
 267 - Total authors: 202
 268 - New authors: 52
 269
 270
 271 Known Issues
 272 ------------
 273
 274 A couple of issues were discovered immediately following the release
 275 that will be fixed in a follow-on point release in the upcoming weeks.
 276
 277 A pair of changes ([CB:67754](https://review.coreboot.org/67754) and
 278 [CB:67662](https://review.coreboot.org/67662)) which merged shortly
 279 before the 4.18 release have created an issue on Intel Apollo Lake
 280 platform boards which prevents SMM/SMI from functioning; this affects
 281 only Apollo Lake (but not Gemini Lake) devices.
 282 See [CB:68599](https://review.coreboot.org/68599) for the fix.
 283
 284 Another issue applies to all Intel-based boards with onboard I2C TPMs
 285 when verified boot is not enabled. The I2C buses don’t get initialized
 286 until after the TPM, causing timeouts, TPM initialization failures, and
 287 long boot times.  See [CB:68550](https://review.coreboot.org/68550) for
 288 the fix.