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

[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.

[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]

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]

Needing soldering/desoldering skills to recover from a bad flash is now largely a thing of the past provided you have a halfway decent motherboard. Just last week I recovered my board from a bad flash by using the onboard flash process that works even without a cpu/memory installed

partcyborg That technology right now is in most cases proprietary. Most likely controlled by MCU which use proprietary firmware. Unless someone will perform adversarial interoperability research on that technology we will not get support in open-source firmware for that. We also can count on some bigger OEM/ODM which will design thing in a open-source firmware friendly way.

[pietrushnic]

One to replace dozens? Hardly a replacement.

Developer12 for now we have to be happy with what we get. Without continues improvements we will not get much more in current circumstances.

[pietrushnic]

It's a sad situation all around to be sure.

A colossal loss of support for a project already pretty stagnant in terms of new hardware, but as I understand it the code that AMD dumped on them to support all those platforms is pretty gnarly and never got fixed/replaced. Most of it is either heavily scrubbed garbage that was tossed over the wall, or is binary-only init but unlike the FSP isn't fixed up and maintained by AMD to meet new needs.

Nobody wants to work on it, so these various platforms running still reasonably modern, featureful chips have finally gotten the boot.

Developer12 this is not whole story. 3mdeb was willing to fix stuff and we tried as much as we could. There is whole patch train here. In case of PC Engines apu2+ we succeeded for some time, but there are some further "improvements" and "stabilization" that will lead to removal of more platforms. Question remain which vendors and which platforms will benefit from those changes? At the end of 2021 we discussed the problem during leadership calls (please check 1st Dec and 19th May here). Since that time criteria for platform removal were not clarified. Also please note who is pro and who is against the changes.

Finally to understand removal of PC Engines apu1 one have to understand that pushback was related to what you described above, but please note someone merged that code in the past, then people building products based on that with the margins that cannot justify rewrite of code that should be silicon vendor responsibility in the first place. As you can see despite of policy that maintenance of apu1 didn't required change of AGESA code we get continues suggestion in patch reviews that fixing broken code as a compliance to new requirements will not work. Rewriting was unbearable in such situation. People estimated in various places 100-250k USD investment needed to clean silicon vendor code.

Question is what will happen with platforms from Intel that coming and promising 15 years availability.

[pietrushnic]

rmoog I have would like to join others who liked below post since it say a lot of true about open-source firmware.

I think Coreboot's situation could be improved dramatically if they did 2 things.

1. Demistify the process of compiling Coreboot for a sepcific target, flashing and recovering from a bad flash. Most people who wanted to consider Coreboot were just scared they'd brick their system because they compiled something wrong.

Please let me know if Dasharo documentation fits your needs. If not please let me know what can be improved.

2. Demistify getting into electronics. tl;dr electronics is a Nigerian scam and most people realize this after surviving 2-5 bulletpoints from the tldr, but, the few people who manage to submit to sunken cost phallacy do in fact obtain the necessary skills in the end. The parallels are clear, but if you don't see the writing on the wall, getting yourself involved in electronic development is a Nigerian scam because:
- people who are already in the know tell you to buy a soldering iron, but they never tell you what kind
- so you go to your normie mall because you want to get it now and not in a week by mail order, and get a soldering iron, but it's big and clunky and only good for welding railways or tractor parts
- when the capricious experts decide to tell you what kind of soldering iron you need, it turns out it's a long sold-out Kickstarter project like the pine64 soldering iron, so good luck overspending by prying the unobtainium soldering iron from someone else's hands
- next thing the self appointed chosenites and prodigies of electricity will tell you that altogether, what you needed to buy is not a soldering iron, but a desoldering station
- you buy the goddamn desoldering station and finally it's something that works
- turns out the desoldering station is not good enough for removing BIOS chips from a motherboard so the chosenites tell you that you need a hot air station, but never tell you which one
- after buying enough hot air stations and trying them out and knowing which ones are trash and waste of money and which ones aren't, you can try out different kinds of tin, flux and rosin
- after you have tested all the materials, you are now maybe ready to begin your adventure with soldering anything
- but wait! There's more! Now you need to learn how to use a BIOS chip programmer. Be sure it's the CH-231 and you have a relatively recent Debian lying around and your Google-fu skills are up to par, because nobody ever thought the CH-231 driver should be upstreamed into the Linux kernel
- by now you are 35 and you spent all your extra income up to this point that could have gone to buy you a house, but instead you have a bunch of rubbish nobody will take off your hands for free

Open-source firmware needs way better documentation and marketing, but who should do that? Major corporations are in general interested in leveraging open-source firmware. Their marketing teams are not paid to yell about open-source firmware and its usefulness. Maybe employee branding teams are interested in use of open-source and free software rhetoric to hire developers.

On the other side can you point to open-source project which is role model in documentation and marketing? It would be interesting to understand how they managed to do that in what structure.

[Developer12]

V1tol What about MSI Z690-A DDR4 and DDR5? Is that not modern enough?

One to replace dozens? Hardly a replacement.

[pietrushnic]

I don't think they have much choice if there is no one to maintain it.

Did anyone tried to check how much hardware is not maintained in Linux kernel? I can assure you there is plenty of dead code there that no one can run today. I didn't saw suggestions about removing that just based on the fact some people cannot use it. Of course even Linux kernel drop support for legacy stuff, but 386 was dropped after 27 years on market (21 years in kernel). There is plan to drop 486 after 23 years of market presence. coreboot "stabilize" platforms which are 7 years old. It is very important to ask question why. I tried to get answer, but didn't get any business reason. I will get to that when replying to other posts.

[pietrushnic]

A project that does not support modern hardware (chromebooks not counted) voluntarily shrinks its hardware list. That's an epic shot in the foot.

V1tol What about MSI Z690-A DDR4 and DDR5? Is that not modern enough?