Old AMD CPU & Motherboard Support Removed From Open-Source Coreboot

[pietrushnic]

But people have discovered they can also flash GPUs in the meantime

bug77 new golden age of computing coming. Already most of the devices contain one or more micro-controllers or full-blown processing unit (CPU, GPU, DPU, VPU, IPU etc.) and we will have more of those devices with end of Moor's Law as we enter domain specific computing. More to that we will start attest all firmware since offshore unapproved code will have to be eliminated as potentially harmful.

[pietrushnic]

there IS coreboot documentation - just not on the coreboot website : because it has been made artificially difficult to contribute anything there, the people wrote their guides elsewhere! And they are scattered all over the Internet... Myself, I wrote a lot of manuals on DangerousPrototypes who was friendly enough to host them, and these manuals may be useful especially for coreboot-supported AMD boards like yours - see http://dangerousprototypes.com/docs/..._G505S_hacking (compatible not just with G505S !) if you are interested.

Speaking of coreboot website - lack of documentation has been (and is being) artificially caused by gatekeeping of their website's documentation section:

1) When it was "wiki-style" - it was impossible to just register an account like on the normal websites: you had to beg the admins for an account, and even after multiple times of begging (myself I am a coreboot dev with dozens of successful commits) I was unable to get one. They have introduced these restrictions to "combat spam bots" - but should have just done some good captcha! (maybe an in-house coreboot-themed one, if don't want to depend on the external services). So, it seems that the only people who had an access to this wiki, were mostly those who got lucky to register in the early days of this wiki (when there weren't any restrictions) or personally knew the admins - but I guess these people, as the seasoned devs, were busy writing code and never had enough time for the docs.

Then, many people have been complaining about the lack of documentation - which was a direct consequence of gatekeeping IMHO. However, instead of understanding the true cause, they though there is something wrong with the "wiki-style" online docs and replaced them with "markdown-style" as "more user-friendly for the devs".

2) When it became the "markdown-style": although now anyone could contribute the docs (finally!) , you just can't come and quickly edit it in the instant WYSIWYG mode - instead, you are doing it locally and then git commit your documentation which gets merged only after the senior devs approval, which slows down the process and is discouraging to be honest. They tell the extra approval is needed to gatekeep the harmful changes, but the likehood of anyone committing something harmful is too small, compared to the more significant harm caused by the lack of documentation.

So, currently the people are writing their coreboot documentation on the alternative websites. And personally I don't see much problem with it ( " Let a hundred flowers bloom; let a hundred schools of thought contend. " ), other than that these alternative websites are often less "eternal" than the coreboot's official place for docs

michaelb1 I completely agree with need for better documentation, but there have to be someone who will write and review it. coreboot ecosystem is simply too small to handle that tasks correctly. To grow coreboot ecosystem there is need for more than just motivated community and behemoths with 10k+ employees. There is need for SME being present and welcome in the ecosystem. Let's see how Linux Foundation membership looks like I think they achieved huge success and diversity. We will see if Open Source Firmware Foundation can repeat that success. I guess OSFF should be key organization present when conflicting interests and problems like described above appear.

OTOH I would like to ask you if you think that Dasharo documentation does the job better in your opinion? If there are any areas for improvement feel free to let me know.

[pietrushnic]

Resource allocator and CPU init codepaths are not written by Intel devs, nor are those even tailored to Intel hardware. The old codepaths mostly worked by accident with the problematic code supporting those old AMD platforms. Maintaining 2 codepaths for essentially doing the same thing is a mess to maintain. No it's not just a few ifdefs... It's thinking about how each change might impact 2 different codepaths instead of one, which involves knowing the details of both. In the Linux kernel that's not allowed for instance.

avph do I understand correctly that beneficiaries are not-old AMD platforms? Can you be more specific which one? I asked many times during coreboot leadership calls and at some point there were even suggestion that when you do mass "stabilization" or tree-wide changes correct justification should be provided. What we have here is speculative beneficiary which seem to be more important than known existing targets respected by community (based on reaction here and during previous "stabilization"). Are we talking about modern Google Chromebooks? StarLabs?

Sidenote: no one stepped up to even test code that would have brought those platforms up to date!

avph can you be more precise what code you have in mind? Why you didn't continue code review proposed much earlier on topic amd_resource_allocator_v4 ? There was a way to keep some platforms on master branch for more time and 3mdeb invested resource to make that happen what can be proven by provided code on linked topic. From gerrit I still don't have good enough explanation why it was not possible.