Re: coherent hypertransport hardcodes.
Jeff Pipkins [EMAIL PROTECTED] 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 ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: coherent hypertransport hardcodes.
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 ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
coherent hypertransport hardcodes.
* YhLu [EMAIL PROTECTED] [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
#define SPEED_100 15
#define SPEED_200 0
#define SPEED_400 2
#define SPEED_600 4
#define SPEED_800 5
#define SPEED_1000 6
#define SUPPORTS(x) (1x)
uint8_t get_maximum_cht_speed(uint16_t mask)
{
if(mask SUPPORTS(SPEED_1000))
return SPEED_1000;
if(mask SUPPORTS(SPEED_800))
return SPEED_800;
if(mask SUPPORTS(SPEED_600))
return SPEED_600;
if(mask SUPPORTS(SPEED_400))
return SPEED_400;
if(mask SUPPORTS(SPEED_200))
return SPEED_200;
if(mask SUPPORTS(SPEED_100))
return SPEED_100;
}
#if 1
void print_speed(uint8_t speed)
{
const static char *speeds[]={ 200, n/a, 400, n/a, 600, 800,
1000, n/a, n/a, n/a, n/a, n/a,
n/a, n/a, n/a, 100 };
print_debug(Link speed: );
print_debug(speeds[speed]);
print_debug(MHz\r\n);
}
#endif
/*
* dev_a, dev_b : device that share a link
* link_a, link_b : link output on device a/b (0,1,2)
*/
void setup_cht_linkspeed(device_t dev_a, device_t dev_b,
uint8_t link_a, uint8_t link_b)
{
uint8_t reg_a, reg_b, speed_max;
uint16_t speed_mask
uint32_t tmp;
reg_a = (0x20*link_a)+0x88;
reg_b = (0x20*link_b)+0x88;
/*
* get link speed mask of both devices and AND them
* to get the speeds supported by both devices.
*/
speed_mask = (pci_read_config32(dev_a, reg_a) 16) \
(pci_read_config32(dev_b, reg_b) 16);
speed_max=get_maximum_cht_speed(speed_mask);
#if 1
print_speed(speed_max);
#endif
/* write link width on device a */
tmp = pci_read_config32(dev_a, reg_a);
tmp = ~(158);
tmp |= (speed_max8);
pci_write_config32(dev_a, reg_a, tmp);
/* write link width on device b */
tmp = pci_read_config32(dev_b, reg_b);
tmp = ~(158);
tmp |= (speed_max8);
pci_write_config32(dev_b, reg_b,
Re: coherent hypertransport hardcodes.
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 ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: coherent hypertransport hardcodes.
* ron minnich [EMAIL PROTECTED] [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 -- Architecture Team SuSE Linux AG ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: coherent hypertransport hardcodes.
* ron minnich [EMAIL PROTECTED] [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 -- Architecture Team SuSE Linux AG ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: coherent hypertransport hardcodes.
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 ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: coherent hypertransport hardcodes.
Stefan Reinauer wrote:
* YhLu [EMAIL PROTECTED] [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)
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: coherent hypertransport hardcodes.
Stefan, I just fixed that 'False' bug. ron ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
