1coreboot 4.13 2================================ 3 4coreboot 4.13 was released on November 20th, 2020. 5 6Since 4.12 there were 4200 new commits by over 234 developers. 7Of these, about 72 contributed to coreboot for the first time. 8 9Thank you to all developers who again helped made coreboot better 10than ever, and a big welcome to our new contributors! 11 12New 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 79Removed mainboards 80------------------ 81 82- Google Cheza 83- Google DragonEgg 84- Google Ripto 85- Google Sushi 86- Open Compute Project SonoraPass 87 88Significant changes 89------------------- 90 91### Native refcode implementation for Bay Trail 92 93Bay Trail no longer needs a refcode binary to function properly. The refcode 94was reimplemented as coreboot code, which should be functionally equivalent. 95Thus, coreboot only needs to run the MRC.bin to successfully boot Bay Trail. 96 97### Unusual config files to build test more code 98 99There's some new highly-unusual config files, whose only purpose is to coerce 100Jenkins into build-testing several disabled-by-default coreboot config options. 101This prevents them from silently decaying over time because of build failures. 102 103### Initial support for Intel Trusted eXecution Technology 104 105coreboot now supports enabling Intel TXT. Though it's not feature-complete yet, 106the code allows successfully launching tboot, a Measured Launch Environment. It 107was tested on Haswell using an Asrock B85M Pro4 mainboard with TPM 2.0 on LPC. 108Though support for other platforms is still not ready, it is being worked on. 109The Haswell MRC.bin needs to be patched so as to enable DPR. Given that the MRC 110binary cannot be redistributed, the best long-term solution is to replace it. 111 112### Hidden PCI devices 113 114This new functionality takes advantage of the existing 'hidden' keyword in the 115devicetree. Since no existing boards were using the keyword, its usage was 116repurposed to make dealing with some unique PCI devices easier. The particular 117case here is Intel's PMC (Power Management Controller). During the FSP-S run, 118the PMC device is made hidden, meaning that its config space looks as if there 119is no device there (Vendor ID reads as 0xFFFF_FFFF). However, the device does 120have fixed resources, both MMIO and I/O. These were previously recorded in 121different places (MMIO was typically an SA fixed resource, and I/O was treated 122as 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 124that its resources can be placed in a more natural location. This also adds the 125ability for the device to participate in SSDT generation. 126 127### Tools for generating SPDs for LP4x memory on TGL and JSL 128 129A set of new tools `gen_spd.go` and `gen_part_id.go` are added to automate the 130process of generating SPDs for LP4x memory and assigning hardware strap IDs for 131memory parts used on TGL and JSL based boards. The SPD data obtained from memory 132part vendors has to be massaged to format it correctly as per JEDEC and Intel MRC 133expectations. These tools take a list of memory parts describing their physical 134attributes as per their datasheet and convert those attributes into SPD files for 135the 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 140A new version of the SMM loader which accommodates platforms with over 32 141CPU threads. The existing version of SMM loader uses a 64K code/data 142segment 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 144the 64K segment to accommodate additional CPUs and in theory allows as many 145CPU threads as possible limited only by SMRAM space and not by 64K. By default 146this loader version is disabled. Please see cpu/x86/Kconfig for more info. 147 148### Address Sanitizer 149 150coreboot now has an in-built Address Sanitizer, a runtime memory debugger 151designed to find out-of-bounds access and use-after-scope bugs. It is made 152available on all x86 platforms in ramstage and on QEMU i440fx, Intel Apollo 153Lake, and Haswell in romstage. Further, it can be enabled in romstage on other 154x86 platforms as well. Refer [ASan documentation](../technotes/asan.md) for 155more info. 156 157### Initial support for x86_64 158 159The x86_64 code support has been revived and enabled for QEMU. While it started 160as PoC and the only supported platform is an emulator, there's interest in 161enabling additional platforms. It would allow to access more than 4GiB of memory 162at runtime and possibly brings optimised code for faster execution times. 163It still needs changes in assembly, fixed integer to pointer conversions in C, 164wrappers for blobs, support for running Option ROMs, among other things. 165 166### Preparations to minimize enabling PCI bus mastering 167 168For security reasons, bus mastering should be enabled as late as possible. In 169coreboot, it's usually not necessary and payloads should only enable it for 170devices they use. Since not all payloads enable bus mastering properly yet, 171some Kconfig options were added as an intermediate step to give some sort of 172"backwards compatibility", which allow enabling or disabling bus mastering by 173groups. 174 175Currently available groups are: 176 177* PCI bridges 178* Any devices 179 180For now, "Any devices" is enabled by default to keep the traditional behaviour, 181which also includes all other options. This is currently necessary, for instance, 182for libpayload-based payloads as the drivers don't enable bus mastering for PCI 183bridges. 184 185Exceptional cases, that may still need early bus master enabling in the future, 186should get their own per-reason Kconfig option. Ideally before the next release. 187 188### Early runtime configurability of the console log level 189 190Traditionally, we didn't allow the log level of the `romstage` console 191to be changed at runtime (e.g. via `get_option()`). It turned out that 192the technical constraints for this (no global variables in `romstage`) 193vanished long ago, though. The new behaviour is to query `get_option()` 194now from the second stage that uses the console on. In other words, if 195the `bootblock` already enables the console, the `romstage` log level 196can be changed via `get_option()`. Keeping the log level of the first 197console static ensures that we can see console output even if there's 198a bug in the more involved code to query options. 199 200### Resource allocator v4 201 202A new revision of resource allocator v4 is now added to coreboot that supports 203multiple ranges for allocating resources. Unlike the previous allocator (v3), it does 204not use the topmost available window for allocation. Instead, it uses the first 205window within the address space that is available and satisfies the resource request. 206This allows utilization of the entire available address space and also allows 207allocation above the 4G boundary. The old resource allocator v3 is still retained for 208some AMD platforms that do not conform to the requirements of the allocator. 209 210Deprecations 211------------ 212 213### PCI bus master configuration options 214 215In order to minimize the usage of PCI bus mastering, the options we introduced in 216this release will be dropped in a future release again. For more details, please 217see [Preparations to minimize enabling PCI bus mastering](#preparations-to-minimize-enabling-pci-bus-mastering-in-coreboot). 218 219### Resource allocator v3 220 221Resource allocator v3 is retained in coreboot tree because the following platforms 222do not conform to the requirements of the resource allocation i.e. not all the fixed 223resources 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 232In order to have a single unified allocator in coreboot, this notice is being added 233to ensure that the platforms listed above are fixed before the next release. If there 234is interest in maintaining support for these platforms beyond the next release, 235please ensure that the platforms are fixed to conform to the expectations of resource 236allocation. 237 238Notes 239----- 240 241### Intel microcode updates 242 243Intel microcode updates tagged *microcode-20200616* are still included in our 244builds. Note, [Intel released new microcode updates] 245(https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/blob/main/releasenote.md) 246tagged 247 2481. *microcode-20201110* 2492. *microcode-20201112* 2503. *microcode-20201118* 251 252with security updates for [INTEL-SA-00381] 253(https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00381.html) 254and [INTEL-SA-00389] 255(https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00389.html). 256 257Due to too short time for rigorous testing and bad experience with botched 258microcode updates in the past, these new updates are not included. Users wanting 259to use those, can apply them in the operating system, or update the submodule 260pointer themselves. 261