On Wed, Dec 8, 2010 at 11:34 AM, Gleb Natapov gleb@redhat.com 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?
On Sat, Dec 11, 2010 at 03:13:35PM +0000, Blue Swirl wrote:
On Wed, Dec 8, 2010 at 11:34 AM, Gleb Natapov gleb@redhat.com 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 withata-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.
-- Gleb.
On Sat, Dec 11, 2010 at 4:06 PM, Gleb Natapov gleb@redhat.com 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 gleb@redhat.com 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
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.
-- Gleb.
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.
-- Gleb.
2010/12/11 Gleb Natapov gleb@redhat.com:
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.
On Sat, Dec 11, 2010 at 07:06:04PM +0000, Blue Swirl wrote:
2010/12/11 Gleb Natapov gleb@redhat.com:
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.
-- Gleb.
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.
2010/12/11 Gleb Natapov gleb@redhat.com:
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.
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 dowith
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.
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 dowith
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
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.
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.
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 0000000000000000 00000008
01001814 00000000 0000000000000000 00000004
01001818 00000000 0000000000000000 00000008
0100181c 00000000 0000000000000000 00000004
01001820 00000000 0000000000000000 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'`.
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.
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
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
-
Alexander Graf -
Andreas Färber -
Benjamin Herrenschmidt -
Blue Swirl -
Gleb Natapov -
Tarl Neustaedter