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

[Blue Swirl]

On Tue, Oct 26, 2010 at 8:34 PM, 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:
>> > On Tue, Oct 26, 2010 at 05:00:25PM +0000, Blue Swirl wrote:
>> >> On Tue, Oct 26, 2010 at 3:43 PM, Gleb Natapov <address@hidden> 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 <address@hidden> 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:
>> >> >> >
>> >> >> > address@hidden,03f7/address@hidden
>> >> >> > address@hidden,03f7/address@hidden
>> >> >> > address@hidden:00:01.1/address@hidden:0
>> >> >> > address@hidden:00:01.1/address@hidden:1
>> >> >> > address@hidden:00:03.0/address@hidden
>> >> >> > address@hidden:00:04.0/address@hidden
>> >> >> >
>> >> >> > 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/address@hidden/address@hidden
>> >> >> /pci/isa/address@hidden/address@hidden
>> >> > Why is it PCI?
>> >>
>> >> I just assumed a PCI to ISA bridge.
>> >>
>> >> >> /pci/address@hidden/1,0
>> >> >> /pci/address@hidden/1,1
>> >> > Where pci address here?
>> >> >
>> >> >> /pci/address@hidden
>> >> >> /pci/address@hidden
>> >> > And here?
>> >>
>> >> That was the part I invented.
>> >>
>> >> > And we will need to describe ROMs too. I planned to have something like:
>> >> > address@hidden 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:
>> >
>> > /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. 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.