Hi coreboot folks,
there have always been platforms in the coreboot tree that are easy to
maintain and others, alas, that seem to be the complete opposite. When
new features or new iterations of existing code are pushed, we'd love
to keep everything up-to-date. But this is infeasible. Given the vast
amount of platforms in-tree, including poorly written ones with inex-
plicable code, it's simply not possible to demand this from any single
developer or entity. Hence, what usually happens is that at first only
the easy-to-maintain platforms are updated. This pattern usually works
for some time, but at some point it looks like coreboot has been forked
within its own tree, making further maintenance too hard. So we drop
old code paths and the platforms relying on them from time to time.
It seems to me that AGESA-based ports are always on the brink of being
dropped. I can't say for sure why that is, neither do I want to pretend
to know how to avoid it. However, I'm convinced that they are among the
hard to maintain ports that drag the project down. And I have no doubt
that we'd have to squabble less about them if somebody would actively
take care of the code. I can't say that I'd be of much help and I don't
really care about the code. But it seemed to me that other people do
care and need a little nudge to get a discussion going.
I'll list some thoughts what could be done. Feel free to agree to or
dismiss any of it. Some things are mutually exclusive, others are not.
I know some people are easily offended by the thought, but I want to
mention it anyway as it seems to me like a cheap solution for the com-
munity as a whole. We could maintain platforms on separate branches.
Keeping things working shouldn't be much effort. At least, I guess the
following would be necessary:
* Keep the toolchain up-to-date and the code compatible.
* Keep the payload hook-ups up-to-date and test them from time to time.
Naturally, this is less effort on a branch that is dedicated to specific
platforms, i.e. does not keep all the other things in the tree like we
have on release branches. I would drop anything not related to the plat-
forms in question right after the branch point.
This would move most of the effort to the folks who actually benefit
from the maintenance. However, given my experience in this community,
I would expect people who usually only work on the master branch to
still be responsive and helpful.
Given that we are talking about platforms that are not based on native
coreboot code but unmaintained vendor code instead, it might help to
port these platforms to coreboot proper.
I don't think that the integration of vendor core is a root-cause of
the trouble. FWIW, other vendor code (well, usually in the form of
blobs) has been integrated into coreboot with more success. However,
a fresh port with decent review could definitely lose a lot of the
burden of the old one.
It's a huge effort of course, I don't want to hide that. Just like for
the famous KGPE-D16 and surrounding platform code, I'd estimate roughly
$200k for such an endeavor (maybe half of it for the initial implemen-
tation and the rest for both sides during a few months of review).
IMHO, this is an investment that was missed initially when these plat-
forms were added to coreboot. Generally, getting something to boot with
coreboot is rather easy. I guess you can get things running with maybe
20% of the effort necessary for a port of reasonable code quality. How-
ever, if things are left in such a state, somebody has to pay 10% on
top during every year of maintenance (which is currently left to the
active coreboot developers). IOW, the current state is also very expen-
sive whilst not getting anywhere, and paid by the wrong people.
The existing documentation, at least AFAICS, is rather thin. Every time
some developer wants to advance coreboot and has to touch the respective
code, they could use some good documentation.
I can't exactly say what is missing. It's like whenever I have to look
into a BKDG, I don't find what I'm looking for. Also, it's very hard
to tell which AMD document applies to what hardware. Register descrip-
tions are usually there, maybe what I'm missing is some in-depth docu-
mentation of the concepts. Or maybe it would already help to extend
the register descriptions. Also, organizing the available information
Comparing BKDGs to Intel's public, scrubbed datasheets, it seems the
latter already have more in-depth textual descriptions.
Cleaning up the existing ports
Of course, one can also try to continue as usual and bring things for-
ward iteratively. This might be the most expensive way, though, so I
put it last. Kyösti has already mentioned some things that could be
done beyond what is immediately necessary to avoid the current depre-
cation plans. He's definitely the guy to talk to about AGESA topics.
Generally, just reading the code and bringing it into a readable state
would help. There is a whole lot of inexplicable code, sometimes it
just can't be explained because it's simply wrong. Sometimes it's just
copy-pasta that was written for a different hardware generation.
Maybe this could help: Try to figure out for every line of code what
assumptions it makes. Try to very such assumptions with the common
coreboot code and available documentation. And if it can't be found,
and the assumption is about software, time to fix the code probably.
If the assumption is about hardware, well, test the hardware (don't
trust the code!). If any assumption is a hardware quirk that is not
easy to find in the documentation, add a code comment about it.
Oh, and I almost forgot, the board ports don't look like coreboot code.
There's CamelCase, odd tables in C code (as if there was no devicetree),
AGESA configuration done in the code of each and every mainboard that
should be done only once in the chipset code... IMHO it looks like a
mess. When one is used to coreboot and then sees this, there should
be no doubt why we have deprecation squabbles ;) This  might be
related. Board ports of other platforms have seen a lot of updates
over the last ten years, that's not easy for ports where one doesn't
know what to begin with.
A last thought about board ports, wrt. to blobbed vendor code I stated
it like this lately: The board port should be written such that in case
one would replace the blob (vendor code) with a native coreboot port,
that should be possible without touching the board code. IMO, there
shouldn't be a trace of AGESA in the mainboard dirs. The mainboard code
should configure the chipset drivers/code and the chipset code can use
AGESA to achieve its goal, but shouldn't be force by mainboard code to