129 lines
4.9 KiB
Markdown
129 lines
4.9 KiB
Markdown
Upcoming release - coreboot 4.22
|
|
========================================================================
|
|
|
|
The 4.22 release is planned for mid-November, 2023
|
|
|
|
Update this document with changes that should be in the release notes.
|
|
|
|
* 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.
|
|
* Note that all changes before the release are done are marked upcoming.
|
|
A final version of the notes are done after the release.
|
|
|
|
### Significant or interesting changes
|
|
|
|
* Add changes that need a full description here
|
|
|
|
* This section should have full descriptions and can or should have
|
|
a link to the referenced commits.
|
|
|
|
### x86: support .data section for pre-memory stages
|
|
|
|
x86 pre-memory stages did not support the `.data` section and as a
|
|
result developers were required to include runtime initialization code
|
|
instead of relying on C global variable definition.
|
|
|
|
Other platforms do not have that limitation. Hence, resolving it helps
|
|
to align code and reduce compilation based restriction (cf. the use of
|
|
`ENV_HAS_DATA_SECTION` compilation flag in various places of coreboot
|
|
code).
|
|
|
|
There were three types of binary to consider:
|
|
1. eXecute-In-Place pre-memory stages
|
|
2. `bootblock` stage is a bit different as it uses Cache-As-Ram but
|
|
the memory mapping and its entry code different
|
|
3. pre-memory stages loaded in and executed from Cache-As-RAM
|
|
(cf. `CONFIG_NO_XIP_EARLY_STAGES`).
|
|
|
|
eXecute-In-Place pre-memory stages (#1) relies on a new ELF segment as
|
|
the code segment Virtual Memory Address and Load Memory Address are
|
|
identical but the data needs to be linked in cache-As-RAM (VMA) but to
|
|
be stored right after the code (LMA).
|
|
|
|
`bootblock` (#2) also uses this new segment to store the data right
|
|
after the code and it loads it to Cache-As-RAM at runtime. However,
|
|
the code involved is different.
|
|
|
|
Not eXecute-In-Place pre-memory stages (#3) did not really need any
|
|
special work other than enabling a .data section as the code and data
|
|
VMA / LMA translation vector is the same.
|
|
|
|
Related important commits:
|
|
|
|
- c9cae530e5ac54c5b3639d0d555966ca5cad65ff ("cbfstool: Make add-stage
|
|
support multiple ignore sections")
|
|
- 79f2e1fc8b6192e96f99c05f71baeb77d4633d40 ("cbfstool: Make add-stage
|
|
support multiple loadable segments")
|
|
- b7832de0260b042c25bf8f53abcb32e20a29ae9c ("x86: Add .data section
|
|
support for pre-memory stages")
|
|
|
|
### x86: Support CBFS cache for pre-memory stages and ramstage
|
|
|
|
The CBFS cache scratchpad offers a generic way to decompress CBFS
|
|
files through the cbfs_map() function without having to reserve a
|
|
per-file specific memory region.
|
|
|
|
CBFS cache x86 support has been added to pre-memory stages and
|
|
ramstage.
|
|
|
|
1. **pre-memory stages**: The new `PRERAM_CBFS_CACHE_SIZE` Kconfig can
|
|
be used to set the pre-memory stages CBFS cache size. A cache size
|
|
of zero disables the CBFS cache feature for all pre-memory
|
|
stages. The default value is 16 KiB which seems a reasonable
|
|
minimal value enough to satisfy basic needs such as the
|
|
decompression of a small configuration file. This setting can be
|
|
adjusted depending on the platform needs and capabilities.
|
|
|
|
Note that we have set this size to zero for all the platforms
|
|
without enough space in Cache-As-RAM to accommodate the default
|
|
size.
|
|
|
|
2. **ramstage**: The new `RAMSTAGE_CBFS_CACHE_SIZE` Kconfig can be
|
|
used to set the ramstage CBFS cache size. A cache size of zero
|
|
disables the CBFS cache feature for ramstage. Similarly to
|
|
pre-memory stages support, the default size is 16 KiB.
|
|
|
|
As we want to support S3 suspend/resume use-case, the CBFS cache
|
|
memory cannot be released to the operating system and therefore
|
|
cannot be an unreserved memory region. The ramstage CBFS cache
|
|
scratchpad is defined as a simple C static buffer as it allows us
|
|
to keep the simple and robust design of the static initialization
|
|
of the `cbfs_cache` global variable (cf. src/lib/cbfs.c).
|
|
|
|
However, since some AMD SoCs (cf. `SOC_AMD_COMMON_BLOCK_NONCAR`
|
|
Kconfig) already define a `_cbfs_cache` region we also introduced a
|
|
`POSTRAM_CBFS_CACHE_IN_BSS` Kconfig to gate the use of a static
|
|
buffer as the CBFS cache scratchpad.
|
|
|
|
### Toolchain updates
|
|
|
|
* Upgrade GMP from 6.2.1 to 6.3.0
|
|
* Upgrade binutils from 2.40 to 2.41
|
|
* Upgrade MPFR from 4.2.0 to 4.2.1
|
|
|
|
### Additional coreboot changes
|
|
|
|
The following are changes across a number of patches, or changes worth
|
|
noting, but not needing a full description.
|
|
|
|
* Changes that only need a line or two of description go here.
|
|
|
|
### Platform Updates
|
|
|
|
* To be filled in immediately before the release by the release team
|
|
|
|
### Plans to move platform support to a branch
|
|
|
|
* Section to be filled in or removed after discussion
|
|
|
|
### Statistics from the 4.21 to the 4.22 release
|
|
|
|
* To be filled in immediately before the release by the release team
|
|
|
|
|
|
### Significant Known and Open Issues
|
|
|
|
* To be filled in immediately before the release by the release team
|