Hi folks,
I've been trying to use OpenBIOS with QEMU, and I've had trouble getting it to boot any PowerPC-based OS discs (Linux, Mac OS X, etc). OpenBIOS just doesn't seem to find anything bootable. If I try booting QEMU with -nographic, I get this output (I get the same with a self-built openbios-qemu.elf from the OpenBIOS SVN as well):
---- snip ----
============================================================= OpenBIOS 1.0 [Apr 12 2009 00:55] Configuration device id QEMU version 1 machine id 1 CPUs: 1 Memory: 128M UUID: 00000000-0000-0000-0000-000000000000 CPU type PowerPC,970FX
Welcome to OpenBIOS v1.0 built on Apr 12 2009 00:55
ELF - yaboot_startup: Entering boot, no path ELF - try_bootinfo: Trying hd:0,ppc\bootinfo.txt ELF - try_bootinfo: Can't open hd:0,ppc\bootinfo.txt ELF - try_path: Trying hd:2,\ofclient ELF - try_path: Can't open hd:2,\ofclient ELF - try_path: Trying hd:2,\yaboot conf=hd:2,\yaboot.conf ELF - try_path: Can't open hd:2,\yaboot *** Boot failure! No secondary bootloader specified ***
---- snip ----
Laurent Vivier suggested in this conversation in February (http://lists.openbios.org/pipermail/openbios/2009-February/003476.html) that there could be a bug in partition map decoding. Has such a bug been confirmed? I was trying to find the bug myself (I am an experienced C/C++ programmer), but the bug seems to be subtle, and my lack of familiarity with the code base doesn't help much.
I've been trying to figure this out for 7 hours straight now... Any advice or other help would be much appreciated!
- Steven
Le samedi 11 avril 2009 à 18:06 -0700, Steven Noonan a écrit :
Hi folks,
Hi
I've been trying to use OpenBIOS with QEMU, and I've had trouble getting it to boot any PowerPC-based OS discs (Linux, Mac OS X, etc). OpenBIOS just doesn't seem to find anything bootable. If I try booting QEMU with -nographic, I get this output (I get the same with a self-built openbios-qemu.elf from the OpenBIOS SVN as well):
OpenBIOS is not able to boot MacOS X. To boot a linux CDROM type "boot cd:" at prompt.
---- snip ----
============================================================= OpenBIOS 1.0 [Apr 12 2009 00:55] Configuration device id QEMU version 1 machine id 1 CPUs: 1 Memory: 128M UUID: 00000000-0000-0000-0000-000000000000 CPU type PowerPC,970FX
Welcome to OpenBIOS v1.0 built on Apr 12 2009 00:55
ELF - yaboot_startup: Entering boot, no path ELF - try_bootinfo: Trying hd:0,ppc\bootinfo.txt ELF - try_bootinfo: Can't open hd:0,ppc\bootinfo.txt ELF - try_path: Trying hd:2,\ofclient ELF - try_path: Can't open hd:2,\ofclient ELF - try_path: Trying hd:2,\yaboot conf=hd:2,\yaboot.conf ELF - try_path: Can't open hd:2,\yaboot *** Boot failure! No secondary bootloader specified ***
---- snip ----
Laurent Vivier suggested in this conversation in February (http://lists.openbios.org/pipermail/openbios/2009-February/003476.html) that there could be a bug in partition map decoding. Has such a bug been confirmed? I was trying to find the bug myself (I am an
I've tried to correct this but it introduces new problems.
experienced C/C++ programmer), but the bug seems to be subtle, and my lack of familiarity with the code base doesn't help much.
I've been trying to figure this out for 7 hours straight now... Any advice or other help would be much appreciated!
Regards, Laurent
On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier Laurent@lvivier.info wrote:
Le samedi 11 avril 2009 à 18:06 -0700, Steven Noonan a écrit :
Hi folks,
Hi
I've been trying to use OpenBIOS with QEMU, and I've had trouble getting it to boot any PowerPC-based OS discs (Linux, Mac OS X, etc). OpenBIOS just doesn't seem to find anything bootable. If I try booting QEMU with -nographic, I get this output (I get the same with a self-built openbios-qemu.elf from the OpenBIOS SVN as well):
OpenBIOS is not able to boot MacOS X.
Well, that's a silly limitation. Is there a reason this isn't implemented? I see that the Mac-on-Linux OpenBIOS version has such support, so it seems strange that the QEMU version does not.
To boot a linux CDROM type "boot cd:" at prompt.
---- snip ----
============================================================= OpenBIOS 1.0 [Apr 12 2009 00:55] Configuration device id QEMU version 1 machine id 1 CPUs: 1 Memory: 128M UUID: 00000000-0000-0000-0000-000000000000 CPU type PowerPC,970FX
Welcome to OpenBIOS v1.0 built on Apr 12 2009 00:55
ELF - yaboot_startup: Entering boot, no path ELF - try_bootinfo: Trying hd:0,ppc\bootinfo.txt ELF - try_bootinfo: Can't open hd:0,ppc\bootinfo.txt ELF - try_path: Trying hd:2,\ofclient ELF - try_path: Can't open hd:2,\ofclient ELF - try_path: Trying hd:2,\yaboot conf=hd:2,\yaboot.conf ELF - try_path: Can't open hd:2,\yaboot *** Boot failure! No secondary bootloader specified ***
---- snip ----
Laurent Vivier suggested in this conversation in February (http://lists.openbios.org/pipermail/openbios/2009-February/003476.html) that there could be a bug in partition map decoding. Has such a bug been confirmed? I was trying to find the bug myself (I am an
I've tried to correct this but it introduces new problems.
experienced C/C++ programmer), but the bug seems to be subtle, and my lack of familiarity with the code base doesn't help much.
I've been trying to figure this out for 7 hours straight now... Any advice or other help would be much appreciated!
Regards, Laurent
On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan steven@uplinklabs.net wrote:
On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier Laurent@lvivier.info wrote:
OpenBIOS is not able to boot MacOS X.
Well, that's a silly limitation. Is there a reason this isn't implemented? I see that the Mac-on-Linux OpenBIOS version has such support, so it seems strange that the QEMU version does not.
I don't know if anyone here is actually interested (this list seems -very- quiet), but...
I've been hacking at OpenBIOS for a bit, and I got it to properly read Mac OS X discs (it kept failing because it would hit an Apple Partition Map header instead of an HFS+ filesystem header). I'm working on adding an XCOFF loader, too, so it should be able to boot Mac OS X soon.
Any chances I could get these changes merged to the main OpenBIOS tree once they're done?
My current working repository is at http://github.com/tycho/openbios. I'm working on the macosx-boot branch. The relevant commit is here (patch also attached): http://github.com/tycho/openbios/commit/4722c8a01d186a08183de49759dc8b7b74cf...
Thoughts?
- Steven
Am 19.04.2009 um 09:50 schrieb Steven Noonan:
On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan steven@uplinklabs.net wrote:
On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier Laurent@lvivier.info wrote:
OpenBIOS is not able to boot MacOS X.
Well, that's a silly limitation. Is there a reason this isn't implemented? I see that the Mac-on-Linux OpenBIOS version has such support, so it seems strange that the QEMU version does not.
I don't know if anyone here is actually interested (this list seems -very- quiet), but...
I've been hacking at OpenBIOS for a bit, and I got it to properly read Mac OS X discs (it kept failing because it would hit an Apple Partition Map header instead of an HFS+ filesystem header). I'm working on adding an XCOFF loader, too, so it should be able to boot Mac OS X soon.
Any chances I could get these changes merged to the main OpenBIOS tree once they're done?
My current working repository is at http://github.com/tycho/openbios. I'm working on the macosx-boot branch. The relevant commit is here (patch also attached): http://github.com/tycho/openbios/commit/4722c8a01d186a08183de49759dc8b7b74cf...
Thoughts?
Your work surely sounds interesting. However, making OpenBIOS boot from the disks is not everything there is to it. Alexander Graf had once posted a series of patches for making Mac OS X boot in QEMU, including changes/additions to device emulation. They were not merged, not sure about the status today.
One issue iirc was that you need to obtain some Apple ID from a real Mac of yours and pass that to QEMU for it to work.
Andreas
On Sun, Apr 19, 2009 at 1:03 AM, Andreas Färber andreas.faerber@web.de wrote:
Am 19.04.2009 um 09:50 schrieb Steven Noonan:
On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan steven@uplinklabs.net wrote:
On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier Laurent@lvivier.info wrote:
OpenBIOS is not able to boot MacOS X.
Well, that's a silly limitation. Is there a reason this isn't implemented? I see that the Mac-on-Linux OpenBIOS version has such support, so it seems strange that the QEMU version does not.
I don't know if anyone here is actually interested (this list seems -very- quiet), but...
I've been hacking at OpenBIOS for a bit, and I got it to properly read Mac OS X discs (it kept failing because it would hit an Apple Partition Map header instead of an HFS+ filesystem header). I'm working on adding an XCOFF loader, too, so it should be able to boot Mac OS X soon.
Any chances I could get these changes merged to the main OpenBIOS tree once they're done?
My current working repository is at http://github.com/tycho/openbios. I'm working on the macosx-boot branch. The relevant commit is here (patch also attached):
http://github.com/tycho/openbios/commit/4722c8a01d186a08183de49759dc8b7b74cf...
Thoughts?
Your work surely sounds interesting. However, making OpenBIOS boot from the disks is not everything there is to it. Alexander Graf had once posted a series of patches for making Mac OS X boot in QEMU, including changes/additions to device emulation. They were not merged, not sure about the status today.
One issue iirc was that you need to obtain some Apple ID from a real Mac of yours and pass that to QEMU for it to work.
Ah, thanks for that tip. I was completely oblivious to his work. But from the looks of it, his work is x86-oriented. My intent was to get the PowerPC version of Mac OS X running, which will probably be a bit easier, particularly since QEMU already emulates the appropriate hardware (g3bw, mac99). It's just a matter of getting OpenBIOS to boot it, I think.
I was originally hacking PearPC into working order, and was going to optimize it, but PearPC's code base is an absolute mess. It contains a ridiculous number of horrible hacks, a very disorganized tree, and it's slower than glacial movement. I eventually decided it made more sense to get QEMU working instead. I did notice that the pre-OpenBIOS version of QEMU was able to boot Mac OS X via Open Hack'Ware, so I was annoyed to find that OpenBIOS didn't have such support. So, I might as well add it.
Am 19.04.2009 um 10:28 schrieb Steven Noonan:
On Sun, Apr 19, 2009 at 1:03 AM, Andreas Färber <andreas.faerber@web.de
wrote:
Am 19.04.2009 um 09:50 schrieb Steven Noonan:
On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan <steven@uplinklabs.net
wrote:
On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier <Laurent@lvivier.info
wrote:
OpenBIOS is not able to boot MacOS X.
Well, that's a silly limitation. Is there a reason this isn't implemented? I see that the Mac-on-Linux OpenBIOS version has such support, so it seems strange that the QEMU version does not.
I don't know if anyone here is actually interested (this list seems -very- quiet), but...
I've been hacking at OpenBIOS for a bit, and I got it to properly read Mac OS X discs (it kept failing because it would hit an Apple Partition Map header instead of an HFS+ filesystem header). I'm working on adding an XCOFF loader, too, so it should be able to boot Mac OS X soon.
Any chances I could get these changes merged to the main OpenBIOS tree once they're done?
My current working repository is at http://github.com/tycho/ openbios. I'm working on the macosx-boot branch. The relevant commit is here (patch also attached):
http://github.com/tycho/openbios/commit/4722c8a01d186a08183de49759dc8b7b74cf...
Thoughts?
Your work surely sounds interesting. However, making OpenBIOS boot from the disks is not everything there is to it. Alexander Graf had once posted a series of patches for making Mac OS X boot in QEMU, including changes/additions to device emulation. They were not merged, not sure about the status today.
One issue iirc was that you need to obtain some Apple ID from a real Mac of yours and pass that to QEMU for it to work.
Ah, thanks for that tip. I was completely oblivious to his work. But from the looks of it, his work is x86-oriented. My intent was to get the PowerPC version of Mac OS X running, which will probably be a bit easier, particularly since QEMU already emulates the appropriate hardware (g3bw, mac99). It's just a matter of getting OpenBIOS to boot it, I think.
Wasn't there a recent revert from g3bw to g3beige machine emulation due to not fully supported devices? Might raise some issues with Leopard, Tiger may work better.
Andreas
In message: f488382f0904190128l4383a56eu67a2f16eb338e61c@mail.gmail.com Steven Noonan steven@uplinklabs.net writes: : I eventually decided it made more : sense to get QEMU working instead. I did notice that the pre-OpenBIOS : version of QEMU was able to boot Mac OS X via Open Hack'Ware, so I was : annoyed to find that OpenBIOS didn't have such support. So, I might as : well add it.
Open Hackware was barely enough to boot older versions of Linux. Other operating systems that needed more extensive properties from the OpenFirmware device tree failed to boot because they weren't present. I was involved in a large effort to get FreeBSD/powerpc booting on QEMU only to have it fail utterly because the amount of hacking on OpenHackWare needed was rather large and mysterious...
Warner
On Sun, Apr 19, 2009 at 10:47 AM, M. Warner Losh imp@bsdimp.com wrote:
In message: f488382f0904190128l4383a56eu67a2f16eb338e61c@mail.gmail.com Steven Noonan steven@uplinklabs.net writes: : I eventually decided it made more : sense to get QEMU working instead. I did notice that the pre-OpenBIOS : version of QEMU was able to boot Mac OS X via Open Hack'Ware, so I was : annoyed to find that OpenBIOS didn't have such support. So, I might as : well add it.
Open Hackware was barely enough to boot older versions of Linux. Other operating systems that needed more extensive properties from the OpenFirmware device tree failed to boot because they weren't present. I was involved in a large effort to get FreeBSD/powerpc booting on QEMU only to have it fail utterly because the amount of hacking on OpenHackWare needed was rather large and mysterious...
Yes, Open Hack'Ware is as much a hack as PearPC is, in my opinion. It uses very strange design decisions, which I suppose were inspired by an "I'll do this later" attitude. For instance, in the CHRP script 'parser' it has, it will do a CRC of the boot script and then do a table lookup to figure out what to do next, i.e.:
case 0xEA06C1A7: /* MacOS 9.2 boot script: * the XCOFF loader is embedded in the file... */ case 0x53A95958: /* iBook 2 restore CD (MacOS X 10.2) */ [snip] goto out; case 0x8d5acb86: /* Darwin-7.01 * The executable file is embedded after the script */ break;
Quite clearly, Open Hack'Ware was aptly named. It seems to have made no effort to actually -execute- the CHRP boot-script, and instead just do whatever would be necessary to get specific OSes working. Blech.
- Steven
On 4/19/09, M. Warner Losh imp@bsdimp.com wrote:
In message: f488382f0904190128l4383a56eu67a2f16eb338e61c@mail.gmail.com
Steven Noonan <steven@uplinklabs.net> writes:: I eventually decided it made more : sense to get QEMU working instead. I did notice that the pre-OpenBIOS : version of QEMU was able to boot Mac OS X via Open Hack'Ware, so I was : annoyed to find that OpenBIOS didn't have such support. So, I might as : well add it.
Open Hackware was barely enough to boot older versions of Linux. Other operating systems that needed more extensive properties from the OpenFirmware device tree failed to boot because they weren't present. I was involved in a large effort to get FreeBSD/powerpc booting on QEMU only to have it fail utterly because the amount of hacking on OpenHackWare needed was rather large and mysterious...
This is what I get with OpenBIOS:
*** Boot failure! No secondary bootloader specified ***
0 > boot cd:,\boot\loader cd:0 Consoles: Open Firmware console
FreeBSD/Open Firmware/PowerPC bootstrap loader, Revision 0.1 (root@xserve.lan.xcllnt.net, Thu Apr 16 18:47:58 UTC 2009) Memory: 131072KB Booted from: cd
Loading /boot/defaults/loader.conf /boot/kernel/kernel data=0x4a4ce0+0x3d4e4 syms=[0x4+0x454f0+0x4+0x5a4b9] / Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Kernel entry at 0x13dac0 ... panic: moea_bootstrap: no space to copy translations Uptime: 1s
In message: f43fc5580904191144y1fd8e4d6m3321855d0c558250@mail.gmail.com Blue Swirl blauwirbel@gmail.com writes: : On 4/19/09, M. Warner Losh imp@bsdimp.com wrote: : > In message: f488382f0904190128l4383a56eu67a2f16eb338e61c@mail.gmail.com : > : > Steven Noonan steven@uplinklabs.net writes: : > : I eventually decided it made more : > : sense to get QEMU working instead. I did notice that the pre-OpenBIOS : > : version of QEMU was able to boot Mac OS X via Open Hack'Ware, so I was : > : annoyed to find that OpenBIOS didn't have such support. So, I might as : > : well add it. : > : > : > Open Hackware was barely enough to boot older versions of Linux. : > Other operating systems that needed more extensive properties from the : > OpenFirmware device tree failed to boot because they weren't present. : > I was involved in a large effort to get FreeBSD/powerpc booting on : > QEMU only to have it fail utterly because the amount of hacking on : > OpenHackWare needed was rather large and mysterious... : : This is what I get with OpenBIOS: : >> *** Boot failure! No secondary bootloader specified *** : : 0 > boot cd:,\boot\loader cd:0 : Consoles: Open Firmware console : : FreeBSD/Open Firmware/PowerPC bootstrap loader, Revision 0.1 : (root@xserve.lan.xcllnt.net, Thu Apr 16 18:47:58 UTC 2009) : Memory: 131072KB : Booted from: cd : : Loading /boot/defaults/loader.conf : /boot/kernel/kernel data=0x4a4ce0+0x3d4e4 syms=[0x4+0x454f0+0x4+0x5a4b9] : / : Hit [Enter] to boot immediately, or any other key for command prompt. : Booting [/boot/kernel/kernel]... : Kernel entry at 0x13dac0 ... : panic: moea_bootstrap: no space to copy translations : Uptime: 1s
That's similar to the one that I've seen as well. The problem with this one, IIRC, is that FreeBSD/powerpc is trying to setup the memory translations for the MMU and the 'translations' property length is zero, or something like that...
Warner
On 4/20/09, M. Warner Losh imp@bsdimp.com wrote:
In message: f43fc5580904191144y1fd8e4d6m3321855d0c558250@mail.gmail.com Blue Swirl blauwirbel@gmail.com writes:
: On 4/19/09, M. Warner Losh imp@bsdimp.com wrote: : > In message: f488382f0904190128l4383a56eu67a2f16eb338e61c@mail.gmail.com : > : > Steven Noonan steven@uplinklabs.net writes: : > : I eventually decided it made more : > : sense to get QEMU working instead. I did notice that the pre-OpenBIOS : > : version of QEMU was able to boot Mac OS X via Open Hack'Ware, so I was : > : annoyed to find that OpenBIOS didn't have such support. So, I might as : > : well add it. : > : > : > Open Hackware was barely enough to boot older versions of Linux. : > Other operating systems that needed more extensive properties from the : > OpenFirmware device tree failed to boot because they weren't present. : > I was involved in a large effort to get FreeBSD/powerpc booting on : > QEMU only to have it fail utterly because the amount of hacking on : > OpenHackWare needed was rather large and mysterious... : : This is what I get with OpenBIOS: : >> *** Boot failure! No secondary bootloader specified *** : : 0 > boot cd:,\boot\loader cd:0 : Consoles: Open Firmware console : : FreeBSD/Open Firmware/PowerPC bootstrap loader, Revision 0.1 : (root@xserve.lan.xcllnt.net, Thu Apr 16 18:47:58 UTC 2009) : Memory: 131072KB : Booted from: cd : : Loading /boot/defaults/loader.conf : /boot/kernel/kernel data=0x4a4ce0+0x3d4e4 syms=[0x4+0x454f0+0x4+0x5a4b9] : / : Hit [Enter] to boot immediately, or any other key for command prompt. : Booting [/boot/kernel/kernel]... : Kernel entry at 0x13dac0 ... : panic: moea_bootstrap: no space to copy translations : Uptime: 1s
That's similar to the one that I've seen as well. The problem with this one, IIRC, is that FreeBSD/powerpc is trying to setup the memory translations for the MMU and the 'translations' property length is zero, or something like that...
Right, the error comes from this line: http://fxr.watson.org/fxr/source/powerpc/powerpc/mmu_oea.c?v=FREEBSD70#L825
On 4/20/09, M. Warner Losh imp@bsdimp.com wrote:
In message: < f43fc5580904191144y1fd8e4d6m3321855d0c558250@mail.gmail.com> Blue Swirl blauwirbel@gmail.com writes:
: On 4/19/09, M. Warner Losh imp@bsdimp.com wrote: : > In message: < f488382f0904190128l4383a56eu67a2f16eb338e61c@mail.gmail.com> : > : > Steven Noonan steven@uplinklabs.net writes: : > : I eventually decided it made more : > : sense to get QEMU working instead. I did notice that the pre-OpenBIOS : > : version of QEMU was able to boot Mac OS X via Open Hack'Ware, so I was : > : annoyed to find that OpenBIOS didn't have such support. So, I might as : > : well add it. : > : > : > Open Hackware was barely enough to boot older versions of Linux. : > Other operating systems that needed more extensive properties from the : > OpenFirmware device tree failed to boot because they weren't present. : > I was involved in a large effort to get FreeBSD/powerpc booting on : > QEMU only to have it fail utterly because the amount of hacking on : > OpenHackWare needed was rather large and mysterious... : : This is what I get with OpenBIOS: : >> *** Boot failure! No secondary bootloader specified *** : : 0 > boot cd:,\boot\loader cd:0 : Consoles: Open Firmware console : : FreeBSD/Open Firmware/PowerPC bootstrap loader, Revision 0.1 : (root@xserve.lan.xcllnt.net, Thu Apr 16 18:47:58 UTC 2009) : Memory: 131072KB : Booted from: cd : : Loading /boot/defaults/loader.conf : /boot/kernel/kernel data=0x4a4ce0+0x3d4e4 syms=[0x4+0x454f0+0x4+ 0x5a4b9] : / : Hit [Enter] to boot immediately, or any other key for command prompt. : Booting [/boot/kernel/kernel]... : Kernel entry at 0x13dac0 ... : panic: moea_bootstrap: no space to copy translations : Uptime: 1s
That's similar to the one that I've seen as well. The problem with this one, IIRC, is that FreeBSD/powerpc is trying to setup the memory translations for the MMU and the 'translations' property length is zero, or something like that...
Right, the error comes from this line: http://fxr.watson.org/fxr/source/powerpc/powerpc/mmu_oea.c?v=FREEBSD70#L825
FWIW, Haiku still stops somewhere at http://dev.haiku-os.org/browser/haiku/trunk/src/system/boot/platform/openfir... ...
[revol@debian ~/devel/haiku/trunk]$ qemu-system-ppc -nographic -serial stdio -cdrom generated.ppc/haiku-boot-cd-ppc.iso -boot d
============================================================= OpenBIOS 1.0 [Mar 31 2009 15:35] Configuration device id QEMU version 1 machine id 2 CPUs: 1 Memory: 128M UUID: 00000000-0000-0000-0000-000000000000 CPU type PowerPC,750
Welcome to OpenBIOS v1.0 built on Mar 31 2009 15:35
checking for memory... 0: base = 0x00000000, size = 134217728 1: empty region total physical memory = 128 MB suggested page table size = 1048576 need new page table, size = 1048576! new table at: 0x07d00000 MSR: 0x00003030 found 4 translations found page table! no mapping for the exception handlers!
François.
Am 20.04.2009 um 23:01 schrieb François Revol:
Haiku still stops somewhere at http://dev.haiku-os.org/browser/haiku/trunk/src/system/boot/platform/openfir... ...
[revol@debian ~/devel/haiku/trunk]$ qemu-system-ppc -nographic -serial stdio -cdrom generated.ppc/haiku-boot-cd-ppc.iso -boot d
============================================================= OpenBIOS 1.0 [Mar 31 2009 15:35] Configuration device id QEMU version 1 machine id 2 CPUs: 1 Memory: 128M UUID: 00000000-0000-0000-0000-000000000000 CPU type PowerPC,750
Welcome to OpenBIOS v1.0 built on Mar 31 2009 15:35
At OpenBIOS r647 with Haiku r34736, this has become:
checking for memory... 0: base = 0x00000000, size = 134217728 1: empty region total physical memory = 128 MB suggested page table size = 1048576 need new page table, size = 1048576!
new table at: 0x07f00000
The bootloader then tries to memset(0x07f00000, 0, 1048576), leading to:
invalid/unsupported opcode: 00 - 00 - 00 (00000000) fff0245c 1 invalid/unsupported opcode: 00 - 00 - 00 (00000000) 00008754 0
Since it apparently tries to execute (just?) zero'ed memory, could this be the same OpenBIOS memory mapping issue recently seen with cmd646 on sparc64?
Boot CDs for the curious are available at: http://www.haiku-files.org/ppc/
If I comment out the memset, I get:
MSR: 0x00003030 found 4 translations
found exception handlers! invalid/unsupported opcode: 00 - 00 - 00 (000c2000) fff02484 1 invalid/unsupported opcode: 00 - 00 - 00 (000c2000) fff02484 1 invalid/unsupported opcode: 00 - 00 - 00 (000c2000) fff02484 1 invalid/unsupported opcode: 00 - 00 - 00 (00000000) 00008754 0
So apparently it does find exception handlers now but no page tables and again goes on to execute garbage.
This is not influenced by choosing between -M g3beige or -M mac99. The amount of memory makes a difference in not showing the invalid opcode errors for, e.g., -m 384, but it does hang at the same place.
Andreas
found page table! no mapping for the exception handlers!
François.
Andreas Färber wrote:
[revol@debian ~/devel/haiku/trunk]$ qemu-system-ppc -nographic -serial stdio -cdrom generated.ppc/haiku-boot-cd-ppc.iso -boot d
============================================================= OpenBIOS 1.0 [Mar 31 2009 15:35] Configuration device id QEMU version 1 machine id 2 CPUs: 1 Memory: 128M UUID: 00000000-0000-0000-0000-000000000000 CPU type PowerPC,750
Welcome to OpenBIOS v1.0 built on Mar 31 2009 15:35
At OpenBIOS r647 with Haiku r34736, this has become:
checking for memory... 0: base = 0x00000000, size = 134217728 1: empty region total physical memory = 128 MB suggested page table size = 1048576 need new page table, size = 1048576!
new table at: 0x07f00000
The bootloader then tries to memset(0x07f00000, 0, 1048576), leading to:
invalid/unsupported opcode: 00 - 00 - 00 (00000000) fff0245c 1 invalid/unsupported opcode: 00 - 00 - 00 (00000000) 00008754 0
Since it apparently tries to execute (just?) zero'ed memory, could this be the same OpenBIOS memory mapping issue recently seen with cmd646 on sparc64?
Boot CDs for the curious are available at: http://www.haiku-files.org/ppc/
If I comment out the memset, I get:
MSR: 0x00003030 found 4 translations
found exception handlers! invalid/unsupported opcode: 00 - 00 - 00 (000c2000) fff02484 1 invalid/unsupported opcode: 00 - 00 - 00 (000c2000) fff02484 1 invalid/unsupported opcode: 00 - 00 - 00 (000c2000) fff02484 1 invalid/unsupported opcode: 00 - 00 - 00 (00000000) 00008754 0
So apparently it does find exception handlers now but no page tables and again goes on to execute garbage.
This is not influenced by choosing between -M g3beige or -M mac99. The amount of memory makes a difference in not showing the invalid opcode errors for, e.g., -m 384, but it does hang at the same place.
Andreas
Is this really a regression? Without the complete output from both cases above it's difficult to tell, however it looks like the old version gets to an OpenBIOS prompt whereas the new version gets further since it is actually executing a bootloader payload.
If it's not a regression, it could be entirely possible that some of the recent changes I made to the CIF code could have a few bugs. In which case, an SVN bisect to identify the offending commit would be really handy.
ATB,
Mark.
Am 22.12.2009 um 14:36 schrieb Mark Cave-Ayland:
Is this really a regression? Without the complete output from both cases above it's difficult to tell, however it looks like the old version gets to an OpenBIOS prompt whereas the new version gets further since it is actually executing a bootloader payload.
Neither gets to an OpenBIOS prompt afaik. Nor to the Welcome banner of the Haiku bootloader, so iiuc not to its payload either.
Complete previous output from the mail I replied to:
checking for memory... 0: base = 0x00000000, size = 134217728 1: empty region total physical memory = 128 MB suggested page table size = 1048576 need new page table, size = 1048576! new table at: 0x07d00000 MSR: 0x00003030 found 4 translations found page table! no mapping for the exception handlers!
http://old.nabble.com/QEMU-OpenBIOS-booting--td23007116i40.html
Similar report on qemu-devel: http://www.archivum.info/qemu-devel@nongnu.org/2009-02/01081/Re:_%5BQemu-dev...
The output I sent was supposed to be complete (minus the OpenBIOS banner we all know):
checking for memory... 0: base = 0x00000000, size = 134217728 1: empty region total physical memory = 128 MB suggested page table size = 1048576 need new page table, size = 1048576! new table at: 0x07f00000
Partial output from real hardware for comparison available here: http://afaerber.planche.de/#ppc_2009_12_20
I considered it a regression because it's four lines less of output. There's also a change of address for the new table - 0x07f00000 vs. 0x07d00000.
an SVN bisect to identify the offending commit would be really handy.
Looking into that.
Andreas
Am 22.12.2009 um 22:48 schrieb Andreas Färber:
Am 22.12.2009 um 14:36 schrieb Mark Cave-Ayland:
an SVN bisect to identify the offending commit would be really handy.
The last two days I bisected within the range r484..r647, with local patch for OSX host support. I gave up this endeavor because too many commits didn't compile for me at all (including assumed-good r484). Some worked with powerpc-gnu-linux-* -> powerpc-elf-* symlinks, but most failed with type errors. Some compiled but found no secondary bootloader. Log attached.
Bisecting did however remind me of a change of the 'ofmem' implementation (r521). That might be an explanation why the address changed from 0x07d00000 to 0x07f00000, I guess?
As for the problematic memset, is there any way I could try out if this is the same issue as with cmd646 or not?
Happy Holidays everyone,
Andreas
git bisect start # bad: [eea4d2035dc57bc37e809bc500f07e2ddf981f6a] I accidently set props[0] twice instead of going through both elements. git bisect bad eea4d2035dc57bc37e809bc500f07e2ddf981f6a # good: [9106d2b2e4ceb94908ce2b72ed3dac9c78f4b5f4] Display more information when ?fcode-verbose enabled (Mark Cave-Ayland) git bisect good 9106d2b2e4ceb94908ce2b72ed3dac9c78f4b5f4 # skip: [cbd2d899e434f89961accf0aeec3499729ea82b5] Allow NULL dlabel path argument without accessing page zero. git bisect skip cbd2d899e434f89961accf0aeec3499729ea82b5 # bad: [bc982d2720dc4c927827629ecf7220d37789c2c0] workaround: fix long broken "make run" at least for the case that there's only one target git bisect bad bc982d2720dc4c927827629ecf7220d37789c2c0 # skip: [58974d230370e9a175ab20f68cabcefac5648a0f] For powerpc, use HFSPlus instead of HFS. git bisect skip 58974d230370e9a175ab20f68cabcefac5648a0f # skip: [90b6e25c9f3aa7beca4b54a85a16f28348bf6d0f] Fix OpenBSD boot git bisect skip 90b6e25c9f3aa7beca4b54a85a16f28348bf6d0f # bad: [fd02afae67c4faf9daca2b47bc3d69b3e5c12ccd] printk() needs openbios/config.h git bisect bad fd02afae67c4faf9daca2b47bc3d69b3e5c12ccd # skip: [df0a9a0370f22c4e6c61ea6369ef597ea32c9f75] Sparc64: configure screen size from QEMU command line options git bisect skip df0a9a0370f22c4e6c61ea6369ef597ea32c9f75 # skip: [2dc91a71269804c6e3ba30dd7886fe0cad6226fb] Sparc32/64: omit less useful FS modules etc. to reduce size git bisect skip 2dc91a71269804c6e3ba30dd7886fe0cad6226fb # skip: [b8fb5aaa87c8b77b026d7464e0fca62ddbe44ebd] ppc: if ":tbxi" (mac) fails, try "ppcootinfo.txt" (chrp). git bisect skip b8fb5aaa87c8b77b026d7464e0fca62ddbe44ebd # skip: [5151c2e85350997197ba51d922f6f3d32aa75a17] Sparc64: partially revert r515: long long is safer than int64_t git bisect skip 5151c2e85350997197ba51d922f6f3d32aa75a17 # skip: [0c4862788444361a99699f594f5bf078887600b2] Fix stack protector problems with newer GCC versions git bisect skip 0c4862788444361a99699f594f5bf078887600b2 # skip: [a2c978fa57707c29d216d361537d27845a80cf68] Do not call close- deblocker since ob_pci_open did not open it. git bisect skip a2c978fa57707c29d216d361537d27845a80cf68 # skip: [f2a96d53cf5c27e9cbcfb6e3fbb90f152842f61a] Revert commit of local change (sparc-elf / sparc-linux-gnu ) git bisect skip f2a96d53cf5c27e9cbcfb6e3fbb90f152842f61a # skip: [be9d48809acb6671ee5e9bbeca4e24db09e689b9] extract ofmem module implementation (Igor Kovalenko) git bisect skip be9d48809acb6671ee5e9bbeca4e24db09e689b9 # skip: [63b981573f91b2c4c8c7e3eb1a38b9864abd6e91] Implement /x FCode (Mark Cave-Ayland) git bisect skip 63b981573f91b2c4c8c7e3eb1a38b9864abd6e91 # skip: [cf621aaa47cdf22931a225d8430c6ff56638568e] switch sparc64 to ofmem module implementation (Igor Kovalenko) git bisect skip cf621aaa47cdf22931a225d8430c6ff56638568e # skip: [4513bf649c169f9413cc00c524fd296f5f7c1293] Implements XCOFF loader (to be able to boot Apple BootX bootloader) git bisect skip 4513bf649c169f9413cc00c524fd296f5f7c1293 # skip: [a09a4edd17ac4f46198b737bbf6bb9c0d1a3af72] Add a .gitignore file git bisect skip a09a4edd17ac4f46198b737bbf6bb9c0d1a3af72 # skip: [24b422f25cd469c5443ce0fac29588e24c04221a] Fix b(field) Fcode evaluation (Mark Cave-Ayland) git bisect skip 24b422f25cd469c5443ce0fac29588e24c04221a # skip: [e36dc88ae193fa3dddfdb4ee3fa7b078d473e720] Author: Pavel Roskin proski@gnu.org git bisect skip e36dc88ae193fa3dddfdb4ee3fa7b078d473e720 # skip: [6186a5f0e4be8313f02c6231b1ceddabd15370d0] Improve client interface debugging git bisect skip 6186a5f0e4be8313f02c6231b1ceddabd15370d0 # skip: [dc157302a5bb0a1def0b7b12d4cf2bf8379e28e3] This patch modifies disk-label.c to not allow to read beyond the selected partition limits. git bisect skip dc157302a5bb0a1def0b7b12d4cf2bf8379e28e3 # skip: [c1cc2d86555e65157aa72bfb925c9db44dc60954] sparc64 video.pal fix memory corruption (Igor Kovalenko) git bisect skip c1cc2d86555e65157aa72bfb925c9db44dc60954 # skip: [01f7e2a1db890593a3e3f02a0cd10040529ef6e9] There are numerous places where using 'ELF_DPRINTF' does not make sense, because the loader does not use ELF binaries or is not directly involved in loading them. git bisect skip 01f7e2a1db890593a3e3f02a0cd10040529ef6e9 # skip: [eeb78b40e1a488082c15cc0f3352be236d87dbe0] Don't try to configure non-existent BARs of bridge devices git bisect skip eeb78b40e1a488082c15cc0f3352be236d87dbe0 # skip: [313f2389f2890b4194f71de060e26034aa437a0d] try_chrp_script() now accepts a third parameter which indicates the script to be loaded and parsed. It will also terminate parsing on the '</chrp-boot>' tag, which makes locating embedded data after the script easier. git bisect skip 313f2389f2890b4194f71de060e26034aa437a0d # skip: [989464d9428262d8a8b605617809af774a9bfe6e] Revert r505 git bisect skip 989464d9428262d8a8b605617809af774a9bfe6e # skip: [5ebc1ae203ee31bd09b94afaa2e5eba2feac2d6e] Add DPRINTF() to disk-label.c git bisect skip 5ebc1ae203ee31bd09b94afaa2e5eba2feac2d6e # bad: [13f57423de22897c47aea57e7d05c2482e8eb696] For mac-parts, when no partition number is provided, open the first HFS partition (type is "Apple_HFS"). git bisect bad 13f57423de22897c47aea57e7d05c2482e8eb696 # skip: [a982a1df58ccfd584d497856f41c12df8fd0f57b] switch ppc to ofmem module implementation (Igor Kovalenko) git bisect skip a982a1df58ccfd584d497856f41c12df8fd0f57b # skip: [4490121a0fd64d6ec6ef155524e3ae65e07f43c8] Fix most Sparc64 warnings from Sparse git bisect skip 4490121a0fd64d6ec6ef155524e3ae65e07f43c8 # skip: [bfee9257e26249644166b043b51df4058f01007a] Save locked tlb space by aligning to 512k pages. git bisect skip bfee9257e26249644166b043b51df4058f01007a # skip: [70f76de21f0e60fb2a822327cb7c465891058e4e] Fix Unix target warnings from Sparse git bisect skip 70f76de21f0e60fb2a822327cb7c465891058e4e # skip: [248153925f84ad04820d48c81f48b52ab76560fa] Some gcc versions need __negti2 git bisect skip 248153925f84ad04820d48c81f48b52ab76560fa # skip: [9fb7d063534ab23fcdee0b9d4bce160914336f3b] Fix most x86 warnings from Sparse git bisect skip 9fb7d063534ab23fcdee0b9d4bce160914336f3b # skip: [7aad9efc1cda7603fda791a916329d7b9849edf3] We can select cpu using unit number instead of name, for instance we can use "dev /cpus/ @0" instead of "dev /cpus/PowerPC,750". This notation is used in Fedora bootscript to know if the CPU is 64-bit or 32-bit: it looks at "64-bit" property of first available CPUS ("@0"). git bisect skip 7aad9efc1cda7603fda791a916329d7b9849edf3
Am 22.12.2009 um 22:48 schrieb Andreas Färber:
checking for memory... 0: base = 0x00000000, size = 134217728 1: empty region total physical memory = 128 MB suggested page table size = 1048576 need new page table, size = 1048576! new table at: 0x07f00000
This hang here can be reproduced by the following 1-byte memset (given -m 128). The commented-out memset does not trigger it. Does the address ring a bell for anyone? The address of env->nip appears to be 0x4703dec, so no obvious connection between the two.
Andreas
diff --git a/src/system/boot/platform/openfirmware/arch/ppc/mmu.cpp b/ src/system/boot/platform/openfirmware/arch/ppc/mmu.cpp index 262e2c1..7af7247 100644 --- a/src/system/boot/platform/openfirmware/arch/ppc/mmu.cpp +++ b/src/system/boot/platform/openfirmware/arch/ppc/mmu.cpp @@ -909,7 +909,8 @@ arch_mmu_init(void)
sPageTableHashMask = tableSize / sizeof(page_table_entry_group) - 1; if (sPageTable != oldTable) - memset(sPageTable, 0, tableSize); + //memset(sPageTable, 0, 9308 /*tableSize*/); + memset((void*)0x7F0245c, 0, 1);
// turn off address translation via the page table/segment mechanism, // identity map the first 256 MB (where our code/data reside)
Am 26.12.2009 um 23:24 schrieb Andreas Färber:
Am 22.12.2009 um 22:48 schrieb Andreas Färber:
checking for memory... 0: base = 0x00000000, size = 134217728 1: empty region total physical memory = 128 MB suggested page table size = 1048576 need new page table, size = 1048576! new table at: 0x07f00000
This hang here can be reproduced by the following 1-byte memset (given -m 128). The commented-out memset does not trigger it.
For comparison, my PowerMac G3 b&w (NewWorld) allocated that table at 0x00400000.
Does the address ring a bell for anyone? The address of env->nip appears to be 0x4703dec, so no obvious connection between the two.
Andreas
diff --git a/src/system/boot/platform/openfirmware/arch/ppc/mmu.cpp b/src/system/boot/platform/openfirmware/arch/ppc/mmu.cpp index 262e2c1..7af7247 100644 --- a/src/system/boot/platform/openfirmware/arch/ppc/mmu.cpp +++ b/src/system/boot/platform/openfirmware/arch/ppc/mmu.cpp @@ -909,7 +909,8 @@ arch_mmu_init(void)
sPageTableHashMask = tableSize / sizeof(page_table_entry_group) - 1; if (sPageTable != oldTable)
memset(sPageTable, 0, tableSize);
//memset(sPageTable, 0, 9308 /*tableSize*/);memset((void*)0x7F0245c, 0, 1);// turn off address translation via the page table/segment mechanism, // identity map the first 256 MB (where our code/data reside)
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
Hello,
Am 31.12.2009 um 17:32 schrieb Andreas Färber:
Am 26.12.2009 um 23:24 schrieb Andreas Färber:
Am 22.12.2009 um 22:48 schrieb Andreas Färber:
checking for memory... 0: base = 0x00000000, size = 134217728 1: empty region total physical memory = 128 MB suggested page table size = 1048576 need new page table, size = 1048576! new table at: 0x07f00000
This hang here can be reproduced by the following 1-byte memset (given -m 128). The commented-out memset does not trigger it.
I've dug some more and noticed that the data parsed from /chosen/mmu/ translations seems wrong:
0: map: 0x00000000, length 16384 -> physical: 0x00000000, mode 132972544 1: map: 0x00030000, length 0 -> physical: 0x07f00000, mode 1048576 2: map: 0x00000002, length -2147483648 -> physical: 0x000eb000, mode 106
Note the weird mode and subsequent values. It looks as if Haiku expects (and gets on real OpenFirmware): void *virtual_address int length void *physical_address int mode whereas OpenBIOS writes in libopenbios/ ofmem_common.c:ofmem_update_mmu_translations: props[ncells++] = t->virt props[ncells++] = t->size props[ncells++] = t->mode
Should this be changed as follows, or is this platform-dependent?
diff --git a/libopenbios/ofmem_common.c b/libopenbios/ofmem_common.c index 8a577b6..71afbc0 100644 --- a/libopenbios/ofmem_common.c +++ b/libopenbios/ofmem_common.c @@ -182,7 +182,7 @@ static void ofmem_update_mmu_translations( void ) for( t = ofmem->trans, ncells = 0; t ; t=t->next, ncells++ ) { }
- props = malloc(ncells * sizeof(ucell) * 3); + props = malloc(ncells * sizeof(ucell) * 4);
if (props == NULL) return; @@ -190,6 +190,7 @@ static void ofmem_update_mmu_translations( void ) for( t = ofmem->trans, ncells = 0 ; t ; t=t->next ) { props[ncells++] = t->virt; props[ncells++] = t->size; + props[ncells++] = t->phys; props[ncells++] = t->mode; }
Thanks, Andreas
Andreas Färber wrote:
I've dug some more and noticed that the data parsed from /chosen/mmu/translations seems wrong:
0: map: 0x00000000, length 16384 -> physical: 0x00000000, mode 132972544 1: map: 0x00030000, length 0 -> physical: 0x07f00000, mode 1048576 2: map: 0x00000002, length -2147483648 -> physical: 0x000eb000, mode 106
Note the weird mode and subsequent values. It looks as if Haiku expects (and gets on real OpenFirmware): void *virtual_address int length void *physical_address int mode whereas OpenBIOS writes in libopenbios/ofmem_common.c:ofmem_update_mmu_translations: props[ncells++] = t->virt props[ncells++] = t->size props[ncells++] = t->mode
Should this be changed as follows, or is this platform-dependent?
Hmmm that's interesting. According to the OpenSolaris kernel source the translations property is mapped to the following struct:
http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/sun4v/sys/...
struct translation { uint32_t virt_hi; /* upper 32 bits of vaddr */ uint32_t virt_lo; /* lower 32 bits of vaddr */ uint32_t size_hi; /* upper 32 bits of size in bytes */ uint32_t size_lo; /* lower 32 bits of size in bytes */ uint32_t tte_hi; /* higher 32 bites of tte */ uint32_t tte_lo; /* lower 32 bits of tte */ };
And in Haiku:
http://dev.haiku-os.org/browser/haiku/trunk/src/system/boot/platform/openfir... struct translation_map { void *virtual_address; int length; void *physical_address; int mode; } translations[64];
So in short, it does indeed look as if there are some platform differences here. I guess this extra field is based upon the Mac OF implementation so it would be good for someone to verify this on a real Mac before we go and hack the source for PPC-only hosts. Note that I can't see any references to the translations property in the OF spec so I guess it must be an extension.
ATB,
Mark.
On Fri, May 21, 2010 at 12:00 PM, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
Andreas Färber wrote:
I've dug some more and noticed that the data parsed from /chosen/mmu/translations seems wrong:
0: map: 0x00000000, length 16384 -> physical: 0x00000000, mode 132972544 1: map: 0x00030000, length 0 -> physical: 0x07f00000, mode 1048576 2: map: 0x00000002, length -2147483648 -> physical: 0x000eb000, mode 106
Note the weird mode and subsequent values. It looks as if Haiku expects (and gets on real OpenFirmware): void *virtual_address int length void *physical_address int mode whereas OpenBIOS writes in libopenbios/ofmem_common.c:ofmem_update_mmu_translations: props[ncells++] = t->virt props[ncells++] = t->size props[ncells++] = t->mode
Should this be changed as follows, or is this platform-dependent?
Hmmm that's interesting. According to the OpenSolaris kernel source the translations property is mapped to the following struct:
http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/sun4v/sys/...
struct translation { uint32_t virt_hi; /* upper 32 bits of vaddr */ uint32_t virt_lo; /* lower 32 bits of vaddr */ uint32_t size_hi; /* upper 32 bits of size in bytes */ uint32_t size_lo; /* lower 32 bits of size in bytes */ uint32_t tte_hi; /* higher 32 bites of tte */ uint32_t tte_lo; /* lower 32 bits of tte */ };
And in Haiku:
http://dev.haiku-os.org/browser/haiku/trunk/src/system/boot/platform/openfir...
struct translation_map { void *virtual_address; int length; void *physical_address; int mode; } translations[64];
So in short, it does indeed look as if there are some platform differences here. I guess this extra field is based upon the Mac OF implementation so it would be good for someone to verify this on a real Mac before we go and hack the source for PPC-only hosts. Note that I can't see any references to the translations property in the OF spec so I guess it must be an extension.
For arm and ppc we have {virt,size,phys,mode} documented in proposed platform bindings. http://playground.sun.com/1275/bindings/arm/arm0_3d.html#34579 http://playground.sun.com/1275/bindings/ppc/release/ppc-2_1.html#REF34579
For sparc there seems to be no such proposal, and linux uses {virt,size,mode}
Igor Kovalenko wrote:
For arm and ppc we have {virt,size,phys,mode} documented in proposed platform bindings. http://playground.sun.com/1275/bindings/arm/arm0_3d.html#34579 http://playground.sun.com/1275/bindings/ppc/release/ppc-2_1.html#REF34579
For sparc there seems to be no such proposal, and linux uses {virt,size,mode}
Right. If this property is platform-specific then it would make sense that the function to generate the translations property should be moved into arch/foo/ofmem_*.c and ofmem_common.c updated to use an architecture-specific callback instead.
ATB,
M-D.
On 21.05.2010, at 10:00, Mark Cave-Ayland wrote:
Andreas Färber wrote:
I've dug some more and noticed that the data parsed from /chosen/mmu/translations seems wrong: 0: map: 0x00000000, length 16384 -> physical: 0x00000000, mode 132972544 1: map: 0x00030000, length 0 -> physical: 0x07f00000, mode 1048576 2: map: 0x00000002, length -2147483648 -> physical: 0x000eb000, mode 106 Note the weird mode and subsequent values. It looks as if Haiku expects (and gets on real OpenFirmware): void *virtual_address int length void *physical_address int mode whereas OpenBIOS writes in libopenbios/ofmem_common.c:ofmem_update_mmu_translations: props[ncells++] = t->virt props[ncells++] = t->size props[ncells++] = t->mode Should this be changed as follows, or is this platform-dependent?
Hmmm that's interesting. According to the OpenSolaris kernel source the translations property is mapped to the following struct:
http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/sun4v/sys/...
struct translation { uint32_t virt_hi; /* upper 32 bits of vaddr */ uint32_t virt_lo; /* lower 32 bits of vaddr */ uint32_t size_hi; /* upper 32 bits of size in bytes */ uint32_t size_lo; /* lower 32 bits of size in bytes */ uint32_t tte_hi; /* higher 32 bites of tte */ uint32_t tte_lo; /* lower 32 bits of tte */ };
And in Haiku:
http://dev.haiku-os.org/browser/haiku/trunk/src/system/boot/platform/openfir...
struct translation_map { void *virtual_address; int length; void *physical_address; int mode; } translations[64];
So in short, it does indeed look as if there are some platform differences here. I guess this extra field is based upon the Mac OF implementation so it would be good for someone to verify this on a real Mac before we go and hack the source for PPC-only hosts. Note that I can't see any references to the translations property in the OF spec so I guess it must be an extension.
Let's see - I went through several machines and tried to find that node. Since they're all inside of Linux, I couldn't easily resolve /chosen/mmu, which btw didn't always exist either.
PowerMac G5:
agraf@mac:/proc/device-tree> find . -name translations ./cpus/PowerPC,970@0/translations agraf@mac:/proc/device-tree> od -t x4 ./cpus/PowerPC,970@0/translations 0000000 00000000 00003000 00000000 00000000 0000020 00000010 00040000 0002d000 00000000 0000040 00040000 00000002 00400000 00700000 0000060 00000000 00400000 00000010 00b00000 0000100 00180000 00000000 00b00000 00000010 0000120 00d00000 00e00000 00000000 00d00000 0000140 00000010 01b00000 00625000 00000000 0000160 01b00000 00000010 02130000 00100000 0000200 00000000 02130000 00000010 1fbfc000 0000220 00004000 00000000 1fbfc000 00000010 0000240 80000000 00080000 00000000 80000000 0000260 00000028 80080000 00001000 00000000 0000300 80080000 00000028 80081000 00001000 0000320 00000000 80081000 00000028 80101000 0000340 00001000 00000000 80101000 00000028 0000360 80102000 00001000 00000000 80102000 0000400 00000028 80200000 00001000 00000000 0000420 80200000 00000028 80400000 00200000 0000440 00000000 80400000 00000028 80600000 0000460 00002000 00000000 80600000 00000028 0000500 90000000 00020000 00000000 90000000 0000520 00000028 91000000 01000000 00000000 0000540 91000000 00000028 98000000 08000000 0000560 00000000 98000000 00000028 f0000000 0000600 00010000 00000000 f0000000 00000028 0000620 f0800000 00001000 00000000 f0800000 0000640 00000028 f0c00000 00001000 00000000 0000660 f0c00000 00000028 f2000000 02800000 0000700 00000000 f2000000 00000028 f4000000 0000720 00400000 00000000 f4000000 00000028 0000740 f8000000 01000000 00000000 f8000000 0000760 00000028 f8070000 00001000 00000000 0001000 f8070000 00000028 ff800000 00400000 0001020 00000000 1fc00000 00000010 fff04000 0001040 00002000 00000000 fff04000 00000028 0001060 fff06000 00002000 00000000 fff06000 0001100 00000028
YDL PowerStation (970MP)
agraf@lychee:/proc/device-tree> find . -name translations ./mmu/translations agraf@lychee:/proc/device-tree> od -t x4 mmu/translations 0000000
IBM POWER5 System
agraf@cherry:/proc/device-tree> find . -name translations ./cpus/PowerPC,POWER5@0/translations agraf@cherry:/proc/device-tree> od -t x4 ./cpus/PowerPC,POWER5@0/translations 0000000
Apparently all our PPC32 machines are offline, so I can't easily check things there. If you like, I can boot up my iBook and see what I can find.
Alex
Alexander Graf wrote:
Let's see - I went through several machines and tried to find that node. Since they're all inside of Linux, I couldn't easily resolve /chosen/mmu, which btw didn't always exist either.
PowerMac G5:
agraf@mac:/proc/device-tree> find . -name translations ./cpus/PowerPC,970@0/translations agraf@mac:/proc/device-tree> od -t x4 ./cpus/PowerPC,970@0/translations 0000000 00000000 00003000 00000000 00000000 0000020 00000010 00040000 0002d000 00000000 0000040 00040000 00000002 00400000 00700000 0000060 00000000 00400000 00000010 00b00000 0000100 00180000 00000000 00b00000 00000010 0000120 00d00000 00e00000 00000000 00d00000 0000140 00000010 01b00000 00625000 00000000 0000160 01b00000 00000010 02130000 00100000 0000200 00000000 02130000 00000010 1fbfc000 0000220 00004000 00000000 1fbfc000 00000010 0000240 80000000 00080000 00000000 80000000 0000260 00000028 80080000 00001000 00000000 0000300 80080000 00000028 80081000 00001000 0000320 00000000 80081000 00000028 80101000 0000340 00001000 00000000 80101000 00000028 0000360 80102000 00001000 00000000 80102000 0000400 00000028 80200000 00001000 00000000 0000420 80200000 00000028 80400000 00200000 0000440 00000000 80400000 00000028 80600000 0000460 00002000 00000000 80600000 00000028 0000500 90000000 00020000 00000000 90000000 0000520 00000028 91000000 01000000 00000000 0000540 91000000 00000028 98000000 08000000 0000560 00000000 98000000 00000028 f0000000 0000600 00010000 00000000 f0000000 00000028 0000620 f0800000 00001000 00000000 f0800000 0000640 00000028 f0c00000 00001000 00000000 0000660 f0c00000 00000028 f2000000 02800000 0000700 00000000 f2000000 00000028 f4000000 0000720 00400000 00000000 f4000000 00000028 0000740 f8000000 01000000 00000000 f8000000 0000760 00000028 f8070000 00001000 00000000 0001000 f8070000 00000028 ff800000 00400000 0001020 00000000 1fc00000 00000010 fff04000 0001040 00002000 00000000 fff04000 00000028 0001060 fff06000 00002000 00000000 fff06000 0001100 00000028
YDL PowerStation (970MP)
agraf@lychee:/proc/device-tree> find . -name translations ./mmu/translations agraf@lychee:/proc/device-tree> od -t x4 mmu/translations 0000000
IBM POWER5 System
agraf@cherry:/proc/device-tree> find . -name translations ./cpus/PowerPC,POWER5@0/translations agraf@cherry:/proc/device-tree> od -t x4 ./cpus/PowerPC,POWER5@0/translations 0000000
Apparently all our PPC32 machines are offline, so I can't easily check things there. If you like, I can boot up my iBook and see what I can find.
Alex
Hi Alex,
Thanks for the offer. Given that Igor has found the documentation for this in the platform bindings (and it matches what is seen in the source code), please don't worry about this for the moment. I shall post a patch for testing shortly.
ATB,
Mark.
Hi guys,
Am 21.05.2010 um 11:57 schrieb Mark Cave-Ayland:
Alexander Graf wrote:
Let's see - I went through several machines and tried to find that node. [...] Apparently all our PPC32 machines are offline, so I can't easily check things there. If you like, I can boot up my iBook and see what I can find.
Thanks for the offer. Given that Igor has found the documentation for this in the platform bindings (and it matches what is seen in the source code), please don't worry about this for the moment.
Sorry for not having been explicit about this. With "(and gets on real OpenFirmware)" I was referring to having tested this on my PowerMac G3. ;) Thanks anyway, Alex.
Andreas
Am 21.05.2010 um 10:16 schrieb Alexander Graf:
On 21.05.2010, at 10:00, Mark Cave-Ayland wrote:
Andreas Färber wrote:
I've dug some more and noticed that the data parsed from /chosen/ mmu/translations seems wrong:
Let's see - I went through several machines and tried to find that node. Since they're all inside of Linux, I couldn't easily resolve / chosen/mmu, which btw didn't always exist either.
My fault. /chosen/mmu property contains an instance reference to the package where the translations property is assumed to exist. On my PowerMac it's in /cpus/PowerPC,750@0, similar to your G5.
Andreas
Le lundi 20 avril 2009 à 22:39 +0300, Blue Swirl a écrit :
On 4/20/09, M. Warner Losh imp@bsdimp.com wrote:
In message: f43fc5580904191144y1fd8e4d6m3321855d0c558250@mail.gmail.com Blue Swirl blauwirbel@gmail.com writes:
: On 4/19/09, M. Warner Losh imp@bsdimp.com wrote: : > In message: f488382f0904190128l4383a56eu67a2f16eb338e61c@mail.gmail.com : > : > Steven Noonan steven@uplinklabs.net writes: : > : I eventually decided it made more : > : sense to get QEMU working instead. I did notice that the pre-OpenBIOS : > : version of QEMU was able to boot Mac OS X via Open Hack'Ware, so I was : > : annoyed to find that OpenBIOS didn't have such support. So, I might as : > : well add it. : > : > : > Open Hackware was barely enough to boot older versions of Linux. : > Other operating systems that needed more extensive properties from the : > OpenFirmware device tree failed to boot because they weren't present. : > I was involved in a large effort to get FreeBSD/powerpc booting on : > QEMU only to have it fail utterly because the amount of hacking on : > OpenHackWare needed was rather large and mysterious... : : This is what I get with OpenBIOS: : >> *** Boot failure! No secondary bootloader specified *** : : 0 > boot cd:,\boot\loader cd:0 : Consoles: Open Firmware console : : FreeBSD/Open Firmware/PowerPC bootstrap loader, Revision 0.1 : (root@xserve.lan.xcllnt.net, Thu Apr 16 18:47:58 UTC 2009) : Memory: 131072KB : Booted from: cd : : Loading /boot/defaults/loader.conf : /boot/kernel/kernel data=0x4a4ce0+0x3d4e4 syms=[0x4+0x454f0+0x4+0x5a4b9] : / : Hit [Enter] to boot immediately, or any other key for command prompt. : Booting [/boot/kernel/kernel]... : Kernel entry at 0x13dac0 ... : panic: moea_bootstrap: no space to copy translations : Uptime: 1s
That's similar to the one that I've seen as well. The problem with this one, IIRC, is that FreeBSD/powerpc is trying to setup the memory translations for the MMU and the 'translations' property length is zero, or something like that...
Right, the error comes from this line: http://fxr.watson.org/fxr/source/powerpc/powerpc/mmu_oea.c?v=FREEBSD70#L825
I think '/memory/available' is badly encoded and doesn't reflect the actual memory availability..
Regards, Laurent
Le dimanche 19 avril 2009 à 10:03 +0200, Andreas Färber a écrit :
Am 19.04.2009 um 09:50 schrieb Steven Noonan:
On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan steven@uplinklabs.net wrote:
On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier Laurent@lvivier.info wrote:
OpenBIOS is not able to boot MacOS X.
Well, that's a silly limitation. Is there a reason this isn't implemented? I see that the Mac-on-Linux OpenBIOS version has such support, so it seems strange that the QEMU version does not.
I don't know if anyone here is actually interested (this list seems -very- quiet), but...
I've been hacking at OpenBIOS for a bit, and I got it to properly read Mac OS X discs (it kept failing because it would hit an Apple Partition Map header instead of an HFS+ filesystem header). I'm working on adding an XCOFF loader, too, so it should be able to boot Mac OS X soon.
Any chances I could get these changes merged to the main OpenBIOS tree once they're done?
My current working repository is at http://github.com/tycho/openbios. I'm working on the macosx-boot branch. The relevant commit is here (patch also attached): http://github.com/tycho/openbios/commit/4722c8a01d186a08183de49759dc8b7b74cf...
Thoughts?
Your work surely sounds interesting. However, making OpenBIOS boot from the disks is not everything there is to it. Alexander Graf had once posted a series of patches for making Mac OS X boot in QEMU, including changes/additions to device emulation. They were not merged, not sure about the status today.
Alexander made a work to boot Intel Mac OS X. It works very well with KVM (I use it).
See the HowTo http://d4wiki.goddamm.it/index.php/Howto:_Mac_OSX_on_KVM .
One issue iirc was that you need to obtain some Apple ID from a real Mac of yours and pass that to QEMU for it to work.
I don't think it is needed with powerPC MacOS X. I seems OpenHackware was able to boot powerPC MacOS X. Perhaps we should look at it.
Regards, Laurent
On Apr 19, 2009, at 3:31 AM, Laurent Vivier wrote:
Le dimanche 19 avril 2009 à 10:03 +0200, Andreas Färber a écrit :
Am 19.04.2009 um 09:50 schrieb Steven Noonan:
On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan steven@uplinklabs.net wrote:
On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier Laurent@lvivier.info wrote:
OpenBIOS is not able to boot MacOS X.
Well, that's a silly limitation. Is there a reason this isn't implemented? I see that the Mac-on-Linux OpenBIOS version has such support, so it seems strange that the QEMU version does not.
I don't know if anyone here is actually interested (this list seems -very- quiet), but...
I've been hacking at OpenBIOS for a bit, and I got it to properly read Mac OS X discs (it kept failing because it would hit an Apple Partition Map header instead of an HFS+ filesystem header). I'm working on adding an XCOFF loader, too, so it should be able to boot Mac OS X soon.
Any chances I could get these changes merged to the main OpenBIOS tree once they're done?
My current working repository is at http://github.com/tycho/ openbios. I'm working on the macosx-boot branch. The relevant commit is here (patch also attached): http://github.com/tycho/openbios/commit/4722c8a01d186a08183de49759dc8b7b74cf...
Thoughts?
Your work surely sounds interesting. However, making OpenBIOS boot from the disks is not everything there is to it. Alexander Graf had once posted a series of patches for making Mac OS X boot in QEMU, including changes/additions to device emulation. They were not merged, not sure about the status today.
Alexander made a work to boot Intel Mac OS X. It works very well with KVM (I use it).
See the HowTo http://d4wiki.goddamm.it/index.php/ Howto:_Mac_OSX_on_KVM .
I'm trying the Mac_OSX_on_KVM Howto above.
I'd like to boot an existing, bootable Mac OS X 10.5.5 GPT formatted, external USB HDD, which boots fine on my 4,1 MBP.
Does anyone know if Alexander's kvm-osx-bootloader can boot real, host managed HDDs, or is it dependent on something associated with disk image files, created by qemu-img?
I don't have the message in front of me now, but I think I was getting "device not found" when I used -hda /dev/sdc or -hda /dev/sdc1.
One issue iirc was that you need to obtain some Apple ID from a real Mac of yours and pass that to QEMU for it to work.
I don't think it is needed with powerPC MacOS X. I seems OpenHackware was able to boot powerPC MacOS X. Perhaps we should look at it.
Regards, Laurent
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
Hi Dave,
On 20.05.2009, at 15:51, Dave Willoughby wrote:
On Apr 19, 2009, at 3:31 AM, Laurent Vivier wrote:
Le dimanche 19 avril 2009 à 10:03 +0200, Andreas Färber a écrit :
Alexander made a work to boot Intel Mac OS X. It works very well with KVM (I use it).
See the HowTo http://d4wiki.goddamm.it/index.php/Howto:_Mac_OSX_on_KVM .
I'm trying the Mac_OSX_on_KVM Howto above.
I'd like to boot an existing, bootable Mac OS X 10.5.5 GPT formatted, external USB HDD, which boots fine on my 4,1 MBP.
GPT formatted by Mac OS X? You need to have an MBR synced on it.
Does anyone know if Alexander's kvm-osx-bootloader can boot real, host managed HDDs, or is it dependent on something associated with disk image files, created by qemu-img?
You boot the bootloader using -kernel which then reads the partition table. That has nothing to do with OpenBIOS and only remotely with qemu though, so if you still can't get it to work, please email me off- list :-).
Alex
Le dimanche 19 avril 2009 à 00:50 -0700, Steven Noonan a écrit :
On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan steven@uplinklabs.net wrote:
On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier Laurent@lvivier.info wrote:
OpenBIOS is not able to boot MacOS X.
Well, that's a silly limitation. Is there a reason this isn't implemented? I see that the Mac-on-Linux OpenBIOS version has such support, so it seems strange that the QEMU version does not.
I don't know if anyone here is actually interested (this list seems -very- quiet), but...
Hi,
I've been hacking at OpenBIOS for a bit, and I got it to properly read Mac OS X discs (it kept failing because it would hit an Apple Partition Map header instead of an HFS+ filesystem header). I'm working on adding an XCOFF loader, too, so it should be able to boot Mac OS X soon.
You can copy it from OpenHackWare. I made some tests and it seems to have some memory conflicts between MacOS kernel and OpenBIOS.
Good Luck.
Any chances I could get these changes merged to the main OpenBIOS tree once they're done?
Yes
My current working repository is at http://github.com/tycho/openbios. I'm working on the macosx-boot branch. The relevant commit is here (patch also attached): http://github.com/tycho/openbios/commit/4722c8a01d186a08183de49759dc8b7b74cf...
Thoughts?
I don't understand why this patch is needed. Could you explain ?
Regards, Laurent
On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier Laurent@lvivier.info wrote:
Le dimanche 19 avril 2009 à 00:50 -0700, Steven Noonan a écrit :
On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan steven@uplinklabs.net wrote:
On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier Laurent@lvivier.info wrote:
OpenBIOS is not able to boot MacOS X.
Well, that's a silly limitation. Is there a reason this isn't implemented? I see that the Mac-on-Linux OpenBIOS version has such support, so it seems strange that the QEMU version does not.
I don't know if anyone here is actually interested (this list seems -very- quiet), but...
Hi,
I've been hacking at OpenBIOS for a bit, and I got it to properly read Mac OS X discs (it kept failing because it would hit an Apple Partition Map header instead of an HFS+ filesystem header). I'm working on adding an XCOFF loader, too, so it should be able to boot Mac OS X soon.
You can copy it from OpenHackWare. I made some tests and it seems to have some memory conflicts between MacOS kernel and OpenBIOS.
Good Luck.
Any chances I could get these changes merged to the main OpenBIOS tree once they're done?
Yes
My current working repository is at http://github.com/tycho/openbios. I'm working on the macosx-boot branch. The relevant commit is here (patch also attached): http://github.com/tycho/openbios/commit/4722c8a01d186a08183de49759dc8b7b74cf...
Thoughts?
I don't understand why this patch is needed. Could you explain ?
If you pass QEMU a Mac OS X install disc ISO (via dd from an original disc), OpenBIOS will try to scan for a bootable partition. When it calls fs_hfsp_open(), it fails the volume_open() call because instead of finding an HFS+ filesystem header, it finds an Apple Partition Map header. The APM header points to the location of the HFS+ filesystem header. So basically, it just gives the necessary offset from the start of that slice to find the HFS+ header.
On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier Laurent@lvivier.info wrote:
Le dimanche 19 avril 2009 à 00:50 -0700, Steven Noonan a écrit :
On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan steven@uplinklabs.net wrote:
On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier Laurent@lvivier.info wrote:
OpenBIOS is not able to boot MacOS X.
Well, that's a silly limitation. Is there a reason this isn't implemented? I see that the Mac-on-Linux OpenBIOS version has such support, so it seems strange that the QEMU version does not.
I don't know if anyone here is actually interested (this list seems -very- quiet), but...
Hi,
I've been hacking at OpenBIOS for a bit, and I got it to properly read Mac OS X discs (it kept failing because it would hit an Apple Partition Map header instead of an HFS+ filesystem header). I'm working on adding an XCOFF loader, too, so it should be able to boot Mac OS X soon.
You can copy it from OpenHackWare. I made some tests and it seems to have some memory conflicts between MacOS kernel and OpenBIOS.
Good Luck.
Two more pre-XCOFF loader commits up: http://github.com/tycho/openbios/commit/e43daa3447b5ce4a2b05b2f32882e4989115... http://github.com/tycho/openbios/commit/7023b78a10f5632fd08d4749615efd3e73ab...
And I have something (uncommitted) that at least -loads- the CHRP-embedded XCOFF binaries now, but I am not sure what to do to execute the result. With ELF, it seems you can just use the call_elf() function. I don't know PowerPC assembler (nor the XCOFF format) well enough yet to know what would be necessary for a call_xcoff() function. Anyone want to help out with this?
- Steven
On 4/19/09, Steven Noonan steven@uplinklabs.net wrote:
On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier Laurent@lvivier.info wrote:
Le dimanche 19 avril 2009 à 00:50 -0700, Steven Noonan a écrit :
On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan steven@uplinklabs.net wrote:
On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier Laurent@lvivier.info wrote:
OpenBIOS is not able to boot MacOS X.
Well, that's a silly limitation. Is there a reason this isn't implemented? I see that the Mac-on-Linux OpenBIOS version has such support, so it seems strange that the QEMU version does not.
I don't know if anyone here is actually interested (this list seems -very- quiet), but...
Hi,
I've been hacking at OpenBIOS for a bit, and I got it to properly read Mac OS X discs (it kept failing because it would hit an Apple Partition Map header instead of an HFS+ filesystem header). I'm working on adding an XCOFF loader, too, so it should be able to boot Mac OS X soon.
You can copy it from OpenHackWare. I made some tests and it seems to have some memory conflicts between MacOS kernel and OpenBIOS.
Good Luck.
Two more pre-XCOFF loader commits up: http://github.com/tycho/openbios/commit/e43daa3447b5ce4a2b05b2f32882e4989115... http://github.com/tycho/openbios/commit/7023b78a10f5632fd08d4749615efd3e73ab...
These look fine to me.
And I have something (uncommitted) that at least -loads- the CHRP-embedded XCOFF binaries now, but I am not sure what to do to execute the result. With ELF, it seems you can just use the call_elf() function. I don't know PowerPC assembler (nor the XCOFF format) well enough yet to know what would be necessary for a call_xcoff() function. Anyone want to help out with this?
Well, call_elf should work regardless of the format. The first and second parameters will be passed verbatim to OS (Linux uses those for initrd address and size), the third is the start address that should be available for all formats. There's some more description near the function call_elf in start.S.
So I'd just add something like call_elf(0, 0, xcoff_start) somewhere.
On Sun, Apr 19, 2009 at 12:23 PM, Blue Swirl blauwirbel@gmail.com wrote:
On 4/19/09, Steven Noonan steven@uplinklabs.net wrote:
On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier Laurent@lvivier.info wrote: > Le dimanche 19 avril 2009 à 00:50 -0700, Steven Noonan a écrit : >> On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan steven@uplinklabs.net wrote: >> > On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier Laurent@lvivier.info wrote: >> >> OpenBIOS is not able to boot MacOS X. >> > >> > Well, that's a silly limitation. Is there a reason this isn't >> > implemented? I see that the Mac-on-Linux OpenBIOS version has such >> > support, so it seems strange that the QEMU version does not. >> >> I don't know if anyone here is actually interested (this list seems >> -very- quiet), but... > > Hi, > >> I've been hacking at OpenBIOS for a bit, and I got it to properly read >> Mac OS X discs (it kept failing because it would hit an Apple >> Partition Map header instead of an HFS+ filesystem header). I'm >> working on adding an XCOFF loader, too, so it should be able to boot >> Mac OS X soon. > > You can copy it from OpenHackWare. > I made some tests and it seems to have some memory conflicts between > MacOS kernel and OpenBIOS. > > Good Luck. >
Two more pre-XCOFF loader commits up: http://github.com/tycho/openbios/commit/e43daa3447b5ce4a2b05b2f32882e4989115... http://github.com/tycho/openbios/commit/7023b78a10f5632fd08d4749615efd3e73ab...
These look fine to me.
And I have something (uncommitted) that at least -loads- the CHRP-embedded XCOFF binaries now, but I am not sure what to do to execute the result. With ELF, it seems you can just use the call_elf() function. I don't know PowerPC assembler (nor the XCOFF format) well enough yet to know what would be necessary for a call_xcoff() function. Anyone want to help out with this?
Well, call_elf should work regardless of the format. The first and second parameters will be passed verbatim to OS (Linux uses those for initrd address and size), the third is the start address that should be available for all formats. There's some more description near the function call_elf in start.S.
So I'd just add something like call_elf(0, 0, xcoff_start) somewhere.
Ah, that did what it should've. I guess 'call_elf' is a misnomer?
I'm not committing the XCOFF loader quite yet. I suspect it would be best to do refactor it to use a similar API to what the ELF loader has, and place it so that it could be shared with the other OpenBIOS targets (pearpc, mol, etc)... Would it be preferred to make the XCOFF loader QEMU-specific or should it be a common API like the ELF loader?
So here's what I get when I try Mac OS X 10.4 (I've enabled a ton of debug output):
Alcarin:qemu steven$ ppc-softmmu/qemu-system-ppc -L pc-bios -cdrom ~/Development/MacOSX-10.4.iso -boot d -M mac99 -nographic
============================================================= OpenBIOS 1.0 [Apr 19 2009 19:39] Configuration device id QEMU version 1 machine id 1 CPUs: 1 Memory: 128M UUID: 00000000-0000-0000-0000-000000000000 CPU type PowerPC,G4
Welcome to OpenBIOS v1.0 built on Apr 19 2009 19:39
YABOOT - yaboot_startup: Entering boot, no path CHRP - try_chrp_script: Trying cd:0,ppc\bootinfo.txt MAC-PARTS: macparts_probe 4552 ?= 4552 MAC-PARTS: macparts_open 0 MAC-PARTS: macparts_get_info 0 2832209920 MAC-PARTS: macparts_block_size = 200 volume_read_wrapper: got sig 482b volume_read_wrapper: got sig 482b ELF - try_chrp_script: Can't open cd:0,ppc\bootinfo.txt CHRP - try_chrp_script: Trying cd:0,System\Library\CoreServices\BootX MAC-PARTS: macparts_probe 4552 ?= 4552 MAC-PARTS: macparts_open 0 MAC-PARTS: macparts_get_info 0 2832209920 MAC-PARTS: macparts_block_size = 200 volume_read_wrapper: got sig 482b volume_read_wrapper: got sig 482b CHRP - try_chrp_script: got bootscript load-base begin dup 6 " </CHRP" $= if 6 + dup 6 " -BOOT>" $= if 8 + true else false then else 1+ false then until ( xcoff-base ) load-size over load-base - - ( xcoff-base xcoff-size ) load-base swap move init-program go
ELF - encode_bootpath: bootpath cd:0,<NULL>\ bootargs <NULL>
$=:>> XCOFF - load_xcoff: Loading 'System\Library\CoreServices\BootX'
XCOFF - load_xcoff: XCOFF file with 3 sections entry:fff0a22c XCOFF - load_xcoff: Read next header (5c) XCOFF - load_xcoff: Load '.text' section from 5c d4 to 5600000 (28000) XCOFF - load_xcoff: Read next header (84) XCOFF - load_xcoff: Load '.data' section from 84 280d4 to 5628000 (2000) XCOFF - load_xcoff: Read next header (ac) XCOFF - load_xcoff: Erase '.bss' section at 562a000 size: 3a000 ELF - transfer_control_to_elf: Starting ELF boot loader
invalid/unsupported opcode: 02 - 0e - 0c (0b717b1c) 05616ed8 1 invalid/unsupported opcode: 00 - 14 - 13 (000064e8) 000094d0 0 Alcarin:qemu steven$
So at least with my patches, we're getting what people with QEMU 0.8.0 were getting: http://tinyurl.com/qemu080
So now what's left is resolving -why- that 'invalid/unsupported opcode' issue crops up.
- Steven
Le dimanche 19 avril 2009 à 13:00 -0700, Steven Noonan a écrit :
On Sun, Apr 19, 2009 at 12:23 PM, Blue Swirl blauwirbel@gmail.com wrote:
On 4/19/09, Steven Noonan steven@uplinklabs.net wrote:
On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier Laurent@lvivier.info wrote:
Le dimanche 19 avril 2009 à 00:50 -0700, Steven Noonan a écrit :
On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan steven@uplinklabs.net wrote:
On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier Laurent@lvivier.info wrote: > OpenBIOS is not able to boot MacOS X.
[...] $=:>> XCOFF - load_xcoff: Loading 'System\Library\CoreServices\BootX'
XCOFF - load_xcoff: XCOFF file with 3 sections entry:fff0a22c XCOFF - load_xcoff: Read next header (5c) XCOFF - load_xcoff: Load '.text' section from 5c d4 to 5600000 (28000) XCOFF - load_xcoff: Read next header (84) XCOFF - load_xcoff: Load '.data' section from 84 280d4 to 5628000 (2000) XCOFF - load_xcoff: Read next header (ac) XCOFF - load_xcoff: Erase '.bss' section at 562a000 size: 3a000 ELF - transfer_control_to_elf: Starting ELF boot loader
invalid/unsupported opcode: 02 - 0e - 0c (0b717b1c) 05616ed8 1 invalid/unsupported opcode: 00 - 14 - 13 (000064e8) 000094d0 0 Alcarin:qemu steven$
So at least with my patches, we're getting what people with QEMU 0.8.0 were getting: http://tinyurl.com/qemu080
So now what's left is resolving -why- that 'invalid/unsupported opcode' issue crops up.
I think the booloader is loaded at addresses overwriting some parts of openbios.
Regards, Laurent
On Sun, Apr 19, 2009 at 1:08 PM, Laurent Vivier Laurent@lvivier.info wrote:
Le dimanche 19 avril 2009 à 13:00 -0700, Steven Noonan a écrit :
On Sun, Apr 19, 2009 at 12:23 PM, Blue Swirl blauwirbel@gmail.com wrote:
On 4/19/09, Steven Noonan steven@uplinklabs.net wrote:
On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier Laurent@lvivier.info wrote: > Le dimanche 19 avril 2009 à 00:50 -0700, Steven Noonan a écrit : >> On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan steven@uplinklabs.net wrote: >> > On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier Laurent@lvivier.info wrote: >> >> OpenBIOS is not able to boot MacOS X. >> >
[...] $=:>> XCOFF - load_xcoff: Loading 'System\Library\CoreServices\BootX'
XCOFF - load_xcoff: XCOFF file with 3 sections entry:fff0a22c XCOFF - load_xcoff: Read next header (5c) XCOFF - load_xcoff: Load '.text' section from 5c d4 to 5600000 (28000) XCOFF - load_xcoff: Read next header (84) XCOFF - load_xcoff: Load '.data' section from 84 280d4 to 5628000 (2000) XCOFF - load_xcoff: Read next header (ac) XCOFF - load_xcoff: Erase '.bss' section at 562a000 size: 3a000 ELF - transfer_control_to_elf: Starting ELF boot loader
invalid/unsupported opcode: 02 - 0e - 0c (0b717b1c) 05616ed8 1 invalid/unsupported opcode: 00 - 14 - 13 (000064e8) 000094d0 0 Alcarin:qemu steven$
So at least with my patches, we're getting what people with QEMU 0.8.0 were getting: http://tinyurl.com/qemu080
So now what's left is resolving -why- that 'invalid/unsupported opcode' issue crops up.
I think the booloader is loaded at addresses overwriting some parts of openbios.
That would make sense, but that tells me QEMU is loading OpenBIOS to the wrong location. From the book "Mac OS X Internals: A Systems Approach":
Table 45. BootX Logical Memory Map
Starting Address Ending Address Purpose 0x00000000 0x00003FFF Exception vectors. 0x00004000 0x03FFFFFF Kernel image, boot structures, and drivers. 0x04000000 0x04FFFFFF File load area. 0x05000000 0x053FFFFF Simple read-time cache for file system metadata. Cache hits are serviced from memory, whereas cache misses result in disk access. 0x05400000 0x055FFFFF Malloc zone: a simple memory allocator is implemented in BootX's libclite subproject. The starting and ending addresses of this range define the block of memory used by the allocator. 0x05600000 0x057FFFFF BootX image. 0x05800000 0x05FFFFFF Unused (occupied by the Open Firmware image).
So it should be loading OpenBIOS to address 0x05800000, and the BootX image should load to 0x05600000 (the latter does as it should, according to the debug output).
Le dimanche 19 avril 2009 à 13:14 -0700, Steven Noonan a écrit :
On Sun, Apr 19, 2009 at 1:08 PM, Laurent Vivier Laurent@lvivier.info wrote:
Le dimanche 19 avril 2009 à 13:00 -0700, Steven Noonan a écrit :
On Sun, Apr 19, 2009 at 12:23 PM, Blue Swirl blauwirbel@gmail.com wrote:
On 4/19/09, Steven Noonan steven@uplinklabs.net wrote:
On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier Laurent@lvivier.info wrote:
Le dimanche 19 avril 2009 à 00:50 -0700, Steven Noonan a écrit : > On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan steven@uplinklabs.net wrote: > > On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier Laurent@lvivier.info wrote: > >> OpenBIOS is not able to boot MacOS X. > >
[...] $=:>> XCOFF - load_xcoff: Loading 'System\Library\CoreServices\BootX'
XCOFF - load_xcoff: XCOFF file with 3 sections entry:fff0a22c XCOFF - load_xcoff: Read next header (5c) XCOFF - load_xcoff: Load '.text' section from 5c d4 to 5600000 (28000) XCOFF - load_xcoff: Read next header (84) XCOFF - load_xcoff: Load '.data' section from 84 280d4 to 5628000 (2000) XCOFF - load_xcoff: Read next header (ac) XCOFF - load_xcoff: Erase '.bss' section at 562a000 size: 3a000 ELF - transfer_control_to_elf: Starting ELF boot loader
invalid/unsupported opcode: 02 - 0e - 0c (0b717b1c) 05616ed8 1 invalid/unsupported opcode: 00 - 14 - 13 (000064e8) 000094d0 0 Alcarin:qemu steven$
So at least with my patches, we're getting what people with QEMU 0.8.0 were getting: http://tinyurl.com/qemu080
So now what's left is resolving -why- that 'invalid/unsupported opcode' issue crops up.
I think the booloader is loaded at addresses overwriting some parts of openbios.
That would make sense, but that tells me QEMU is loading OpenBIOS to
The problem is in OpenBios: I put some structures in memory without knowing this... but this is not part of openfirmware specification.
the wrong location. From the book "Mac OS X Internals: A Systems Approach":
Table 45. BootX Logical Memory Map
Starting Address Ending Address Purpose 0x00000000 0x00003FFF Exception vectors. 0x00004000 0x03FFFFFF Kernel image, boot structures, and drivers.
I put there some memory allocation information.
0x04000000 0x04FFFFFF File load area. 0x05000000 0x053FFFFF Simple read-time cache for file system metadata. Cache hits are serviced from memory, whereas cache misses result in disk access. 0x05400000 0x055FFFFF Malloc zone: a simple memory allocator is implemented in BootX's libclite subproject. The starting and ending addresses of this range define the block of memory used by the allocator.
BootX should use openBIOS functions to allocate memory (as Yaboot does...)
0x05600000 0x057FFFFF BootX image.
This should be "load-base"
0x05800000 0x05FFFFFF Unused (occupied by the Open Firmware image).
So it should be loading OpenBIOS to address 0x05800000, and the BootX image should load to 0x05600000 (the latter does as it should, according to the debug output).
For the moment OpenBIOS is loaded at end physical memory and mapped at end of space address (the reset vector is here).
Regards, Laurent
On Sun, Apr 19, 2009 at 1:24 PM, Laurent Vivier Laurent@vivier.eu wrote:
Le dimanche 19 avril 2009 à 13:14 -0700, Steven Noonan a écrit :
On Sun, Apr 19, 2009 at 1:08 PM, Laurent Vivier Laurent@lvivier.info wrote:
Le dimanche 19 avril 2009 à 13:00 -0700, Steven Noonan a écrit :
On Sun, Apr 19, 2009 at 12:23 PM, Blue Swirl blauwirbel@gmail.com wrote:
On 4/19/09, Steven Noonan steven@uplinklabs.net wrote:
On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier Laurent@lvivier.info wrote: > Le dimanche 19 avril 2009 à 00:50 -0700, Steven Noonan a écrit : >> On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan steven@uplinklabs.net wrote: >> > On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier Laurent@lvivier.info wrote: >> >> OpenBIOS is not able to boot MacOS X. >> >
[...] $=:>> XCOFF - load_xcoff: Loading 'System\Library\CoreServices\BootX'
XCOFF - load_xcoff: XCOFF file with 3 sections entry:fff0a22c XCOFF - load_xcoff: Read next header (5c) XCOFF - load_xcoff: Load '.text' section from 5c d4 to 5600000 (28000) XCOFF - load_xcoff: Read next header (84) XCOFF - load_xcoff: Load '.data' section from 84 280d4 to 5628000 (2000) XCOFF - load_xcoff: Read next header (ac) XCOFF - load_xcoff: Erase '.bss' section at 562a000 size: 3a000 ELF - transfer_control_to_elf: Starting ELF boot loader
invalid/unsupported opcode: 02 - 0e - 0c (0b717b1c) 05616ed8 1 invalid/unsupported opcode: 00 - 14 - 13 (000064e8) 000094d0 0 Alcarin:qemu steven$
So at least with my patches, we're getting what people with QEMU 0.8.0 were getting: http://tinyurl.com/qemu080
So now what's left is resolving -why- that 'invalid/unsupported opcode' issue crops up.
I think the booloader is loaded at addresses overwriting some parts of openbios.
That would make sense, but that tells me QEMU is loading OpenBIOS to
The problem is in OpenBios: I put some structures in memory without knowing this... but this is not part of openfirmware specification.
Agreed, this seems to be an undocumented Apple-ism. But since OSes other than Mac OS X run on PowerPC macs (i.e. BSD, Linux), I must assume that they are aware of these quirks and don't hammer those memory locations. Since that's the case, it may be wise to conform to what Apple's Open Firmware does, even if it _is_ undocumented.
How easy would it be to get OpenBIOS to load to the position Mac OS X and BootX expect it to be? Based on what the book says, there are 8MB of memory available to the Open Firmware, would that be enough for the OpenBIOS executable image and any allocations it would need to perform?
the wrong location. From the book "Mac OS X Internals: A Systems Approach":
Table 45. BootX Logical Memory Map
Starting Address Ending Address Purpose 0x00000000 0x00003FFF Exception vectors. 0x00004000 0x03FFFFFF Kernel image, boot structures, and drivers.
I put there some memory allocation information.
0x04000000 0x04FFFFFF File load area. 0x05000000 0x053FFFFF Simple read-time cache for file system metadata. Cache hits are serviced from memory, whereas cache misses result in disk access. 0x05400000 0x055FFFFF Malloc zone: a simple memory allocator is implemented in BootX's libclite subproject. The starting and ending addresses of this range define the block of memory used by the allocator.
BootX should use openBIOS functions to allocate memory (as Yaboot does...)
Apparently BootX is tricky that way. I don't have the BootX source code, so I can't verify the author's statement, but I would guess he knows what he's talking about.
0x05600000 0x057FFFFF BootX image.
This should be "load-base"
0x05800000 0x05FFFFFF Unused (occupied by the Open Firmware image).
So it should be loading OpenBIOS to address 0x05800000, and the BootX image should load to 0x05600000 (the latter does as it should, according to the debug output).
For the moment OpenBIOS is loaded at end physical memory and mapped at end of space address (the reset vector is here).
Alright, is that location part of the official specification? If so, good, then we could use that memory for any allocations OpenBIOS would need to do. If not, then who's to say that location won't get hammered by the OS or boot loader?
Le dimanche 19 avril 2009 à 13:33 -0700, Steven Noonan a écrit :
On Sun, Apr 19, 2009 at 1:24 PM, Laurent Vivier Laurent@vivier.eu wrote:
Le dimanche 19 avril 2009 à 13:14 -0700, Steven Noonan a écrit :
On Sun, Apr 19, 2009 at 1:08 PM, Laurent Vivier Laurent@lvivier.info wrote:
Le dimanche 19 avril 2009 à 13:00 -0700, Steven Noonan a écrit :
On Sun, Apr 19, 2009 at 12:23 PM, Blue Swirl blauwirbel@gmail.com wrote:
On 4/19/09, Steven Noonan steven@uplinklabs.net wrote: > On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier Laurent@lvivier.info wrote: > > Le dimanche 19 avril 2009 à 00:50 -0700, Steven Noonan a écrit : > >> On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan steven@uplinklabs.net wrote: > >> > On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier Laurent@lvivier.info wrote: > >> >> OpenBIOS is not able to boot MacOS X. > >> >
[...] $=:>> XCOFF - load_xcoff: Loading 'System\Library\CoreServices\BootX'
> XCOFF - load_xcoff: XCOFF file with 3 sections entry:fff0a22c > XCOFF - load_xcoff: Read next header (5c) > XCOFF - load_xcoff: Load '.text' section from 5c d4 to 5600000 (28000) > XCOFF - load_xcoff: Read next header (84) > XCOFF - load_xcoff: Load '.data' section from 84 280d4 to 5628000 (2000) > XCOFF - load_xcoff: Read next header (ac) > XCOFF - load_xcoff: Erase '.bss' section at 562a000 size: 3a000 > ELF - transfer_control_to_elf: Starting ELF boot loader
invalid/unsupported opcode: 02 - 0e - 0c (0b717b1c) 05616ed8 1 invalid/unsupported opcode: 00 - 14 - 13 (000064e8) 000094d0 0 Alcarin:qemu steven$
So at least with my patches, we're getting what people with QEMU 0.8.0 were getting: http://tinyurl.com/qemu080
So now what's left is resolving -why- that 'invalid/unsupported opcode' issue crops up.
I think the booloader is loaded at addresses overwriting some parts of openbios.
That would make sense, but that tells me QEMU is loading OpenBIOS to
The problem is in OpenBios: I put some structures in memory without knowing this... but this is not part of openfirmware specification.
Agreed, this seems to be an undocumented Apple-ism. But since OSes other than Mac OS X run on PowerPC macs (i.e. BSD, Linux), I must
AIX is also using OpenFirmware / PPC / CHRP, and I think they don't care of Apple-ism.
assume that they are aware of these quirks and don't hammer those memory locations. Since that's the case, it may be wise to conform to what Apple's Open Firmware does, even if it _is_ undocumented.
'Yes, we can' (R).
How easy would it be to get OpenBIOS to load to the position Mac OS X and BootX expect it to be? Based on what the book says, there are 8MB of memory available to the Open Firmware, would that be enough for the OpenBIOS executable image and any allocations it would need to perform?
the wrong location. From the book "Mac OS X Internals: A Systems Approach":
Table 45. BootX Logical Memory Map
Starting Address Ending Address Purpose 0x00000000 0x00003FFF Exception vectors. 0x00004000 0x03FFFFFF Kernel image, boot structures, and drivers.
I put there some memory allocation information.
0x04000000 0x04FFFFFF File load area. 0x05000000 0x053FFFFF Simple read-time cache for file system metadata. Cache hits are serviced from memory, whereas cache misses result in disk access. 0x05400000 0x055FFFFF Malloc zone: a simple memory allocator is implemented in BootX's libclite subproject. The starting and ending addresses of this range define the block of memory used by the allocator.
BootX should use openBIOS functions to allocate memory (as Yaboot does...)
Apparently BootX is tricky that way. I don't have the BootX source code, so I can't verify the author's statement, but I would guess he knows what he's talking about.
Look here:
http://www.opensource.apple.com/darwinsource/tarballs/apsl/BootX-81.tar.gz
(You need an Apple Developer ID)
Regards, Laurent
On Sun, Apr 19, 2009 at 1:48 PM, Laurent Vivier Laurent@vivier.eu wrote:
Le dimanche 19 avril 2009 à 13:33 -0700, Steven Noonan a écrit :
On Sun, Apr 19, 2009 at 1:24 PM, Laurent Vivier Laurent@vivier.eu wrote:
Le dimanche 19 avril 2009 à 13:14 -0700, Steven Noonan a écrit :
On Sun, Apr 19, 2009 at 1:08 PM, Laurent Vivier Laurent@lvivier.info wrote:
Le dimanche 19 avril 2009 à 13:00 -0700, Steven Noonan a écrit :
On Sun, Apr 19, 2009 at 12:23 PM, Blue Swirl blauwirbel@gmail.com wrote: > On 4/19/09, Steven Noonan steven@uplinklabs.net wrote: >> On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier Laurent@lvivier.info wrote: >> > Le dimanche 19 avril 2009 à 00:50 -0700, Steven Noonan a écrit : >> >> On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan steven@uplinklabs.net wrote: >> >> > On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier Laurent@lvivier.info wrote: >> >> >> OpenBIOS is not able to boot MacOS X. >> >> > [...] $=:>> XCOFF - load_xcoff: Loading 'System\Library\CoreServices\BootX' >> XCOFF - load_xcoff: XCOFF file with 3 sections entry:fff0a22c >> XCOFF - load_xcoff: Read next header (5c) >> XCOFF - load_xcoff: Load '.text' section from 5c d4 to 5600000 (28000) >> XCOFF - load_xcoff: Read next header (84) >> XCOFF - load_xcoff: Load '.data' section from 84 280d4 to 5628000 (2000) >> XCOFF - load_xcoff: Read next header (ac) >> XCOFF - load_xcoff: Erase '.bss' section at 562a000 size: 3a000 >> ELF - transfer_control_to_elf: Starting ELF boot loader invalid/unsupported opcode: 02 - 0e - 0c (0b717b1c) 05616ed8 1 invalid/unsupported opcode: 00 - 14 - 13 (000064e8) 000094d0 0 Alcarin:qemu steven$
So at least with my patches, we're getting what people with QEMU 0.8.0 were getting: http://tinyurl.com/qemu080
So now what's left is resolving -why- that 'invalid/unsupported opcode' issue crops up.
I think the booloader is loaded at addresses overwriting some parts of openbios.
That would make sense, but that tells me QEMU is loading OpenBIOS to
The problem is in OpenBios: I put some structures in memory without knowing this... but this is not part of openfirmware specification.
Agreed, this seems to be an undocumented Apple-ism. But since OSes other than Mac OS X run on PowerPC macs (i.e. BSD, Linux), I must
AIX is also using OpenFirmware / PPC / CHRP, and I think they don't care of Apple-ism.
assume that they are aware of these quirks and don't hammer those memory locations. Since that's the case, it may be wise to conform to what Apple's Open Firmware does, even if it _is_ undocumented.
'Yes, we can' (R).
How easy would it be to get OpenBIOS to load to the position Mac OS X and BootX expect it to be? Based on what the book says, there are 8MB of memory available to the Open Firmware, would that be enough for the OpenBIOS executable image and any allocations it would need to perform?
the wrong location. From the book "Mac OS X Internals: A Systems Approach":
Table 45. BootX Logical Memory Map
Starting Address Ending Address Purpose 0x00000000 0x00003FFF Exception vectors. 0x00004000 0x03FFFFFF Kernel image, boot structures, and drivers.
I put there some memory allocation information.
0x04000000 0x04FFFFFF File load area. 0x05000000 0x053FFFFF Simple read-time cache for file system metadata. Cache hits are serviced from memory, whereas cache misses result in disk access. 0x05400000 0x055FFFFF Malloc zone: a simple memory allocator is implemented in BootX's libclite subproject. The starting and ending addresses of this range define the block of memory used by the allocator.
BootX should use openBIOS functions to allocate memory (as Yaboot does...)
Apparently BootX is tricky that way. I don't have the BootX source code, so I can't verify the author's statement, but I would guess he knows what he's talking about.
Look here:
http://www.opensource.apple.com/darwinsource/tarballs/apsl/BootX-81.tar.gz
(You need an Apple Developer ID)
Aha. From sl.h:
/*
Memory Map: assumed 96 MB (temporarily bumping to 112 MB for 4359362)
Physical Address
Open Firmware Version 3x, 4x, ... 00000000 - 00003FFF : Exception Vectors 00004000 - 057FFFFF : Free Memory // 05800000 - 05FFFFFF : OF Image (top 8 MB reserved) [96 MB map] 06800000 - 06FFFFFF : OF Image (top 8 MB reserved) [112 MB map]
Logical Address
// 96 MB map (currently unused - 4363357 tracks re-adoption) 00000000 - 00003FFF : Exception Vectors 00004000 - 03FFFFFF : Kernel Image, Boot Struct and Drivers (~64 MB) 04000000 - 04FFFFFF : File Load Area (16 MB) [80 MB] 05000000 - 053FFFFF : FS Cache (4 MB) [84 MB] 05400000 - 055FFFFF : Malloc Zone (2 MB) [86 MB] 05600000 - 057FFFFF : BootX Image (2 MB) [88 MB] 05800000 - 05FFFFFF : Unused/OF (8 MB) [96 MB]
// 112 MB map (per 4359362) 00000000 - 00003FFF : Exception Vectors 00004000 - 03FFFFFF : Kernel Image, Boot Struct and Drivers (~64 MB) 04000000 - 05FFFFFF : File Load Area (32 MB) [96 MB] 06000000 - 063FFFFF : FS Cache (4 MB) [100 MB] 06400000 - 065FFFFF : Malloc Zone (2 MB) [102 MB] 06600000 - 067FFFFF : BootX Image (2 MB) [104 MB] 06800000 - 06FFFFFF : Unused/OF (8 MB) [112 MB] */
The 96MB map looks like what we're trying to conform to. I wonder what this "4359362" they refer to is? An internal bug number or document number?
On Sun, Apr 19, 2009 at 2:02 PM, Steven Noonan steven@uplinklabs.net wrote:
On Sun, Apr 19, 2009 at 1:48 PM, Laurent Vivier Laurent@vivier.eu wrote:
Le dimanche 19 avril 2009 à 13:33 -0700, Steven Noonan a écrit :
On Sun, Apr 19, 2009 at 1:24 PM, Laurent Vivier Laurent@vivier.eu wrote:
Le dimanche 19 avril 2009 à 13:14 -0700, Steven Noonan a écrit : The problem is in OpenBios: I put some structures in memory without knowing this... but this is not part of openfirmware specification.
Agreed, this seems to be an undocumented Apple-ism. But since OSes other than Mac OS X run on PowerPC macs (i.e. BSD, Linux), I must
AIX is also using OpenFirmware / PPC / CHRP, and I think they don't care of Apple-ism.
assume that they are aware of these quirks and don't hammer those memory locations. Since that's the case, it may be wise to conform to what Apple's Open Firmware does, even if it _is_ undocumented.
'Yes, we can' (R).
How easy would it be to get OpenBIOS to load to the position Mac OS X and BootX expect it to be? Based on what the book says, there are 8MB of memory available to the Open Firmware, would that be enough for the OpenBIOS executable image and any allocations it would need to perform?
the wrong location. From the book "Mac OS X Internals: A Systems Approach":
Table 45. BootX Logical Memory Map
Starting Address Ending Address Purpose 0x00000000 0x00003FFF Exception vectors. 0x00004000 0x03FFFFFF Kernel image, boot structures, and drivers.
I put there some memory allocation information.
0x04000000 0x04FFFFFF File load area. 0x05000000 0x053FFFFF Simple read-time cache for file system metadata. Cache hits are serviced from memory, whereas cache misses result in disk access. 0x05400000 0x055FFFFF Malloc zone: a simple memory allocator is implemented in BootX's libclite subproject. The starting and ending addresses of this range define the block of memory used by the allocator.
BootX should use openBIOS functions to allocate memory (as Yaboot does...)
Apparently BootX is tricky that way. I don't have the BootX source code, so I can't verify the author's statement, but I would guess he knows what he's talking about.
Look here:
http://www.opensource.apple.com/darwinsource/tarballs/apsl/BootX-81.tar.gz
(You need an Apple Developer ID)
Aha. From sl.h:
/*
Memory Map: assumed 96 MB (temporarily bumping to 112 MB for 4359362)
Physical Address
Open Firmware Version 3x, 4x, ... 00000000 - 00003FFF : Exception Vectors 00004000 - 057FFFFF : Free Memory // 05800000 - 05FFFFFF : OF Image (top 8 MB reserved) [96 MB map] 06800000 - 06FFFFFF : OF Image (top 8 MB reserved) [112 MB map]
Logical Address
// 96 MB map (currently unused - 4363357 tracks re-adoption) 00000000 - 00003FFF : Exception Vectors 00004000 - 03FFFFFF : Kernel Image, Boot Struct and Drivers (~64 MB) 04000000 - 04FFFFFF : File Load Area (16 MB) [80 MB] 05000000 - 053FFFFF : FS Cache (4 MB) [84 MB] 05400000 - 055FFFFF : Malloc Zone (2 MB) [86 MB] 05600000 - 057FFFFF : BootX Image (2 MB) [88 MB] 05800000 - 05FFFFFF : Unused/OF (8 MB) [96 MB]
// 112 MB map (per 4359362) 00000000 - 00003FFF : Exception Vectors 00004000 - 03FFFFFF : Kernel Image, Boot Struct and Drivers (~64 MB) 04000000 - 05FFFFFF : File Load Area (32 MB) [96 MB] 06000000 - 063FFFFF : FS Cache (4 MB) [100 MB] 06400000 - 065FFFFF : Malloc Zone (2 MB) [102 MB] 06600000 - 067FFFFF : BootX Image (2 MB) [104 MB] 06800000 - 06FFFFFF : Unused/OF (8 MB) [112 MB] */
The 96MB map looks like what we're trying to conform to. I wonder what this "4359362" they refer to is? An internal bug number or document number?
OK, so I guess we should use the 112MB map, since the other one says "currently unused", which reads to me as "deprecated".
So I'm looking into changing it to load to the position Apple's Open Firmware would. Do these values seem right to you? (it's intentionally space-smashed to prevent someone applying this to mainline)
diff --git a/arch/ppc/qemu/ldscript b/arch/ppc/qemu/ldscript index 66fcbcd..8fdf654 100644 --- a/arch/ppc/qemu/ldscript +++ b/arch/ppc/qemu/ldscript @@ -3,15 +3,15 @@ OUTPUT_ARCH(powerpc) /* Initial load address */ -BASE_ADDR = 0xfff00000; +BASE_ADDR = 0x06800000; -/* As NVRAM is at 0xfff04000, the .text needs to be after that +/* As NVRAM is at 0x06804000, the .text needs to be after that */ -TEXT_ADDR = 0xfff08000; +TEXT_ADDR = 0x06808000; /* Hard reset vector address */ -HRESET_ADDR = 0xfffffffc; +HRESET_ADDR = 0x06ffffff; CSTACK_SIZE = 32768; /* client stack size */
The only issue with doing things this way is now to figure out what to change this to:
#define FREE_BASE 0x00004000
My first thought was to utilize all 8MB of the space that Apple says we can have, and use any space after the OpenBIOS image. My second thought was: how do we know where the OpenBIOS executable image ends?
Any ideas?
On Sun, Apr 19, 2009 at 2:32 PM, Steven Noonan steven@uplinklabs.net wrote:
On Sun, Apr 19, 2009 at 2:02 PM, Steven Noonan steven@uplinklabs.net wrote:
On Sun, Apr 19, 2009 at 1:48 PM, Laurent Vivier Laurent@vivier.eu wrote:
Le dimanche 19 avril 2009 à 13:33 -0700, Steven Noonan a écrit :
On Sun, Apr 19, 2009 at 1:24 PM, Laurent Vivier Laurent@vivier.eu wrote:
Le dimanche 19 avril 2009 à 13:14 -0700, Steven Noonan a écrit : The problem is in OpenBios: I put some structures in memory without knowing this... but this is not part of openfirmware specification.
Agreed, this seems to be an undocumented Apple-ism. But since OSes other than Mac OS X run on PowerPC macs (i.e. BSD, Linux), I must
AIX is also using OpenFirmware / PPC / CHRP, and I think they don't care of Apple-ism.
assume that they are aware of these quirks and don't hammer those memory locations. Since that's the case, it may be wise to conform to what Apple's Open Firmware does, even if it _is_ undocumented.
'Yes, we can' (R).
How easy would it be to get OpenBIOS to load to the position Mac OS X and BootX expect it to be? Based on what the book says, there are 8MB of memory available to the Open Firmware, would that be enough for the OpenBIOS executable image and any allocations it would need to perform?
the wrong location. From the book "Mac OS X Internals: A Systems Approach":
Table 45. BootX Logical Memory Map
Starting Address Ending Address Purpose 0x00000000 0x00003FFF Exception vectors. 0x00004000 0x03FFFFFF Kernel image, boot structures, and drivers.
I put there some memory allocation information.
0x04000000 0x04FFFFFF File load area. 0x05000000 0x053FFFFF Simple read-time cache for file system metadata. Cache hits are serviced from memory, whereas cache misses result in disk access. 0x05400000 0x055FFFFF Malloc zone: a simple memory allocator is implemented in BootX's libclite subproject. The starting and ending addresses of this range define the block of memory used by the allocator.
BootX should use openBIOS functions to allocate memory (as Yaboot does...)
Apparently BootX is tricky that way. I don't have the BootX source code, so I can't verify the author's statement, but I would guess he knows what he's talking about.
Look here:
http://www.opensource.apple.com/darwinsource/tarballs/apsl/BootX-81.tar.gz
(You need an Apple Developer ID)
Aha. From sl.h:
/*
Memory Map: assumed 96 MB (temporarily bumping to 112 MB for 4359362)
Physical Address
Open Firmware Version 3x, 4x, ... 00000000 - 00003FFF : Exception Vectors 00004000 - 057FFFFF : Free Memory // 05800000 - 05FFFFFF : OF Image (top 8 MB reserved) [96 MB map] 06800000 - 06FFFFFF : OF Image (top 8 MB reserved) [112 MB map]
Logical Address
// 96 MB map (currently unused - 4363357 tracks re-adoption) 00000000 - 00003FFF : Exception Vectors 00004000 - 03FFFFFF : Kernel Image, Boot Struct and Drivers (~64 MB) 04000000 - 04FFFFFF : File Load Area (16 MB) [80 MB] 05000000 - 053FFFFF : FS Cache (4 MB) [84 MB] 05400000 - 055FFFFF : Malloc Zone (2 MB) [86 MB] 05600000 - 057FFFFF : BootX Image (2 MB) [88 MB] 05800000 - 05FFFFFF : Unused/OF (8 MB) [96 MB]
// 112 MB map (per 4359362) 00000000 - 00003FFF : Exception Vectors 00004000 - 03FFFFFF : Kernel Image, Boot Struct and Drivers (~64 MB) 04000000 - 05FFFFFF : File Load Area (32 MB) [96 MB] 06000000 - 063FFFFF : FS Cache (4 MB) [100 MB] 06400000 - 065FFFFF : Malloc Zone (2 MB) [102 MB] 06600000 - 067FFFFF : BootX Image (2 MB) [104 MB] 06800000 - 06FFFFFF : Unused/OF (8 MB) [112 MB] */
The 96MB map looks like what we're trying to conform to. I wonder what this "4359362" they refer to is? An internal bug number or document number?
OK, so I guess we should use the 112MB map, since the other one says "currently unused", which reads to me as "deprecated".
So I'm looking into changing it to load to the position Apple's Open Firmware would. Do these values seem right to you? (it's intentionally space-smashed to prevent someone applying this to mainline)
diff --git a/arch/ppc/qemu/ldscript b/arch/ppc/qemu/ldscript index 66fcbcd..8fdf654 100644 --- a/arch/ppc/qemu/ldscript +++ b/arch/ppc/qemu/ldscript @@ -3,15 +3,15 @@ OUTPUT_ARCH(powerpc)
/* Initial load address */ -BASE_ADDR = 0xfff00000; +BASE_ADDR = 0x06800000;
-/* As NVRAM is at 0xfff04000, the .text needs to be after that +/* As NVRAM is at 0x06804000, the .text needs to be after that */ -TEXT_ADDR = 0xfff08000; +TEXT_ADDR = 0x06808000;
/* Hard reset vector address */ -HRESET_ADDR = 0xfffffffc; +HRESET_ADDR = 0x06ffffff;
CSTACK_SIZE = 32768; /* client stack size */
With the above numbers, I get linker problems:
target/arch/ppc/qemu/start.o: In function `vector__0x300': (.text.vectors+0x384): relocation truncated to fit: R_PPC_ADDR24 against `.text.vectors'+c target/arch/ppc/qemu/start.o: In function `vector__0x400': (.text.vectors+0x484): relocation truncated to fit: R_PPC_ADDR24 against `.text.vectors'+c
I don't see why it'd do that.
The only issue with doing things this way is now to figure out what to change this to:
#define FREE_BASE 0x00004000
My first thought was to utilize all 8MB of the space that Apple says we can have, and use any space after the OpenBIOS image. My second thought was: how do we know where the OpenBIOS executable image ends?
Any ideas?
On Sun, Apr 19, 2009 at 3:28 PM, Steven Noonan steven@uplinklabs.net wrote:
On Sun, Apr 19, 2009 at 2:32 PM, Steven Noonan steven@uplinklabs.net wrote:
On Sun, Apr 19, 2009 at 2:02 PM, Steven Noonan steven@uplinklabs.net wrote:
On Sun, Apr 19, 2009 at 1:48 PM, Laurent Vivier Laurent@vivier.eu wrote:
Le dimanche 19 avril 2009 à 13:33 -0700, Steven Noonan a écrit :
On Sun, Apr 19, 2009 at 1:24 PM, Laurent Vivier Laurent@vivier.eu wrote:
Le dimanche 19 avril 2009 à 13:14 -0700, Steven Noonan a écrit : The problem is in OpenBios: I put some structures in memory without knowing this... but this is not part of openfirmware specification.
Agreed, this seems to be an undocumented Apple-ism. But since OSes other than Mac OS X run on PowerPC macs (i.e. BSD, Linux), I must
AIX is also using OpenFirmware / PPC / CHRP, and I think they don't care of Apple-ism.
assume that they are aware of these quirks and don't hammer those memory locations. Since that's the case, it may be wise to conform to what Apple's Open Firmware does, even if it _is_ undocumented.
'Yes, we can' (R).
How easy would it be to get OpenBIOS to load to the position Mac OS X and BootX expect it to be? Based on what the book says, there are 8MB of memory available to the Open Firmware, would that be enough for the OpenBIOS executable image and any allocations it would need to perform?
> the wrong location. From the book "Mac OS X Internals: A Systems > Approach": > > Table 45. BootX Logical Memory Map > > Starting Address Ending Address Purpose > 0x00000000 0x00003FFF Exception vectors. > 0x00004000 0x03FFFFFF Kernel image, boot structures, and drivers.
I put there some memory allocation information.
> 0x04000000 0x04FFFFFF File load area. > 0x05000000 0x053FFFFF Simple read-time cache for file system > metadata. Cache hits are serviced from memory, whereas cache misses > result in disk access. > 0x05400000 0x055FFFFF Malloc zone: a simple memory allocator is > implemented in BootX's libclite subproject. The starting and ending > addresses of this range define the block of memory used by the > allocator.
BootX should use openBIOS functions to allocate memory (as Yaboot does...)
Apparently BootX is tricky that way. I don't have the BootX source code, so I can't verify the author's statement, but I would guess he knows what he's talking about.
Look here:
http://www.opensource.apple.com/darwinsource/tarballs/apsl/BootX-81.tar.gz
(You need an Apple Developer ID)
Aha. From sl.h:
/*
Memory Map: assumed 96 MB (temporarily bumping to 112 MB for 4359362)
Physical Address
Open Firmware Version 3x, 4x, ... 00000000 - 00003FFF : Exception Vectors 00004000 - 057FFFFF : Free Memory // 05800000 - 05FFFFFF : OF Image (top 8 MB reserved) [96 MB map] 06800000 - 06FFFFFF : OF Image (top 8 MB reserved) [112 MB map]
Logical Address
// 96 MB map (currently unused - 4363357 tracks re-adoption) 00000000 - 00003FFF : Exception Vectors 00004000 - 03FFFFFF : Kernel Image, Boot Struct and Drivers (~64 MB) 04000000 - 04FFFFFF : File Load Area (16 MB) [80 MB] 05000000 - 053FFFFF : FS Cache (4 MB) [84 MB] 05400000 - 055FFFFF : Malloc Zone (2 MB) [86 MB] 05600000 - 057FFFFF : BootX Image (2 MB) [88 MB] 05800000 - 05FFFFFF : Unused/OF (8 MB) [96 MB]
// 112 MB map (per 4359362) 00000000 - 00003FFF : Exception Vectors 00004000 - 03FFFFFF : Kernel Image, Boot Struct and Drivers (~64 MB) 04000000 - 05FFFFFF : File Load Area (32 MB) [96 MB] 06000000 - 063FFFFF : FS Cache (4 MB) [100 MB] 06400000 - 065FFFFF : Malloc Zone (2 MB) [102 MB] 06600000 - 067FFFFF : BootX Image (2 MB) [104 MB] 06800000 - 06FFFFFF : Unused/OF (8 MB) [112 MB] */
The 96MB map looks like what we're trying to conform to. I wonder what this "4359362" they refer to is? An internal bug number or document number?
OK, so I guess we should use the 112MB map, since the other one says "currently unused", which reads to me as "deprecated".
So I'm looking into changing it to load to the position Apple's Open Firmware would. Do these values seem right to you? (it's intentionally space-smashed to prevent someone applying this to mainline)
diff --git a/arch/ppc/qemu/ldscript b/arch/ppc/qemu/ldscript index 66fcbcd..8fdf654 100644 --- a/arch/ppc/qemu/ldscript +++ b/arch/ppc/qemu/ldscript @@ -3,15 +3,15 @@ OUTPUT_ARCH(powerpc)
/* Initial load address */ -BASE_ADDR = 0xfff00000; +BASE_ADDR = 0x06800000;
-/* As NVRAM is at 0xfff04000, the .text needs to be after that +/* As NVRAM is at 0x06804000, the .text needs to be after that */ -TEXT_ADDR = 0xfff08000; +TEXT_ADDR = 0x06808000;
/* Hard reset vector address */ -HRESET_ADDR = 0xfffffffc; +HRESET_ADDR = 0x06ffffff;
CSTACK_SIZE = 32768; /* client stack size */
With the above numbers, I get linker problems:
target/arch/ppc/qemu/start.o: In function `vector__0x300': (.text.vectors+0x384): relocation truncated to fit: R_PPC_ADDR24 against `.text.vectors'+c target/arch/ppc/qemu/start.o: In function `vector__0x400': (.text.vectors+0x484): relocation truncated to fit: R_PPC_ADDR24 against `.text.vectors'+c
I don't see why it'd do that.
What the hell? Why would this change resolve it?
diff --git a/arch/ppc/qemu/start.S b/arch/ppc/qemu/start.S index 66df9a2..108fd9b 100644 --- a/arch/ppc/qemu/start.S +++ b/arch/ppc/qemu/start.S @@ -206,7 +206,7 @@ VECTOR( 0x300, "DSI" ): addi r3,r3,LO(dsi_exception) mtctr r3 bctrl - ba exception_return + b exception_return VECTOR( 0x400, "ISI" ): EXCEPTION_PREAMBLE @@ -214,7 +214,7 @@ VECTOR( 0x400, "ISI" ): addi r3,r3,LO(isi_exception) mtctr r3 bctrl - ba exception_return + b exception_return ILLEGAL_VECTOR( 0x500 ) ILLEGAL_VECTOR( 0x600 )
The only issue with doing things this way is now to figure out what to change this to:
#define FREE_BASE 0x00004000
My first thought was to utilize all 8MB of the space that Apple says we can have, and use any space after the OpenBIOS image. My second thought was: how do we know where the OpenBIOS executable image ends?
Any ideas?
On Sun, 19 Apr 2009, Steven Noonan wrote:
On Sun, Apr 19, 2009 at 3:28 PM, Steven Noonan steven@uplinklabs.net wrote:
On Sun, Apr 19, 2009 at 2:32 PM, Steven Noonan steven@uplinklabs.net wrote:
On Sun, Apr 19, 2009 at 2:02 PM, Steven Noonan steven@uplinklabs.net wrote:
On Sun, Apr 19, 2009 at 1:48 PM, Laurent Vivier Laurent@vivier.eu wrote:
Le dimanche 19 avril 2009 ? 13:33 -0700, Steven Noonan a ?crit :
On Sun, Apr 19, 2009 at 1:24 PM, Laurent Vivier Laurent@vivier.eu wrote: > Le dimanche 19 avril 2009 ? 13:14 -0700, Steven Noonan a ?crit : > The problem is in OpenBios: I put some structures in memory without > knowing this... but this is not part of openfirmware specification.
[..snip..]
diff --git a/arch/ppc/qemu/ldscript b/arch/ppc/qemu/ldscript index 66fcbcd..8fdf654 100644 --- a/arch/ppc/qemu/ldscript +++ b/arch/ppc/qemu/ldscript @@ -3,15 +3,15 @@ OUTPUT_ARCH(powerpc)
/* Initial load address */ -BASE_ADDR = 0xfff00000; +BASE_ADDR = 0x06800000;
-/* As NVRAM is at 0xfff04000, the .text needs to be after that +/* As NVRAM is at 0x06804000, the .text needs to be after that */ -TEXT_ADDR = 0xfff08000; +TEXT_ADDR = 0x06808000;
/* Hard reset vector address */ -HRESET_ADDR = 0xfffffffc; +HRESET_ADDR = 0x06ffffff;
CSTACK_SIZE = 32768; /* client stack size */
With the above numbers, I get linker problems:
target/arch/ppc/qemu/start.o: In function `vector__0x300': (.text.vectors+0x384): relocation truncated to fit: R_PPC_ADDR24 against `.text.vectors'+c target/arch/ppc/qemu/start.o: In function `vector__0x400': (.text.vectors+0x484): relocation truncated to fit: R_PPC_ADDR24 against `.text.vectors'+c
I don't see why it'd do that.
What the hell? Why would this change resolve it?
diff --git a/arch/ppc/qemu/start.S b/arch/ppc/qemu/start.S index 66df9a2..108fd9b 100644 --- a/arch/ppc/qemu/start.S +++ b/arch/ppc/qemu/start.S @@ -206,7 +206,7 @@ VECTOR( 0x300, "DSI" ): addi r3,r3,LO(dsi_exception) mtctr r3 bctrl
ba exception_return
b exception_return
Because exception_return's address (now near 0x06808000) doesn't fit into 26 bit sign extended AA field.
VECTOR( 0x400, "ISI" ): EXCEPTION_PREAMBLE@@ -214,7 +214,7 @@ VECTOR( 0x400, "ISI" ): addi r3,r3,LO(isi_exception) mtctr r3 bctrl
ba exception_return
b exception_return ILLEGAL_VECTOR( 0x500 ) ILLEGAL_VECTOR( 0x600 )The only issue with doing things this way is now to figure out what to change this to:
#define FREE_BASE 0x00004000
My first thought was to utilize all 8MB of the space that Apple says we can have, and use any space after the OpenBIOS image. My second thought was: how do we know where the OpenBIOS executable image ends?
Any ideas?
So I decided a better idea was to keep the OpenBIOS ROM where it is and then instead use the location 0x06800000 for the memory allocations so that the 0x4000 block doesn't get smashed. It was far more feasible than moving where the ROM is stored, and I don't think anything cares about the contents of 0x06800000 to 06FFFFFF anyway.
Also, the reason I was getting "invalid opcode" was because Open Hack'Ware's XCOFF loader didn't take into account some other unknown variable which PearPC accounted for. I added the necessary code to make that work.
So now instead of an invalid opcode, we get this (which I don't know how to debug. it looks like a Forth exception):
Alcarin:qemu steven$ make -C ppc-softmmu && ppc-softmmu/qemu-system-ppc -L pc-bios -cdrom ~/Development/MacOSX-10.4.iso -boot d -M mac99 -nographic make: Nothing to be done for `all'.
============================================================= OpenBIOS 1.0 [Apr 20 2009 03:23] Configuration device id QEMU version 1 machine id 1 CPUs: 1 Memory: 128M UUID: 00000000-0000-0000-0000-000000000000 CPU type PowerPC,G4
Welcome to OpenBIOS v1.0 built on Apr 20 2009 03:23
YABOOT - yaboot_startup: Entering boot, no path CHRP - try_chrp_script: Trying cd:0,ppc\bootinfo.txt MAC-PARTS: macparts_probe 4552 ?= 4552 MAC-PARTS: macparts_open 0 MAC-PARTS: macparts_get_info 0 2832209920 MAC-PARTS: macparts_block_size = 200 ELF - try_chrp_script: Can't open cd:0,ppc\bootinfo.txt CHRP - try_chrp_script: Trying cd:0,System\Library\CoreServices\BootX MAC-PARTS: macparts_probe 4552 ?= 4552 MAC-PARTS: macparts_open 0 MAC-PARTS: macparts_get_info 0 2832209920 MAC-PARTS: macparts_block_size = 200 CHRP - try_chrp_script: got bootscript load-base begin dup 6 " </CHRP" $= if 6 + dup 6 " -BOOT>" $= if 8 + true else false then else 1+ false then until ( xcoff-base ) load-size over load-base - - ( xcoff-base xcoff-size ) load-base swap move init-program go
ELF - encode_bootpath: bootpath cd:0,<NULL>\ bootargs <NULL>
$=:>> XCOFF - load_xcoff: Loading 'System\Library\CoreServices\BootX'
XCOFF - load_xcoff: XCOFF file with 3 sections entry:05616ecc XCOFF - load_xcoff: Read next header (5c) XCOFF - load_xcoff: Load '.text' section from 5c d4 to 5600000 (28000) XCOFF - load_xcoff: Found entry point offset in '.text': 94112 XCOFF - load_xcoff: Read next header (84) XCOFF - load_xcoff: Load '.data' section from 84 280d4 to 5628000 (2000) XCOFF - load_xcoff: Read next header (ac) XCOFF - load_xcoff: Erase '.bss' section at 562a000 size: 3a000 XCOFF - load_xcoff: Found actual entry point: 05600adc ELF - transfer_control_to_elf: Starting ELF boot loader
unselect-dev:interpret: exception -13 caught EXIT 0 > Killed
Any ideas?
- Steven
On Sun, Apr 19, 2009 at 8:27 PM, Steven Noonan steven@uplinklabs.net wrote:
So I decided a better idea was to keep the OpenBIOS ROM where it is and then instead use the location 0x06800000 for the memory allocations so that the 0x4000 block doesn't get smashed. It was far more feasible than moving where the ROM is stored, and I don't think anything cares about the contents of 0x06800000 to 06FFFFFF anyway.
Also, the reason I was getting "invalid opcode" was because Open Hack'Ware's XCOFF loader didn't take into account some other unknown variable which PearPC accounted for. I added the necessary code to make that work.
So now instead of an invalid opcode, we get this (which I don't know how to debug. it looks like a Forth exception):
Alcarin:qemu steven$ make -C ppc-softmmu && ppc-softmmu/qemu-system-ppc -L pc-bios -cdrom ~/Development/MacOSX-10.4.iso -boot d -M mac99 -nographic make: Nothing to be done for `all'.
============================================================= OpenBIOS 1.0 [Apr 20 2009 03:23] Configuration device id QEMU version 1 machine id 1 CPUs: 1 Memory: 128M UUID: 00000000-0000-0000-0000-000000000000 CPU type PowerPC,G4
Welcome to OpenBIOS v1.0 built on Apr 20 2009 03:23
YABOOT - yaboot_startup: Entering boot, no path CHRP - try_chrp_script: Trying cd:0,ppc\bootinfo.txt MAC-PARTS: macparts_probe 4552 ?= 4552 MAC-PARTS: macparts_open 0 MAC-PARTS: macparts_get_info 0 2832209920 MAC-PARTS: macparts_block_size = 200 ELF - try_chrp_script: Can't open cd:0,ppc\bootinfo.txt CHRP - try_chrp_script: Trying cd:0,System\Library\CoreServices\BootX MAC-PARTS: macparts_probe 4552 ?= 4552 MAC-PARTS: macparts_open 0 MAC-PARTS: macparts_get_info 0 2832209920 MAC-PARTS: macparts_block_size = 200 CHRP - try_chrp_script: got bootscript load-base begin dup 6 " </CHRP" $= if 6 + dup 6 " -BOOT>" $= if 8 + true else false then else 1+ false then until ( xcoff-base ) load-size over load-base - - ( xcoff-base xcoff-size ) load-base swap move init-program go
ELF - encode_bootpath: bootpath cd:0,<NULL>\ bootargs <NULL>
$=:>> XCOFF - load_xcoff: Loading 'System\Library\CoreServices\BootX'
XCOFF - load_xcoff: XCOFF file with 3 sections entry:05616ecc XCOFF - load_xcoff: Read next header (5c) XCOFF - load_xcoff: Load '.text' section from 5c d4 to 5600000 (28000) XCOFF - load_xcoff: Found entry point offset in '.text': 94112 XCOFF - load_xcoff: Read next header (84) XCOFF - load_xcoff: Load '.data' section from 84 280d4 to 5628000 (2000) XCOFF - load_xcoff: Read next header (ac) XCOFF - load_xcoff: Erase '.bss' section at 562a000 size: 3a000 XCOFF - load_xcoff: Found actual entry point: 05600adc ELF - transfer_control_to_elf: Starting ELF boot loader
unselect-dev:interpret: exception -13 caught EXIT 0 > Killed
Any ideas?
Also, my most recent changes are committed and pushed for public viewing: http://github.com/tycho/openbios/commits/macosx-boot
Steven Noonan (3): ofmem: don't clobber the position that Mac OS X's kernel resides in kernel/internal.c: incorrectly uses %x format where %lx is needed qemu/main.c: load embedded XCOFF binaries in CHRP scripts
- Steven
On 20.04.2009, at 05:50, Steven Noonan wrote:
On Sun, Apr 19, 2009 at 8:27 PM, Steven Noonan steven@uplinklabs.net wrote:
So I decided a better idea was to keep the OpenBIOS ROM where it is and then instead use the location 0x06800000 for the memory allocations so that the 0x4000 block doesn't get smashed. It was far more feasible than moving where the ROM is stored, and I don't think anything cares about the contents of 0x06800000 to 06FFFFFF anyway.
Also, the reason I was getting "invalid opcode" was because Open Hack'Ware's XCOFF loader didn't take into account some other unknown variable which PearPC accounted for. I added the necessary code to make that work.
So now instead of an invalid opcode, we get this (which I don't know how to debug. it looks like a Forth exception):
Alcarin:qemu steven$ make -C ppc-softmmu && ppc-softmmu/qemu-system-ppc -L pc-bios -cdrom ~/Development/MacOSX-10.4.iso -boot d -M mac99 -nographic make: Nothing to be done for `all'.
============================================================= OpenBIOS 1.0 [Apr 20 2009 03:23] Configuration device id QEMU version 1 machine id 1 CPUs: 1 Memory: 128M UUID: 00000000-0000-0000-0000-000000000000 CPU type PowerPC,G4
Welcome to OpenBIOS v1.0 built on Apr 20 2009 03:23
YABOOT - yaboot_startup: Entering boot, no path CHRP - try_chrp_script: Trying cd:0,ppc\bootinfo.txt MAC-PARTS: macparts_probe 4552 ?= 4552 MAC-PARTS: macparts_open 0 MAC-PARTS: macparts_get_info 0 2832209920 MAC-PARTS: macparts_block_size = 200 ELF - try_chrp_script: Can't open cd:0,ppc\bootinfo.txt CHRP - try_chrp_script: Trying cd:0,System\Library\CoreServices \BootX MAC-PARTS: macparts_probe 4552 ?= 4552 MAC-PARTS: macparts_open 0 MAC-PARTS: macparts_get_info 0 2832209920 MAC-PARTS: macparts_block_size = 200 CHRP - try_chrp_script: got bootscript load-base begin dup 6 " </CHRP" $= if 6 + dup 6 " -BOOT>" $= if 8 + true else false then else 1+ false then until ( xcoff-base ) load-size over load-base - - ( xcoff-base xcoff-size ) load-base swap move init-program go
ELF - encode_bootpath: bootpath cd:0,<NULL>\ bootargs <NULL>
$=:>> XCOFF - load_xcoff: Loading 'System\Library\CoreServices\BootX'
XCOFF - load_xcoff: XCOFF file with 3 sections entry:05616ecc XCOFF - load_xcoff: Read next header (5c) XCOFF - load_xcoff: Load '.text' section from 5c d4 to 5600000 (28000) XCOFF - load_xcoff: Found entry point offset in '.text': 94112 XCOFF - load_xcoff: Read next header (84) XCOFF - load_xcoff: Load '.data' section from 84 280d4 to 5628000 (2000) XCOFF - load_xcoff: Read next header (ac) XCOFF - load_xcoff: Erase '.bss' section at 562a000 size: 3a000 XCOFF - load_xcoff: Found actual entry point: 05600adc ELF - transfer_control_to_elf: Starting ELF boot loader
unselect-dev:interpret: exception -13 caught EXIT 0 > Killed
Any ideas?
Also, my most recent changes are committed and pushed for public viewing: http://github.com/tycho/openbios/commits/macosx-boot
Wow - I just returned from vacation and that's what I found in my inbox! What a nice surprise. This fits along really well with my efforts to get KVM running on POWER ;-).
So - have you made any progress since then?
Alex
[Trimmed qemu-devel from CC-list]
On 4/19/09, Steven Noonan steven@uplinklabs.net wrote:
On Sun, Apr 19, 2009 at 12:23 PM, Blue Swirl blauwirbel@gmail.com wrote:
On 4/19/09, Steven Noonan steven@uplinklabs.net wrote:
On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier Laurent@lvivier.info wrote:
Le dimanche 19 avril 2009 à 00:50 -0700, Steven Noonan a écrit :
On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan steven@uplinklabs.net wrote:
On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier Laurent@lvivier.info wrote: > OpenBIOS is not able to boot MacOS X.
Well, that's a silly limitation. Is there a reason this isn't implemented? I see that the Mac-on-Linux OpenBIOS version has such support, so it seems strange that the QEMU version does not.
I don't know if anyone here is actually interested (this list seems -very- quiet), but...
Hi,
I've been hacking at OpenBIOS for a bit, and I got it to properly read Mac OS X discs (it kept failing because it would hit an Apple Partition Map header instead of an HFS+ filesystem header). I'm working on adding an XCOFF loader, too, so it should be able to boot Mac OS X soon.
You can copy it from OpenHackWare. I made some tests and it seems to have some memory conflicts between MacOS kernel and OpenBIOS.
Good Luck.
Two more pre-XCOFF loader commits up: http://github.com/tycho/openbios/commit/e43daa3447b5ce4a2b05b2f32882e4989115... http://github.com/tycho/openbios/commit/7023b78a10f5632fd08d4749615efd3e73ab...
These look fine to me.
And I have something (uncommitted) that at least -loads- the CHRP-embedded XCOFF binaries now, but I am not sure what to do to execute the result. With ELF, it seems you can just use the call_elf() function. I don't know PowerPC assembler (nor the XCOFF format) well enough yet to know what would be necessary for a call_xcoff() function. Anyone want to help out with this?
Well, call_elf should work regardless of the format. The first and second parameters will be passed verbatim to OS (Linux uses those for initrd address and size), the third is the start address that should be available for all formats. There's some more description near the function call_elf in start.S.
So I'd just add something like call_elf(0, 0, xcoff_start) somewhere.
Ah, that did what it should've. I guess 'call_elf' is a misnomer?
I'm not committing the XCOFF loader quite yet. I suspect it would be best to do refactor it to use a similar API to what the ELF loader has, and place it so that it could be shared with the other OpenBIOS targets (pearpc, mol, etc)... Would it be preferred to make the XCOFF loader QEMU-specific or should it be a common API like the ELF loader?
I suspect the other PPC targets do not work. Is XCOFF used outside of Mac?
So here's what I get when I try Mac OS X 10.4 (I've enabled a ton of debug output):
Alcarin:qemu steven$ ppc-softmmu/qemu-system-ppc -L pc-bios -cdrom ~/Development/MacOSX-10.4.iso -boot d -M mac99 -nographic
============================================================= OpenBIOS 1.0 [Apr 19 2009 19:39] Configuration device id QEMU version 1 machine id 1 CPUs: 1 Memory: 128M UUID: 00000000-0000-0000-0000-000000000000 CPU type PowerPC,G4
Welcome to OpenBIOS v1.0 built on Apr 19 2009 19:39
YABOOT - yaboot_startup: Entering boot, no path CHRP - try_chrp_script: Trying cd:0,ppc\bootinfo.txt MAC-PARTS: macparts_probe 4552 ?= 4552 MAC-PARTS: macparts_open 0 MAC-PARTS: macparts_get_info 0 2832209920 MAC-PARTS: macparts_block_size = 200 volume_read_wrapper: got sig 482b volume_read_wrapper: got sig 482b ELF - try_chrp_script: Can't open cd:0,ppc\bootinfo.txt CHRP - try_chrp_script: Trying cd:0,System\Library\CoreServices\BootX MAC-PARTS: macparts_probe 4552 ?= 4552 MAC-PARTS: macparts_open 0 MAC-PARTS: macparts_get_info 0 2832209920 MAC-PARTS: macparts_block_size = 200 volume_read_wrapper: got sig 482b volume_read_wrapper: got sig 482b CHRP - try_chrp_script: got bootscript
load-base begin dup 6 " </CHRP" $= if 6 + dup 6 " -BOOT>" $= if 8 + true else false then else 1+ false then until ( xcoff-base ) load-size over load-base - - ( xcoff-base xcoff-size ) load-base swap move init-program go
ELF - encode_bootpath: bootpath cd:0,<NULL>\ bootargs <NULL>
$=:>> XCOFF - load_xcoff: Loading 'System\Library\CoreServices\BootX'
XCOFF - load_xcoff: XCOFF file with 3 sections entry:fff0a22c
If this is the entry, it's much too high, it's where OpenBIOS ROM is located. Or the loader should also add the virtual memory mappings to cover these addresses. IIRC the DSI/ISI handler in ofmem.c also makes some assumptions about virtual memory layout.
XCOFF - load_xcoff: Read next header (5c) XCOFF - load_xcoff: Load '.text' section from 5c d4 to 5600000 (28000) XCOFF - load_xcoff: Read next header (84) XCOFF - load_xcoff: Load '.data' section from 84 280d4 to 5628000 (2000) XCOFF - load_xcoff: Read next header (ac) XCOFF - load_xcoff: Erase '.bss' section at 562a000 size: 3a000 ELF - transfer_control_to_elf: Starting ELF boot loader
invalid/unsupported opcode: 02 - 0e - 0c (0b717b1c) 05616ed8 1
I guess the execution starts at somewhere near 0x5600000 but the loaded file may assume that the program counter is closer to 0xfff0a22c so while PC-relative accesses work, absolute addresses won't.
invalid/unsupported opcode: 00 - 14 - 13 (000064e8) 000094d0 0 Alcarin:qemu steven$
So at least with my patches, we're getting what people with QEMU 0.8.0 were getting: http://tinyurl.com/qemu080
So now what's left is resolving -why- that 'invalid/unsupported opcode' issue crops up.
That message comes from QEMU.
Le dimanche 19 avril 2009 à 11:59 -0700, Steven Noonan a écrit :
On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier Laurent@lvivier.info wrote:
Le dimanche 19 avril 2009 à 00:50 -0700, Steven Noonan a écrit :
On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan steven@uplinklabs.net wrote:
On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier Laurent@lvivier.info wrote:
OpenBIOS is not able to boot MacOS X.
Well, that's a silly limitation. Is there a reason this isn't implemented? I see that the Mac-on-Linux OpenBIOS version has such support, so it seems strange that the QEMU version does not.
I don't know if anyone here is actually interested (this list seems -very- quiet), but...
Hi,
I've been hacking at OpenBIOS for a bit, and I got it to properly read Mac OS X discs (it kept failing because it would hit an Apple Partition Map header instead of an HFS+ filesystem header). I'm working on adding an XCOFF loader, too, so it should be able to boot Mac OS X soon.
You can copy it from OpenHackWare. I made some tests and it seems to have some memory conflicts between MacOS kernel and OpenBIOS.
In fact what I have is a Mach-O loader which load mach_kernel from "/".
Good Luck.
Two more pre-XCOFF loader commits up: http://github.com/tycho/openbios/commit/e43daa3447b5ce4a2b05b2f32882e4989115... http://github.com/tycho/openbios/commit/7023b78a10f5632fd08d4749615efd3e73ab...
Seems good but do you really need to check for embedded XCOFF in this patch and are you really able to execute the boot-script ?
In Panther Install CD, BootX is:
<CHRP-BOOT> <COMPATIBLE> MacRISC MacRISC3 MacRISC4 </COMPATIBLE> <DESCRIPTION> Boot Loader for Mac OS X. </DESCRIPTION> <OS-BADGE-ICONS> </OS-BADGE-ICONS> <BOOT-SCRIPT> ... <BOOT-SCRIPT> load-base begin dup 6 " </CHRP" $= if 6 + dup 6 " -BOOT>" $= if 8 + true else false then else 1+ false then until ( xcoff-base ) load-size over load-base - - ( xcoff-base xcoff-size ) load-base swap move init-program go </BOOT-SCRIPT> </CHRP-BOOT> [...XCOFF HERE]
Regards, Laurent
On Sun, Apr 19, 2009 at 12:47 PM, Laurent Vivier Laurent@lvivier.info wrote:
Le dimanche 19 avril 2009 à 11:59 -0700, Steven Noonan a écrit :
On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier Laurent@lvivier.info wrote:
Le dimanche 19 avril 2009 à 00:50 -0700, Steven Noonan a écrit :
On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan steven@uplinklabs.net wrote:
On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier Laurent@lvivier.info wrote:
OpenBIOS is not able to boot MacOS X.
Well, that's a silly limitation. Is there a reason this isn't implemented? I see that the Mac-on-Linux OpenBIOS version has such support, so it seems strange that the QEMU version does not.
I don't know if anyone here is actually interested (this list seems -very- quiet), but...
Hi,
I've been hacking at OpenBIOS for a bit, and I got it to properly read Mac OS X discs (it kept failing because it would hit an Apple Partition Map header instead of an HFS+ filesystem header). I'm working on adding an XCOFF loader, too, so it should be able to boot Mac OS X soon.
You can copy it from OpenHackWare. I made some tests and it seems to have some memory conflicts between MacOS kernel and OpenBIOS.
In fact what I have is a Mach-O loader which load mach_kernel from "/".
Good Luck.
Two more pre-XCOFF loader commits up: http://github.com/tycho/openbios/commit/e43daa3447b5ce4a2b05b2f32882e4989115... http://github.com/tycho/openbios/commit/7023b78a10f5632fd08d4749615efd3e73ab...
Seems good but do you really need to check for embedded XCOFF in this patch and are you really able to execute the boot-script ?
Yes, it does properly execute the boot-script.
And no, it doesn't actually _check_ for an XCOFF, despite the comment I added. I suppose these lines could be removed from that patch:
+ + /* check for an embedded XCOFF binary */ + + /* eat newline */ + if (read_io(fd, tagbuf, 1) < 0) + goto badf; + + /* eat '\x04', ASCII 'end-of-transmission' */ + if (read_io(fd, tagbuf, 1) < 0) + goto badf; + + /* next bytes should be XCOFF magic */ + + /* TODO: Add XCOFF loader here. */ +
But they don't have any side effects. They are essentially just prep work for loading an embedded XCOFF which would begin after consuming the two bytes after the CHRP-BOOT block.
In Panther Install CD, BootX is:
<CHRP-BOOT> <COMPATIBLE> MacRISC MacRISC3 MacRISC4 </COMPATIBLE> <DESCRIPTION> Boot Loader for Mac OS X. </DESCRIPTION> <OS-BADGE-ICONS> </OS-BADGE-ICONS> <BOOT-SCRIPT> ... <BOOT-SCRIPT> load-base begin dup 6 " </CHRP" $= if 6 + dup 6 " -BOOT>" $= if 8 + true else false then else 1+ false then until ( xcoff-base ) load-size over load-base - - ( xcoff-base xcoff-size ) load-base swap move init-program go </BOOT-SCRIPT> </CHRP-BOOT> [...XCOFF HERE]
On Sun, Apr 19, 2009 at 12:47 PM, Laurent Vivier Laurent@lvivier.info wrote:
Le dimanche 19 avril 2009 à 11:59 -0700, Steven Noonan a écrit :
On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier Laurent@lvivier.info wrote:
Le dimanche 19 avril 2009 à 00:50 -0700, Steven Noonan a écrit :
On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan steven@uplinklabs.net wrote:
On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier Laurent@lvivier.info wrote:
OpenBIOS is not able to boot MacOS X.
Well, that's a silly limitation. Is there a reason this isn't implemented? I see that the Mac-on-Linux OpenBIOS version has such support, so it seems strange that the QEMU version does not.
I don't know if anyone here is actually interested (this list seems -very- quiet), but...
Hi,
I've been hacking at OpenBIOS for a bit, and I got it to properly read Mac OS X discs (it kept failing because it would hit an Apple Partition Map header instead of an HFS+ filesystem header). I'm working on adding an XCOFF loader, too, so it should be able to boot Mac OS X soon.
You can copy it from OpenHackWare. I made some tests and it seems to have some memory conflicts between MacOS kernel and OpenBIOS.
In fact what I have is a Mach-O loader which load mach_kernel from "/".
Good Luck.
Two more pre-XCOFF loader commits up: http://github.com/tycho/openbios/commit/e43daa3447b5ce4a2b05b2f32882e4989115... http://github.com/tycho/openbios/commit/7023b78a10f5632fd08d4749615efd3e73ab...
Seems good but do you really need to check for embedded XCOFF in this patch and are you really able to execute the boot-script ?
Oh, I should say that it does _execute_ the boot-script, but I don't know if it's properly handled by the Forth interpreter. Any idea what the boot-script you cite is supposed to actually _do_ (I gave up trying to read Forth at around 3 AM last night)?
In Panther Install CD, BootX is:
<CHRP-BOOT> <COMPATIBLE> MacRISC MacRISC3 MacRISC4 </COMPATIBLE> <DESCRIPTION> Boot Loader for Mac OS X. </DESCRIPTION> <OS-BADGE-ICONS> </OS-BADGE-ICONS> <BOOT-SCRIPT> ... <BOOT-SCRIPT> load-base begin dup 6 " </CHRP" $= if 6 + dup 6 " -BOOT>" $= if 8 + true else false then else 1+ false then until ( xcoff-base ) load-size over load-base - - ( xcoff-base xcoff-size ) load-base swap move init-program go </BOOT-SCRIPT> </CHRP-BOOT> [...XCOFF HERE]
Regards, Laurent
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
Le dimanche 19 avril 2009 à 13:01 -0700, Steven Noonan a écrit :
On Sun, Apr 19, 2009 at 12:47 PM, Laurent Vivier Laurent@lvivier.info wrote:
Le dimanche 19 avril 2009 à 11:59 -0700, Steven Noonan a écrit :
On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier Laurent@lvivier.info wrote:
Le dimanche 19 avril 2009 à 00:50 -0700, Steven Noonan a écrit :
On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan steven@uplinklabs.net wrote:
On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier Laurent@lvivier.info wrote: > OpenBIOS is not able to boot MacOS X.
Well, that's a silly limitation. Is there a reason this isn't implemented? I see that the Mac-on-Linux OpenBIOS version has such support, so it seems strange that the QEMU version does not.
I don't know if anyone here is actually interested (this list seems -very- quiet), but...
Hi,
I've been hacking at OpenBIOS for a bit, and I got it to properly read Mac OS X discs (it kept failing because it would hit an Apple Partition Map header instead of an HFS+ filesystem header). I'm working on adding an XCOFF loader, too, so it should be able to boot Mac OS X soon.
You can copy it from OpenHackWare. I made some tests and it seems to have some memory conflicts between MacOS kernel and OpenBIOS.
In fact what I have is a Mach-O loader which load mach_kernel from "/".
Good Luck.
Two more pre-XCOFF loader commits up: http://github.com/tycho/openbios/commit/e43daa3447b5ce4a2b05b2f32882e4989115... http://github.com/tycho/openbios/commit/7023b78a10f5632fd08d4749615efd3e73ab...
Seems good but do you really need to check for embedded XCOFF in this patch and are you really able to execute the boot-script ?
Oh, I should say that it does _execute_ the boot-script, but I don't know if it's properly handled by the Forth interpreter. Any idea what the boot-script you cite is supposed to actually _do_ (I gave up trying to read Forth at around 3 AM last night)?
I think the script seeks in itself the address of the embedded XCOFF (after "-BOOT"), computes it size, copies it to load-base, initializes it ("init-program") and executes it ("go").
In Panther Install CD, BootX is:
<CHRP-BOOT> <COMPATIBLE> MacRISC MacRISC3 MacRISC4 </COMPATIBLE> <DESCRIPTION> Boot Loader for Mac OS X. </DESCRIPTION> <OS-BADGE-ICONS> </OS-BADGE-ICONS> <BOOT-SCRIPT> ... <BOOT-SCRIPT> load-base begin dup 6 " </CHRP" $= if 6 + dup 6 " -BOOT>" $= if 8 + true else false then else 1+ false then until ( xcoff-base ) load-size over load-base - - ( xcoff-base xcoff-size ) load-base swap move init-program go </BOOT-SCRIPT> </CHRP-BOOT> [...XCOFF HERE]
Regards, Laurent
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
On Sun, Apr 19, 2009 at 1:21 PM, Laurent Vivier Laurent@vivier.eu wrote:
Le dimanche 19 avril 2009 à 13:01 -0700, Steven Noonan a écrit :
On Sun, Apr 19, 2009 at 12:47 PM, Laurent Vivier Laurent@lvivier.info wrote:
Le dimanche 19 avril 2009 à 11:59 -0700, Steven Noonan a écrit :
On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier Laurent@lvivier.info wrote:
Le dimanche 19 avril 2009 à 00:50 -0700, Steven Noonan a écrit :
On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan steven@uplinklabs.net wrote: > On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier Laurent@lvivier.info wrote: >> OpenBIOS is not able to boot MacOS X. > > Well, that's a silly limitation. Is there a reason this isn't > implemented? I see that the Mac-on-Linux OpenBIOS version has such > support, so it seems strange that the QEMU version does not.
I don't know if anyone here is actually interested (this list seems -very- quiet), but...
Hi,
I've been hacking at OpenBIOS for a bit, and I got it to properly read Mac OS X discs (it kept failing because it would hit an Apple Partition Map header instead of an HFS+ filesystem header). I'm working on adding an XCOFF loader, too, so it should be able to boot Mac OS X soon.
You can copy it from OpenHackWare. I made some tests and it seems to have some memory conflicts between MacOS kernel and OpenBIOS.
In fact what I have is a Mach-O loader which load mach_kernel from "/".
Good Luck.
Two more pre-XCOFF loader commits up: http://github.com/tycho/openbios/commit/e43daa3447b5ce4a2b05b2f32882e4989115... http://github.com/tycho/openbios/commit/7023b78a10f5632fd08d4749615efd3e73ab...
Seems good but do you really need to check for embedded XCOFF in this patch and are you really able to execute the boot-script ?
Oh, I should say that it does _execute_ the boot-script, but I don't know if it's properly handled by the Forth interpreter. Any idea what the boot-script you cite is supposed to actually _do_ (I gave up trying to read Forth at around 3 AM last night)?
I think the script seeks in itself the address of the embedded XCOFF (after "-BOOT"), computes it size, copies it to load-base, initializes it ("init-program") and executes it ("go").
Ah, duh, that should've been obvious to me. I'm a Forth flunkie, so if someone could implement these:
( xcoff-base ) load-size over load-base - - ( xcoff-base xcoff-size ) load-base swap move init-program go
Then we'd be doing what we -really- should be doing instead of my hackish "oh, there's an XCOFF here! let's load it."
In Panther Install CD, BootX is:
<CHRP-BOOT> <COMPATIBLE> MacRISC MacRISC3 MacRISC4 </COMPATIBLE> <DESCRIPTION> Boot Loader for Mac OS X. </DESCRIPTION> <OS-BADGE-ICONS> </OS-BADGE-ICONS> <BOOT-SCRIPT> ... <BOOT-SCRIPT> load-base begin dup 6 " </CHRP" $= if 6 + dup 6 " -BOOT>" $= if 8 + true else false then else 1+ false then until ( xcoff-base ) load-size over load-base - - ( xcoff-base xcoff-size ) load-base swap move init-program go </BOOT-SCRIPT> </CHRP-BOOT> [...XCOFF HERE]
Le dimanche 19 avril 2009 à 13:23 -0700, Steven Noonan a écrit :
On Sun, Apr 19, 2009 at 1:21 PM, Laurent Vivier Laurent@vivier.eu wrote:
Le dimanche 19 avril 2009 à 13:01 -0700, Steven Noonan a écrit :
On Sun, Apr 19, 2009 at 12:47 PM, Laurent Vivier Laurent@lvivier.info wrote:
Le dimanche 19 avril 2009 à 11:59 -0700, Steven Noonan a écrit :
On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier Laurent@lvivier.info wrote:
Le dimanche 19 avril 2009 à 00:50 -0700, Steven Noonan a écrit : > On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan steven@uplinklabs.net wrote: > > On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier Laurent@lvivier.info wrote: > >> OpenBIOS is not able to boot MacOS X. > > > > Well, that's a silly limitation. Is there a reason this isn't > > implemented? I see that the Mac-on-Linux OpenBIOS version has such > > support, so it seems strange that the QEMU version does not. > > I don't know if anyone here is actually interested (this list seems > -very- quiet), but...
Hi,
> I've been hacking at OpenBIOS for a bit, and I got it to properly read > Mac OS X discs (it kept failing because it would hit an Apple > Partition Map header instead of an HFS+ filesystem header). I'm > working on adding an XCOFF loader, too, so it should be able to boot > Mac OS X soon.
You can copy it from OpenHackWare. I made some tests and it seems to have some memory conflicts between MacOS kernel and OpenBIOS.
In fact what I have is a Mach-O loader which load mach_kernel from "/".
Good Luck.
Two more pre-XCOFF loader commits up: http://github.com/tycho/openbios/commit/e43daa3447b5ce4a2b05b2f32882e4989115... http://github.com/tycho/openbios/commit/7023b78a10f5632fd08d4749615efd3e73ab...
Seems good but do you really need to check for embedded XCOFF in this patch and are you really able to execute the boot-script ?
Oh, I should say that it does _execute_ the boot-script, but I don't know if it's properly handled by the Forth interpreter. Any idea what the boot-script you cite is supposed to actually _do_ (I gave up trying to read Forth at around 3 AM last night)?
I think the script seeks in itself the address of the embedded XCOFF (after "-BOOT"), computes it size, copies it to load-base, initializes it ("init-program") and executes it ("go").
Ah, duh, that should've been obvious to me. I'm a Forth flunkie, so if someone could implement these:
You can write it in C... I have written a Mach-O loader (but it seems broken now)
( xcoff-base ) load-size over load-base - - ( xcoff-base xcoff-size ) load-base swap move init-program go
Then we'd be doing what we -really- should be doing instead of my hackish "oh, there's an XCOFF here! let's load it."
This explains why OpenHackware is written as it is.
In Panther Install CD, BootX is:
<CHRP-BOOT> <COMPATIBLE> MacRISC MacRISC3 MacRISC4 </COMPATIBLE> <DESCRIPTION> Boot Loader for Mac OS X. </DESCRIPTION> <OS-BADGE-ICONS> </OS-BADGE-ICONS> <BOOT-SCRIPT> ... <BOOT-SCRIPT> load-base begin dup 6 " </CHRP" $= if 6 + dup 6 " -BOOT>" $= if 8 + true else false then else 1+ false then until ( xcoff-base ) load-size over load-base - - ( xcoff-base xcoff-size ) load-base swap move init-program go </BOOT-SCRIPT> </CHRP-BOOT> [...XCOFF HERE]
-
Alexander Graf -
Alexander Graf -
Andreas Färber -
Blue Swirl -
Dave Willoughby -
François Revol -
Igor Kovalenko -
Laurent Vivier -
Laurent Vivier -
M. Warner Losh -
malc -
Mark Cave-Ayland -
Steven Noonan