Documentation/releases/coreboot-4.15-relnotes.md

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