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