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
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
|
coreboot 4.12
=============
coreboot 4.12 was released on May 12th, 2020.
Since 4.11 there were 2692 new commits by over 190 developers and of
these, 59 contributed for the first time, which is quite an amazing
increase.
Thank you to all developers who again helped made coreboot better
than ever, and a big welcome to our new contributors!
Maintainers
-----------
This release saw some activity on the MAINTAINERS file, showing more
persons, teams and companies declare publicly that they intend to
take care of mainboards and subsystems.
To all new maintainers, thanks a lot!
Documentation
-------------
Our documentation efforts in the code tree are picking up steam, with
some 70 commits in that general area. Everything from typo fixes to
documenting mainboard support or coreboot APIs.
There's still room to improve, but the contributions are getting more
and better.
Hardware support
----------------
The removals due to the announced deprecations as well as the
deduplication of boards into variants skew the stats a bit, so at
a top level view this is a rare coreboot release in that it removes
more boards (51) than it adds (49).
After accounting for the variant moves the numbers in favor of more
hardware supported than the previous version. Besides a whole lot
of Chrome OS devices (again), this release features a whole bunch
of retrofits for devices originally shipping with non-coreboot OEM
firmware, but also support for devices that come with coreboot right
out of the box.
For that, a shout out to System76, Protectli, Libretrend and the
Open Compute Project!
Cleanup
--------
We simplified the header that comes at the top of every file:
Instead of a lengthy reference to the license any given file
is under, or even the license text itself, we opted for simple
[SPDX](https://www.spdx.org) identifiers.
Since people also handled copyright lines differently, we now opt for
collecting authors in AUTHORS and let git history tell the whole story.
While at it, the content-free "This file is part of this-and-that
project" header was also dropped.
Besides that, there has also been more work to sort out the headers
we include across the tree to minimize the code impacting every
compilation unit.
Now that our board-variant mechanism matured, many boards that were
individual models so far were converted into variants, making it
easier to maintain families of devices.
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
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
-------------------
### SMMSTORE is now production ready
See [smmstore](../drivers/smmstore.md) for the documentation on
the API, but note that there will be an update to it featuring a
much-improved but incompatible API.
### Unit testing infrastructure
Unit testing of coreboot is now possible in a more structured way, with new
build subsystem and adoption of [Cmocka](https://cmocka.org/) framework. Tree
has new directory `tests/`, which comprises infrastructure and examples of unit
tests. See
[Unit testing coreboot](../technotes/2020-03-unit-testing-coreboot.md) for the
design document.
Final Notes
-----------
Your favorite new feature or supported board didn't make it to the
release notes? They're maintained collaboratively in the coreboot
tree, so when you land something noteworthy don't be shy, contribute
to the upcoming release's document in Documentation/releases!
|
