[coreboot] Supported Motherboards

Felix Held felix-coreboot at felixheld.de
Fri Nov 23 16:28:06 CET 2018


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



More information about the coreboot mailing list