Re: [Qemu-devel] [PATCH 0/5] boot order specification

[Gleb Natapov]

On Tue, Oct 26, 2010 at 04:14:24PM -0500, Scott Wood wrote:
> On Tue, 26 Oct 2010 22:34:51 +0200
> Gleb Natapov <address@hidden> wrote:
> 
> > On Tue, Oct 26, 2010 at 07:57:00PM +0000, Blue Swirl wrote:
> > > On Tue, Oct 26, 2010 at 7:35 PM, Gleb Natapov <address@hidden> wrote:
> > > > But looking elsewhere I found some description of DTS. It is very
> > > > elaborate and looks like this:
> > > >
> > > > /address@hidden {
> > > > plenty of info here
> > > > }
> > > >
> > > > The only example of /address@hidden that I found is here
> > > > http://wiki.freebsd.org/FlattenedDeviceTree but not any spec about its
> > > > format.
> > > 
> > > That's FDT, it's a bit different.
> > > 
> > > There are some trees here:
> > > http://penguinppc.org/historical/dev-trees-html/trees-index.html
> > > 
> > > For example dual G4 500 has several /address@hidden nodes.
> > > 
> > Yes, it has: /address@hidden for instance. Now lets try to decipher 
> > address f0000000 according to pci2_1.pdf below. It says:
> > The text representation of a PCI address is one of the following forms:
> >          DD
> >          DD,F
> >          [n]i[t]DD,F,RR,NNNNNNNN
> >          [n]m[t][p]DD,F,RR,NNNNNNNN
> >          [n]x[p]DD,F,RR,NNNNNNNNNNNNNNNN
> >     where:
> >          DD                         is an ASCII hexadecimal number in the 
> > range 0...1F
> >          F                          is an ASCII numeral in the range 0...7
> >          RR                         is an ASCII hexadecimal number in the 
> > range 0...FF
> >          NNNNNNNN                   is an ASCII hexadecimal number in the 
> > range 0...FFFFFFFF
> >          NNNNNNNNNNNNNNNN           is an ASCII hexadecimal number in the 
> > range 0...FFFFFFFFFFFFFFFF
> >          [n]                        is the letter 'n', whose presence is 
> > optional
> >          [t]                        is the letter 't', whose presence is 
> > optional
> >          [p]                        is the letter 'p', whose presence is 
> > optional
> >          i                          is the letter 'i'
> >          m                          is the letter 'm'
> >          x                          is the letter 'x'
> >          ,                          is the character ',' (comma)
> > 
> > Nothing resembles f0000000. There is also 2.2.1.1 Numerical Representation
> > but no luck there too. This number is illegal according to it.
> 
> The encoding above applies to unit addresses inside the PCI bus node.
> 
> The unit address of the PCI controller node itself is encoded according
> to its parent bus.
> 
Ah so to talk to pci controller OS writes to 0xf0000000?
http://penguinppc.org/historical/dev-trees-html/g4_agp_500_1.html has 3
such pci definitions:
/address@hidden
/address@hidden
/address@hidden
If G4 500 has 3 PCI domains it all makes perfect sense then.

> > May be this is memory address PCI bar is mapped into?
> 
> It should correspond to the node's reg property.
> 
> What's in the reg property depends on the binding for that particular
> PCI controller.
> 
> -Scott

--
                        Gleb.