On Sat, Dec 11, 2010 at 05:19:01PM +0000, Blue Swirl wrote: > >> What should we do with > >> at...@600 vs dr...@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 at...@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 p...@80000000/pci-bri...@d/pci-...@1/ata-4. at...@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 > /p...@80000000/pci-bri...@d/pci-...@1/ata-4/disk and > /p...@80000000/pci-bri...@d/pci-...@1/ata-4/d...@1: > http://penguinppc.org/historical/dev-trees-html/g4_pci_350.html You are saying that qemu creates paths like: /grac...@fec00000/i...@3/dr...@1/d...@0 /grac...@fec00000/i...@3/dr...@1/d...@1 I do not understand why qemu creates node dr...@1. It should be dr...@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.
