@Nico By removing open-source AGESA and all boards that use them, you would remove many boards that can boot blobless (like KGPE-D16 and KCMA-D8, there's also cheap low-end like E350M1, although I'm not sure this uses AGESA).
This would mean that if we want blobless, we can either use much less powerful than ASUS boards Intel-based boards from 10 years ago or use Chromebooks. This would severely lower the number of coreboot users.
You said we could maintain AGESA code on our own and even rewrite. I'm with Mike about this. I'm not a firmware engineer, I can understand so-so what the code is doing but writing it is completely beyond me. I'm also engaged in other open-source project (I contribute to FreeBSD ports) and this doesn't leave time to work on coreboot.
Also, running tokei in AGESA dir currently shows: pkubaj@KGPE-D16:$~/coreboot/src/vendorcode/amd/agesa/f15tn$ tokei ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Language Files Lines Code Comments Blanks ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Assembly 1 209 184 0 25 C 457 143870 77558 54737 11575 C Header 251 130554 91038 29652 9864 ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Total 709 274633 168780 84389 21464 -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
The size of AGESA is currently about 10% of coreboot. Nico, do you think a single person working in spare time can reimplement 10% of coreboot?
On 11/11/18 5:42 PM, Piotr Kubaj via coreboot wrote:
The size of AGESA is currently about 10% of coreboot. Nico, do you think a single person working in spare time can reimplement 10% of coreboot?
I don't care how much it looks like. It's likely bloated vendor code. For instance, look at the numbers for this:
$ tokei src/cpu/amd/family_10h-family_15h/ src/northbridge/amd/{amdfam10/,amdht/,amdmct/}
I wouldn't be surprised if this non-agesa code even covers more than a single AGESA platform (like agesa/f15tn). So that might also be 1% instead of 10%, it's hard to compare.
That's still a lot of code. I don't know how hard it is to configure AMD compared to Intel. But for Intel a lot platforms just showed up because somebody did it in his spare time (without documentation). So it seems doable.
Nico
Hi!
Seems that I forgot to send this e-mail, so here's a rather late response:
By removing open-source AGESA and all boards that use them, you would remove many boards that can boot blobless (like KGPE-D16 and KCMA-D8, there's also cheap low-end like E350M1, although I'm not sure this uses AGESA).
KGPE-D16 and KCMA-D8 don't use the AGESA code, but a more readable open source reimplementation of the platform initialization for fam15 described in the freely available BIOS writers guide for that generation. The fam15 (not to be confused with fam15tn or fam15rl) AGESA code already got removed from coreboot master. IIRC someone tried to port the F2A85-M over to the non-AGESA codebase, but I'm not sure how far that project got in the end.
To Nico's follow-up mail: Yes, there's a huge amount of duplicated, but sometimes still slightly changed code in the AGESA vendorcode; basically for each platform generation supported by the AGESA code, there is a full AGESA source tree in vendorcode. The initialization isn't substantially more difficult on the open source AGESA platforms than on the Intel platforms with native open source initialization, but since the native Intel code isn't jut copypasted vendorcode, but a reimplementation, it's much more readable for at least some hardware generations.
And yeah, the AGESA code is quite awful; I tried to clean up that mess a bit, but decided for me after spending maybe two days on that that I could do much more useful and satisfying things in my spare time. Sure, I (sadly) don't expect hardware vendor code to be very well engineered (sometimes a product just needs to be shipped, is based on some old codebase and when the product is released the team that worked on the firmware needs to work on some other project and doesn't get much time for cleaning up things), but for example relying on the compiler do the right thing in the case of undefined behavior is really bad practice. Sure, if you don't use another compiler or compiler version, it won't break, but this is no assumption I'd make when writing code.
Probably a rewrite (or in this case adding the support to the existing non-AGESA source) would also be faster than trying to properly clean up that AGESA mess.
I get the impressions that a few people are quite vocal on the mailing list about keeping stuff in the master branch that fell into disrepair and hinders the project in moving forward and improving things, but those few people seem to mostly complain, but don't either contribute patches to be merged in upstream master or hire people to fix things.
And that some code is no longer in the master branch doesn't mean that it's gone; that's one of the awesome features of using a version control system like git :) And if someone cares enough to fix that code, it can of course also be brought back into the master branch. Maybe a list of mainboards that aren't in the master branch any more and the last release before they got removed might be useful; I wouldn't assume that that version works though.
But yeah, for me and saving developer and maintainer time and keeping the project rolling is much much more important than dragging unmaintained and possibly broken code around in the master branch that makes it difficult to do tree-wide improvements.
Regards Felix
On 11/23/2018 10:28 AM, Felix Held wrote:
I get the impressions that a few people are quite vocal on the mailing list about keeping stuff in the master branch that fell into disrepair and hinders the project in moving forward and improving things.
I can agree yes some stuff that clearly no longer works should be removed from master but people were talking about for instance removing the native fam15h boards KGPE-D16 and KCMA-D8 (last and best owner controlled libre firmware x86 boards and arguably the best examples of coreboot ports and hw init code) because they thought they didn't have a working S3 mode without soliciting someone to test it until I reported back that it still works (I use it all the time and tested it in master).
I feel as though at the current rate of people being too eager to remove still functional boards for arbitrary reasons there won't be any easily obtainable non development boards on master - another side issue is that coreboot repos don't contain the libs required to compile the older versions which are becoming increasingly unavailable with some only downloadable from a single site hence I suggest the direct hosting of them rather than requiring people to download from third party websites that may or may not work in the future.
There needs to be some type of solution to this issue or in so many years coreboot master will no longer be an open source firmware project since it will only be able to initiate new x86 systems that happen to require binary blobs.
I have never met a comp-sci/comp-engineering graduate or anyone in a computer field who has heard of coreboot and that needs to change - there needs to be some type of advertising so that there can be more than a few wizards capable of the dark arts of firmware editing and who have the time and resources to deal with arbitrary continued maintenance.
but those few people seem to mostly complain, but don't either contribute patches to be merged in upstream master or hire people to fix things.
I have provided technical support to over 100 coreboot users and have enticed many more to procure a supported board and start using it, I also donate to projects and provide hardware to developers when I can...the ways you say are not the only ways to contribute :D
Am So., 25. Nov. 2018 um 17:14 Uhr schrieb Taiidan@gmx.com <Taiidan@gmx.com
:
I can agree yes some stuff that clearly no longer works should be removed from master but people were talking about for instance removing the native fam15h boards KGPE-D16 and KCMA-D8 (last and best owner controlled libre firmware x86 boards and arguably the best examples of coreboot ports and hw init code)
To be honest, in my opinion the Intel i945/gm45 hw init beats anything that's out there for AMD. I may be biased though :-)
I feel as though at the current rate of people being too eager to remove
still functional boards for arbitrary reasons there won't be any easily obtainable non development boards on master -
It's not so arbitrary: The problem is that every deviation we carry along in the tree means an explosion in the feature and test matrix: Every boolean option means that we have twice as many configurations that could go wrong.
There are two conflicting statements by non-developing users and we need some decision on how to deal with them:
1. Users want new features that land on master to work on their boards. 2. Users don't want to invest time in keeping their boards working on master.
2. is somewhat handled by telling users to go for the latest release and/or commit that is known to work, but that means that they won't benefit from newer features.
Even without the efforts to streamline coreboot development which mean that old APIs are shut down, there's no guarantee that boards will remain working on master without maintenance: This project deliberately does away with the traditional BIOS development model of "copy, paste, modify and forget", for greater cohesion and feature parity.
That approach comes at a cost, and one part of that is that without a maintainer for a board (since we also do away with the "forget" part of traditional BIOS development), the master branch is unreliable for that board by default. Once there is a maintainer, the changes advocated for the next release or the one after that aren't _that_ much effort. And it's not like with the romcc-romstage removal, where we removed classes of devices (those without CAR), the changes proposed now are all completely on the software design side.
It may even work to set aside some time dedicated to testing patches somebody does without hardware access to bring up chipsets up to newest standards. Naturally that has more friction than having developer and user reside in the same place or even be the same person. However for most boards we don't have any signal if anybody is still using them or has a desire to use a newer revision than whatever they already have on their boards.
Apparently this thread brought up some such interested parties, which I already see as a benefit, but I'd rather have a mechanism that doesn't require the threat of board removal. Suggestions welcome :-)
another side issue is that
coreboot repos don't contain the libs required to compile the older versions which are becoming increasingly unavailable with some only
You're referring to the dependencies for crossgcc? That's a good point, I'll see that I'll set up a mirror for those. Everything else comes from git repos we control, so that should be safe. If I'm missing anything else in this assessment, I'd like to learn about it so I can fix it.
since it will only be able to initiate new x86 systems that happen to require binary blobs.
Why no ARM or RISC-V? :-(
I have never met a comp-sci/comp-engineering graduate or anyone in a
computer field who has heard of coreboot and that needs to change
Uni Heidelberg used to use coreboot for FPGA work on AMD gear, they even contributed. There are a few master theses that were written around coreboot.
Also, everybody on this mailing list is arguably "in a computer field" and I'd suggest that they have heard of coreboot.
Patrick
-
Felix Held -
Nico Huber -
Patrick Georgi -
Piotr Kubaj -
Taiidan＠gmx.com