[coreboot] v3 HT

Marc Jones Marc.Jones at amd.com
Mon Oct 27 21:57:53 CET 2008


Myles Watson wrote:
> I've been looking at v2 and v3 HT code.  It seems like the biggest problem
> is that we changed the representation of the device tree and didn't change
> the code.
> 
> I think it would be best to have the dts match an lspci as closely as
> possible.  That means the code has to be a little smarter so that it can
> fill in the missing information.
> 
> If we start with a dts which describes the Serengeti machine, we have:
> 
> 
> /{
> 	device_operations="serengeti";
> 	mainboard_vendor = "AMD";
> 	mainboard_name = "Serengeti";
> 	cpus { };
> 	apic at 0 {
> 	};
> 	domain at 0 {
> 		/config/("northbridge/amd/k8/domain");
> 		pci0 at 18,0 {
> 			/config/("northbridge/amd/k8/pci");
> 			pci at 0,0 {
> 				/config/("southbridge/amd/amd8111/pci.dts");
> 				pci at 1,0{
> 	
> /config/("southbridge/amd/amd8111/nic.dts");
> 				};
> 			};
> 			pci at 1,0 {
> 				/config/("southbridge/amd/amd8111/lpc.dts");
> 			};
> 			pci at 1,1 {
> 				/config/("southbridge/amd/amd8111/ide.dts");
> 			};
> 			pci at 1,0{
> 	
> /config/("southbridge/amd/amd8132/pcix.dts");				};
> 
> 		};
> 		pci1 at 18,0 {
> 			/config/("northbridge/amd/k8/pci");
> 		};
> 		pci2 at 18,0 {
> 			/config/("northbridge/amd/k8/pci");
> 		};
> 		pci at 18,1 {};
> 		pci at 18,2 {};
> 		pci at 18,3 {};
> 		ioport at 2e {
> 			/config/("superio/winbond/w83627hf/dts");
> 			com1enable = "1";
> 		};
> 	};
> };
> 
> It doesn't exactly match an lspci, because lspci doesn't care what link the
> devices are on.  I think we have to keep that difference.
>

The dts is wrong here. Like you said, it shouldn't care about the link. 
They are not bridges. Devices like the 8111 are the bridge.

> Then when the hypertransport enumeration code runs, the bridges appear to be
> siblings of their children.  With v2 there was another layer of hierarchy so
> that the children of link 0 would just be the 8132 and the 8111.
> 
> So the new code should:
> 1. Scan the list of children for bridges
> 2. Assign the devices bus numbers and attach them correctly

I'm not sure what you intend. I think that the bus numbers can be set as 
they are found in the depth first scan. I don't think you have to do a 
bridge only scan.

> 
> Does that mean that we need to create dynamic bus devices or structures to
> hold that information?  Probably not.  We can just change pointer
> assignments.
>

Each bridge device holds its assigned number and decodes config space 
accesses for devices below it.  The dts pointers need to be connected in 
the same way. (I think that is what you were saying)

> I don't think we need to expand the dts to fix this, we just need to make
> the code match the structure.

I think so too.


Marc

-- 
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:Marc.Jones at amd.com
http://www.amd.com/embeddedprocessors





More information about the coreboot mailing list