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