Nico Huber:
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.
Thank you for the well written summary. Have been asking myself some of the same questions. Lack the experience to make a recommendation for or against any approach.
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.
Is this different than the status quo? I think the concern here is once platforms are dropped from master, people rarely take the time to consider or backport any improvements to the out of sight, out of mind old branches. On the other hand, concerns about trying to maintain code with mounds of technical debt are entirely valid.
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.
You mention the KGPE-D16 as an example. I hadn't followed at the time, but from what I can tell it was a well-written, coreboot native port. However, that didn't save it from getting dropped, presumably under a similar scenario. What would be different with today's scenario, for example?
Documenting Hardware
Can't speak to this.
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.
The code Kyösti referenced in soc/amd is definitely a lot easier to follow than vendorcode/amd.
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.
Your "[1]" footnote didn't seem to make it.
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.
Something hybrid like this is what I was considering to remove LEGACY_SMP_INIT. Could the first portions of fam14-16 bootstrap (i.e. up to and including AP early initialization) be done with a more common/cleaner coreboot approach, then chained over to AGESA vendorcode for the rest? I have been unable to figure out the answer or how much work would be involved. If it is a valid approach, might let other native pieces be added in the future to more easily address new requirements.