January 2013 - OpenBIOS - mail.coreboot.org

testing Max OS X boot on latest trunk (revision 1080)
by Amadeusz Sławiński Feb. 28, 2013

Feb. 28, 2013

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

2 1

[PATCH] SPARC32 : microSPARC-II identification
by Olivier DANET Feb. 3, 2013

Feb. 3, 2013

For the microSPARC-II = Fujitsu MB86904 = Sun STP1012PGA, PSR.IMPL=0 and PSR.VERS=4 This CPU model is used as default by QEMU when emulating a SparcStation-4 or SparcStation-5 Signed-off-by: Olivier DANET <odanet(a)caramail.com> diff a/openbios-devel/arch/sparc32/openbios.c b/openbios-devel/arch/sparc32/openbios.c --- a/openbios-devel/arch/sparc32/openbios.c +++ b/openbios-devel/arch/sparc32/openbios.c @@ -244,9 +244,9 @@ static const struct cpudef sparc_defs[] .iu_version = 0x04 << 24, /* Impl 0, ver 4 */ .name = "FMI,MB86904", .psr_impl = 0, - .psr_vers = 5, + .psr_vers = 4, .impl = 0, - .vers = 5, + .vers = 4, .dcache_line_size = 0x10, .dcache_lines = 0x200, .dcache_assoc = 1,

2 1

Fix double nvram entry on newworld
by Amadeusz Sławiński Feb. 2, 2013

Feb. 2, 2013

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);

5 5

[commit] r1097 - trunk/openbios-devel/drivers
by repository service Jan. 31, 2013

Jan. 31, 2013

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);

1 0

Re: [OpenBIOS] Mac OS X panic - qemu fix
by Programmingkid Jan. 30, 2013

Jan. 30, 2013

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.

3 2

new world (qemu -mac99), double nvram entry
by Amadeusz Sławiński Jan. 29, 2013

Jan. 29, 2013

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>

2 1

Re: [OpenBIOS] G3Beige OpenFirmware Tree?
by Mark Cave-Ayland Jan. 27, 2013

Jan. 27, 2013

On 25/01/13 19:31, Blue Swirl wrote: > PenguinPPC used to have them online, but not anymore. Wayback Machine > still remembers: > http://web.archive.org/web/20090107130842/http://penguinppc.org/historical/… > > Other trees are also there: > http://web.archive.org/web/20081120133742/http://penguinppc.org/historical/… That's very useful. I'm tempted to archive these and put them somewhere on the wiki, as once these are gone it's going to be hard to find them again. Also - I notice in the link above that g3_beige_266 doesn't have a CMD646 controller? The g3_bw does though. ATB, Mark.

4 4

G3Beige OpenFirmware Tree?
by Mark Cave-Ayland Jan. 27, 2013

Jan. 27, 2013

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.

6 15

Re: [OpenBIOS] G3Beige OpenFirmware Tree?
by Mark Cave-Ayland Jan. 27, 2013

Jan. 27, 2013

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.

1 1

Re: [OpenBIOS] G3Beige OpenFirmware Tree?
by Mark Cave-Ayland Jan. 27, 2013

Jan. 27, 2013

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.

2 1