summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorJason Glenesk <jason.glenesk@amd.corp-partner.google.com>2021-10-18 07:04:09 -0700
committerPatrick Georgi <pgeorgi@google.com>2021-10-28 09:35:58 +0000
commit2c78ee29972af524d39ef393666d63bc01db98c9 (patch)
treeaf8a6c1ec3e7bff16ef4a074d8b371be3bfc25b7
parent9a56ff9c2d2657f1cf5c9c18e96caaddd7897f68 (diff)
downloadcoreboot-2c78ee29972af524d39ef393666d63bc01db98c9.tar.gz
coreboot-2c78ee29972af524d39ef393666d63bc01db98c9.tar.bz2
coreboot-2c78ee29972af524d39ef393666d63bc01db98c9.zip
Documentation/releases: Update 4.15 release notes
Update details for upcoming 4.15 release Signed-off-by: Jason Glenesk <jason.glenesk@amd.corp-partner.google.com> Change-Id: I4517f7c17ce5788c82a1eafb1589e39b1ce403ff Reviewed-on: https://review.coreboot.org/c/coreboot/+/58422 Reviewed-by: Martin Roth <martinroth@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
-rw-r--r--Documentation/releases/coreboot-4.15-relnotes.md88
1 files changed, 81 insertions, 7 deletions
diff --git a/Documentation/releases/coreboot-4.15-relnotes.md b/Documentation/releases/coreboot-4.15-relnotes.md
index 334d4cae06f7..1f5947fbc3d6 100644
--- a/Documentation/releases/coreboot-4.15-relnotes.md
+++ b/Documentation/releases/coreboot-4.15-relnotes.md
@@ -1,14 +1,57 @@
Upcoming release - coreboot 4.15
================================
-The 4.15 release is planned for October 2021.
+The 4.15 release is planned for November 1st, 2021.
-Update this document with changes that should be in the release notes.
+Since 4.14 there have been more than 2448 new commits by more than 219 developers.
+Of these, over 73 contributed to coreboot for the first time.
-* Please use Markdown.
-* See the past few release notes for the general format.
-* The chip and board additions and removals will be updated right
- before the release, so those do not need to be added.
+Welcome to the project!
+
+
+
+Thank you to all the developers who continue to make coreboot the
+great open source firmware project that it is.
+
+New mainboards
+--------------
+* Asus p8h61-m_pro_cm6630
+* Asus p8h77-v
+* Asus p8z77-v
+* Google nipperkin
+* Lenovo w541
+* Siemens mc_ehl
+* SuperMicro x9sae
+* System76 addw1
+* System76 darp6
+* System76 darp7
+* System76 galp4
+* System76 galp5
+* System76 lemp10
+
+Removed mainboards
+------------------
+* Google Mancomb
+
+Deprecations and incompatible changes
+-------------------------------------
+
+### COREBOOTPAYLOAD option
+
+Drop the deprecated COREBOOTPAYLOAD option, and replace it with MrChromebox's
+updated UefiPayloadPkg option. Simplify the Kconfig options to make it easier
+to build from upstream edk2 master. Drop the TIANOCORE_USE_8254_TIMER Kconfig
+option since it applied only to CorebootPayloadPkg. Clean up the Makefile now
+that we're only building from a single Tianocore package/target.
+
+### Remove old lp4x and ddr4 versions of spd_tools
+
+The migration to the new unified version of spd_tools is complete, so
+the old lp4x and ddr4 versions can be removed.
+
+### Remove AMD PI 00630F01
+
+No board currently uses AMD PI 00630F01 so remove it.
Significant changes
-------------------
@@ -37,4 +80,35 @@ payload)
Unit testing of libpayload is now possible in the same fashion as in the main
coreboot tree.
-### Add significant changes here
+### Introduce new method for accessing cpu_info
+
+There is currently a fundamental flaw in the current cpu_info()
+implementation. It assumes that current stack is CONFIG_STACK_SIZE
+aligned. This assumption breaks down when performing SMM relocation.
+
+The first step in performing SMM relocation is changing the SMBASE. This
+is accomplished by installing the smmstub at 0x00038000, which is the
+default SMM entry point. The stub is configured to set up a new stack
+with the size of 1 KiB (CONFIG_SMM_STUB_STACK_SIZE), and an entry point
+of smm_do_relocation located in RAMSTAGE RAM.
+
+This means that when smm_do_relocation is executed, it is running in SMM
+with a different sized stack. When cpu_info() gets called it will be
+using CONFIG_STACK_SIZE to calculate the location of the cpu_info
+struct. This results in reading random memory. Since cpu_info() has to
+run in multiple environments, we can't use a compile time constant to
+locate the cpu_info struct.
+
+This CL introduces a new way of locating cpu_info. It uses a per-cpu
+segment descriptor that points to a per-cpu segment that is allocated on
+the stack. By using a segment descriptor to point to the per-cpu data,
+we no longer need to calculate the location of the cpu_info struct. This
+has the following advantages:
+* Stacks no longer need to be CONFIG_STACK_SIZE aligned.
+* Accessing an unconfigured segment will result in an exception. This
+ ensures no one can call cpu_info() from an unsupported environment.
+* Segment selectors are cleared when entering SMM and restored when
+ leaving SMM.
+* There is a 1:1 mapping between cpu and cpu_info. When using
+ COOP_MULTITASKING, a new cpu_info is currently allocated at the top of
+ each thread's stack. This no longer needs to happen.