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.
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
