[coreboot] G505s status (and test report)
felix-coreboot at felixheld.de
Tue Nov 17 21:04:51 CET 2015
> As for adding support for Bolton and refactoring and unifying the FCH code, I would like to pick up the task, because I want to invest myself in coreboot dev again and I hope that I will have some time to spend in the near future...
IIRC someone in the IRC channel was also interested in the Bolton FCH;
maybe you could work on that together. I don't remember the nickname though.
> But I need to understand a little bit more the current architecture of coreboot and also the impact of recent developpements like the (proposed) switch from AGESA to native init..
> But just to have an idea of the complexity of this task (refactoring amd fch code) can you give me some details of what needs to be done?
The FCH code of AGESA fam12, fam15tn and fam16kb isn't in a separate
directory, but inside AGESA vendorcode. Which FCH code gets build,
doesn't depend not on the southbridge Kconfig setting. Both fam12 and
fam15tn trees include support for Hudson; the version in fam15tn is
newer and likely has some bugfixes. The FCH code in fam16kb is different
(Yangtze), but not too different.
I'd try to move the FCH support out of the different vendorcode/agesa
subtrees into one tree structure in vendorcode/ages. Maybe see
http://review.coreboot.org/#/c/7782/ for something to begin your work.
When moving the code out of the AGESA subtrees you should adapt the
Kconfig stuff, so that the selection of the FCH code depends on the
selected southbridge. That might involve some patching to the subtrees
where you factor out the FCH support.
When you have factored out the FCH vendorcode and somehow merged it into
one directory structure where only the stuff relevant for one platform
gets built, it should be relatively easy to extend the support for
On the AGESA stuff: It seems that the internal tree has support for all
different families in one tree and only the source code which is
relevant for one family gets built for that family. Before the code drop
for each family everything unneeded for that family was removed and the
remaining stuff of that tree was released for that family.
I can really recommend the 3 way folder compare mode of meld for the
task of merging the 3 different FCH support code subtrees. fam12 and
fam15tn have code for the same chips, but slightly different code; i'd
use the newer version (fam15tn), since it likely contains some bugfixes.
To get the XHCI support on Bolton working, you'd at least have to patch
Hudson2XhciResetService.c; in that file the code matches onto the PCI ID
of the XHCI controller, which changed between Hudson and Bolton. You
likely need to patch some other stuff as well to get the XHCI controller
When you have moved the FCH code out of the AGESA subtrees, it would be
really great if you'd write native initialization for the FCH, which can
be uses from both AGESA-based (maybe some glue code to AGESA is still
needed for that) and native init based boards, but thats likely a
I hope that this helps you a bit; that was more or less everything i
remember from working on that. The current state of the code isn't
pretty, but you'll see that quite quickly...
Also have a look at my (unfinished) Bolton support without working XHCI.
Maybe it just needs the small patch that it also matches on the PCI ID
of the XHCI controller in Bolton, but well, that would just be a hack.
More information about the coreboot