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
-
Felix Held