On Wed, Sep 29, 2010 at 2:54 AM, Arne Georg Gleditsch firstname.lastname@example.org wrote:
I'm trying (again) to get my head around how the different pieces of HT-enumeration interacts... Do we have any documentation on the variables
HT_CHAIN_UNITID_BASE HT_CHAIN_END_UNITID_BASE SB_HT_CHAIN_ON_BUS0 SB_HT_CHAIN_UNITID_OFFSET_ONLY
and their intended/actual semantics? The H8QIi I'm working on has a RS780 (or 890, but I'm working from the 780 code base) SB which expects to find itself on unit 0. Both the existing code and the hardware seems determined about this; rs780.c has this hard coded, and changing the base unitid in the HT cap block appears to have no effect.
So, I'm trying to keep it there. However, processLink in h3finit wants to shift the devies upwards in order to discover the ncht chain -- unless the AMD_CB_ManualBUIDSwapList callback is invoked. The AMD_CB_ManualBUIDSwapList in ht_wrapper is only effective if CONFIG_HT_CHAIN_UNITID_BASE is non-zero, though, which kindof makes it a non-starter for me. (The callback also makes some assumptions about which HT link the SB is on that seem unwarranted.)
I think perhaps the best solution is to override the BUIDSwapList callback in ht_wrapper, but I'm not sure what the easiest way to do that is. Should I just call amdHtInitialize without going through amd_ht_init at all? Or should we make amd_ht_init merge mainboard specific callbacks in some way? Thoughts welcome.
Yes, This stuff is a mess. 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.
Can you point what you are looking at in 780.c that is hard-coding the HT address?
There is a non-patch that may address this, check this email thread: http://patchwork.coreboot.org/patch/1053/