1coreboot 4.15 2================================ 3 4coreboot 4.15 was released on November 5th, 2021. 5 6Since 4.14 there have been more than 2597 new commits by more than 219 developers. 7Of these, over 73 contributed to coreboot for the first time. 8 9Welcome to the project! 10 11Thank you to all the developers who continue to make coreboot the 12great open source firmware project that it is. 13 14Important Announcement 15---------------------- 16We are going to be changing the cadence from every 6 months, to every 3 months. 17That means the 4.16 release will be coming in February, 2022. 18 19 20New mainboards 21-------------- 22* Asus p8h61-m_pro_cm6630 23* Asus p8h77-v 24* Asus p8z77-v 25* Google nipperkin 26* Lenovo w541 27* Siemens mc_ehl 28* Supermicro x9sae 29* System76 addw1 30* System76 addw2 31* System76 bonw14 32* System76 darp6 33* System76 darp7 34* System76 galp2 35* System76 galp3 36* System76 galp3-b 37* System76 galp4 38* System76 galp5 39* System76 gaze14 40* System76 lemp10 41* System76 oryp7 42* System76 oryp8 43 44Removed mainboards 45------------------ 46* Google Mancomb 47 48Deprecations and incompatible changes 49------------------------------------- 50 51### COREBOOTPAYLOAD option 52 53Drop the deprecated COREBOOTPAYLOAD option, and replace it with MrChromebox's 54updated UefiPayloadPkg option. Simplify the Kconfig options to make it easier 55to build from upstream edk2 master. Drop the EDK2_USE_8254_TIMER Kconfig 56option since it applies only to CorebootPayloadPkg. Clean up the Makefile now 57that we're only building from a single edk2 package/target. 58 59### Remove old lp4x and ddr4 versions of spd_tools 60 61The migration to the new unified version of spd_tools is complete, so 62the old lp4x and ddr4 versions can be removed. 63 64### Remove AMD PI 00630F01 65 66No board currently uses AMD PI 00630F01 so remove it. 67 68Significant changes 69------------------- 70 71### Merged family of Asus mainboards using H61 chipset 72 73By using newer coreboot features like board variants and override devicetrees, 74lots of code can now be shared. This should ease maintenance and also make it 75easier for newcomers to add support for even more mainboards. 76 77### Changed default setting for Intel chipset lockdown 78 79Previously, the default behaviour for Intel chipset lockdown was to let the FSP 80do it. Since all related mainboards used the coreboot mechanisms for chipset 81lockdown, the default behaviour was changed to that. 82 83### Payloads unit testing 84 85Libpayload now supports the mock architecture, which can be used for unit testing 86payloads. (For examples see 87[depthcharge](https://chromium.googlesource.com/chromiumos/platform/depthcharge/) 88payload) 89 90### Unit testing infrastructure 91 92Unit testing of libpayload is now possible in the same fashion as in the main 93coreboot tree. 94 95### Introduce new method for accessing cpu_info 96 97There is currently a fundamental flaw in the current cpu_info() 98implementation. It assumes that current stack is CONFIG_STACK_SIZE 99aligned. This assumption breaks down when performing SMM relocation. 100 101The first step in performing SMM relocation is changing the SMBASE. This 102is accomplished by installing the smmstub at 0x00038000, which is the 103default SMM entry point. The stub is configured to set up a new stack 104with the size of 1 KiB (CONFIG_SMM_STUB_STACK_SIZE), and an entry point 105of smm_do_relocation located in RAMSTAGE RAM. 106 107This means that when smm_do_relocation is executed, it is running in SMM 108with a different sized stack. When cpu_info() gets called it will be 109using CONFIG_STACK_SIZE to calculate the location of the cpu_info 110struct. This results in reading random memory. Since cpu_info() has to 111run in multiple environments, we can't use a compile time constant to 112locate the cpu_info struct. 113 114This CL introduces a new way of locating cpu_info. It uses a per-cpu 115segment descriptor that points to a per-cpu segment that is allocated on 116the stack. By using a segment descriptor to point to the per-cpu data, 117we no longer need to calculate the location of the cpu_info struct. This 118has the following advantages: 119* Stacks no longer need to be CONFIG_STACK_SIZE aligned. 120* Accessing an unconfigured segment will result in an exception. This 121 ensures no one can call cpu_info() from an unsupported environment. 122* Segment selectors are cleared when entering SMM and restored when 123 leaving SMM. 124* There is a 1:1 mapping between cpu and cpu_info. When using 125 COOP_MULTITASKING, a new cpu_info is currently allocated at the top of 126 each thread's stack. This no longer needs to happen. 127