coherent hypertransport hardcodes.

[tomz]

Stefan Reinauer wrote:

> * YhLu <YhLu at tyan.com> [030719 02:59]:
>
> > I have tested Stefan's the code about coherent_ht.c, and add some hardcode
> > to it.
> > coherent_ht.o.c is the original one. Coherent_ht.1.c is total hardcode one.
> > coherent_ht.c and coherent_ht.2.c are modified with some hardcode ones.
>
> I am not happy with these hardcodes at all, they will make all
> motherboards fail that have a different link setup than the tyan S2880
> (It should be ok for hdama, but will definitely make the AMD quartet
> fail)
>
> Link speed and width setup should be done "dynamically" based on the link
> capabilities of the devices connected to each other.
>
> I wrote two functions to do this for every pair of hypertransport
> devices, they should probably be enhanced to take a configurable
> (per nvram or config option) maximum in addition to relying on what the
> devices say.
>
> This needs support from the motherboard specific Config.lb files,
> because we need to know for every cpu which bridge/cpu is connected to
> which link on the hypertransport bus.
>
> Tom from LNXI has also written some code that fills the speed registers
> it seems. But this is executed in C-Payload when doing PCI. As we need
> to assert LDTSTOP_L I am not sure whether it can be kept there. Tom?

Yes, I have code working that dynamically sets the link speeds and widths.
The only board I have tested it on is the hdama, and it seems to work.
The code now is messy, as we originally had it in the early setup, but needed
more registers in the rom c compiler than were available, so we moved
it to the PCI setup.  It presently works by calculating the values and
comparing them to the ones presently set.  If they are different, they are
set to the correct values, and a reset is done.  I am using a reset because
I have not yet been able to get the LDTSTOP_L to work.  The system
reboots and the next time the routine is run, the values in the registers
are correct, so the reset is not done, and the system continues to boot.

I am presently rewriting the routines without optimizing registers, so it is
more understandable.  I will make the code available when it is done.

I looked at the link_speed.c and link_width.c routines.  The reg_a and reg_b
settings will not work for the following reasons:  The upstream link may be
a host or a slave.  For example on the hdama the uplink is a host for the
8131,  and a slave for the 8111.  The speed registers are in a different
location for the slave and host.  The links are not in fixed locations, and are
not all 0x20 in length.  The only fixed location is the start of the link chain
at location 0x34.  For example on the  hdama 8131, 0x34 points to 0xa0,
which points to 0xb8, which points to 0xc0, which is identified by the
capability and flags registers as the needed link entry.

I will let you know of further development.  Tom Zimmerman

>
>
> I checked in cpu and southbridge dependent parts of LDTSTOP_L assertion,
> they should be operational as soon as we know the link configuration
> from the config file .
>
> The static tree generated at the moment seems not right to me:
> for the one cpu that is actually configured, several nodes are
> generated:
>
> struct chip static_dev9 = {
> /* cpu /home/stepan/LinuxBIOS/freebios2/src/cpu/k8 */
>   .next = &static_dev8,
> };
> struct chip static_dev8 = {
> /* cpu /home/stepan/LinuxBIOS/freebios2/src/cpu/k7 */
>   .next = &static_dev7,
> };
> struct chip static_dev7 = {
> /* cpu /home/stepan/LinuxBIOS/freebios2/src/cpu/p6 */
>   .next = &static_dev6,
> };
> struct chip static_dev6 = {
> /* cpu /home/stepan/LinuxBIOS/freebios2/src/cpu/p5 */
>   .next = &static_dev5,
> };
>
> I assume this is to allow callbacks for each cpu type the k8
> "implements" at the right place. but it looks really nasty. And
> it seems that there are no callbacks anyways here. Or am I wrong?
>
> Is this really needed? It looks like this should be one entry for every
> cpu that can be plugged into the system, plus for every bridge on the
> system.
>
> In the config file this shows up as:
>
>  option i686=1
>  option i586=1
>  option INTEL_PPRO_MTRR=1
>  option k7=1
>  option k8=1
>
> Ron, is it already possible to add information on links between the
> cht and ncht devices?
>
> The chain i want to describe looks pretty much like:
>
>        K8-CPU[2] ------- K8-CPU[3]
>           |                 |
>           |                 |
>        K8-CPU[0] ------- K8-CPU[1]
>           |                 |
>           |                 |
>        8111-SB[0]        8131-SB[0]
>
> with possibly multiple bridges of the same type.
>
> Stefan
>
>   ------------------------------------------------------------------------
>
>    link_speed.cName: link_speed.c
>                Type: Plain Text (text/plain)
>
>    link_width.cName: link_width.c
>                Type: Plain Text (text/plain)