Re: [coreboot] v3 HT

[Myles Watson]

> -----Original Message-----
> From: Marc Jones [mailto:[e-mail]]
> Sent: Monday, October 27, 2008 2:58 PM
> To: Myles Watson
> Cc: 'Coreboot'
> Subject: Re: [coreboot] v3 HT
>
> 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@0 {
> >    };
> >    domain@0 {
> >    	/config/("northbridge/amd/k8/domain");
> >    	pci0@18,0 {
> >    		/config/("northbridge/amd/k8/pci");
> >    		pci@0,0 {
> >    			/config/("southbridge/amd/amd8111/pci.dts");
> >    			pci@1,0{
> >
> > /config/("southbridge/amd/amd8111/nic.dts");
> >    			};
> >    		};
> >    		pci@1,0 {
> >    			/config/("southbridge/amd/amd8111/lpc.dts");
> >    		};
> >    		pci@1,1 {
> >    			/config/("southbridge/amd/amd8111/ide.dts");
> >    		};
> >    		pci@1,0{
> >
> > /config/("southbridge/amd/amd8132/pcix.dts");

};
> > };
> > pci1@18,0 {
> > 	/config/("northbridge/amd/k8/pci");
> > };
> > pci2@18,0 {
> > 	/config/("northbridge/amd/k8/pci");
> > };
> > pci@18,1 {};
> > pci@18,2 {};
> > pci@18,3 {};
> > ioport@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.

Can we agree on a simplified dts to start with, then?  It would help me out
a lot.
> > 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:
> > Scan the list of children for bridges
> > 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.

This is where it gets ugly.

As far as I can tell, the 8111 is not visible until after the 8132 gets
initialized enough to not mask the 8111's unitid.  This is the reason for
all of the #defines from v2.

The code doesn't seem to be organized in a depth-first manner.  It would be
nice, but then wouldn't you have to move the unitids so that the southbridge
could stay where it was?

I don't understand enough to know why the 8111 needs to be at 6.  I'm
assuming that it is wired to be there.  It doesn't look like the same is
true for the 8132.

As a side note:
The 8132 doesn't have the "bridge" bit set (maybe an oversight, maybe not.)
It's not bridging to the 8111, but it is a bridge.
> > 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)

Yes.  The problem is that the code isn't set up to take the depth-first
information and propagate it.

Thanks,
Myles