Arthur Heymans has uploaded this change for review.
4.12 release notes: Add some explanation behind depreciations
Some features are made mandatory, meaning that some platforms have
been dropped from master. This also explains that further development
on these popular platforms can happen on the 4.11 branch.
TODO is this really the right place or is it too technical for release
notes?
Change-Id: I95e01c301e7db6f81ef88a89d709ebab35c9ccfb
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
---
M Documentation/releases/coreboot-4.12-relnotes.md
1 file changed, 61 insertions(+), 0 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/64/37064/1
diff --git a/Documentation/releases/coreboot-4.12-relnotes.md b/Documentation/releases/coreboot-4.12-relnotes.md
index f9c5f7e..67bef34 100644
--- a/Documentation/releases/coreboot-4.12-relnotes.md
+++ b/Documentation/releases/coreboot-4.12-relnotes.md
@@ -10,6 +10,67 @@
* The chip and board additions and removals will be updated right
before the release, so those do not need to be added.
+Deprecations
+------------
+
+For the 4.12 release a few features on x86 became mandatory. These are
+relocatable ramstage, postcar stage and C_ENVIRONMENT_BOOTBLOCK.
+
+### Relocatable ramstage
+
+Relocatable stages are a feature only implemented only on x86, where
+stages can be relocated at runtime. This is used to place ramstage in
+a better location that does not collide with memory the OS tends to
+use. The rationale behind making this mandatory is that you always
+want cbmem to be cached so it's a good location to run ramstage from.
+It avoids using lower memory altogether so the OS can make use
+of it and no backing up needs to happen on S3 resume.
+
+### Postcar stage
+
+With Postcar stage tearing down Cache-as-Ram is done in a separate
+stage. This means that romstage has a clean program boundary and
+that all variables in romstage can be accessed via their initial
+reference at all times. There is no need to link global and static
+variables via the CAR\_GLOBAL macro and no need to access them with
+car\_set/get\_var/ptr functions.
+
+### C\_ENVIRONMENT\_BOOTBLOCK
+
+Historically the bootblock on x86 platforms has been compiled with
+romcc. This means that the generated code only uses CPU registers
+and therefore no stack. This 20K+ LOC compiler is limited and hard
+to maintain. A different solution is to set up Cache-as-Ram in the
+bootblock and run GCC compiled code in the bootblock. The advantages
+are increased flexibility: e.g. printing to console is possible and
+VBOOT can run before romstage, making romstage updatable via RW FMAP
+regions.
+
+### Platforms dropped from master
+
+The following platforms did not implement those feature are dropped
+from master to allow the master branch to move on:
+- AMDFAM10
+- all FSP1.0 platforms: BROADWELL_DE, FSP_BAYTRAIL, RANGELEY
+- VIA VX900
+- TODO (AMD?)
+
+In particular on FSP1.0 it is impossible to implement POSTCAR stage.
+The reason is that FSP1.0 relocates the CAR region to the HOB before
+returning to coreboot. This means that after FSP returns to coreboot
+accessing variables via their original address is not possible. One
+way of obtaining that behavior would be to set up Cache-as-Ram again
+(but with open source code) and copy the relocated data from the HOB
+there. This solution is deemed too hacky. Maybe a lesson can be
+learned from this: blobs should not interfere with the execution
+environment, as this makes proper integration much harder.
+
+### 4.11_branch
+
+Given that some platforms supported by FSP1.0 are being produced and
+popular, the 4.11 release was made into a branch in which further
+development can happen.
+
Significant changes
-------------------
To view, visit change 37064. To unsubscribe, or for help writing mail filters, visit settings.