Marc Jones marcj303@gmail.com writes:
Yes, This stuff is a mess.
Thank you, then I'm not mad. :)
I don't completly understand it and couldn't document it. The swaplist is really a place holder. I am not sure how the fields really work. Part of the problem is the use of the same early ht init for sb decode etc from K8, and then the later real ht init based on the AMD code. The requirement of the CONFIG_HT_CHAIN_UNITID_BASE setting for the BUIDSwaplist may be wrong.
The SB_ setting refers to the the last device in the chain, like the sb600 or sb700.
Hm, ok. That helps a bit.
Can you point what you are looking at in 780.c that is hard-coding the HT address?
In rs780.c
277 nb_dev = dev_find_slot(0, PCI_DEVFN(0, 0)); 278 if (!nb_dev) { 279 die("rs780_enable: CAN NOT FIND RS780 DEVICE, HALT!\n");
appears to assume that the rs780 exists as device 0.
There is a non-patch that may address this, check this email thread: http://patchwork.coreboot.org/patch/1053/
Right, I remember seeing that go by... Reading the patch, it would appear to be addressing the same issue. After digging a bit into this today, I now believe I can make things behave relatively sane by simply passing something like
static BOOL ht_swaplist(u8 node, u8 link, u8 **List) { static u8 swaplist[] = { 0x0, 0xff, 0xff }; if ((node == 0) && (link == 2)) { *List = swaplist; return 1; } return 0; }
as the swaplist callback for this particular mainboard. If we can come up with a way of doing that in a reasonably clean manner, I think I prefer that to more magic based on the HT_CHAIN-variables.
Hm. However, I also notice that of the boards calling the amd_ht_init-wrapper, the only other ones with HT_CHAIN_UNITID_BASE == 0x0 are tilapia and mahogany, both rs780-based. And mahogany apparently needs patches to h3finit.c to work. Does tilapia_fam10 work as-is?
Perhaps I should just work the above into the general swaplist callback for these cases?