Documentation/releases/coreboot-4.13-relnotes.md

   1 coreboot 4.13
   2 ================================
   3
   4 coreboot 4.13 was released on November 20th, 2020.
   5
   6 Since 4.12 there were 4200 new commits by over 234 developers.
   7 Of these, about 72 contributed to coreboot for the first time.
   8
   9 Thank you to all developers who again helped made coreboot better
  10 than ever, and a big welcome to our new contributors!
  11
  12 New mainboards
  13 --------------
  14
  15 - Acer G43T-AM3
  16 - AMD Cereme
  17 - Asus A88XM-E FM2+
  18 - Biostar TH61-ITX
  19 - BostenTech GBYT4
  20 - Clevo L140CU/L141CU
  21 - Dell OptiPlex 9010
  22 - Example Min86 (fake board)
  23 - Google Ambassador
  24 - Google Asurada
  25 - Google Berknip
  26 - Google Boldar
  27 - Google Boten
  28 - Google Burnet
  29 - Google Cerise
  30 - Google Coachz
  31 - Google Dalboz
  32 - Google Dauntless
  33 - Google Delbin
  34 - Google Dirinboz
  35 - Google Dooly
  36 - Google Drawcia
  37 - Google Eldrid
  38 - Google Elemi
  39 - Google Esche
  40 - Google Ezkinil
  41 - Google Faffy
  42 - Google Fennel
  43 - Google Genesis
  44 - Google Hayato
  45 - Google Lantis
  46 - Google Lindar
  47 - Google Madoo
  48 - Google Magolor
  49 - Google Metaknight
  50 - Google Morphius
  51 - Google Noibat
  52 - Google Pompom
  53 - Google Shuboz
  54 - Google Stern
  55 - Google Terrador
  56 - Google Todor
  57 - Google Trembyle
  58 - Google Vilboz
  59 - Google Voema
  60 - Google Volteer2
  61 - Google Voxel
  62 - Google Willow
  63 - Google Woomax
  64 - Google Wyvern
  65 - HP EliteBook 2560p
  66 - HP EliteBook Folio 9480m
  67 - HP ProBook 6360b
  68 - Intel Alderlake-P RVP
  69 - Kontron COMe-bSL6
  70 - Lenovo ThinkPad X230s
  71 - Open Compute Project DeltaLake
  72 - Prodrive Hermes
  73 - Purism Librem Mini
  74 - Purism Librem Mini v2
  75 - Siemens Chili
  76 - Supermicro X11SSH-F
  77 - System76 lemp9
  78
  79 Removed mainboards
  80 ------------------
  81
  82 - Google Cheza
  83 - Google DragonEgg
  84 - Google Ripto
  85 - Google Sushi
  86 - Open Compute Project SonoraPass
  87
  88 Significant changes
  89 -------------------
  90
  91 ### Native refcode implementation for Bay Trail
  92
  93 Bay Trail no longer needs a refcode binary to function properly. The refcode
  94 was reimplemented as coreboot code, which should be functionally equivalent.
  95 Thus, coreboot only needs to run the MRC.bin to successfully boot Bay Trail.
  96
  97 ### Unusual config files to build test more code
  98
  99 There's some new highly-unusual config files, whose only purpose is to coerce
 100 Jenkins into build-testing several disabled-by-default coreboot config options.
 101 This prevents them from silently decaying over time because of build failures.
 102
 103 ### Initial support for Intel Trusted eXecution Technology
 104
 105 coreboot now supports enabling Intel TXT. Though it's not feature-complete yet,
 106 the code allows successfully launching tboot, a Measured Launch Environment. It
 107 was tested on Haswell using an Asrock B85M Pro4 mainboard with TPM 2.0 on LPC.
 108 Though support for other platforms is still not ready, it is being worked on.
 109 The Haswell MRC.bin needs to be patched so as to enable DPR. Given that the MRC
 110 binary cannot be redistributed, the best long-term solution is to replace it.
 111
 112 ### Hidden PCI devices
 113
 114 This new functionality takes advantage of the existing 'hidden' keyword in the
 115 devicetree. Since no existing boards were using the keyword, its usage was
 116 repurposed to make dealing with some unique PCI devices easier. The particular
 117 case here is Intel's PMC (Power Management Controller). During the FSP-S run,
 118 the PMC device is made hidden, meaning that its config space looks as if there
 119 is no device there (Vendor ID reads as 0xFFFF_FFFF). However, the device does
 120 have fixed resources, both MMIO and I/O. These were previously recorded in
 121 different places (MMIO was typically an SA fixed resource, and I/O was treated
 122 as an LPC resource). With this change, when a device in the tree is marked as
 123 'hidden', it is not probed (`pci_probe_dev()`) but rather assumed to exist so
 124 that its resources can be placed in a more natural location. This also adds the
 125 ability for the device to participate in SSDT generation.
 126
 127 ### Tools for generating SPDs for LP4x memory on TGL and JSL
 128
 129 A set of new tools `gen_spd.go` and `gen_part_id.go` are added to automate the
 130 process of generating SPDs for LP4x memory and assigning hardware strap IDs for
 131 memory parts used on TGL and JSL based boards. The SPD data obtained from memory
 132 part vendors has to be massaged to format it correctly as per JEDEC and Intel MRC
 133 expectations. These tools take a list of memory parts describing their physical
 134 attributes as per their datasheet and convert those attributes into SPD files for
 135 the platforms. More details about the tools are added in
 136 [README.md](https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/util/spd_tools/intel/lp4x/README.md).
 137
 138 ### New version of SMM loader
 139
 140 A new version of the SMM loader which accommodates platforms with over 32
 141 CPU threads.  The existing version of SMM loader uses a 64K code/data
 142 segment and only a limited number of CPU threads can fit into one segment
 143 (because of save state, STM, other features, etc). This loader extends beyond
 144 the 64K segment to accommodate additional CPUs and in theory allows as many
 145 CPU threads as possible limited only by SMRAM space and not by 64K. By default
 146 this loader version is disabled. Please see cpu/x86/Kconfig for more info.
 147
 148 ### Address Sanitizer
 149
 150 coreboot now has an in-built Address Sanitizer, a runtime memory debugger
 151 designed to find out-of-bounds access and use-after-scope bugs. It is made
 152 available on all x86 platforms in ramstage and on QEMU i440fx, Intel Apollo
 153 Lake, and Haswell in romstage. Further, it can be enabled in romstage on other
 154 x86 platforms as well. Refer [ASan documentation](../technotes/asan.md) for
 155 more info.
 156
 157 ### Initial support for x86_64
 158
 159 The x86_64 code support has been revived and enabled for QEMU. While it started
 160 as PoC and the only supported platform is an emulator, there's interest in
 161 enabling additional platforms. It would allow to access more than 4GiB of memory
 162 at runtime and possibly brings optimised code for faster execution times.
 163 It still needs changes in assembly, fixed integer to pointer conversions in C,
 164 wrappers for blobs, support for running Option ROMs, among other things.
 165
 166 ### Preparations to minimize enabling PCI bus mastering
 167
 168 For security reasons, bus mastering should be enabled as late as possible. In
 169 coreboot, it's usually not necessary and payloads should only enable it for
 170 devices they use. Since not all payloads enable bus mastering properly yet,
 171 some Kconfig options were added as an intermediate step to give some sort of
 172 "backwards compatibility", which allow enabling or disabling bus mastering by
 173 groups.
 174
 175 Currently available groups are:
 176
 177 * PCI bridges
 178 * Any devices
 179
 180 For now, "Any devices" is enabled by default to keep the traditional behaviour,
 181 which also includes all other options. This is currently necessary, for instance,
 182 for libpayload-based payloads as the drivers don't enable bus mastering for PCI
 183 bridges.
 184
 185 Exceptional cases, that may still need early bus master enabling in the future,
 186 should get their own per-reason Kconfig option. Ideally before the next release.
 187
 188 ### Early runtime configurability of the console log level
 189
 190 Traditionally, we didn't allow the log level of the `romstage` console
 191 to be changed at runtime (e.g. via `get_option()`). It turned out that
 192 the technical constraints for this (no global variables in `romstage`)
 193 vanished long ago, though. The new behaviour is to query `get_option()`
 194 now from the second stage that uses the console on. In other words, if
 195 the `bootblock` already enables the console, the `romstage` log level
 196 can be changed via `get_option()`. Keeping the log level of the first
 197 console static ensures that we can see console output even if there's
 198 a bug in the more involved code to query options.
 199
 200 ### Resource allocator v4
 201
 202 A new revision of resource allocator v4 is now added to coreboot that supports
 203 multiple ranges for allocating resources. Unlike the previous allocator (v3), it does
 204 not use the topmost available window for allocation. Instead, it uses the first
 205 window within the address space that is available and satisfies the resource request.
 206 This allows utilization of the entire available address space and also allows
 207 allocation above the 4G boundary. The old resource allocator v3 is still retained for
 208 some AMD platforms that do not conform to the requirements of the allocator.
 209
 210 Deprecations
 211 ------------
 212
 213 ### PCI bus master configuration options
 214
 215 In order to minimize the usage of PCI bus mastering, the options we introduced in
 216 this release will be dropped in a future release again. For more details, please
 217 see [Preparations to minimize enabling PCI bus mastering](#preparations-to-minimize-enabling-pci-bus-mastering).
 218
 219 ### Resource allocator v3
 220
 221 Resource allocator v3 is retained in coreboot tree because the following platforms
 222 do not conform to the requirements of the resource allocation i.e. not all the fixed
 223 resources of the platform are provided during the `read_resources()` operation:
 224
 225 * northbridge/amd/pi/00630F01
 226 * northbridge/amd/pi/00730F01
 227 * northbridge/amd/pi/00660F01
 228 * northbridge/amd/agesa/family14
 229 * northbridge/amd/agesa/family15tn
 230 * northbridge/amd/agesa/family16kb
 231
 232 In order to have a single unified allocator in coreboot, this notice is being added
 233 to ensure that the platforms listed above are fixed before the next release. If there
 234 is interest in maintaining support for these platforms beyond the next release,
 235 please ensure that the platforms are fixed to conform to the expectations of resource
 236 allocation.
 237
 238 Notes
 239 -----
 240
 241 ### Intel microcode updates
 242
 243 Intel microcode updates tagged *microcode-20200616* are still included in our
 244 builds. Note, [Intel released new microcode updates]
 245 (https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/blob/main/releasenote.md)
 246 tagged
 247
 248 1.  *microcode-20201110*
 249 2.  *microcode-20201112*
 250 3.  *microcode-20201118*
 251
 252 with security updates for [INTEL-SA-00381]
 253 (https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00381.html)
 254 and [INTEL-SA-00389]
 255 (https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00389.html).
 256
 257 Due to too short time for rigorous testing and bad experience with botched
 258 microcode updates in the past, these new updates are not included. Users wanting
 259 to use those, can apply them in the operating system, or update the submodule
 260 pointer themselves.