From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=34447 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PB1oy-0002Gc-OU for qemu-devel@nongnu.org; Wed, 27 Oct 2010 04:57:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PB1or-0006FD-Qv for qemu-devel@nongnu.org; Wed, 27 Oct 2010 04:57:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35150) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PB1or-0006F0-GN for qemu-devel@nongnu.org; Wed, 27 Oct 2010 04:57:17 -0400 Date: Wed, 27 Oct 2010 10:57:12 +0200 From: Gleb Natapov Subject: Re: [Qemu-devel] [PATCH 0/5] boot order specification Message-ID: <20101027085712.GJ26191@redhat.com> References: <1288090091-25874-1-git-send-email-gleb@redhat.com> <20101026154313.GC2764@redhat.com> <20101026193510.GD2764@redhat.com> <20101026203451.GE2764@redhat.com> <20101026161424.6759413c@udp111988uds.am.freescale.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101026161424.6759413c@udp111988uds.am.freescale.net> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Scott Wood Cc: Blue Swirl , qemu-devel@nongnu.org On Tue, Oct 26, 2010 at 04:14:24PM -0500, Scott Wood wrote: > On Tue, 26 Oct 2010 22:34:51 +0200 > Gleb Natapov 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 wrote: > > > > But looking elsewhere I found some description of DTS. It is very > > > > elaborate and looks like this: > > > > > > > > /pci@xxx { > > > > plenty of info here > > > > } > > > > > > > > The only example of /pci@xxx 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 /pci@xyz nodes. > > > > > Yes, it has: /pci@f0000000 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: /pci@f0000000 /pci@f2000000 /pci@f4000000 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.