diff options
Diffstat (limited to 'Documentation')
| -rw-r--r-- | Documentation/releases/coreboot-4.12-relnotes.md | 63 |
1 files changed, 63 insertions, 0 deletions
diff --git a/Documentation/releases/coreboot-4.12-relnotes.md b/Documentation/releases/coreboot-4.12-relnotes.md index 7943aa7161..b172c4a92e 100644 --- a/Documentation/releases/coreboot-4.12-relnotes.md +++ b/Documentation/releases/coreboot-4.12-relnotes.md @@ -10,6 +10,69 @@ notes. * 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 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 or the payload 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 linked +addresses without runtime resolution. 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 and so is the code that one has to write in that +environment. 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 and consistency with other architectures as +well as other stages: 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 ------------------- |