nested description of chains
Stefan Reinauer
stepan at suse.de
Fri Sep 12 06:37:00 CEST 2003
Hi,
looking at the big picture again and again, I don't think that
nesting hypertransport devices when doing the chain description is a
very good idea as it gives us some limitations.
* CPUs (North bridges) don't fit in the scenario, since they
might be arranged in a circular chain:
CPU-3 --- CPU-2
| |
| |
CPU-0 --- CPU-1
If trying to pack this into the nested description manner as it
is now, we can't describe the fact that it's a circular organization:
northbridge amd/amdk8 "mc0"
pci 0:18.0
[..]
northbridge amd/amdk8 "mc1"
pci 0:19.0
northbridge amd/amdk8 "mc2"
pci 0:1a.0
northbridge amd/amdk8 "mc3"
[..] (nesting ad nauseum)
end
end
end
northbridge amd/amdk8 "mc3"
[..] (nesting ad nauseum)
end
end
* Non-CPU components can be described as long as they are not ring
organized, but for Hypertransport devices the description tries
to hide the fact that the organization form is a chain.
Adding a nested description for components like a superio chip makes
perfect sense, since it's unlikely that superio chips are ever
cascaded or put into a circular chain. Also, the connection between
the I/O hub (southbridge) and the superio can be seen as a
peer-to-peer connection rather than a bus that allows arbitrary links
between all components.
The reason why I am writing this is that currently we have a hardcoded
assumption in in LinuxBIOS' coherent hypertransport setup that looks
like this:
| |
[2] [2]
CPU-3 [1] --- [1] CPU-2
[0] [0]
| |
[2] [2]
CPU-0 [1] --- [1] CPU-1
[0] [0]
| |
[x] means that HT link no x is used for a certain link.
But this is not the only available organization method for a
hypertransport setup. Assumed a CPU HT device looks like this:
| [LDT2]
___|__
| |
| CPU0 |-- [LDT1]
|______|
|
| [LDT0]
A hypertransport setup like this is a little more complex, but
still perfectly valid:
_______________
| ______ |
| | 8111 | |
| |______| |
| ___|__ |
| | | |
| | CPU0 |__|
| |______|
| ______|
| | ________________
| | ___|__ ______ |
| | | | | 8131 | |
| | | CPU1 |--|______| |
| | |______| |
| |_____| |
|_______ |
___|__ |
| | |
| CPU2 |--[term] |
|______| |
________| |
| |
| [term] |
| ___|__ |
| | | |
| | CPU3 |-------------
| |______|
|______|
I'll look at getting this scenario supported in the coherent_ht setup.
But it would be nice to see configurations like this happen without
actually touching the code when working a new opteron based port
somewhen in future.
Comments? Flames?
Stefan
--
Architecture Team
SuSE Linux AG
More information about the coreboot
mailing list