On Tue, Oct 26, 2010 at 8:34 PM, Gleb Natapov <g...@redhat.com> 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 <g...@redhat.com> wrote: >> > On Tue, Oct 26, 2010 at 05:00:25PM +0000, Blue Swirl wrote: >> >> On Tue, Oct 26, 2010 at 3:43 PM, Gleb Natapov <g...@redhat.com> wrote: >> >> > On Tue, Oct 26, 2010 at 03:35:38PM +0000, Blue Swirl wrote: >> >> >> On Tue, Oct 26, 2010 at 10:48 AM, Gleb Natapov <g...@redhat.com> wrote: >> >> >> > This is current sate of the patch series for people to comment on. >> >> >> > I dropped ioport double reservation checking from isa-bus and added >> >> >> > bus_id field for IDE bus since as Markus pointed out unit has >> >> >> > different >> >> >> > meaning there. >> >> >> > >> >> >> > This patch series produce names like: >> >> >> > >> >> >> > i...@03f1-03f5,03f7/f...@a >> >> >> > i...@03f1-03f5,03f7/f...@b >> >> >> > p...@0000:00:01.1/i...@1:0 >> >> >> > p...@0000:00:01.1/i...@1:1 >> >> >> > p...@0000:00:03.0/virtio-...@0 >> >> >> > p...@0000:00:04.0/virtio-...@0 >> >> >> > >> >> >> > They will be passed to BIOS to determine boot order. >> >> >> >> >> >> We also use OpenBIOS for PPC and Sparcs. A compatible boot device for >> >> >> those would be OpenFirmware tree name. I think your names should then >> >> >> become: >> >> >> /pci/isa/f...@3f1/f...@0 >> >> >> /pci/isa/f...@3f1/f...@1 >> >> > Why is it PCI? >> >> >> >> I just assumed a PCI to ISA bridge. >> >> >> >> >> /pci/i...@0/1,0 >> >> >> /pci/i...@0/1,1 >> >> > Where pci address here? >> >> > >> >> >> /pci/virtio-...@1 >> >> >> /pci/virtio-...@2 >> >> > And here? >> >> >> >> That was the part I invented. >> >> >> >> > And we will need to describe ROMs too. I planned to have something like: >> >> > r...@romfilename for roms loaded with -option-rom command line option. >> >> >> >> I don't think OF has standard for those. >> >> >> >> >> >> >> >> The PCI addressing scheme in OF was a bit twisty, I just invented >> >> >> integers in place of those. >> >> >> >> >> >> Anyway, I don't think we should invent yet another device path naming >> >> >> system. >> >> > IS this format documented somewhere? I am not attached to specific >> >> > format at all. >> >> >> >> A lot of docs are here: >> >> http://playground.sun.com/pub/p1275/home.html >> > Search for flat, device or tree returns nothing on this page. >> > >> > But looking elsewhere I found some description of DTS. It is very >> > elaborate and looks like this: >> > >> > /p...@xxx { >> > plenty of info here >> > } >> > >> > The only example of /p...@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 /p...@xyz nodes. >> > Yes, it has: /p...@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. May be > this is memory address PCI bar is mapped into? But according to which > spec?
For PPC yes, but that depends on the system. This is described in the common spec. >And this kind of addressing has no meaning as interface between > qemu and firmware since qemu does not map PCI bars. No, but we still need to identify the devices. This could still be a useful way to address them so that also the BIOS can identify them. For example, this 0xf0000000 can be used by BIOS to probe for a PCI controller. >> >> >> >> Here's the PCI bindings doc: >> >> http://playground.sun.com/pub/p1275/bindings/pci/pci2_1.pdf >> > The funny thing is that pci address used in /pci@ example from wiki >> > above is incorrect according to this spec. >> > >> > And I thought ACPI spec is confusing :) Can you clarify things a little >> > bit please? >> >> Perhaps you should start by reading the main OF document, it can be found in: >> http://www.openfirmware.info/IEEE_1275-1994 > Perhaps. But searching for PCI there returns nothing. What section > exactly should enlighten me? One interesting thing I found at the > beginning: > 1.1 Purpose and scope > This document describes a software architecture for the firmware that > controls a computer before the operating system has begun execution > > Interfaces between firmware and OS is not always suitable for > qemu->guest communication. That can be true. Next idea: If QEMU passed a FDT to BIOS, then the original boot device problem could be solved by decorating various tree nodes with "QEMU,boot" tags.