blob: 8b9a099c1257bbc4d6d620fb50245568d934cc43 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
|
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
|
