Hi, Myles, About the HT code, I have a question.
I am debugging my board, which is Fam10+RS780+SB700. The CPU and RS780 are the two HT node. It seems like the RS690/SB600 board. In early_ht.c, the comment in enumertate_ht_chain() says,
#if CONFIG_HT_CHAIN_UNITID_BASE != 0 /* CONFIG_HT_CHAIN_UNITID_BASE could be 0 (only one ht device in the ht chain), if so, don't need to go through the chain */
I am wondering if the CONFIG_HT_CHAIN_UNITID_BASE is 0 in my case. If not, why in the supported RS690/SB600 board, the CONFIG_HT_CHAIN_UNITID_BASE is 0.
Thanks.
Zheng
________________________________________ From: Marc Jones [mailto:Marc.Jones@applieddesigncorp.com] Sent: Wednesday, November 04, 2009 7:31 AM To: Bao, Zheng Cc: Writer, Tim; Xie, Michael; Ni, John; Wang, Qingpei Subject: RE: coreboot 780/710 review
Joe, I am not sure that you made a good change. I don't completely understand the defines either. These settings are for the pre-HT init and I don't know how much should be setup. Some of the problems come in when the pre-HT init and the fam10 init don't agree on the UNITID setting. Do you know what the UNITIDs end up as with the legacy bios? I was not clear how this was breaking for you and what your change did. I think that setting CHAIN_UNITID_BASE=0 is wrong since you have two HT devices, CPU, 780/710? 780 is considered the SB since it is Alink to the 710 right? SB_HT_CHAIN_ON_BUS0=1 should put the SB on bus 0. I am not sure about UNITID_OFFSET being set or not. I think that some early HT SB (CHAIN_END_UNITID) had to be hardcoded to 0x6, but ATI doesn't have that problem and you can leave the default setting of 0x20. You can try asking on the coreboot list as well. Myles has been working on the HT code a lot. I think that these settings should work: #HT Unit ID offset, default is 1, the typical one, 0 mean only one HT device default CONFIG_HT_CHAIN_UNITID_BASE=1
#real SB Unit ID, default is 0x20, mean dont touch it at last #default CONFIG_HT_CHAIN_END_UNITID_BASE=0x6
#make the SB HT chain on bus 0, default is not (0) default CONFIG_SB_HT_CHAIN_ON_BUS0=1
#only offset for SB chain?, default is yes(1) default CONFIG_SB_HT_CHAIN_UNITID_OFFSET_ONLY=0 Also, Note that the coreboot svn was reorganized yesterday. Try to make a patch based on the new tree. Marc
Hi, Myles, About the HT code, I have a question.
I am debugging my board, which is Fam10+RS780+SB700. The CPU and RS780 are the two HT node.
Aren't there three? How is the SB700 connected to the RS780?
It seems like the RS690/SB600 board.
The RS690/SB600 board has three.
In early_ht.c, the comment in enumertate_ht_chain() says, #if CONFIG_HT_CHAIN_UNITID_BASE != 0 /* CONFIG_HT_CHAIN_UNITID_BASE could be 0 (only one ht device in the ht chain), if so, don't need to go through the chain */
I am wondering if the CONFIG_HT_CHAIN_UNITID_BASE is 0 in my case. If not, why in the supported RS690/SB600 board, the CONFIG_HT_CHAIN_UNITID_BASE is 0.
Good question. How does it end up being enumerated?
Does the lspci end up how you would expect/like on your board?
Part of the confusing part to me is that there are three enumerations that can happen:
early_ht.c: Just enumerate the southbridge chain in case that's needed for serial initialization or ROM access.
incoherent_ht.c: Enumerate all chains so that they can be optimized before the first reset.
hypertransport.c: Enumerate the chains according to the device tree.
Thanks, Myles
On Wed, Nov 4, 2009 at 11:02 AM, Myles Watson mylesgw@gmail.com wrote:
Hi, Myles, About the HT code, I have a question.
I am debugging my board, which is Fam10+RS780+SB700. The CPU and RS780
are
the two HT node.
Is there a SimNOW config that is close? Could you make one? That would make it easier to help.
The latest public SimNOW has the RS780 and SB700.
Thanks, Myles
On Wed, Nov 4, 2009 at 10:02 AM, Myles Watson mylesgw@gmail.com wrote:
Hi, Myles, About the HT code, I have a question.
I am debugging my board, which is Fam10+RS780+SB700. The CPU and RS780
are
the two HT node.
Aren't there three? How is the SB700 connected to the RS780?
It seems like the RS690/SB600 board.
The RS690/SB600 board has three.
I looked again, and it doesn't. Sorry about that. It looked like three at first because there are two 'chip' declarations on that HT link, but since the second one doesn't start at 0.0, it doesn't get separated as a link in the chain.
In early_ht.c, the comment in enumertate_ht_chain() says, #if CONFIG_HT_CHAIN_UNITID_BASE != 0 /* CONFIG_HT_CHAIN_UNITID_BASE could be 0 (only one ht device in the ht chain), if so, don't need to go through the chain */
I am wondering if the CONFIG_HT_CHAIN_UNITID_BASE is 0 in my case. If
not,
why in the supported RS690/SB600 board, the CONFIG_HT_CHAIN_UNITID_BASE
is
I think it should be. As long as it is the only member of the chain is should work fine to just leave it at 0.
Thanks, Myles
On Wed, Nov 4, 2009 at 10:02 AM, Myles Watson mylesgw@gmail.com wrote:
Hi, Myles, About the HT code, I have a question.
I am debugging my board, which is Fam10+RS780+SB700. The CPU and RS780 are the two HT node.
Aren't there three? How is the SB700 connected to the RS780?
It seems like the RS690/SB600 board.
The RS690/SB600 board has three.
There is just the CPU and 690 or 780. The AMD 600 or 700 is connect with Alink, not HT.
early_ht.c: Just enumerate the southbridge chain in case that's needed for serial initialization or ROM access.
incoherent_ht.c: Enumerate all chains so that they can be optimized before the first reset.
hypertransport.c: Enumerate the chains according to the device tree.
Is early_ht.c, enumerate_ht_chain(), even needed. The subtractive path should work. Maybe depends on the southbridge/configuration.
For Fam10, I think that where problems happen is the early_ht.c sets values that are found and used by the AGESA based code that has a slightly different search algorithm. This happens in ht3init.c, process_link(). Failures in process_link() cause the system to halt even if it could continue based on the early setup.
Marc
There is just the CPU and 690 or 780. The AMD 600 or 700 is connect with Alink, not HT.
You're right. I didn't look closely enough.
early_ht.c: Just enumerate the southbridge chain in case that's needed
for
serial initialization or ROM access.
incoherent_ht.c: Enumerate all chains so that they can be optimized
before
the first reset.
hypertransport.c: Enumerate the chains according to the device tree.
Is early_ht.c, enumerate_ht_chain(), even needed. The subtractive path should work. Maybe depends on the southbridge/configuration.
For K8, early_ht.c doesn't even get compiled in if you set CONFIG_HT_CHAIN_UNITID_BASE to 0.
It's needed for the case where there is a tunnel, then the southbridge. Serengeti Cheetah is a good example. You can't get to the southbridge until you've moved the 8131 or 8132 out of the way.
For Fam10, I think that where problems happen is the early_ht.c sets values that are found and used by the AGESA based code that has a slightly different search algorithm. This happens in ht3init.c, process_link(). Failures in process_link() cause the system to halt even if it could continue based on the early setup.
I wish I knew more about Fam10, but I don't have a board, so I haven't been that motivated to look into it further.
Thanks, Myles
The Agesa code goes the branch of Manual BUID assignment. The swap list is, {0x0, 0x0, 0xFF, 0x0, 0xFF}. I made a swaplist manually and the ht link was set up correctly. Now the problem is, 1. If I let AMD_CB_ManualBUIDSwapList give the swap list, it will provide {0xFF, CONFIG_HT_CHAIN_UNITID_BASE, CONFIG_HT_CHAIN_END_UNITID_BASE, 0xFF} It seems that the list is far from we expect. 2. What is the meaning of each entry in the swaplist?
Zheng
-----Original Message----- From: Myles Watson [mailto:mylesgw@gmail.com] Sent: Thursday, November 05, 2009 6:46 AM To: 'Marc Jones' Cc: Bao, Zheng; coreboot@coreboot.org Subject: RE: [coreboot] what should CONFIG_HT_CHAIN_UNITID_BASE be in "CPU/1HT device" mode?
There is just the CPU and 690 or 780. The AMD 600 or 700 is connect with Alink, not HT.
You're right. I didn't look closely enough.
early_ht.c: Just enumerate the southbridge chain in case that's
needed
for
serial initialization or ROM access.
incoherent_ht.c: Enumerate all chains so that they can be optimized
before
the first reset.
hypertransport.c: Enumerate the chains according to the device tree.
Is early_ht.c, enumerate_ht_chain(), even needed. The subtractive path should work. Maybe depends on the southbridge/configuration.
For K8, early_ht.c doesn't even get compiled in if you set CONFIG_HT_CHAIN_UNITID_BASE to 0.
It's needed for the case where there is a tunnel, then the southbridge. Serengeti Cheetah is a good example. You can't get to the southbridge until you've moved the 8131 or 8132 out of the way.
For Fam10, I think that where problems happen is the early_ht.c sets values that are found and used by the AGESA based code that has a slightly different search algorithm. This happens in ht3init.c, process_link(). Failures in process_link() cause the system to halt even if it could continue based on the early setup.
I wish I knew more about Fam10, but I don't have a board, so I haven't been that motivated to look into it further.
Thanks, Myles
-
Bao, Zheng -
Marc Jones -
Myles Watson