Re: [OpenBIOS] [PATCHv8 00/16] boot order specification

[Blue Swirl]

On Wed, Dec 8, 2010 at 11:34 AM, Gleb Natapov  wrote:
> Forget to save a couple of buffers before sending version 7 :(
>
> Anthony, Blue can this be applied now?

I made some more tests, this time with PPC. I modified OpenBIOS to
print out the boot device list:

$ qemu-system-ppc -drive if=none,id=hda,file=/dev/null -device
ide-drive,drive=hda,bootindex=1 -drive if=none,id=cd,file=/dev/null
-device ide-drive,drive=cd,bootindex=0 -nographic -prom-env
'auto-boot?=false' -L .
qemu-system-ppc: pci_add_option_rom: failed to find romfile "vgabios-stdvga.bin"
Could not open option rom 'pxe-ne2k_pci.bin': No such file or directory
> > =============================================================
> > OpenBIOS 1.0 [Nov 28 2010 19:37]
> > Configuration device id QEMU version 1 machine id 2
> > CPUs: 1
> > Memory: 128M
> > UUID: 00000000-0000-0000-0000-000000000000
> > CPU type PowerPC,750
> > bootindex /grackle@fec00000/ide@3/drive@1/disk@1
> > /grackle@fec00000/ide@3/drive@1/disk@0

Welcome to OpenBIOS v1.0 built on Nov 28 2010 19:37

0 > show-devs
7be6324 /
7be6440 /aliases
7be64e4 /openprom (BootROM)
7bebfa0 /openprom/client-services
7be668c /options
7be6704 /chosen
7be67e8 /builtin
7be688c /builtin/console
7bebcac /packages
7becda8 /packages/cmdline
7becee8 /packages/disk-label
7bedb58 /packages/terminal-emulator
7bee548 /packages/deblocker
7bee89c /packages/hfsplus-files
7beeb3c /packages/hfs-files
7beedd8 /packages/ext2-files
7bef010 /packages/iso9660-files
7bef248 /packages/grubfs-files
7bef480 /packages/mac-parts
7bef6b8 /packages/pc-parts
7bef8ec /packages/xcoff-loader
7bef9b8 /packages/elf-loader
7befa80 /packages/bootinfo-loader
7bed958 /cpus
7bf2fe8 /cpus/PowerPC,750@0 (cpu)
7beda58 /memory@0 (memory)
7befb4c /pci@80000000 (pci)
7beff64 /pci@80000000/QEMU,VGA@1 (display)
7bf0438 /pci@80000000/NE2000@2 (network)
7bf0814 /pci@80000000/pci-ata@3 (pci-ide)
7bf0c50 /pci@80000000/pci-ata@3/ata-1@500 (ata)
7bf0dd0 /pci@80000000/pci-ata@3/ata-2@600 (ata)
7bf0f50 /pci@80000000/pci-ata@3/ata-2@600/disk@1 (block)
7bf131c /pci@80000000/pci-ata@3/ata-2@600/disk@0 (block)
7bf1674 /pci@80000000/mac-io@4 (mac-io)
7bf1b54 /pci@80000000/mac-io@4/via-cuda@16000 (via-cuda)
7bf1d70 /pci@80000000/mac-io@4/via-cuda@16000/adb (adb)
7bf1ed8 /pci@80000000/mac-io@4/via-cuda@16000/adb/keyboard@8 (keyboard)
7bf2080 /pci@80000000/mac-io@4/via-cuda@16000/adb/mouse@9 (mouse)
7bf220c /pci@80000000/mac-io@4/via-cuda@16000/rtc (rtc)
7bf23f4 /pci@80000000/mac-io@4/nvram@60000 (nvram)
7bf2614 /pci@80000000/mac-io@4/escc@13000 (escc)
7bf271c /pci@80000000/mac-io@4/escc@13000/ch-a@13020 (serial)
7bf29b4 /pci@80000000/mac-io@4/escc@13000/ch-b@13000 (serial)
7bf2c20 /pci@80000000/mac-io@4/ata-3@20000 (ata)
 ok

/grackle@fec00000/ide@3/drive@1/disk@1 does not match
/pci@80000000/pci-ata@3/ata-2@600/disk@1.

I wonder where '@80000000' comes from. A dump of original g3beige
device tree is here:
http://penguinppc.org/historical/dev-trees-html/g3_beige_300.html

But actually the tree generated by OpenBIOS looks more like g3bw one:
http://penguinppc.org/historical/dev-trees-html/g3bw_400.html

How can we get the names to be more compatible? At least
s/grackle/pci/ is easy to do in QEMU, but which instance (QEMU or
OpenBIOS) should handle pci-ata vs ide change? What should we do with
ata-2@600 vs drive@1?

[PATCHv8 00/16] boot order specification

[Gleb Natapov]

On Sat, Dec 11, 2010 at 03:13:35PM +0000, Blue Swirl wrote:
> On Wed, Dec 8, 2010 at 11:34 AM, Gleb Natapov  wrote:
> > Forget to save a couple of buffers before sending version 7 :(
> >
> > Anthony, Blue can this be applied now?
>
> I made some more tests, this time with PPC. I modified OpenBIOS to
> print out the boot device list:
>
> $ qemu-system-ppc -drive if=none,id=hda,file=/dev/null -device
> ide-drive,drive=hda,bootindex=1 -drive if=none,id=cd,file=/dev/null
> -device ide-drive,drive=cd,bootindex=0 -nographic -prom-env
> 'auto-boot?=false' -L .
> qemu-system-ppc: pci_add_option_rom: failed to find romfile "vgabios-stdvga.bin"
> Could not open option rom 'pxe-ne2k_pci.bin': No such file or directory
> > > =============================================================
> > > OpenBIOS 1.0 [Nov 28 2010 19:37]
> > > Configuration device id QEMU version 1 machine id 2
> > > CPUs: 1
> > > Memory: 128M
> > > UUID: 00000000-0000-0000-0000-000000000000
> > > CPU type PowerPC,750
> > > bootindex /grackle@fec00000/ide@3/drive@1/disk@1
> > > /grackle@fec00000/ide@3/drive@1/disk@0
>
> Welcome to OpenBIOS v1.0 built on Nov 28 2010 19:37
>
> 0 > show-devs
> 7be6324 /
> 7be6440 /aliases
> 7be64e4 /openprom (BootROM)
> 7bebfa0 /openprom/client-services
> 7be668c /options
> 7be6704 /chosen
> 7be67e8 /builtin
> 7be688c /builtin/console
> 7bebcac /packages
> 7becda8 /packages/cmdline
> 7becee8 /packages/disk-label
> 7bedb58 /packages/terminal-emulator
> 7bee548 /packages/deblocker
> 7bee89c /packages/hfsplus-files
> 7beeb3c /packages/hfs-files
> 7beedd8 /packages/ext2-files
> 7bef010 /packages/iso9660-files
> 7bef248 /packages/grubfs-files
> 7bef480 /packages/mac-parts
> 7bef6b8 /packages/pc-parts
> 7bef8ec /packages/xcoff-loader
> 7bef9b8 /packages/elf-loader
> 7befa80 /packages/bootinfo-loader
> 7bed958 /cpus
> 7bf2fe8 /cpus/PowerPC,750@0 (cpu)
> 7beda58 /memory@0 (memory)
> 7befb4c /pci@80000000 (pci)
> 7beff64 /pci@80000000/QEMU,VGA@1 (display)
> 7bf0438 /pci@80000000/NE2000@2 (network)
> 7bf0814 /pci@80000000/pci-ata@3 (pci-ide)
> 7bf0c50 /pci@80000000/pci-ata@3/ata-1@500 (ata)
> 7bf0dd0 /pci@80000000/pci-ata@3/ata-2@600 (ata)
> 7bf0f50 /pci@80000000/pci-ata@3/ata-2@600/disk@1 (block)
> 7bf131c /pci@80000000/pci-ata@3/ata-2@600/disk@0 (block)
> 7bf1674 /pci@80000000/mac-io@4 (mac-io)
> 7bf1b54 /pci@80000000/mac-io@4/via-cuda@16000 (via-cuda)
> 7bf1d70 /pci@80000000/mac-io@4/via-cuda@16000/adb (adb)
> 7bf1ed8 /pci@80000000/mac-io@4/via-cuda@16000/adb/keyboard@8 (keyboard)
> 7bf2080 /pci@80000000/mac-io@4/via-cuda@16000/adb/mouse@9 (mouse)
> 7bf220c /pci@80000000/mac-io@4/via-cuda@16000/rtc (rtc)
> 7bf23f4 /pci@80000000/mac-io@4/nvram@60000 (nvram)
> 7bf2614 /pci@80000000/mac-io@4/escc@13000 (escc)
> 7bf271c /pci@80000000/mac-io@4/escc@13000/ch-a@13020 (serial)
> 7bf29b4 /pci@80000000/mac-io@4/escc@13000/ch-b@13000 (serial)
> 7bf2c20 /pci@80000000/mac-io@4/ata-3@20000 (ata)
>  ok
>
> /grackle@fec00000/ide@3/drive@1/disk@1 does not match
> /pci@80000000/pci-ata@3/ata-2@600/disk@1.

hw/ppc_oldworld.c has:
pci_bus = pci_grackle_init(0xfec00000, pic);
i.e it registers pci controller at MMIO address 0xfec00000. 0x80000000
is isa mmio base. Why OpenBIOS uses 80000000 as address of pci
controller? May be on real HW all memory access above 0x80000000 is
redirected to pci controller and it emulates isa? Then we should fix
qemu to do the same.
> I wonder where '@80000000' comes from. A dump of original g3beige
> device tree is here:
> http://penguinppc.org/historical/dev-trees-html/g3_beige_300.html
>
> But actually the tree generated by OpenBIOS looks more like g3bw one:
> http://penguinppc.org/historical/dev-trees-html/g3bw_400.html
>
> How can we get the names to be more compatible? At least
> s/grackle/pci/ is easy to do in QEMU, but which instance (QEMU or
> OpenBIOS) should handle pci-ata vs ide change?

http://playground.sun.com/pub/p1275/bindings/pci/pci2_1.pdf has table on
page 10 that defines how pci class code should be translated into OF
name. This is what my patch is using. pci-ata does not look spec
compliant (or is there more up-to-date spec?)
>                                             What should we do with
>
> ata-2@600 vs drive@1?

There is no available IDE OF binding spec, so I when with the way
OpenBIOS reports ata on qemu-x86. I have no idea what 600 in ata-2@600
may mean, but looking at g3_beige_300.html there is no such node there
and looking at any other device tree in http://penguinppc.org/historical/dev-trees-html/
I haven't found one that use this kind of addressing for pci-ata. 
http://penguinppc.org/historical/dev-trees-html/g3bw_400.html for
instance has pci@80000000/pci-bridge@d/pci-ata@1/ata-4. ata-2@600 kind of
addressing is used by devices on mac-io bus which I do not think we
emulate in qemu. So it looks like OpneBIOS is wrong here.

[PATCHv8 00/16] boot order specification

[Blue Swirl]

On Sat, Dec 11, 2010 at 4:06 PM, Gleb Natapov  wrote:
> On Sat, Dec 11, 2010 at 03:13:35PM +0000, Blue Swirl wrote:
> > On Wed, Dec 8, 2010 at 11:34 AM, Gleb Natapov  wrote:
> > > Forget to save a couple of buffers before sending version 7 :(
> > >
> > > Anthony, Blue can this be applied now?
> >
> > I made some more tests, this time with PPC. I modified OpenBIOS to
> > print out the boot device list:
> >
> > $ qemu-system-ppc -drive if=none,id=hda,file=/dev/null -device
> > ide-drive,drive=hda,bootindex=1 -drive if=none,id=cd,file=/dev/null
> > -device ide-drive,drive=cd,bootindex=0 -nographic -prom-env
> > 'auto-boot?=false' -L .
> > qemu-system-ppc: pci_add_option_rom: failed to find romfile "vgabios-stdvga.bin"
> > Could not open option rom 'pxe-ne2k_pci.bin': No such file or directory
> > > > =============================================================
> > > > OpenBIOS 1.0 [Nov 28 2010 19:37]
> > > > Configuration device id QEMU version 1 machine id 2
> > > > CPUs: 1
> > > > Memory: 128M
> > > > UUID: 00000000-0000-0000-0000-000000000000
> > > > CPU type PowerPC,750
> > > > bootindex /grackle@fec00000/ide@3/drive@1/disk@1
> > > > /grackle@fec00000/ide@3/drive@1/disk@0
> >
> > Welcome to OpenBIOS v1.0 built on Nov 28 2010 19:37
> >
> > 0 > show-devs
> > 7be6324 /
> > 7be6440 /aliases
> > 7be64e4 /openprom (BootROM)
> > 7bebfa0 /openprom/client-services
> > 7be668c /options
> > 7be6704 /chosen
> > 7be67e8 /builtin
> > 7be688c /builtin/console
> > 7bebcac /packages
> > 7becda8 /packages/cmdline
> > 7becee8 /packages/disk-label
> > 7bedb58 /packages/terminal-emulator
> > 7bee548 /packages/deblocker
> > 7bee89c /packages/hfsplus-files
> > 7beeb3c /packages/hfs-files
> > 7beedd8 /packages/ext2-files
> > 7bef010 /packages/iso9660-files
> > 7bef248 /packages/grubfs-files
> > 7bef480 /packages/mac-parts
> > 7bef6b8 /packages/pc-parts
> > 7bef8ec /packages/xcoff-loader
> > 7bef9b8 /packages/elf-loader
> > 7befa80 /packages/bootinfo-loader
> > 7bed958 /cpus
> > 7bf2fe8 /cpus/PowerPC,750@0 (cpu)
> > 7beda58 /memory@0 (memory)
> > 7befb4c /pci@80000000 (pci)
> > 7beff64 /pci@80000000/QEMU,VGA@1 (display)
> > 7bf0438 /pci@80000000/NE2000@2 (network)
> > 7bf0814 /pci@80000000/pci-ata@3 (pci-ide)
> > 7bf0c50 /pci@80000000/pci-ata@3/ata-1@500 (ata)
> > 7bf0dd0 /pci@80000000/pci-ata@3/ata-2@600 (ata)
> > 7bf0f50 /pci@80000000/pci-ata@3/ata-2@600/disk@1 (block)
> > 7bf131c /pci@80000000/pci-ata@3/ata-2@600/disk@0 (block)
> > 7bf1674 /pci@80000000/mac-io@4 (mac-io)
> > 7bf1b54 /pci@80000000/mac-io@4/via-cuda@16000 (via-cuda)
> > 7bf1d70 /pci@80000000/mac-io@4/via-cuda@16000/adb (adb)
> > 7bf1ed8 /pci@80000000/mac-io@4/via-cuda@16000/adb/keyboard@8 (keyboard)
> > 7bf2080 /pci@80000000/mac-io@4/via-cuda@16000/adb/mouse@9 (mouse)
> > 7bf220c /pci@80000000/mac-io@4/via-cuda@16000/rtc (rtc)
> > 7bf23f4 /pci@80000000/mac-io@4/nvram@60000 (nvram)
> > 7bf2614 /pci@80000000/mac-io@4/escc@13000 (escc)
> > 7bf271c /pci@80000000/mac-io@4/escc@13000/ch-a@13020 (serial)
> > 7bf29b4 /pci@80000000/mac-io@4/escc@13000/ch-b@13000 (serial)
> > 7bf2c20 /pci@80000000/mac-io@4/ata-3@20000 (ata)
> >  ok
> >
> > /grackle@fec00000/ide@3/drive@1/disk@1 does not match
> > /pci@80000000/pci-ata@3/ata-2@600/disk@1.
>
> hw/ppc_oldworld.c has:
> pci_bus = pci_grackle_init(0xfec00000, pic);
> i.e it registers pci controller at MMIO address 0xfec00000. 0x80000000
> is isa mmio base. Why OpenBIOS uses 80000000 as address of pci
> controller? May be on real HW all memory access above 0x80000000 is
> redirected to pci controller and it emulates isa? Then we should fix
> qemu to do the same.
> > I wonder where '@80000000' comes from. A dump of original g3beige
> > device tree is here:
> > http://penguinppc.org/historical/dev-trees-html/g3_beige_300.html
> >
> > But actually the tree generated by OpenBIOS looks more like g3bw one:
> > http://penguinppc.org/historical/dev-trees-html/g3bw_400.html
> >
> > How can we get the names to be more compatible? At least
> > s/grackle/pci/ is easy to do in QEMU, but which instance (QEMU or
> > OpenBIOS) should handle pci-ata vs ide change?
>
> http://playground.sun.com/pub/p1275/bindings/pci/pci2_1.pdf has table on
> page 10 that defines how pci class code should be translated into OF
> name. This is what my patch is using. pci-ata does not look spec
> compliant (or is there more up-to-date spec?)

There could be a FCode Program which sets the name.
> > What should we do with
> > ata-2@600 vs drive@1?
>
> There is no available IDE OF binding spec, so I when with the way
> OpenBIOS reports ata on qemu-x86. I have no idea what 600 in ata-2@600
> may mean, but looking at g3_beige_300.html there is no such node there
> and looking at any other device tree in http://penguinppc.org/historical/dev-trees-html/
> I haven't found one that use this kind of addressing for pci-ata.
> http://penguinppc.org/historical/dev-trees-html/g3bw_400.html for
> instance has pci@80000000/pci-bridge@d/pci-ata@1/ata-4. ata-2@600 kind of
> addressing is used by devices on mac-io bus which I do not think we
> emulate in qemu. So it looks like OpneBIOS is wrong here.

We have PMAC IDE, but this device is CMD646, so mac-io bus addressing
rules should not be used.

In this tree there are two disks connected to CMD646, named
/pci@80000000/pci-bridge@d/pci-ata@1/ata-4/disk and
/pci@80000000/pci-bridge@d/pci-ata@1/ata-4/disk@1:
http://penguinppc.org/historical/dev-trees-html/g4_pci_350.html

[PATCHv8 00/16] boot order specification

[Gleb Natapov]

On Sat, Dec 11, 2010 at 05:19:01PM +0000, Blue Swirl wrote:
> > > What should we do with
> > > ata-2@600 vs drive@1?
> >
> > There is no available IDE OF binding spec, so I when with the way
> > OpenBIOS reports ata on qemu-x86. I have no idea what 600 in ata-2@600
> > may mean, but looking at g3_beige_300.html there is no such node there
> > and looking at any other device tree in http://penguinppc.org/historical/dev-trees-html/
> > I haven't found one that use this kind of addressing for pci-ata.
> > http://penguinppc.org/historical/dev-trees-html/g3bw_400.html for
> > instance has pci@80000000/pci-bridge@d/pci-ata@1/ata-4. ata-2@600 kind of
> > addressing is used by devices on mac-io bus which I do not think we
> > emulate in qemu. So it looks like OpneBIOS is wrong here.
>
> We have PMAC IDE, but this device is CMD646, so mac-io bus addressing
> rules should not be used.

So you agree that OpenBIOS is wrong here?
> In this tree there are two disks connected to CMD646, named
> /pci@80000000/pci-bridge@d/pci-ata@1/ata-4/disk and
> /pci@80000000/pci-bridge@d/pci-ata@1/ata-4/disk@1:
> http://penguinppc.org/historical/dev-trees-html/g4_pci_350.html

You are saying that qemu creates paths like:
/grackle@fec00000/ide@3/drive@1/disk@0
/grackle@fec00000/ide@3/drive@1/disk@1

I do not understand why qemu creates node drive@1. It should be drive@0
according to the code. I'll look at why unit-address is incorrect for
the node. But assuming that this problem is fixed then paths created by
qemu is very similar to the paths in g4_pci_350.html. It looks like in 
g4_pci_350.html they omit unit address if it is zero.

[Qemu-devel] Re: [PATCHv8 00/16] boot order specification

[Gleb Natapov]

On Sat, Dec 11, 2010 at 08:02:23PM +0200, Gleb Natapov wrote:
> On Sat, Dec 11, 2010 at 05:19:01PM +0000, Blue Swirl wrote:
> > > > What should we do with
> > > > ata-2@600 vs drive@1?
> > >
> > > There is no available IDE OF binding spec, so I when with the way
> > > OpenBIOS reports ata on qemu-x86. I have no idea what 600 in ata-2@600
> > > may mean, but looking at g3_beige_300.html there is no such node there
> > > and looking at any other device tree in http://penguinppc.org/historical/dev-trees-html/
> > > I haven't found one that use this kind of addressing for pci-ata.
> > > http://penguinppc.org/historical/dev-trees-html/g3bw_400.html for
> > > instance has pci@80000000/pci-bridge@d/pci-ata@1/ata-4. ata-2@600 kind of
> > > addressing is used by devices on mac-io bus which I do not think we
> > > emulate in qemu. So it looks like OpneBIOS is wrong here.
> >
> > We have PMAC IDE, but this device is CMD646, so mac-io bus addressing
> > rules should not be used.
>
> So you agree that OpenBIOS is wrong here?
> > In this tree there are two disks connected to CMD646, named
> > /pci@80000000/pci-bridge@d/pci-ata@1/ata-4/disk and
> > /pci@80000000/pci-bridge@d/pci-ata@1/ata-4/disk@1:
> > http://penguinppc.org/historical/dev-trees-html/g4_pci_350.html
>
> You are saying that qemu creates paths like:
> /grackle@fec00000/ide@3/drive@1/disk@0
> /grackle@fec00000/ide@3/drive@1/disk@1
>
> I do not understand why qemu creates node drive@1. It should be drive@0
> according to the code. I'll look at why unit-address is incorrect for
> the node. But assuming that this problem is fixed then paths created by
> qemu is very similar to the paths in g4_pci_350.html. It looks like in 
> g4_pci_350.html they omit unit address if it is zero.

Ah the problem is that we have not qdevified mac io bus. Since first to
ide disks are automatically attached to mac-io bus device paths for them
are incorrect. Next two ide devices will be attached to CMD646 and qemu
will generate correct device paths for them:

qemu-system-ppc -drive if=none,id=hda,file=/dev/null -device ide-drive,drive=hda,bootindex=1
-drive if=none,id=cd,file=/dev/null -device ide-drive,drive=cd,bootindex=0 -nographic -drive
if=none,id=hdb,file=/dev/null -device ide-drive,drive=hdb,bus=ide.0,bootindex=2 -drive
if=none,id=hdc,file=/dev/null -device ide-drive,drive=hdc,bus=ide.0,bootindex=3
adding '/grackle@fec00000/ide@3/drive@1/disk@1' at index 0
adding '/grackle@fec00000/ide@3/drive@1/disk@0' at index 1
adding '/grackle@fec00000/ide@3/drive@0/disk@0' at index 2
adding '/grackle@fec00000/ide@3/drive@0/disk@1' at index 3

So the fix is to qdevify mac io bus.

[PATCHv8 00/16] boot order specification

[Blue Swirl]

2010/12/11 Gleb Natapov :
> On Sat, Dec 11, 2010 at 05:19:01PM +0000, Blue Swirl wrote:
> > > > What should we do with
> > > > ata-2@600 vs drive@1?
> > >
> > > There is no available IDE OF binding spec, so I when with the way
> > > OpenBIOS reports ata on qemu-x86. I have no idea what 600 in ata-2@600
> > > may mean, but looking at g3_beige_300.html there is no such node there
> > > and looking at any other device tree in http://penguinppc.org/historical/dev-trees-html/
> > > I haven't found one that use this kind of addressing for pci-ata.
> > > http://penguinppc.org/historical/dev-trees-html/g3bw_400.html for
> > > instance has pci@80000000/pci-bridge@d/pci-ata@1/ata-4. ata-2@600 kind of
> > > addressing is used by devices on mac-io bus which I do not think we
> > > emulate in qemu. So it looks like OpneBIOS is wrong here.
> >
> > We have PMAC IDE, but this device is CMD646, so mac-io bus addressing
> > rules should not be used.
>
> So you agree that OpenBIOS is wrong here?

I think so.

[Qemu-devel] Re: [PATCHv8 00/16] boot order specification

[Blue Swirl]

2010/12/11 Gleb Natapov :
> On Sat, Dec 11, 2010 at 08:02:23PM +0200, Gleb Natapov wrote:
> > On Sat, Dec 11, 2010 at 05:19:01PM +0000, Blue Swirl wrote:
> > > > > What should we do with
> > > > > ata-2@600 vs drive@1?
> > > >
> > > > There is no available IDE OF binding spec, so I when with the way
> > > > OpenBIOS reports ata on qemu-x86. I have no idea what 600 in ata-2@600
> > > > may mean, but looking at g3_beige_300.html there is no such node there
> > > > and looking at any other device tree in http://penguinppc.org/historical/dev-trees-html/
> > > > I haven't found one that use this kind of addressing for pci-ata.
> > > > http://penguinppc.org/historical/dev-trees-html/g3bw_400.html for
> > > > instance has pci@80000000/pci-bridge@d/pci-ata@1/ata-4. ata-2@600 kind of
> > > > addressing is used by devices on mac-io bus which I do not think we
> > > > emulate in qemu. So it looks like OpneBIOS is wrong here.
> > >
> > > We have PMAC IDE, but this device is CMD646, so mac-io bus addressing
> > > rules should not be used.
> >
> > So you agree that OpenBIOS is wrong here?
> > > In this tree there are two disks connected to CMD646, named
> > > /pci@80000000/pci-bridge@d/pci-ata@1/ata-4/disk and
> > > /pci@80000000/pci-bridge@d/pci-ata@1/ata-4/disk@1:
> > > http://penguinppc.org/historical/dev-trees-html/g4_pci_350.html
> >
> > You are saying that qemu creates paths like:
> > /grackle@fec00000/ide@3/drive@1/disk@0
> > /grackle@fec00000/ide@3/drive@1/disk@1
> >
> > I do not understand why qemu creates node drive@1. It should be drive@0
> > according to the code. I'll look at why unit-address is incorrect for
> > the node. But assuming that this problem is fixed then paths created by
> > qemu is very similar to the paths in g4_pci_350.html. It looks like in
> > g4_pci_350.html they omit unit address if it is zero.
>
> Ah the problem is that we have not qdevified mac io bus. Since first to
> ide disks are automatically attached to mac-io bus device paths for them
> are incorrect. Next two ide devices will be attached to CMD646 and qemu
> will generate correct device paths for them:
>
> qemu-system-ppc -drive if=none,id=hda,file=/dev/null -device ide-drive,drive=hda,bootindex=1
> -drive if=none,id=cd,file=/dev/null -device ide-drive,drive=cd,bootindex=0 -nographic -drive
> if=none,id=hdb,file=/dev/null -device ide-drive,drive=hdb,bus=ide.0,bootindex=2 -drive
> if=none,id=hdc,file=/dev/null -device ide-drive,drive=hdc,bus=ide.0,bootindex=3
> adding '/grackle@fec00000/ide@3/drive@1/disk@1' at index 0
> adding '/grackle@fec00000/ide@3/drive@1/disk@0' at index 1
> adding '/grackle@fec00000/ide@3/drive@0/disk@0' at index 2
> adding '/grackle@fec00000/ide@3/drive@0/disk@1' at index 3

But why is the path almost the same as CMD646, shouldn't 'ide@3' be
different since the PCI device is not the same?
> So the fix is to qdevify mac io bus.

OK.

[Qemu-devel] Re: [PATCHv8 00/16] boot order specification

[Gleb Natapov]

On Sat, Dec 11, 2010 at 07:06:04PM +0000, Blue Swirl wrote:
> 2010/12/11 Gleb Natapov :
> > On Sat, Dec 11, 2010 at 08:02:23PM +0200, Gleb Natapov wrote:
> > > On Sat, Dec 11, 2010 at 05:19:01PM +0000, Blue Swirl wrote:
> > > > > > What should we do with
> > > > > > ata-2@600 vs drive@1?
> > > > >
> > > > > There is no available IDE OF binding spec, so I when with the way
> > > > > OpenBIOS reports ata on qemu-x86. I have no idea what 600 in ata-2@600
> > > > > may mean, but looking at g3_beige_300.html there is no such node there
> > > > > and looking at any other device tree in http://penguinppc.org/historical/dev-trees-html/
> > > > > I haven't found one that use this kind of addressing for pci-ata.
> > > > > http://penguinppc.org/historical/dev-trees-html/g3bw_400.html for
> > > > > instance has pci@80000000/pci-bridge@d/pci-ata@1/ata-4. ata-2@600 kind of
> > > > > addressing is used by devices on mac-io bus which I do not think we
> > > > > emulate in qemu. So it looks like OpneBIOS is wrong here.
> > > >
> > > > We have PMAC IDE, but this device is CMD646, so mac-io bus addressing
> > > > rules should not be used.
> > >
> > > So you agree that OpenBIOS is wrong here?
> > > > In this tree there are two disks connected to CMD646, named
> > > > /pci@80000000/pci-bridge@d/pci-ata@1/ata-4/disk and
> > > > /pci@80000000/pci-bridge@d/pci-ata@1/ata-4/disk@1:
> > > > http://penguinppc.org/historical/dev-trees-html/g4_pci_350.html
> > >
> > > You are saying that qemu creates paths like:
> > > /grackle@fec00000/ide@3/drive@1/disk@0
> > > /grackle@fec00000/ide@3/drive@1/disk@1
> > >
> > > I do not understand why qemu creates node drive@1. It should be drive@0
> > > according to the code. I'll look at why unit-address is incorrect for
> > > the node. But assuming that this problem is fixed then paths created by
> > > qemu is very similar to the paths in g4_pci_350.html. It looks like in
> > > g4_pci_350.html they omit unit address if it is zero.
> >
> > Ah the problem is that we have not qdevified mac io bus. Since first to
> > ide disks are automatically attached to mac-io bus device paths for them
> > are incorrect. Next two ide devices will be attached to CMD646 and qemu
> > will generate correct device paths for them:
> >
> > qemu-system-ppc -drive if=none,id=hda,file=/dev/null -device ide-drive,drive=hda,bootindex=1
> > -drive if=none,id=cd,file=/dev/null -device ide-drive,drive=cd,bootindex=0 -nographic -drive
> > if=none,id=hdb,file=/dev/null -device ide-drive,drive=hdb,bus=ide.0,bootindex=2 -drive
> > if=none,id=hdc,file=/dev/null -device ide-drive,drive=hdc,bus=ide.0,bootindex=3
> > adding '/grackle@fec00000/ide@3/drive@1/disk@1' at index 0
> > adding '/grackle@fec00000/ide@3/drive@1/disk@0' at index 1
> > adding '/grackle@fec00000/ide@3/drive@0/disk@0' at index 2
> > adding '/grackle@fec00000/ide@3/drive@0/disk@1' at index 3
>
> But why is the path almost the same as CMD646, shouldn't 'ide@3' be
> different since the PCI device is not the same?

It should, but since the mac io is not qdevified there is no qdev pci
device for it.
> > So the fix is to qdevify mac io bus.
>
> OK.

[Qemu-devel] Re: [PATCHv8 00/16] boot order specification

[Benjamin Herrenschmidt]

On Sat, 2010-12-11 at 18:06 +0200, Gleb Natapov wrote:
> http://playground.sun.com/pub/p1275/bindings/pci/pci2_1.pdf has table
> on
> page 10 that defines how pci class code should be translated into OF
> name. This is what my patch is using. pci-ata does not look spec
> compliant (or is there more up-to-date spec?)
> >                                             What should we do
>
> with
> > ata-2@600 vs drive@1?
>
> There is no available IDE OF binding spec, so I when with the way
> OpenBIOS reports ata on qemu-x86. I have no idea what 600 in ata-2@600
> may mean, but looking at g3_beige_300.html there is no such node there
> and looking at any other device tree in
> http://penguinppc.org/historical/dev-trees-html/

Those are old and I wouldn't look too closely at what Apple does.

ATA doesn't really need anything complex, mostly the ata controller,
generally named "ata" nowadays with a #address-cells of 1 and a
#size-cells of 0. Children are then typically disk, cdrom, ... (ie block
devices) with a unit address of 0 for master and 1 for slave.

In the case of controllers with multiple ports, typically you have one
such "ata" node per bus. "pci-ata" is a liberal use by Apple here
representing the actual host controller PCI device.

In any case, what matters is the "compatible" property. This is what
defines the programming interface of a device.
> I haven't found one that use this kind of addressing for pci-ata. 
> http://penguinppc.org/historical/dev-trees-html/g3bw_400.html for
> instance has pci@80000000/pci-bridge@d/pci-ata@1/ata-4. ata-2@600 kind
> of
> addressing is used by devices on mac-io bus which I do not think we
> emulate in qemu. So it looks like OpneBIOS is wrong here.

Well, it's possible that the @600 represents a register offset within
pci-ata, this is entirely up to pci-ata to do as it wishes there to
define it's own internal binding. Is there a "ranges" property defining
translation accross "pci-ata" ?

Cheers,
Ben.

[Qemu-devel] Re: [PATCHv8 00/16] boot order specification

[Benjamin Herrenschmidt]

> > > Ah the problem is that we have not qdevified mac io bus. Since first to
> > > ide disks are automatically attached to mac-io bus device paths for them
> > > are incorrect. Next two ide devices will be attached to CMD646 and qemu
> > > will generate correct device paths for them:
> > >
> > > qemu-system-ppc -drive if=none,id=hda,file=/dev/null -device ide-drive,drive=hda,bootindex=1
> > > -drive if=none,id=cd,file=/dev/null -device ide-drive,drive=cd,bootindex=0 -nographic -drive
> > > if=none,id=hdb,file=/dev/null -device ide-drive,drive=hdb,bus=ide.0,bootindex=2 -drive
> > > if=none,id=hdc,file=/dev/null -device ide-drive,drive=hdc,bus=ide.0,bootindex=3
> > > adding '/grackle@fec00000/ide@3/drive@1/disk@1' at index 0
> > > adding '/grackle@fec00000/ide@3/drive@1/disk@0' at index 1
> > > adding '/grackle@fec00000/ide@3/drive@0/disk@0' at index 2
> > > adding '/grackle@fec00000/ide@3/drive@0/disk@1' at index 3
> >
> > But why is the path almost the same as CMD646, shouldn't 'ide@3' be
> > different since the PCI device is not the same?
>
> It should, but since the mac io is not qdevified there is no qdev pci
> device for it.

Note that a better long term solution for all these is to have qemu
maintain the device-tree, using libfdt, and pass it to the firmware.

I have a port of SLOF that I can't release just yet (soon hopefully) on
top of another ppc "machine" for qemu that will also hopefully be soon
out there, but basically, what I do there is pass the FDT to SLOF, in
which I use forth code to expand it into a real OF device-tree.

Then, my SLOF code "populates" methods for known devices.

The only problem with that approach is the phandles. OpenBIOS/SLOF/OFW
will "assign" it's own phandle to nodes it creates, ignoring the
"phandle" properties created by libfdt.

That means that linkage within the device-tree will be potentially
broken accross the transition (ie, interrupt-parent, interrupt-map
etc... all contain phandle values to reference another node).

The way I get away with it right now is that I never use such linkage in
SLOF and I preserve the original "phandle" properties, which Linux will
then pickup and use instead of the SLOF "native" phandle when parsing
the tree.

A better long run option would be to have OF itself (whichever variant)
use some remapping on the phandles (instead of making them just
pointers) so it can create nodes with specific phandles.

Once you have your device-tree in qemu, everything looks simpler, you no
longer have to play guess work as to what the path will look like inside
the firmware. It also opens the door for passing bits of the device-tree
dynamically to the kernel for hotplug etc...

Cheers,
Ben.

[Qemu-devel] Re: [PATCHv8 00/16] boot order specification

[Andreas Färber]

Am 12.12.2010 um 00:22 schrieb Benjamin Herrenschmidt:
> On Sat, 2010-12-11 at 18:06 +0200, Gleb Natapov wrote:
> > http://playground.sun.com/pub/p1275/bindings/pci/pci2_1.pdf has table
> > on
> > page 10 that defines how pci class code should be translated into OF
> > name. This is what my patch is using. pci-ata does not look spec
> > compliant (or is there more up-to-date spec?)
> > >                                           What should we do
> >
> > with
> > > ata-2@600 vs drive@1?
> >
> > There is no available IDE OF binding spec, so I when with the way
> > OpenBIOS reports ata on qemu-x86. I have no idea what 600 in  
> > ata-2@600
> > may mean, but looking at g3_beige_300.html there is no such node  
> > there
> > and looking at any other device tree in
> > http://penguinppc.org/historical/dev-trees-html/
>
> Those are old and I wouldn't look too closely at what Apple does.

The only working system emulation we have are Macs (G3 beige, G4, G5),  
so we can't just ignore Apple.
Alex even made me stick to their odd 0x41 rtas-version property. ;)
> ATA doesn't really need anything complex, mostly the ata controller,
> generally named "ata" nowadays with a #address-cells of 1 and a
> #size-cells of 0. Children are then typically disk, cdrom, ... (ie  
> block
> devices) with a unit address of 0 for master and 1 for slave.
>
> In the case of controllers with multiple ports, typically you have one
> such "ata" node per bus. "pci-ata" is a liberal use by Apple here
> representing the actual host controller PCI device.
>
> In any case, what matters is the "compatible" property. This is what
> defines the programming interface of a device.
> > I haven't found one that use this kind of addressing for pci-ata.
> > http://penguinppc.org/historical/dev-trees-html/g3bw_400.html for
> > instance has pci@80000000/pci-bridge@d/pci-ata@1/ata-4. ata-2@600  
> > kind
> > of
> > addressing is used by devices on mac-io bus which I do not think we
> > emulate in qemu. So it looks like OpneBIOS is wrong here.
>
> Well, it's possible that the @600 represents a register offset within
> pci-ata, this is entirely up to pci-ata to do as it wishes there to
> define it's own internal binding. Is there a "ranges" property  
> defining
> translation accross "pci-ata" ?

No, but that may be OpenBIOS' fault. Here's its reg, in case it helps:

reg                       00001800 00000000 00000000   00000000 00000000
                          01001810 00000000 00000000   00000000 00000008
                          01001814 00000000 00000000   00000000 00000004
                          01001818 00000000 00000000   00000000 00000008
                          0100181c 00000000 00000000   00000000 00000004
                          01001820 00000000 00000000   00000000 00000010

Regards,
Andreas

[Qemu-devel] Re: [PATCHv8 00/16] boot order specification

[Benjamin Herrenschmidt]

> The only working system emulation we have are Macs (G3 beige, G4, G5),  
> so we can't just ignore Apple.
> Alex even made me stick to their odd 0x41 rtas-version property. ;)

Hah :-) Nothing ever used RTAS on these... afaik, it didn't even work
properly.
> No, but that may be OpenBIOS' fault. Here's its reg, in case it helps:
>
> reg                       00001800 00000000 00000000   00000000 00000000
>                           01001810 00000000 00000000   00000000 00000008
>                           01001814 00000000 00000000   00000000 00000004
>                           01001818 00000000 00000000   00000000 00000008
>                           0100181c 00000000 00000000   00000000 00000004
>                           01001820 00000000 00000000   00000000 00000010

That looks like PCI.... odd to keep a PCI addressing scheme below a PCI
device...

Cheers,
Ben.

[Qemu-devel] Re: [PATCHv8 00/16] boot order specification

[Tarl Neustaedter]

On 2010-12-14 3:31 PM, Benjamin Herrenschmidt wrote:
> > No, but that may be OpenBIOS' fault. Here's its reg, in case it helps:
> > > reg                       00001800 00000000 00000000   00000000 00000000
> > >                             01001810 00000000 00000000   00000000 00000008
> > >                             01001814 00000000 00000000   00000000 00000004
> > >                             01001818 00000000 00000000   00000000 00000008
> > >                             0100181c 00000000 00000000   00000000 00000004
> > >                             01001820 00000000 00000000   00000000 00000010
>
> That looks like PCI.... odd to keep a PCI addressing scheme below a PCI
> device...

That looks like the reg property for ide@3 - it's a pci child, so the 
addressing is in the pci bus. It looks like it has five BARs in IO space, each 
between 4 and 10 bytes long.

[Qemu-devel] Re: [PATCHv8 00/16] boot order specification

[Andreas Färber]

Am 14.12.2010 um 21:41 schrieb Tarl Neustaedter:
> On 2010-12-14 3:31 PM, Benjamin Herrenschmidt wrote:
> > > No, but that may be OpenBIOS' fault. Here's its reg, in case it  
> > > helps:
> > > > > reg                       00001800 00000000 00000000
> > >
> > > 00000000 00000000
> > > >                         01001810 00000000 00000000    
> > >
> > > 00000000 00000008
> > > >                         01001814 00000000 00000000    
> > >
> > > 00000000 00000004
> > > >                         01001818 00000000 00000000    
> > >
> > > 00000000 00000008
> > > >                         0100181c 00000000 00000000    
> > >
> > > 00000000 00000004
> > > >                         01001820 00000000 00000000    
> > >
> > > 00000000 00000010
> > > >
> >
> > That looks like PCI.... odd to keep a PCI addressing scheme below a  
> > PCI
> > device...
>
> That looks like the reg property for ide@3 - it's a pci child, so  
> the addressing is in the pci bus. It looks like it has five BARs in  
> IO space, each between 4 and 10 bytes long.

It was an excerpt from `dev /pci/pci-ata .properties` on `qemu-system- 
ppc -nographic -prom-env 'auto-boot?=false'`.

[Qemu-devel] Re: [PATCHv8 00/16] boot order specification

[Benjamin Herrenschmidt]

On Tue, 2010-12-14 at 22:34 +0100, Andreas Färber wrote:
> > That looks like the reg property for ide@3 - it's a pci child, so  
> > the addressing is in the pci bus. It looks like it has five BARs
>
> in
> > IO space, each between 4 and 10 bytes long.
>
> It was an excerpt from `dev /pci/pci-ata .properties` on
> `qemu-system- 
> ppc -nographic -prom-env 'auto-boot?=false'`.

Ah ok, that's fine then. I though you were looking at the children of
pci-ata.

On a real B&W G3 it looks like this:

compatible       "pci1095,646"
    	 "pci1095,646"
    	 "pciclass,01018f"
assigned-addresses 81010810 00000000 00001440 00000000 00000010
    	 81010814 00000000 00001430 00000000 00000010
    	 81010818 00000000 00001420 00000000 00000010
    	 8101081c 00000000 00001410 00000000 00000010
    	 81010820 00000000 00001400 00000000 00000010
#address-cells   00000001
fast-back-to-back
#size-cells      00000000
subsystem-id     00000646 (1606)
vendor-id        00001095 (4245)
device_type      "pci-ide"
min-grant        00000002
revision-id      00000005
subsystem-vendor-id 00001095 (4245)
name             "pci-ata"
max-latency      00000004
devsel-speed     00000001
device-id        00000646 (1606)
class-code       0001018f (65935)
reg              00010800 00000000 00000000 00000000 00000000 01010810
    	 00000000 00000000 00000000 00000010 01010814 00000000
    	 00000000 00000000 00000010 01010818 00000000 00000000
    	 00000000 00000010 0101081c 00000000 00000000 00000000
    	 00000010 01010820 00000000 00000000 00000000 00000010
interrupts       00000001
linux,phandle    ff873960

ata-4@0:
compatible       "cmd646-ata"
#address-cells   00000001
#size-cells      00000000
device_type      "ata"
name             "ata-4"
reg              00000000
linux,phandle    ff874828

Cheers,
Ben.

[Qemu-devel] Re: [PATCHv8 00/16] boot order specification

[Alexander Graf]

On 14.12.2010, at 21:31, Benjamin Herrenschmidt wrote:
> > The only working system emulation we have are Macs (G3 beige, G4, G5),  
> > so we can't just ignore Apple.
> > Alex even made me stick to their odd 0x41 rtas-version property. ;)
>
> Hah :-) Nothing ever used RTAS on these... afaik, it didn't even work
> properly.

Then let's not use rtas for the Mac machine, but rather go with Andreas' new machine. Changing the value there to what real FW uses on that machine is more than reasonable :)

Alex

[Qemu-devel] Re: [PATCHv8 00/16] boot order specification

[Andreas Färber]

Am 15.12.2010 um 00:02 schrieb Alexander Graf:
> On 14.12.2010, at 21:31, Benjamin Herrenschmidt wrote:
> > > The only working system emulation we have are Macs (G3 beige, G4,  
> > > G5),
> > > so we can't just ignore Apple.
> > > Alex even made me stick to their odd 0x41 rtas-version property. ;)
> >
> > Hah :-) Nothing ever used RTAS on these... afaik, it didn't even work
> > properly.
>
> Then let's not use rtas for the Mac machine, but rather go with  
> Andreas' new machine. Changing the value there to what real FW uses  
> on that machine is more than reasonable :)

The value is already conditional on is_apple(), so I don't think it  
needs changing.
I just mustn't forget to fix the old is_apple() {  return 1; }  
implementation for the new machines. :)

Andreas