HT_CHAIN_* woes

[Arne Georg Gleditsch]

Hi,

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.

[Myles Watson]

On Wed, Sep 29, 2010 at 2:54 AM, Arne Georg Gleditsch
 wrote:
> Hi,
>
> 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

These were all originally for K8.  K8 code is much simpler, so you
could start there.

Thanks,
Myles

[Marc Jones]

On Wed, Sep 29, 2010 at 2:54 AM, Arne Georg Gleditsch
 wrote:
> Hi,
>
> 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/

Marc

[Arne Georg Gleditsch]

Marc Jones  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?

[Marc Jones]

On Wed, Sep 29, 2010 at 2:12 PM, Arne Georg Gleditsch
 wrote:
> Marc Jones  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.

Sorry. I mis-spoke. The 780 is the last HT device, sb700 is a Alink
(PCI like) device.
> > 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.

Ah, ok. I see.

http://www.hypertransport.org/docs/tech/HTC20051222-0046-0008-Final-4-21-06....
See section 7.2.2 to start.
> > 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?

I don't think it does, I think that we need the patch, which is why I
acked it. We haven't received any more clarification from Zheng.
> Perhaps I should just work the above into the general swaplist callback
> for these cases?

If you can figure it out, please do. I didn't really look at the
swaplist contents and how it works.

Marc