R: [COMMIT] freebios2 How much have I broken?

Eric W. Biederman ebiederman at lnxi.com
Mon Oct 13 20:51:00 CEST 2003


Ok. I see what the symptoms are and I think I have a clue about
what is going on.  It is going to take me a little bit to see what I can
to fix the problem well enough so it will not recur.

	/* Config Base and Limit i Registers
	 * F1:0xE0 i = 0
	 * F1:0xE4 i = 1
	 * F1:0xE8 i = 2
	 * F1:0xEC i = 3
	 * [ 0: 0] Read Enable
	 *         0 = Reads Disabled
	 *         1 = Reads Enabled
	 * [ 1: 1] Write Enable
	 *         0 = Writes Disabled
	 *         1 = Writes Enabled
	 * [ 2: 2] Device Number Compare Enable
	 *         0 = The ranges are based on bus number
	 *         1 = The ranges are ranges of devices on bus 0
	 * [ 3: 3] Reserved
	 * [ 6: 4] Destination Node
	 *         000 = Node 0
	 *         001 = Node 1
	 *         010 = Node 2
	 *         011 = Node 3
	 *         100 = Node 4
	 *         101 = Node 5
	 *         110 = Node 6
	 *         111 = Node 7
	 * [ 7: 7] Reserved
	 * [ 9: 8] Destination Link
	 *         00 = Link 0
	 *         01 = Link 1
	 *         10 = Link 2
	 *         11 - Reserved
	 * [15:10] Reserved
	 * [23:16] Bus Number Base i
	 *         This field defines the lowest bus number in configuration region i
	 * [31:24] Bus Number Limit i
	 *         This field defines the highest bus number in configuration regin i
	 */
	PCI_ADDR(0, 0x18, 1, 0xE0), 0x0000FC88, 0x04000203,
	PCI_ADDR(0, 0x18, 1, 0xE4), 0x0000FC88, 0x06050003,
	PCI_ADDR(0, 0x18, 1, 0xE8), 0x0000FC88, 0x00000000,
	PCI_ADDR(0, 0x18, 1, 0xEC), 0x0000FC88, 0x00000000,

You start out with:
 busses 0 - 4 mapped to node 0 link 2
 busses 5 - 6 mapped to node 0 link 0

All other busses disabled.

In northbridge.c:amdk8_scan_chains

For link 0 I scan through and find that register 0xE4 is used for node 0 link 0.

I then pick the next free bus number one and assign that to node 0 link 0, in 
register 0xE4. 

But bus 1 is still routed in register 0xE0 to node 0 link 2.  I believe 0xE0 comes
first and overrides my logic.  Either that or the cpu is confused because there
are two inconsistent mappings for bus 1.


So there look to be two fixes.
1) In resourcemap.c just map bus 0 to the node 0 link 0, and leave everything else unmapped.
2) Modify the bus scanning code to unmap busses beyond it's current maximum, so we do
   not get ambiguous mappings.

Either one should allow the busses to be scanned in either order.

I will think through and see if I can code the second fix properly, as it will just
save grief.  If you can try the simpler solution, I would appreciate it.

Eric



More information about the coreboot mailing list