On 29.11.21 14:49, awokd wrote: >> >> 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?
Yes, these ports wouldn't hold the master branch back anymore. > 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. They are out of sight either way, IMHO. The original deprecation notice is over a year old, why would anyone still put any effort into it? I assume if there was a dedicated place for these ports, people might even be encouraged to work on it because they don't have to fear that the ports are completely abandoned soon. I guess it depends most on the maintainers of such a branch. If they'd let it rot, things won't get better of course. >> >> 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. AFAIR, it's the exact opposite. IIRC, Timothy asked for $200k to publish the code, clean it up, and for upstreaming. They only got $50k which was enough to publish the code, that IMHO, was in a PoC state (it worked somehow for their selection of CPUs and DRAM, but not generally). And review was mostly skipped. There was this argument all over the review: that the existing code (K8 etc. IIRC) was broken anyway. I can't say if this is true. But it felt a little that upstreaming the KGPE-D16 work, in the given state and with the given resources, led to abandoning the last native AMD ports. > However, that didn't save it from getting dropped, presumably under a > similar scenario. What would be different with today's scenario, for > example? Sincere, reasonable funding, clean code, decent review. Everything would (should?) be different. Before you consider paying somebody for the effort, you have to find somebody qualified and willing to do it anyway. I'd start with that. Then ask why they think they could succeed. >> 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. Sorry, sent it later: [1] https://en.wikipedia.org/wiki/Broken_windows_theory >> 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. It's just software, so it could certainly be done. How much work would be involved is the right question. Alas, I have no idea. One needs to study the AGESA sources to tell, I guess. However, LEGACY_SMP_INIT sounds like something that is usually done late in ramstage. I'm not sure this is anything to make an early cut. Nico _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
