[coreboot] G505s status (and test report)

[Felix Held]

Hi Florentin!

> 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...
Great!

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 
Bolton FCH.

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

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 
non-trivial task.

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.

Regards
Felix