Re: K8 + 2.4.21 + Tyan S2880

[YhLu]

Eric,

My boss has said that I can release the source code to you.

Please find out the patch I made. Make the diff to today's tree.

I didn't test RON new script and still use the old scripts tools.

I strip out the LSI scsi support, because I don't know if there is any
license problem, and I have referred to their documents and may need put
their FW in the ROM.

It's greater you add ops->enable function that make it easy to handle
special device. To some device if it is not gotten magic code, it will not
get the resource allocate to it. Before that I have to do it in init
function and re-allocate the resource to it again. Please refer to my old
amd8131_ioapic.c in southbridge/amd8111. Also you init the io_base, upper16
reg, otherwise the device in PCIX will not got io port allocated to them,
and will not work.

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.

raminit.c and raminit.1.c are till the hardcode one, and I have tried to use
the configurable one, but auto.c can not be compiled, it is too big and used
up REG?
The old one has been renamed to raminit.o.c.

To start other cpus, in auto.c  We must enable apic and make sure all
apic_id is right. Please refer to mainboard/tyan/s2880/auto.c boot_cpu
function.

Again, thank you all to answer my questions to help Tyan s2880 work with
LinuxBIOS.

Regards

Yinghai Lu

K8 + 2.4.21 + Tyan S2880

YhLu  writes:
> Eric,
>
> My boss has said that I can release the source code to you.
>
> Please find out the patch I made. Make the diff to today's tree.
>
> I didn't test RON new script and still use the old scripts tools.
>
> I strip out the LSI scsi support, because I don't know if there is any
> license problem, and I have referred to their documents and may need put
> their FW in the ROM.
>
> It's greater you add ops->enable function that make it easy to handle
> special device. To some device if it is not gotten magic code, it will not
> get the resource allocate to it. Before that I have to do it in init
> function and re-allocate the resource to it again. Please refer to my old
> amd8131_ioapic.c in southbridge/amd8111. Also you init the io_base, upper16
> reg, otherwise the device in PCIX will not got io port allocated to them,
> and will not work.
>
> 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.
>
> raminit.c and raminit.1.c are till the hardcode one, and I have tried to use
> the configurable one, but auto.c can not be compiled, it is too big and used
> up REG?
> The old one has been renamed to raminit.o.c.
>
> To start other cpus, in auto.c  We must enable apic and make sure all
> apic_id is right. Please refer to mainboard/tyan/s2880/auto.c boot_cpu
> function.
>
> Again, thank you all to answer my questions to help Tyan s2880 work with
> LinuxBIOS.

Welcome.

You have the most interesting time.  Your stuff always seems to come in 
just as I am about to walk away for the day.

I have just gotten SMP working in my tree and that is checked in.

I did the fun thing and am using the apic timer as my timer.  It has
the nice property of working without calibration because it is based
on the FSB clock, which on the Opteron is fixed at 200Mhz.  And as a
very cool thing I have that code compiling both ways.

More later, Good Night.

Eric

K8 + 2.4.21 + Tyan S2880

YhLu  writes:
> Eric,
>
> My boss has said that I can release the source code to you.
>
> Please find out the patch I made. Make the diff to today's tree.
>
> I didn't test RON new script and still use the old scripts tools.
>
> I strip out the LSI scsi support, because I don't know if there is any
> license problem, and I have referred to their documents and may need put
> their FW in the ROM.

Ah, an interesting problem.
> It's greater you add ops->enable function that make it easy to handle
> special device. To some device if it is not gotten magic code, it will not
> get the resource allocate to it. Before that I have to do it in init
> function and re-allocate the resource to it again.

Welcome.
> Please refer to my old amd8131_ioapic.c in southbridge/amd8111.
> Also you init the io_base, upper16 reg, otherwise the device in PCIX
> will not got io port allocated to them,  and will not work.

Sorry I don't quite parse that sentence.
> 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.

Interesting looking at this code are you working with C0 stepping Opterons?
I have the stock B3 and am having fun getting the memory resets in all of the proper
places.
> raminit.c and raminit.1.c are till the hardcode one, and I have tried to use
> the configurable one, but auto.c can not be compiled, it is too big and used
> up REG?

Looking.  It is your romcc options.  By default romcc will not use mmx
or sse registers unless you tell it that you have them.  I have been
doing this with -mcpu=k8.  The register pressure is much less when you
have 24 registers to work with instead of just 8.
> The old one has been renamed to raminit.o.c.
>
> To start other cpus, in auto.c  We must enable apic and make sure all
> apic_id is right. Please refer to mainboard/tyan/s2880/auto.c boot_cpu
> function.

Yep, an interesting way of doing it.
> Again, thank you all to answer my questions to help Tyan s2880 work with
> LinuxBIOS.

Ron, Stefan.  Could one of you help with merging Yinghai's code?  I
might have time, but I don't think I will manage it before I leave
for OLS on Tuesday.

Eric

K8 + 2.4.21 + Tyan S2880

[ron minnich]

What I will do is first, get my tree in sync with Greg's new config tool 
code and Eric's new updates for SMP; Then look at YhLu's code and try to 
get it integrated.

Next week is K8 week for me. It is very exciting to see this coming up on 
my bench after reading about all the work you folks have been doing.

ron

coherent hypertransport hardcodes.

[Stefan Reinauer]

* YhLu  [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?

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

coherent hypertransport hardcodes.

[ron minnich]

On Fri, 25 Jul 2003, Stefan Reinauer wrote:
> 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 agree with you. This is arguably wrong, there should only be one cpu
entry in the tree; it's on the "to fix" list. The code is pretty dumb
right now, just emitting a tree for all devices. I'm just trying to figure
out how "to fix" it, but have an idea. Most preferable would be to say
just:

cpu k8 end

and have it automagically bring in whatever else is needed. I think that 
is the right thing.
> 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?

There will be no callbacks unless they are defined. None are defined.
> 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.

yes, this is what should be there.
> 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.

something like:

cpu k8 
    register "cpuid" = "1"
    regiser  "southlink" = "amd8111-1"
    register "rightlink" = "k8-cpu3"
end

or some such? Would something like this do it?

this is something we need to finish up. But yes, it's in the plan. We're 
still trying to figure out what people most want.

I hope it can last until week after next, I am gone most of next week, but 
maybe we can convince Greg to put it in.

I think there is work left to be done in this part of configuration.

ron

coherent hypertransport hardcodes.

[Stefan Reinauer]

* ron minnich  [030725 17:38]:
> I agree with you. This is arguably wrong, there should only be one cpu
> entry in the tree; it's on the "to fix" list. The code is pretty dumb
> right now, just emitting a tree for all devices. I'm just trying to figure
> out how "to fix" it, but have an idea. Most preferable would be to say
> just:
>
> cpu k8 end
> and have it automagically bring in whatever else is needed. I think that 
> is the right thing.

Ack.
> > 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]
>
> cpu k8 
>    register "cpuid" = "1"
>    regiser  "southlink" = "amd8111-1"
>    register "rightlink" = "k8-cpu3"
> end
> or some such? Would something like this do it?

Yes, then cpu and bridge configuration could be done really readable
like in this example of above scenario:

cpu cpu-k8-0
        register "cpuid"      = "0"
        register "arch"       = "k8" # if a special cpu type needs 
                                     # to add callbacks.

register "acrosslink" = "cpu-k8-1"
        register "uplink"     = "cpu-k8-2"
        register "downlink"   = "bridge-8111-0"
end

cpu cpu-k8-1
        register "cpuid"      = "1"
        register "arch"       = "k8"

register "acrosslink" = "cpu-k8-0"
        register "uplink"     = "cpu-k8-3"
        register "downlink"   = "bridge-8131-0"
end

cpu cpu-k8-2
        register "cpuid"      = "2"
        register "arch"       = "k8"

register "acrosslink" = "cpu-k8-3"
        register "downlink"   = "cpu-k8-0"
end

cpu cpu-k8-3
        register "cpuid"      = "3"
        register "arch"       = "k8"

register "acrosslink" = "cpu-k8-2"
        register "downlink"   = "cpu-k8-1"
end

bridge bridge-8111-0
        register "class"      = "southbridge"
        register "bridgeid"   = "0" # first 8111 sb on the bus

register "vendor"     = "amd"
        register "deviceid"   = "amd8111"

register "uplink"     = "cpu-k8-0"

# special configuration like switching off
        # builtin nics could happen here.

end

bridge bridge-8131-0 #
        register "class"      = "pcibridge" # currently 8131 code sits
                                            # in src/southbridge. It
                                            # could be either moved or
                                            # mapped.
        register "bridgeid"   = "0"         # first 8131 pci-x bridge
                                            # on the bus

register "vendor"     = "amd"
        register "deviceid"   = "amd8131"

register "uplink"     = "cpu-k8-1"
end
> this is something we need to finish up. But yes, it's in the plan. We're 
> still trying to figure out what people most want.
> I hope it can last until week after next, I am gone most of next week, but 
> maybe we can convince Greg to put it in.

this would make the configuration scenario of AMD64 systems a lot more
flexible. Most of the hardcodes like link speed selection for the tyan
board could be made configurable in the motherboard configuration file
without really knowing anything but the board specification.

Stefan

coherent hypertransport hardcodes.

[Jeff Pipkins]

Just a reminder (in case this isn't complicated enough yet), on 
configurations with nc chains like k8=>8131->8111 or k8=>8131->8131, the 
link downstream from the 8131 has to be 8 bits wide, even if it has 16 
bits coming into it.

--Jeff

coherent hypertransport hardcodes.

Jeff Pipkins  writes:
> Just a reminder (in case this isn't complicated enough yet), on configurations
> with nc chains like k8=>8131->8111 or k8=>8131->8131, the link downstream from
> the 8131 has to be 8 bits wide, even if it has 16 bits coming into it.

If you aren't hard coding that one is trivial to get right because the 8131
reports the downstream link is only 8 bits.

Although that is a pretty good case for not chaining two 8131s...

Eric

coherent hypertransport hardcodes.

[ron minnich]

On Fri, 25 Jul 2003, Stefan Reinauer wrote:
> 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)

just checking, did this cause trouble for you Stefan? If so, we may want 
to back these out.

ron

coherent hypertransport hardcodes.

[Stefan Reinauer]

* ron minnich  [030725 17:38]:
> On Fri, 25 Jul 2003, Stefan Reinauer wrote:
> > 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)
>
> just checking, did this cause trouble for you Stefan? If so, we may want 
> to back these out.

I have not enabled LDTSTOP_L assertion in the tree yet, thus the writes
to the link speed registers are done but wait to become current. I'm
thinking about moving the code to tyans mb specific code and have the
same thing for the other mainboards until it can be done dynamically.

Stefan

coherent hypertransport hardcodes.

[ron minnich]

On Fri, 25 Jul 2003, Stefan Reinauer wrote:
> I have not enabled LDTSTOP_L assertion in the tree yet, thus the writes
> to the link speed registers are done but wait to become current. I'm
> thinking about moving the code to tyans mb specific code and have the
> same thing for the other mainboards until it can be done dynamically.

OK. we're looking at your ideas on the config tool and will try to have 
something for you next week.

ron

coherent hypertransport hardcodes.

[tomz]

Stefan Reinauer wrote:
> YhLu  [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)

coherent hypertransport hardcodes.

[ron minnich]

Stefan, I just fixed that 'False' bug.

ron