Documentation/releases/coreboot-4.16-relnotes.md

   1 coreboot 4.16
   2 ========================================================================
   3
   4 The 4.16 release was done on February 25th, 2022.
   5
   6 Since 4.15 there have been more than 1770 new commits by more than 170
   7 developers.  Of these, more than 35 contributed to coreboot for the
   8 first time.
   9
  10 Welcome to the project!
  11
  12 Thank you to all the developers who continue to make coreboot the
  13 great open source firmware project that it is.
  14
  15 New mainboards:
  16 ---------------
  17 * Acer Aspire VN7-572G
  18 * AMD Chausie
  19 * ASROCK H77 Pro4-M
  20 * ASUS P8Z77-M
  21 * Emulation QEMU power9
  22 * Google Agah
  23 * Google Anahera4ES
  24 * Google Banshee
  25 * Google Beadrix
  26 * Google Brya4ES
  27 * Google Crota
  28 * Google Dojo
  29 * Google Gimble4ES
  30 * Google Herobrine_Rev0
  31 * Google Kingler
  32 * Google Kinox
  33 * Google Krabby
  34 * Google Moli
  35 * Google Nereid
  36 * Google Nivviks
  37 * Google Primus4ES
  38 * Google Redrix4ES
  39 * Google Skyrim
  40 * Google Taeko4ES
  41 * Google Taniks
  42 * Google Vell
  43 * Google Volmar
  44 * Intel Alderlake-N RVP
  45 * Prodrive Atlas
  46 * Star Labs Star Labs StarBook Mk V (i3-1115G4 and i7-1165G7)
  47 * System76 gaze16 3050
  48 * System76 gaze16 3060
  49 * System76 gaze16 3060-b
  50
  51 Removed mainboards:
  52 -------------------
  53 * Google ->  Corsola
  54 * Google ->  Nasher
  55 * Google ->  Stryke
  56
  57 Added processors:
  58 -----------------
  59 * src/cpu/power9
  60 * src/soc/amd/sabrina
  61
  62 Submodule Updates
  63 -----------------
  64 * /3rdparty/amd_blobs (6 commits)
  65 * /3rdparty/arm-trusted-firmware (965 commits)
  66 * /3rdparty/blobs (30 commits)
  67 * /3rdparty/chromeec (2212 commits)
  68 * /3rdparty/intel-microcode (1 commits)
  69 * /3rdparty/qc_blobs (13 commits)
  70 * /3rdparty/vboot (44 commits)
  71
  72 Plans to move platform support to a branch:
  73 -------------------------------------------
  74 After the 4.18 release in November 2022, we plan to move support for any
  75 boards still requiring RESOURCE_ALLOCATOR_V3 to the 4.18 branch.  V4 was
  76 introduced more than a year ago and with minor changes most platforms
  77 were able to work just fine with it. A major difference is that V3 uses
  78 just one continuous region below 4G to allocate all PCI memory BAR's. V4
  79 uses all available space below 4G and if asked to, also above 4G too.
  80 This makes it important that SoC code properly reports all fixed
  81 resources.
  82
  83 Currently only AGESA platforms have issues with it. On Gerrit both
  84 attempts to fix AMD AGESA codebases to use V4 and compatibility modes
  85 inside the V4 allocator have been proposed, but both efforts seem
  86 stalled. See the (not yet merged) documentation
  87 [CR:43603](https://review.coreboot.org/c/coreboot/+/43603) on it's
  88 details. It looks like properly reporting all fixed resources is the
  89 issue.
  90
  91 At this point, we are not specifying which platforms this will include
  92 as there are a number of patches to fix these issues in flight.
  93 Hopefully, all platforms will end up being migrated to the v4 resource
  94 allocator so that none of the platforms need to be supported on the
  95 branch.
  96
  97 Additionally, even if the support for the platform is moved to a branch,
  98 it can be brought back to ToT if they're fixed to support the v4
  99 allocator.
 100
 101 Plans for Code Deprecation
 102 --------------------------
 103 As of release 4.18 (November 2022) we plan to deprecate LEGACY_SMP_INIT.
 104 This also includes the codepath for SMM_ASEG. This code is used to start
 105 APs and do some feature programming on each AP, but also set up SMM.
 106 This has largely been superseded by PARALLEL_MP, which should be able to
 107 cover all use cases of LEGACY_SMP_INIT, with little code changes. The
 108 reason for deprecation is that having 2 codepaths to do the virtually
 109 the same increases maintenance burden on the community a lot, while also
 110 being rather confusing.
 111
 112 A few things are lacking in PARALLEL_MP init:
 113 - Support for !CONFIG_SMP on single core systems. It's likely easy to
 114   extend PARALLEL_MP or write some code that just does CPU detection on
 115   the BSP CPU.
 116 - Support SMM in the legacy ASEG (0xa0000 - 0xb0000) region. A POC
 117   showed that it's not that hard to do with PARALLEL_MP
 118   https://review.coreboot.org/c/coreboot/+/58700
 119
 120 No platforms in the tree have any hardware limitations that would block
 121 migrating to PARALLEL_MP / a simple !CONFIG_SMP codebase.
 122
 123 Significant changes
 124 -------------------
 125 This is, of course, not a complete list of all changes in the 4.16
 126 coreboot release, but a sampling of some of the more interesting and
 127 significant changes.
 128
 129 ### Option to disable Intel Management Engine
 130 Disable the Intel (Converged Security) Management Engine ((CS)ME) via
 131 HECI based on Intel Core processors from Skylake to Alder Lake. State is
 132 set based on a CMOS value of `me_state`. A value of `0` will result in a
 133 (CS)ME state of `0` (working) and value of `1` will result in a (CS)ME
 134 state of `3` (disabled). For an example CMOS layout and more info, see
 135 [cse.c](https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/src/soc/intel/common/block/cse/cse.c).
 136
 137
 138 ### Add [AMD] apcb_v3_edit tool
 139 apcb_v3_edit.py tool edits APCB V3 binaries. Specifically it will inject
 140 up to 16 SPDs into an existing APCB. The APCB must have a magic number
 141 at the top of each SPD slot.
 142
 143
 144 ### Allow enable/disable ME via CMOS
 145 Add .enable method that will set the CSME state. The state is based on
 146 the new CMOS option me_state, with values of 0 and 1. The method is very
 147 stable when switching between different firmware platforms.
 148
 149 This method should not be used in combination with USE_ME_CLEANER.
 150
 151 State 1 will result in:
 152 ME: Current Working State   : 4
 153 ME: Current Operation State : 1
 154 ME: Current Operation Mode  : 3
 155 ME: Error Code              : 2
 156
 157 State 0 will result in:
 158 ME: Current Working State   : 5
 159 ME: Current Operation State : 1
 160 ME: Current Operation Mode  : 0
 161 ME: Error Code              : 0
 162
 163
 164 ### Move LAPIC configuration to MP init
 165 Implementation for setup_lapic() did two things -- call enable_lapic()
 166 and virtual_wire_mode_init().
 167
 168 In PARALLEL_MP case enable_lapic() was redundant as it was already
 169 executed prior to initialize_cpu() call.  For the !PARALLEL_MP case
 170 enable_lapic() is added to AP CPUs.
 171
 172
 173 ### Add ANSI escape sequences for highlighting
 174 Add ANSI escape sequences to highlight a log line based on its loglevel
 175 to the output of "interactive" consoles that are meant to be displayed
 176 on a terminal (e.g. UART). This should help make errors and warnings
 177 stand out better among the usual spew of debug messages. For users whose
 178 terminal or use case doesn't support these sequences for some reason (or
 179 who simply don't like them), they can be disabled with a Kconfig.
 180
 181 While ANSI escape sequences can be used to add color, minicom (the
 182 presumably most common terminal emulator for UART endpoints?) doesn't
 183 support color output unless explicitly enabled (via -c command line
 184 flag), and other terminal emulators may have similar restrictions, so in
 185 an effort to make this as widely useful by default as possible I have
 186 chosen not to use color codes and implement this highlighting via
 187 bolding, underlining and inverting alone (which seem to go through in
 188 all cases). If desired, support for separate color highlighting could be
 189 added via Kconfig later.
 190
 191
 192 ### Add cbmem_dump_console
 193 This function is similar to cbmem_dump_console_to_uart except it uses
 194 the normally configured consoles. A console_paused flag was added to
 195 prevent the cbmem console from writing to itself.
 196
 197
 198 ### Add coreboot-configurator
 199 A simple GUI to change CMOS settings in coreboot's CBFS, via the
 200 nvramtool utility.  Testing on Debian, Ubuntu and Manjaro with coreboot
 201 4.14+, but should work with any distribution or coreboot release that
 202 has an option table. For more info, please check the
 203 [README](https://web.archive.org/web/20220225194308/https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/util/coreboot-configurator/README.md).
 204
 205
 206 ### Update live ISO configs to NixOS 21.11
 207 Update configs so that they work with NixOS 21.11. Drop `iasl` package
 208 since it was replaced with `acpica-tools`.
 209
 210
 211 ### Move to U-Boot v2021.10
 212 Move to building the latest U-Boot.
 213
 214
 215 ### Support systems with >128 cores
 216 Each time the spinlock is acquired a byte is decreased and then the
 217 sign of the byte is checked. If there are more than 128 cores the sign
 218 check will overflow. An easy fix is to increase the word size of the
 219 spinlock acquiring and releasing.
 220
 221
 222 ### Add [samsung] sx9360 [proximity sensor] driver
 223 Add driver for setting up Semtech sx9360 SAR sensor.
 224 The driver is based on sx9310.c. The core of the driver is the same, but
 225 the bindings are slightly different.
 226
 227 Registers are documented [in the kernel tree:](https://web.archive.org/web/20220225182803/https://patchwork.kernel.org/project/linux-iio/patch/20211213024057.3824985-4-gwendal@chromium.org/)
 228 Documentation/devicetree/bindings/iio/proximity/semtech,sx9360.yaml
 229
 230
 231 ### Add driver for Genesys Logic [SD Controller] GL9750
 232 The device is a PCIe Gen1 to SD 3.0 card reader controller to be
 233 used in the Chromebook. The datasheet name is GL9750S and the revision
 234 is 01.
 235
 236 The patch disables ASPM L0s.
 237
 238
 239 ### Add support for Realtek RT8125
 240 The Realtek RT8168 and RT8125 have a similar programming interface,
 241 therefore add the PCI device ID for the RT8125 into driver for support.
 242
 243
 244 ### Add Fibocom 5G WWAN ACPI support
 245 Support PXSX._RST and PXSX.MRST._RST for warm and cold reset.
 246 PXSX._RST is invoked on driver removal.
 247
 248 build dependency:
 249   soc/intel/common/block/pcie/rtd3
 250
 251 This driver will use the rtd3 methods for the same parent in the device
 252 tree. The rtd3 chip needs to be added on the same root port in the
 253 devicetree separately.
 254
 255
 256 ### Fix bug in vr_config
 257 The `cpu_get_power_max()` function returns the TDP in milliwatts, but
 258 the vr_config code interprets the value in watts. Divide the value by
 259 1000 to fix this.
 260
 261 This also fixes an integer overflow when `cpu_get_power_max()` returns
 262 a value greater than 65535 (UINT16_MAX).
 263
 264
 265 ### Make mixed topology work
 266 When using a mixed memory topology with DDR4, it's not possible to boot
 267 when no DIMMs are installed, even though memory-down is available. This
 268 happens because the DIMM SPD length defaults to 256 when no DIMM SPD is
 269 available. Relax the length check when no DIMMs are present to overcome
 270 this problem.
 271
 272
 273 ### Add FSP 2.3 support
 274 FSP 2.3 specification introduces following changes:
 275
 276 1. FSP_INFO_HEADER changes
 277    Updated SpecVersion from 0x22 to 0x23
 278    Updated HeaderRevision from 5 to 6
 279    Added ExtendedImageRevision
 280    FSP_INFO_HEADER length changed to 0x50
 281
 282 2. Added FSP_NON_VOLATILE_STORAGE_HOB2
 283
 284 Following changes are implemented in the patch to support FSP 2.3:
 285
 286 - Add Kconfig option
 287 - Update FSP build binary version info based on ExtendedImageRevision
 288   field in header
 289 - New NV HOB related changes will be pushed as part of another patch
 290
 291
 292 ### Join hash calculation for verification and measurement
 293 This patch moves the CBFS file measurement when CONFIG_TPM_MEASURED_BOOT
 294 is enabled from the lookup step into the code where a file is actually
 295 loaded or mapped from flash. This has the advantage that CBFS routines
 296 which just look up a file to inspect its metadata (e.g. cbfs_get_size())
 297 do not cause the file to be measured twice. It also removes the existing
 298 inefficiency that files are loaded twice when measurement is enabled
 299 (once to measure and then again when they are used). When CBFS
 300 verification is enabled and uses the same hash algorithm as the TPM, we
 301 are even able to only hash the file a single time and use the result for
 302 both purposes.
 303
 304
 305 ### Skip FSP Notify APIs
 306 Alder Lake SoC deselects Kconfigs as below:
 307 - USE_FSP_NOTIFY_PHASE_READY_TO_BOOT
 308 - USE_FSP_NOTIFY_PHASE_END_OF_FIRMWARE
 309 to skip FSP notify APIs (Ready to boot and End of Firmware) and make
 310 use of native coreboot driver to perform SoC recommended operations
 311 prior booting to payload/OS.
 312
 313 Additionally, created a helper function `heci_finalize()` to keep HECI
 314 related operations separated for easy guarding again config.
 315
 316 TODO: coreboot native implementation to skip FSP notify phase API (post
 317 pci enumeration) is still WIP.
 318
 319
 320 ### Add support for PCIe Resizable BARs
 321 Section 7.8.6 of the PCIe spec (rev 4) indicates that some devices can
 322 indicates support for "Resizable BARs" via a PCIe extended capability.
 323
 324 When support this capability is indicated by the device, the size of
 325 each BAR is determined in a different way than the normal "moving
 326 bits" method. Instead, a pair of capability and control registers is
 327 allocated in config space for each BAR, which can be used to both
 328 indicate the different sizes the device is capable of supporting for
 329 the BAR (powers-of-2 number of bits from 20 [1 MiB] to 63 [8 EiB]), and
 330 to also inform the device of the size that the allocator actually
 331 reserved for the MMIO range.
 332
 333 This patch adds a Kconfig for a mainboard to select if it knows that it
 334 will have a device that requires this support during PCI enumeration.
 335 If so, there is a corresponding Kconfig to indicate the maximum number
 336 of bits of address space to hand out to devices this way (again, limited
 337 by what devices can support and each individual system may want to
 338 support, but just like above, this number can range from 20 to 63) If
 339 the device can support more bits than this Kconfig, the resource request
 340 is truncated to the number indicated by this Kconfig.