Here are results of my testing booting OS X on latest trunk
Logs in attachment
Not patched ones (fails without get-key-map):
10.0.log
10.2.log
10.4.log
Patched with gsoc get-key-map patch:
10.0-gkm.log
10.2-gkm-panic.log
10.4-gkm.log
Patched with gsoc divide by 0:
10.2-gkm-dvb0.log
Logs from patched boot without CIF:
all-without-cif.log
10.2 ones show that there is need for some solution regarding division
by 0, some notes from my talks with Mark:
My g5 machine returns 0 when dividing by 0, no warnings are printed:
0 > 0 0 / ok
1 > . ok
0 > 0
0 > 2 0 / ok
1 > . ok
0 > 0
Question is how to implement it, or maybe just use gsoc patch?
Also it seems that Mac OS X seems to provide it's own fill-rectangle and draw-rectangle
it prints:
FILL-RECTANGLE isn't unique.
and also similar message when I apply gsoc draw-rectangle patch
so it seems that this one isn't needed
Another problem is that it seems to be unable to open/load kernel.
On graphic side of things it seems to draw things better than with gsoc
patches, graphics are not weirdly resized, but there is not much to see
except boot folder graphic (10.0)/white apple(10.2, 10.4).
Amadeusz
Fix double nvram entry on newworld
There are two nvram entries on newworld (for example qemu -M mac99)
The first one (nvram@fff04000) has initialized .properties while the
other one has words.
0 > dev / ls
...
fff75e24 pci@f2000000
fff77848 nvram@fff04000
fff778e0 nvram
ok
0 > dev /nvram@fff04000 ok
0 > words
ok
0 > .properties
name "nvram"
#bytes 2000
reg fff04000 00004000
device_type "nvram"
compatible "nvram,flash"
ok
0 > dev /nvram@0 ok
0 > words close open seek write read size
ok
0 > .properties
name "nvram"
ok
This patch fixes initialization, so only one node is created
containing both .properties and words.
0 > dev / ls
...
fff75e24 pci@f2000000
fff77868 nvram@fff04000
ok
0 > dev /nvram@fff04000 ok
0 > words close open seek write read size
ok
0 > .properties
name "nvram"
#bytes 2000
reg fff04000 00004000
device_type "nvram"
compatible "nvram,flash"
ok
Signed-off-by: Amadeusz Sławiński <amade(a)asmblr.net>
diff -uNr a/drivers/macio.c b/drivers/macio.c
--- a/drivers/macio.c 2013-01-28 12:16:54.849868216 +0100
+++ b/drivers/macio.c 2013-01-28 12:17:27.595867493 +0100
@@ -57,12 +57,6 @@
} else {
nvram_offset = NW_IO_NVRAM_OFFSET;
nvram_size = NW_IO_NVRAM_SIZE;
- push_str("/");
- fword("find-device");
- fword("new-device");
- push_str("nvram");
- fword("device-name");
- fword("finish-device");
}
nvram = (char*)addr + nvram_offset;
snprintf(buf, sizeof(buf), "%s/nvram", path);
Author: mcayland
Date: Thu Jan 31 22:37:13 2013
New Revision: 1097
URL: http://tracker.coreboot.org/trac/openbios/changeset/1097
Log:
macio.c: Fix double nvram entry on newworld
There are two nvram entries on newworld (for example qemu -M mac99)
The first one (nvram@fff04000) has initialized .properties while the
other one has words.
0 > dev / ls
...
fff75e24 pci@f2000000
fff77848 nvram@fff04000
fff778e0 nvram
ok
0 > dev /nvram@fff04000 ok
0 > words
ok
0 > .properties
name "nvram"
reg fff04000 00004000
device_type "nvram"
compatible "nvram,flash"
ok
0 > dev /nvram@0 ok
0 > words close open seek write read size
ok
0 > .properties
name "nvram"
ok
This patch fixes initialization, so only one node is created
containing both .properties and words.
0 > dev / ls
...
fff75e24 pci@f2000000
fff77868 nvram@fff04000
ok
0 > dev /nvram@fff04000 ok
0 > words close open seek write read size
ok
0 > .properties
name "nvram"
reg fff04000 00004000
device_type "nvram"
compatible "nvram,flash"
ok
Signed-off-by: Amadeusz Sławiński <amade(a)asmblr.net>
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk>
Modified:
trunk/openbios-devel/drivers/macio.c
Modified: trunk/openbios-devel/drivers/macio.c
==============================================================================
--- trunk/openbios-devel/drivers/macio.c Sat Jan 26 13:50:15 2013 (r1096)
+++ trunk/openbios-devel/drivers/macio.c Thu Jan 31 22:37:13 2013 (r1097)
@@ -57,12 +57,6 @@
} else {
nvram_offset = NW_IO_NVRAM_OFFSET;
nvram_size = NW_IO_NVRAM_SIZE;
- push_str("/");
- fword("find-device");
- fword("new-device");
- push_str("nvram");
- fword("device-name");
- fword("finish-device");
}
nvram = (char*)addr + nvram_offset;
snprintf(buf, sizeof(buf), "%s/nvram", path);
On Jan 29, 2013, at 9:25 AM, Amadeusz Sławiński wrote:
> Hey, you may want to try this patch against qemu
> https://lists.nongnu.org/archive/html/qemu-ppc/2013-01/msg00392.html
> it fixes, some of panics I have seen when trying to boot darwin/OS X
>
> On normal (not mac99) qemu machine, I was able to get to "Waiting for
> root device" on darwinppc, OS X 10.2, OS X 10.4
I also see waiting for root device on Mac OS 10.2. Mac OS 10.0 has a kernel panic. Excellent job. This patch is a step in the right direction.
Too bad this patch comes a day after QEMU 1.3.1 is released. Hopefully it will be included in the next release.
Does anyone know what is wrong with the Mac99 target? I think it has the potential of being a better target than an emulated Beige G3.
When looking at qemu -mac99 I noticed that there are two nvram entries in openbios:
The first one (nvram@fff04000) has initialized .properties while the
other one has words.
0 > dev / ls
...
fff75e24 pci@f2000000
fff77848 nvram@fff04000
fff778e0 nvram
ok
0 > dev /nvram@fff04000 ok
0 > words
ok
0 > .properties
name "nvram"
#bytes 2000
reg fff04000 00004000
device_type "nvram"
compatible "nvram,flash"
ok
0 > dev /nvram@0 ok
0 > words close open seek write read size
ok
0 > .properties
name "nvram"
ok
Attached patch fixes initialization, so only one node is created
containing both .properties and words.
0 > dev / ls
...
fff75e24 pci@f2000000
fff77868 nvram@fff04000
ok
0 > dev /nvram@fff04000 ok
0 > words close open seek write read size
ok
0 > .properties
name "nvram"
#bytes 2000
reg fff04000 00004000
device_type "nvram"
compatible "nvram,flash"
ok
Signed-off-by: Amadeusz Sławiński <amade(a)asmblr.net>
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/CMD646AT…
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.
On 25/01/13 21:50, Artyom Tarasenko wrote:
> A comment in FreeBSD ofw_pcibus.c says:
>
> /*
> * Any AAPL,interrupts property gets priority and is
> * fully specified (i.e. does not need routing)
> */
>
> https://github.com/oza/FreeBSD-8.0-dyntick/blob/master/sys/powerpc/ofw/ofw_…
>
> Could it be that multiple entries in the AAPL,interrupts properties
> mean that the corresponding device has multiple interrupt lines?
Interesting. My last thought was that if you are behind a PCI bridge
then the first interrupt line may be that of the bridge device?
I've also noticed that the mac-io IDE driver also fails in its start
method, so I'm wondering if this something more generic related to the
IDE layer which isn't quite right in OpenBIOS?
I might try and see if I can install some kind of XCOFF gdb and take a
look to see if I can work out from stepping through the function exactly
which part is failing.
ATB,
Mark.
On 26/01/13 22:14, Artyom Tarasenko wrote:
> At least something. I haven't looked into the qemu-ppc implementation of cmd646,
> does it support DMA? (qemu-sparc64 doesn't ant that's the reason why
> Linux cmd646 driver fails).
That's a good point. I see there are functions in QEMU's hw/ide/cmd646.c
called bmdma_read() and bmdma_write() which would suggest that DMA is
supported?
ATB,
Mark.
