[coreboot] dts proposal

Peter Stuge peter at stuge.se
Mon Feb 11 03:22:53 CET 2008

On Sun, Feb 10, 2008 at 01:51:18PM -0800, ron minnich wrote:
> This is a possible dts for alix1c. This actually builds and works,
> but linux panics, so that's an issue, but how does it look?

Definately the right direction, but some comments..

> 	cpus {
> 		cpupath="0";
> 		enabled;
> 	};
> 	cpu at 0 {

Why both cpus+cpupath and cpu at 0 ?

> 		apic at 0 {
> 			/config/("northbridge/amd/geodelx/apic");
> 			apicpath="0,0,0";

Why both apic at 0 and apicpath?

> 	domain at 0 {

How come both cpu and domain can be @0 ?

Yes, I know, the meaning of the path depends on the type. Wait, the
containing block type, or the new block type? It is too confusing!

> 		/config/("northbridge/amd/geodelx/domain");
> 		enabled;
> 		pcibus at 0 {

What is the pcibus at? Could the number be optional when there is
only one? Rephrase: Is this the PCI bus number? Can we count on it
to always be 0-based and increase by one for each bus?

> 			pci at 1,0 {
> 			/config/("northbridge/amd/geodelx/pci");
> 				enabled;
> 			};

What's behind this PCI-PCI-bridge? Is this the external PCI bus?

(By the way, I think we should add a .dts suffix when we have several
files for a component.)

> 			southbridge at f,0 {

South, on PCI bus 0, south is device 0:f.0. Ok.

> 				lpc at 2e {
> 					/config/("superio/winbond/w83627hf/dts");
> 					com1enable = "1";
> 				};

Now the path is an ioport.

Sorry, I just can't get my head around it. I fear a support problem
too, with the different path types looking very similar but being
quite different.

Which path types do we have so far?


More information about the coreboot mailing list