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

Gleb Natapov gleb at redhat.com
Sat Dec 11 19:02:23 CET 2010


On Sat, Dec 11, 2010 at 05:19:01PM +0000, Blue Swirl wrote:
> >>                                                 What should we do with
> >> ata-2 at 600 vs drive at 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 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 pci at 80000000/pci-bridge at d/pci-ata at 1/ata-4. ata-2 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
> /pci at 80000000/pci-bridge at d/pci-ata at 1/ata-4/disk and
> /pci at 80000000/pci-bridge at d/pci-ata at 1/ata-4/disk at 1:
> http://penguinppc.org/historical/dev-trees-html/g4_pci_350.html
You are saying that qemu creates paths like:
/grackle at fec00000/ide at 3/drive at 1/disk at 0
/grackle at fec00000/ide at 3/drive at 1/disk at 1

I do not understand why qemu creates node drive at 1. It should be drive at 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.



More information about the OpenBIOS mailing list