qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Scott Wood
Subject: Re: [Qemu-devel] [PATCH 0/5] boot order specification
Date: Tue, 26 Oct 2010 16:14:24 -0500

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.

> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]