G3Beige OpenFirmware Tree?

[Mark Cave-Ayland]

Hi all,

Having spent a bit of time over the past week getting a bit further with 
booting the Darwin kernel, I'm now at the point where I can see that the 
reason the boot fails is because the CMD646ATA::start() method is 
failing in the driver here:

http://www.opensource.apple.com/source/CMD646ATA/CMD646ATA-1.0.6f1/CMD646ATA...

I suspect it's a strange interaction between the CMD646ATA and 
CMD646Root drivers, but I was wondering if anyone had a complete 
OpenFirmware tree output from a real G3 Beige machine so I can compare 
the various properties between the real device tree and the QEMU device 
tree? Google appears to be struggling with this one.

Many thanks,

Mark.

[Amadeusz Sławiński]

On Thu, Jan 24, 2013 at 12:02:07AM +0000, Mark Cave-Ayland wrote:
> Hi all,
>
> Having spent a bit of time over the past week getting a bit further with 
> booting the Darwin kernel, I'm now at the point where I can see that the 
> reason the boot fails is because the CMD646ATA::start() method is 
> failing in the driver here:
>
> http://www.opensource.apple.com/source/CMD646ATA/CMD646ATA-1.0.6f1/CMD646ATA...
>
> I suspect it's a strange interaction between the CMD646ATA and 
> CMD646Root drivers, but I was wondering if anyone had a complete 
> OpenFirmware tree output from a real G3 Beige machine so I can compare 
> the various properties between the real device tree and the QEMU device 
> tree? Google appears to be struggling with this one.

Not sure if it will be of any help, but I stumbled upon this one:
http://johannes.sipsolutions.net/PowerBook/openfirmware-device-tree
it's g4 powerbook

you probably need to boot it like:
qemu-system-ppc -bios openbios-qemu.elf -drive file=cd.img,media=cdrom,index=1,if=ide -g 800x600x32 -m 512 -boot order=d -prom-env "auto-boot?=false"

if you check
dev /aliases .properties
there should be ide1 which will be similar to
cd                      /pci@f2000000/mac-io@17/ata-3@20000/disk@0
from powerbook tree

boot ide1:,\:tbxi
there won't be one of failures related to ata-3 in debug output, however
it still seems to stop in almost the same way

Amadeusz

[Mark Cave-Ayland]

On 24/01/13 00:27, Amadeusz Sławiński wrote:
> Not sure if it will be of any help, but I stumbled upon this one:
> http://johannes.sipsolutions.net/PowerBook/openfirmware-device-tree
> it's g4 powerbook
>
> you probably need to boot it like:
> qemu-system-ppc -bios openbios-qemu.elf -drive file=cd.img,media=cdrom,index=1,if=ide -g 800x600x32 -m 512 -boot order=d -prom-env "auto-boot?=false"
>
> if you check
> dev /aliases .properties
> there should be ide1 which will be similar to
> cd                      /pci@f2000000/mac-io@17/ata-3@20000/disk@0
> from powerbook tree
>
> boot ide1:,\:tbxi
> there won't be one of failures related to ata-3 in debug output, however
> it still seems to stop in almost the same way

Yeah that doesn't have the Grackle PCI bridge on it which is what I'm 
trying to look at.

Interestingly enough I've now managed to get PearPC working, and that 
does manage to detect the CDROM during Darwin installation. So I'm 
having a look at the device tree there for clues.

One thing that is interesting is that PearPC has an extra PCI bridge 
between the PCI node and the CMD646 Controller, e.g.

/pci/pci-bridge/pci-ata/ata-4

compared to:

/pci/pci-ata/ata-1

I'm wondering what the actual device model in QEMU is, i.e. is it a 
problem with the PCI bridge being added directly to the PCI node by 
OpenBIOS as an accident during probing, or whether this is how QEMU 
actually models the hardware.

ATB,

Mark.

[Programmingkid]

On Jan 23, 2013, at 7:02 PM, Mark Cave-Ayland wrote:
> Hi all,
>
> Having spent a bit of time over the past week getting a bit further with booting the Darwin kernel, I'm now at the point where I can see that the reason the boot fails is because the CMD646ATA::start() method is failing in the driver here:
>
> http://www.opensource.apple.com/source/CMD646ATA/CMD646ATA-1.0.6f1/CMD646ATA...
>
> I suspect it's a strange interaction between the CMD646ATA and CMD646Root drivers, but I was wondering if anyone had a complete OpenFirmware tree output from a real G3 Beige machine so I can compare the various properties between the real device tree and the QEMU device tree? Google appears to be struggling with this one.

The closest I can give you is a G3 iMac. If you think it is good enough, I will send it to you.

[Mark Cave-Ayland]

On 24/01/13 02:31, Programmingkid wrote:
> The closest I can give you is a G3 iMac. If you think it is good enough, I will send it to you.

Possibly; I'm particularly looking for something which has the Grackle 
PCI host to CPU bridge so I can look at the related interrupt properties.

ATB,

Mark.

[Mark Morgan Lloyd]

Mark Cave-Ayland wrote:
> Hi all,
>
> Having spent a bit of time over the past week getting a bit further with 
> booting the Darwin kernel, I'm now at the point where I can see that the 
> reason the boot fails is because the CMD646ATA::start() method is 
> failing in the driver here:
>
> http://www.opensource.apple.com/source/CMD646ATA/CMD646ATA-1.0.6f1/CMD646ATA...
>
> I suspect it's a strange interaction between the CMD646ATA and 
> CMD646Root drivers, but I was wondering if anyone had a complete 
> OpenFirmware tree output from a real G3 Beige machine so I can compare 
> the various properties between the real device tree and the QEMU device 
> tree? Google appears to be struggling with this one.

I've got one of those machines, set up for OS and Linux (i.e. it's a bit 
fragile and I'd rather not try installing anything else on it). If that 
sounds useful tell me what to do.

[Mark Cave-Ayland]

On 24/01/13 09:27, Mark Morgan Lloyd wrote:
> I've got one of those machines, set up for OS and Linux (i.e. it's a bit
> fragile and I'd rather not try installing anything else on it). If that
> sounds useful tell me what to do.

Thanks! I think perhaps a tarball of /proc/device-tree from Linux is 
what I need? There may be a utility to dump the tree from OS X too, but 
I'm not exactly sure what it is.

Many thanks,

Mark.

[Mark Morgan Lloyd]

Mark Cave-Ayland wrote:
> On 24/01/13 09:27, Mark Morgan Lloyd wrote:
> > I've got one of those machines, set up for OS and Linux (i.e. it's a bit
> > fragile and I'd rather not try installing anything else on it). If that
> > sounds useful tell me what to do.
>
> Thanks! I think perhaps a tarball of /proc/device-tree from Linux is 
> what I need? There may be a utility to dump the tree from OS X too, but 
> I'm not exactly sure what it is.

My OS is 9 (I think), I only use it for transferring control to Linux. 
You have off-list mail created as below, note error messages of the type 
indicated:

0 2>root@pye-dev-05:/# tar -czf proc_device-tree.tar.gz /proc/device-tree
tar: Removing leading `/' from member names
tar: /proc/device-tree/perch: file changed as we read it
..

Let me know if there's anything else I can do to help.

[Mark Cave-Ayland]

On 25/01/13 09:48, Mark Morgan Lloyd wrote:
> > On 24/01/13 09:27, Mark Morgan Lloyd wrote:
> > > I've got one of those machines, set up for OS and Linux (i.e. it's a bit
> > > fragile and I'd rather not try installing anything else on it). If that
> > > sounds useful tell me what to do.
> >
> > Thanks! I think perhaps a tarball of /proc/device-tree from Linux is
> > what I need? There may be a utility to dump the tree from OS X too,
> > but I'm not exactly sure what it is.
>
> My OS is 9 (I think), I only use it for transferring control to Linux.
> You have off-list mail created as below, note error messages of the type
> indicated:
>
> 0 2>root@pye-dev-05:/# tar -czf proc_device-tree.tar.gz /proc/device-tree
> tar: Removing leading `/' from member names
> tar: /proc/device-tree/perch: file changed as we read it
> ..
>
> Let me know if there's anything else I can do to help.

Hi Mark,

Thanks for doing this. So I've had a play with PearPC and I can make the 
CMD646ATA fail during its start method similar to the way that QEMU does 
by commenting out the IDE interface IRQ entry from the "interrupt-map" 
property. This seems to support my theory that the problem is related to 
interrupt mapping.

Now AIUI g3beige is an "Old World" Mac and so the interrupt information 
should be held in the "AAPL,interrupts" property. I've verified that 
both QEMU and OpenBIOS calculate the irq_line in the same way (based 
upon device id), however I do see that some of the "AAPL,interrupts" 
values contain more than one integer. I wonder what this is supposed to 
represent?

ATB,

Mark.

[Mark Morgan Lloyd]

Mark Cave-Ayland wrote:
> On 25/01/13 09:48, Mark Morgan Lloyd wrote:
> > > On 24/01/13 09:27, Mark Morgan Lloyd wrote:
> > > > I've got one of those machines, set up for OS and Linux (i.e. it's a 
> > > > bit
> > > > fragile and I'd rather not try installing anything else on it). If that
> > > > sounds useful tell me what to do.
> > >
> > > Thanks! I think perhaps a tarball of /proc/device-tree from Linux is
> > > what I need? There may be a utility to dump the tree from OS X too,
> > > but I'm not exactly sure what it is.
> >
> > My OS is 9 (I think), I only use it for transferring control to Linux.
> > You have off-list mail created as below, note error messages of the type
> > indicated:
> >
> > 0 2>root@pye-dev-05:/# tar -czf proc_device-tree.tar.gz /proc/device-tree
> > tar: Removing leading `/' from member names
> > tar: /proc/device-tree/perch: file changed as we read it
> > ..
> >
> > Let me know if there's anything else I can do to help.
>
> Hi Mark,
>
> Thanks for doing this. So I've had a play with PearPC and I can make the 
> CMD646ATA fail during its start method similar to the way that QEMU does 
> by commenting out the IDE interface IRQ entry from the "interrupt-map" 
> property. This seems to support my theory that the problem is related to 
> interrupt mapping.
>
> Now AIUI g3beige is an "Old World" Mac and so the interrupt information 
> should be held in the "AAPL,interrupts" property. I've verified that 
> both QEMU and OpenBIOS calculate the irq_line in the same way (based 
> upon device id), however I do see that some of the "AAPL,interrupts" 
> values contain more than one integer. I wonder what this is supposed to 
> represent?

Not knowing, can't say :-)  I'm definitely not a Mac guru, I've only got 
it so I can check Free Pascal on Linux/PPC on occasion.

[Programmingkid]

On Jan 25, 2013, at 11:20 AM, Mark Cave-Ayland wrote:
> On 25/01/13 09:48, Mark Morgan Lloyd wrote:
> > > On 24/01/13 09:27, Mark Morgan Lloyd wrote:
> > > > I've got one of those machines, set up for OS and Linux (i.e. it's a bit
> > > > fragile and I'd rather not try installing anything else on it). If that
> > > > sounds useful tell me what to do.
> > >
> > > Thanks! I think perhaps a tarball of /proc/device-tree from Linux is
> > > what I need? There may be a utility to dump the tree from OS X too,
> > > but I'm not exactly sure what it is.
> >
> > My OS is 9 (I think), I only use it for transferring control to Linux.
> > You have off-list mail created as below, note error messages of the type
> > indicated:
> >
> > 0 2>root@pye-dev-05:/# tar -czf proc_device-tree.tar.gz /proc/device-tree
> > tar: Removing leading `/' from member names
> > tar: /proc/device-tree/perch: file changed as we read it
> > ..
> >
> > Let me know if there's anything else I can do to help.
>
> Hi Mark,
>
> Thanks for doing this. So I've had a play with PearPC and I can make the CMD646ATA fail during its start method similar to the way that QEMU does by commenting out the IDE interface IRQ entry from the "interrupt-map" property. This seems to support my theory that the problem is related to interrupt mapping.
>
> Now AIUI g3beige is an "Old World" Mac and so the interrupt information should be held in the "AAPL,interrupts" property. I've verified that both QEMU and OpenBIOS calculate the irq_line in the same way (based upon device id), however I do see that some of the "AAPL,interrupts" values contain more than one integer. I wonder what this is supposed to represent?
>
> ATB,
>
> Mark.

I just wanted to add that my Ubuntu Linux 5 CD also fails to boot because of a problem with the CMD646 controller. Here is the error message:

[c0149ee4] ide_pci_register_driver+0x54/0x5c
[f100e634] cmd64x_ide_init+0x18/0x28 [cmd64x]
       cmd64x: can't be loaded
missing kernel or user mode driver cmd64x

[Mark Cave-Ayland]

On 25/01/13 18:07, Programmingkid wrote:
> I just wanted to add that my Ubuntu Linux 5 CD also fails to boot because of a problem with the CMD646 controller. Here is the error message:
>
> [c0149ee4] ide_pci_register_driver+0x54/0x5c
> [f100e634] cmd64x_ide_init+0x18/0x28 [cmd64x]
>         cmd64x: can't be loaded
> missing kernel or user mode driver cmd64x

I've just downloaded ubuntu-5.10-live-powerpc.iso in order to recreate 
this, but all I can get is a black screen. Can you confirm both the ISO 
you are using and the QEMU options you are using?

ATB,

Mark.

[Mark Morgan Lloyd]

Mark Cave-Ayland wrote:
> On 25/01/13 18:07, Programmingkid wrote:
> > I just wanted to add that my Ubuntu Linux 5 CD also fails to boot 
> > because of a problem with the CMD646 controller. Here is the error 
> > message:
> >
> > [c0149ee4] ide_pci_register_driver+0x54/0x5c
> > [f100e634] cmd64x_ide_init+0x18/0x28 [cmd64x]
> >         cmd64x: can't be loaded
> > missing kernel or user mode driver cmd64x
>
> I've just downloaded ubuntu-5.10-live-powerpc.iso in order to recreate 
> this, but all I can get is a black screen. Can you confirm both the ISO 
> you are using and the QEMU options you are using?

I don't have a reference for this, but my recollection is that when I 
was setting this machine up I found it documented that the G3 firmware 
couldn't boot Linux directly, you had to start with OS and use the Bootx 
app.

[Programmingkid]

On Jan 26, 2013, at 12:33 PM, Mark Cave-Ayland wrote:
> On 25/01/13 18:07, Programmingkid wrote:
> > I just wanted to add that my Ubuntu Linux 5 CD also fails to boot because of a problem with the CMD646 controller. Here is the error message:
> >
> > [c0149ee4] ide_pci_register_driver+0x54/0x5c
> > [f100e634] cmd64x_ide_init+0x18/0x28 [cmd64x]
> >        cmd64x: can't be loaded
> > missing kernel or user mode driver cmd64x
>
> I've just downloaded ubuntu-5.10-live-powerpc.iso in order to recreate this, but all I can get is a black screen. Can you confirm both the ISO you are using and the QEMU options you are using?

I am actually using Ubuntu 5.04 (Hoardy Hedgehog).

http://old-releases.ubuntu.com/releases/hoary/

QEMU options:
qemu-system-ppc -bios obj-ppc/openbios-qemu.elf.nostrip -cdrom /dev/cdrom  -g 640x480x8 -m 1024 -serial stdio -boot d

[Artyom Tarasenko]

Hi Mark,

On Fri, Jan 25, 2013 at 5:20 PM, Mark Cave-Ayland
 wrote:
> On 25/01/13 09:48, Mark Morgan Lloyd wrote:
> > > On 24/01/13 09:27, Mark Morgan Lloyd wrote:
> > > > I've got one of those machines, set up for OS and Linux (i.e. it's a bit
> > > > fragile and I'd rather not try installing anything else on it). If that
> > > > sounds useful tell me what to do.
> > >
> > > Thanks! I think perhaps a tarball of /proc/device-tree from Linux is
> > > what I need? There may be a utility to dump the tree from OS X too,
> > > but I'm not exactly sure what it is.
> >
> > My OS is 9 (I think), I only use it for transferring control to Linux.
> > You have off-list mail created as below, note error messages of the type
> > indicated:
> >
> > 0 2>root@pye-dev-05:/# tar -czf proc_device-tree.tar.gz /proc/device-tree
> > tar: Removing leading `/' from member names
> > tar: /proc/device-tree/perch: file changed as we read it
> > ..
> >
> > Let me know if there's anything else I can do to help.
>
> Hi Mark,
>
> Thanks for doing this. So I've had a play with PearPC and I can make the
> CMD646ATA fail during its start method similar to the way that QEMU does by
> commenting out the IDE interface IRQ entry from the "interrupt-map"
> property. This seems to support my theory that the problem is related to
> interrupt mapping.

Looks very similar to sparc64/sun4u problems I struggled ~ a half a year ago.
> Now AIUI g3beige is an "Old World" Mac and so the interrupt information
> should be held in the "AAPL,interrupts" property. I've verified that both
> QEMU and OpenBIOS calculate the irq_line in the same way (based upon device
> id), however I do see that some of the "AAPL,interrupts" values contain more
> than one integer. I wonder what this is supposed to represent?

Could it be that the irq line is wired to the interrupt controller not
as a PCI irq line? Similarly to the sun4u machines?
Have you looked in the Linux/PPC  cmd646 driver for the insights?

Artyom

[Blue Swirl]

On Thu, Jan 24, 2013 at 12:02 AM, Mark Cave-Ayland
 wrote:
> Hi all,
>
> Having spent a bit of time over the past week getting a bit further with
> booting the Darwin kernel, I'm now at the point where I can see that the
> reason the boot fails is because the CMD646ATA::start() method is failing in
> the driver here:
>
> http://www.opensource.apple.com/source/CMD646ATA/CMD646ATA-1.0.6f1/CMD646ATA...
>
> I suspect it's a strange interaction between the CMD646ATA and CMD646Root
> drivers, but I was wondering if anyone had a complete OpenFirmware tree
> output from a real G3 Beige machine so I can compare the various properties
> between the real device tree and the QEMU device tree? Google appears to be
> struggling with this one.

PenguinPPC used to have them online, but not anymore. Wayback Machine
still remembers:
http://web.archive.org/web/20090107130842/http://penguinppc.org/historical/d...

Other trees are also there:
http://web.archive.org/web/20081120133742/http://penguinppc.org/historical/d...
> Many thanks,
>
> Mark.