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.
Branching --------- 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.
Porting ------- 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.
Documenting Hardware -------------------- 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 could help.
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 [1] 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 do so.
Nico