12 Apr
2009
12 Apr
'09
3:06 a.m.
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
12 Apr
12 Apr
10:39 a.m.
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 ----
I've tried to correct this but it introduces new problems.
>
=============================================================
> 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!
Regards,
Laurent
15 Apr
15 Apr
7:46 a.m.
On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier <Laurent(a)lvivier.info> wrote:
Le samedi 11 avril 2009 à 18:06 -0700, Steven Noonan a
écrit :
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.
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 ----
I've tried to correct this but it introduces new problems.
>
=============================================================
> 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!
Regards,
Laurent
19 Apr
19 Apr
9:50 a.m.
On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan <steven(a)uplinklabs.net> wrote:
On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier
<Laurent(a)lvivier.info> wrote:
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/4722c8a01d186a08183de49759dc8b7b74c…
Thoughts?
- Steven
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. 
10:03 a.m.
Am 19.04.2009 um 09:50 schrieb Steven Noonan:
On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan
<steven(a)uplinklabs.net> wrote:
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 12, 2009 at 1:39 AM, Laurent Vivier
<Laurent(a)lvivier.info> wrote:
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/4722c8a01d186a08183de49759dc8b7b74c…
Thoughts? 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.
10:28 a.m.
On Sun, Apr 19, 2009 at 1:03 AM, Andreas Färber <andreas.faerber(a)web.de> wrote:
Am 19.04.2009 um 09:50 schrieb Steven Noonan:
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.
On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan
<steven(a)uplinklabs.net>
wrote:
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.
On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier <Laurent(a)lvivier.info>
wrote:
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/4722c8a01d186a08183de49759dc8b7b74c…
Thoughts?
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.
11:44 a.m.
Am 19.04.2009 um 10:28 schrieb Steven Noonan:
On Sun, Apr 19, 2009 at 1:03 AM, Andreas Färber
<andreas.faerber(a)web.de
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
wrote:
Am 19.04.2009 um 09:50 schrieb Steven Noonan:
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. On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan
<steven(a)uplinklabs.net
wrote:
>
> On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier <Laurent(a)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/4722c8a01d186a08183de49759dc8b7b74c…
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. 
7:47 p.m.
New subject: [Qemu-devel] Re: QEMU OpenBIOS booting?
In message: <f488382f0904190128l4383a56eu67a2f16eb338e61c(a)mail.gmail.com>
Steven Noonan <steven(a)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
7:56 p.m.
New subject: [Qemu-devel] Re: QEMU OpenBIOS booting?
On Sun, Apr 19, 2009 at 10:47 AM, M. Warner Losh <imp(a)bsdimp.com> wrote:
In message:
<f488382f0904190128l4383a56eu67a2f16eb338e61c(a)mail.gmail.com>
Steven Noonan <steven(a)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
8:44 p.m.
New subject: [Qemu-devel] Re: QEMU OpenBIOS booting?
On 4/19/09, M. Warner Losh <imp(a)bsdimp.com> wrote:
In message:
<f488382f0904190128l4383a56eu67a2f16eb338e61c(a)mail.gmail.com>
Steven Noonan <steven(a)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(a)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
20 Apr
20 Apr
1:18 a.m.
New subject: [Qemu-devel] Re: QEMU OpenBIOS booting?
In message: <f43fc5580904191144y1fd8e4d6m3321855d0c558250(a)mail.gmail.com>
Blue Swirl <blauwirbel(a)gmail.com> writes:
: On 4/19/09, M. Warner Losh <imp(a)bsdimp.com> wrote:
: > In message: <f488382f0904190128l4383a56eu67a2f16eb338e61c(a)mail.gmail.com>
: >
: > Steven Noonan <steven(a)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(a)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
9:39 p.m.
New subject: [Qemu-devel] Re: QEMU OpenBIOS booting?
On 4/20/09, M. Warner Losh <imp(a)bsdimp.com> wrote:
In message:
<f43fc5580904191144y1fd8e4d6m3321855d0c558250(a)mail.gmail.com>
Blue Swirl <blauwirbel(a)gmail.com> writes:
: On 4/19/09, M. Warner Losh <imp(a)bsdimp.com> wrote:
: > In message: <f488382f0904190128l4383a56eu67a2f16eb338e61c(a)mail.gmail.com>
: >
: > Steven Noonan <steven(a)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(a)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
11:01 p.m.
New subject: [Qemu-devel] Re: QEMU OpenBIOS booting?
On 4/20/09, M. Warner Losh <imp(a)bsdimp.com>
wrote:
FWIW, Haiku still stops somewhere at
http://dev.haiku-os.org/browser/haiku/trunk/src/system/boot/platform/openfi…
...
[revol@debian ~/devel/haiku/trunk]$ qemu-system-ppc -nographic -serial
stdio -cdrom generated.ppc/haiku-boot-cd-ppc.iso -boot d
In message: <
f43fc5580904191144y1fd8e4d6m3321855d0c558250(a)mail.gmail.com>
Blue Swirl <blauwirbel(a)gmail.com> writes:
: On 4/19/09, M. Warner Losh <imp(a)bsdimp.com> wrote:
: > In message: <
f488382f0904190128l4383a56eu67a2f16eb338e61c(a)mail.gmail.com>
: >
: > Steven Noonan <steven(a)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(a)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
>
=============================================================
> 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.
22 Dec
22 Dec
12:29 a.m.
New subject: Haiku/ppc regression? (was: QEMU OpenBIOS booting?)
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/openfi…
...
[revol@debian ~/devel/haiku/trunk]$ qemu-system-ppc -nographic -serial
stdio -cdrom generated.ppc/haiku-boot-cd-ppc.iso -boot d
At OpenBIOS r647 with Haiku r34736, this has become:
>
=============================================================
> 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: 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.
2:36 p.m.
New subject: Haiku/ppc regression?
Andreas Färber wrote:
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.
--
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063
Sirius Labs: http://www.siriusit.co.uk/labs
[revol@debian
~/devel/haiku/trunk]$ qemu-system-ppc -nographic -serial
stdio -cdrom generated.ppc/haiku-boot-cd-ppc.iso -boot d
At OpenBIOS r647 with Haiku r34736, this has become:
>
=============================================================
> 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: 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
10:48 p.m.
New subject: Haiku/ppc regression?
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-de…
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
24 Dec
24 Dec
7:16 p.m.
New subject: Haiku/ppc regression?
Am 22.12.2009 um 22:48 schrieb Andreas Färber:
Am 22.12.2009 um 14:36 schrieb Mark Cave-Ayland:
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(a)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
an SVN bisect to identify the offending commit
would be really handy.
26 Dec
26 Dec
11:24 p.m.
New subject: Haiku/ppc regression?
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)
31 Dec
31 Dec
5:32 p.m.
New subject: Haiku/ppc regression?
Am 26.12.2009 um 23:24 schrieb Andreas Färber:
Am 22.12.2009 um 22:48 schrieb Andreas Färber:
For comparison, my PowerMac G3 b&w (NewWorld) allocated that table at
0x00400000.
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)
--
OpenBIOS http://openbios.org/
Mailinglist: http://lists.openbios.org/mailman/listinfo
Free your System - May the Forth be with you
21 May
21 May
12:11 a.m.
New subject: Haiku/ppc regression?
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
10 a.m.
New subject: Haiku/ppc regression?
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/openfi…
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.
--
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063
Sirius Labs: http://www.siriusit.co.uk/labs
10:07 a.m.
New subject: Haiku/ppc regression?
On Fri, May 21, 2010 at 12:00 PM, Mark Cave-Ayland
<mark.cave-ayland(a)siriusit.co.uk> wrote:
Andreas Färber 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}
--
Kind regards,
Igor V. Kovalenko
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/openfi…
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.
10:18 a.m.
New subject: Haiku/ppc regression?
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.
--
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063
Sirius Labs: http://www.siriusit.co.uk/labs
10:16 a.m.
New subject: Haiku/ppc regression?
On 21.05.2010, at 10:00, Mark Cave-Ayland wrote:
Andreas Färber 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
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/openfi…
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.
11:57 a.m.
New subject: Haiku/ppc regression?
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.
--
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063
Sirius Labs: http://www.siriusit.co.uk/labs
7:39 p.m.
New subject: Haiku/ppc regression?
Hi guys,
Am 21.05.2010 um 11:57 schrieb Mark Cave-Ayland:
Alexander Graf wrote:
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
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.
24 May
24 May
2:22 p.m.
New subject: Haiku/ppc regression?
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
21 Apr
21 Apr
12:15 a.m.
New subject: [Qemu-devel] Re: QEMU OpenBIOS booting?
Le lundi 20 avril 2009 à 22:39 +0300, Blue Swirl a écrit :
On 4/20/09, M. Warner Losh <imp(a)bsdimp.com>
wrote:
I think '/memory/available' is badly encoded and doesn't reflect the
actual memory availability..
Regards,
Laurent
In message:
<f43fc5580904191144y1fd8e4d6m3321855d0c558250(a)mail.gmail.com>
Blue Swirl <blauwirbel(a)gmail.com> writes:
: On 4/19/09, M. Warner Losh <imp(a)bsdimp.com> wrote:
: > In message: <f488382f0904190128l4383a56eu67a2f16eb338e61c(a)mail.gmail.com>
: >
: > Steven Noonan <steven(a)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(a)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
19 Apr
19 Apr
10:31 a.m.
Le dimanche 19 avril 2009 à 10:03 +0200, Andreas Färber a écrit :
Am 19.04.2009 um 09:50 schrieb Steven Noonan:
Alexander made a work to boot Intel Mac OS X.
It works very well with KVM (I use it).
http://alex.csgraf.de/
See the HowTo http://d4wiki.goddamm.it/index.php/Howto:_Mac_OSX_on_KVM .
On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan
<steven(a)uplinklabs.net> wrote:
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. On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier
<Laurent(a)lvivier.info> wrote:
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/4722c8a01d186a08183de49759dc8b7b74c…
Thoughts? 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. 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
20 May
20 May
3:51 p.m.
On Apr 19, 2009, at 3:31 AM, Laurent Vivier wrote:
Le dimanche 19 avril 2009 à 10:03 +0200, Andreas
Färber a écrit :
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.
Am 19.04.2009 um 09:50 schrieb Steven Noonan:
Alexander made a work to boot Intel Mac OS X.
It works very well with KVM (I use it).
http://alex.csgraf.de/
See the HowTo http://d4wiki.goddamm.it/index.php/
Howto:_Mac_OSX_on_KVM . On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan
<steven(a)uplinklabs.net> wrote:
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. On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier
<Laurent(a)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/4722c8a01d186a08183de49759dc8b7b74c…
Thoughts? 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 
4:14 p.m.
Hi Dave,
On 20.05.2009, at 15:51, Dave Willoughby wrote:
On Apr 19, 2009, at 3:31 AM, Laurent Vivier wrote:
GPT formatted by Mac OS X? You need to have an MBR synced on it.
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).
http://alex.csgraf.de/
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?
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
19 Apr
19 Apr
10:24 a.m.
Le dimanche 19 avril 2009 à 00:50 -0700, Steven Noonan a écrit :
On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan
<steven(a)uplinklabs.net> wrote:
Hi,
On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier
<Laurent(a)lvivier.info> wrote:
I don't know if anyone here is actually interested (this list seems
-very- quiet), but... 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'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/4722c8a01d186a08183de49759dc8b7b74c…
Thoughts?
I don't understand why this patch is needed. Could you explain ?
Regards,
Laurent
10:27 a.m.
On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier <Laurent(a)lvivier.info> wrote:
Le dimanche 19 avril 2009 à 00:50 -0700, Steven Noonan
a écrit :
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 Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan
<steven(a)uplinklabs.net> wrote:
Hi,
On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier
<Laurent(a)lvivier.info> wrote:
I don't know if anyone here is actually interested (this list seems
-very- quiet), but... 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'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/4722c8a01d186a08183de49759dc8b7b74c…
Thoughts?
I don't understand why this patch is needed. Could you explain ?
8:59 p.m.
On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier <Laurent(a)lvivier.info> wrote:
Le dimanche 19 avril 2009 à 00:50 -0700, Steven Noonan
a écrit :
Two more pre-XCOFF loader commits up:
http://github.com/tycho/openbios/commit/e43daa3447b5ce4a2b05b2f32882e498911…
http://github.com/tycho/openbios/commit/7023b78a10f5632fd08d4749615efd3e73a…
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 Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan
<steven(a)uplinklabs.net> wrote:
Hi,
On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier
<Laurent(a)lvivier.info> wrote:
I don't know if anyone here is actually interested (this list seems
-very- quiet), but... 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'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.
9:23 p.m.
On 4/19/09, Steven Noonan <steven(a)uplinklabs.net> wrote:
On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier
<Laurent(a)lvivier.info> wrote:
These look fine to me.
Le dimanche 19 avril 2009 à 00:50 -0700, Steven
Noonan a écrit :
Two more pre-XCOFF loader commits up:
http://github.com/tycho/openbios/commit/e43daa3447b5ce4a2b05b2f32882e498911…
http://github.com/tycho/openbios/commit/7023b78a10f5632fd08d4749615efd3e73a… On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan
<steven(a)uplinklabs.net> wrote:
Hi,
On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier
<Laurent(a)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.
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.
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.
10 p.m.
On Sun, Apr 19, 2009 at 12:23 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote:
On 4/19/09, Steven Noonan
<steven(a)uplinklabs.net> wrote:
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
On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier
<Laurent(a)lvivier.info> wrote:
These look fine to me.
Le dimanche 19 avril 2009 à 00:50 -0700, Steven
Noonan a écrit :
Two more pre-XCOFF loader commits up:
http://github.com/tycho/openbios/commit/e43daa3447b5ce4a2b05b2f32882e498911…
http://github.com/tycho/openbios/commit/7023b78a10f5632fd08d4749615efd3e73a… On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan
<steven(a)uplinklabs.net> wrote:
> On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier <Laurent(a)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.
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. >
=============================================================
> 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
10:08 p.m.
Le dimanche 19 avril 2009 à 13:00 -0700, Steven Noonan a écrit :
On Sun, Apr 19, 2009 at 12:23 PM, Blue Swirl
<blauwirbel(a)gmail.com> wrote:
I think the booloader is loaded at addresses overwriting some parts of
openbios.
Regards,
Laurent
On 4/19/09, Steven Noonan
<steven(a)uplinklabs.net> wrote:
> On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier <Laurent(a)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(a)uplinklabs.net> wrote:
> >> > On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier
<Laurent(a)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.
10:14 p.m.
On Sun, Apr 19, 2009 at 1:08 PM, Laurent Vivier <Laurent(a)lvivier.info> wrote:
Le dimanche 19 avril 2009 à 13:00 -0700, Steven Noonan
a écrit :
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).
On Sun, Apr 19, 2009 at 12:23 PM, Blue Swirl
<blauwirbel(a)gmail.com> wrote:
I think the booloader is loaded at addresses overwriting some parts of
openbios.
On 4/19/09, Steven Noonan
<steven(a)uplinklabs.net> wrote:
> On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier <Laurent(a)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(a)uplinklabs.net> wrote:
> >> > On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier
<Laurent(a)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.
10:24 p.m.
Le dimanche 19 avril 2009 à 13:14 -0700, Steven Noonan a écrit :
On Sun, Apr 19, 2009 at 1:08 PM, Laurent Vivier
<Laurent(a)lvivier.info> wrote:
The problem is in OpenBios: I put some structures in memory without
knowing this... but this is not part of openfirmware specification.
Le dimanche 19 avril 2009 à 13:00 -0700, Steven
Noonan a écrit :
That would make sense, but that tells me QEMU is loading OpenBIOS to On Sun, Apr 19, 2009 at 12:23 PM, Blue Swirl
<blauwirbel(a)gmail.com> wrote:
I think the booloader is loaded at addresses overwriting some parts of
openbios.
On 4/19/09, Steven Noonan
<steven(a)uplinklabs.net> wrote:
> On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier <Laurent(a)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(a)uplinklabs.net> wrote:
> >> > On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier
<Laurent(a)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. 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
10:33 p.m.
On Sun, Apr 19, 2009 at 1:24 PM, Laurent Vivier <Laurent(a)vivier.eu> wrote:
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.
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:14 -0700, Steven Noonan
a écrit :
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?
On Sun, Apr 19, 2009 at 1:08 PM, Laurent Vivier
<Laurent(a)lvivier.info> wrote:
The problem is in OpenBios: I put some structures in memory without
knowing this... but this is not part of openfirmware specification. Le dimanche 19 avril 2009 à 13:00 -0700, Steven
Noonan a écrit :
That would make sense, but that tells me QEMU is loading OpenBIOS to On Sun, Apr 19, 2009 at 12:23 PM, Blue Swirl
<blauwirbel(a)gmail.com> wrote:
> On 4/19/09, Steven Noonan <steven(a)uplinklabs.net> wrote:
>> On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier <Laurent(a)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(a)uplinklabs.net> wrote:
>> >> > On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier
<Laurent(a)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.
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).
10:48 p.m.
Le dimanche 19 avril 2009 à 13:33 -0700, Steven Noonan a écrit :
On Sun, Apr 19, 2009 at 1:24 PM, Laurent Vivier
<Laurent(a)vivier.eu> wrote:
AIX is also using OpenFirmware / PPC / CHRP, and I think they don't care
of Apple-ism.
Le dimanche 19 avril 2009 à 13:14 -0700, Steven
Noonan a écrit :
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 On Sun, Apr 19, 2009 at 1:08 PM, Laurent Vivier
<Laurent(a)lvivier.info> wrote:
The problem is in OpenBios: I put some structures in memory without
knowing this... but this is not part of openfirmware specification. Le dimanche 19 avril 2009 à 13:00 -0700, Steven
Noonan a écrit :
> On Sun, Apr 19, 2009 at 12:23 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote:
> > On 4/19/09, Steven Noonan <steven(a)uplinklabs.net> wrote:
> >> On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier <Laurent(a)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(a)uplinklabs.net> wrote:
> >> >> > On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier
<Laurent(a)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 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?
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
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...)
11:02 p.m.
On Sun, Apr 19, 2009 at 1:48 PM, Laurent Vivier <Laurent(a)vivier.eu> wrote:
Le dimanche 19 avril 2009 à 13:33 -0700, Steven Noonan
a écrit :
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 1:24 PM, Laurent Vivier
<Laurent(a)vivier.eu> wrote:
AIX is also using OpenFirmware / PPC / CHRP, and I think they don't care
of Apple-ism.
Le dimanche 19 avril 2009 à 13:14 -0700, Steven
Noonan a écrit :
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 On Sun, Apr 19, 2009 at 1:08 PM, Laurent Vivier
<Laurent(a)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(a)gmail.com>
wrote:
>> > On 4/19/09, Steven Noonan <steven(a)uplinklabs.net> wrote:
>> >> On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier
<Laurent(a)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(a)uplinklabs.net> wrote:
>> >> >> > On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier
<Laurent(a)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. 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?
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)
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...)
11:32 p.m.
On Sun, Apr 19, 2009 at 2:02 PM, Steven Noonan <steven(a)uplinklabs.net> wrote:
On Sun, Apr 19, 2009 at 1:48 PM, Laurent Vivier
<Laurent(a)vivier.eu> wrote:
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?
Le dimanche 19 avril 2009 à 13:33 -0700, Steven
Noonan a écrit :
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 1:24 PM, Laurent Vivier
<Laurent(a)vivier.eu> wrote:
AIX is also using OpenFirmware / PPC / CHRP, and I think they don't care
of Apple-ism.
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 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?
Look here:
http://www.opensource.apple.com/darwinsource/tarballs/apsl/BootX-81.tar.gz
(You need an Apple Developer ID)
> 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.
20 Apr
20 Apr
12:28 a.m.
On Sun, Apr 19, 2009 at 2:32 PM, Steven Noonan <steven(a)uplinklabs.net> wrote:
On Sun, Apr 19, 2009 at 2:02 PM, Steven Noonan
<steven(a)uplinklabs.net> wrote:
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.
On Sun, Apr 19, 2009 at 1:48 PM, Laurent Vivier
<Laurent(a)vivier.eu> wrote:
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 */ Le dimanche 19 avril 2009 à 13:33 -0700, Steven
Noonan a écrit :
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 1:24 PM, Laurent Vivier
<Laurent(a)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)
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?
12:36 a.m.
On Sun, Apr 19, 2009 at 3:28 PM, Steven Noonan <steven(a)uplinklabs.net> wrote:
On Sun, Apr 19, 2009 at 2:32 PM, Steven Noonan
<steven(a)uplinklabs.net> wrote:
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 )
On Sun, Apr 19, 2009 at 2:02 PM, Steven Noonan
<steven(a)uplinklabs.net> wrote:
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.
On Sun, Apr 19, 2009 at 1:48 PM, Laurent Vivier
<Laurent(a)vivier.eu> wrote:
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 */ Le dimanche 19 avril 2009 à 13:33 -0700, Steven
Noonan a écrit :
> On Sun, Apr 19, 2009 at 1:24 PM, Laurent Vivier <Laurent(a)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?
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?
2:15 a.m.
New subject: [Qemu-devel] Re: QEMU OpenBIOS booting?
On Sun, 19 Apr 2009, Steven Noonan wrote:
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.
On Sun, Apr 19, 2009 at 3:28 PM, Steven Noonan
<steven(a)uplinklabs.net> wrote:
> On Sun, Apr 19, 2009 at 2:32 PM, Steven Noonan <steven(a)uplinklabs.net> wrote:
>> On Sun, Apr 19, 2009 at 2:02 PM, Steven Noonan <steven(a)uplinklabs.net>
wrote:
>>> On Sun, Apr 19, 2009 at 1:48 PM, Laurent Vivier <Laurent(a)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(a)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.
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 )
--
mailto:av1474@comtv.ru
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?
5:27 a.m.
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
5:50 a.m.
On Sun, Apr 19, 2009 at 8:27 PM, Steven Noonan <steven(a)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'.
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
>
=============================================================
> 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?
26 Apr
26 Apr
10:13 a.m.
On 20.04.2009, at 05:50, Steven Noonan wrote:
On Sun, Apr 19, 2009 at 8:27 PM, Steven Noonan
<steven(a)uplinklabs.net> wrote:
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
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'.
Also, my most recent changes are committed and pushed for public
viewing:
http://github.com/tycho/openbios/commits/macosx-boot >
=============================================================
> 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?
19 Apr
19 Apr
10:19 p.m.
[Trimmed qemu-devel from CC-list]
On 4/19/09, Steven Noonan <steven(a)uplinklabs.net> wrote:
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.
On Sun, Apr 19, 2009 at 12:23 PM, Blue Swirl
<blauwirbel(a)gmail.com> wrote:
I suspect the other PPC targets do not work. Is XCOFF used outside of Mac?
On 4/19/09, Steven Noonan
<steven(a)uplinklabs.net> wrote:
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? On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier
<Laurent(a)lvivier.info> wrote:
These look fine to me.
Le dimanche 19 avril 2009 à 00:50 -0700, Steven
Noonan a écrit :
> On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan <steven(a)uplinklabs.net> wrote:
> > On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier <Laurent(a)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/e43daa3447b5ce4a2b05b2f32882e498911…
http://github.com/tycho/openbios/commit/7023b78a10f5632fd08d4749615efd3e73a… 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. 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
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.
>
=============================================================
> 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.
That message comes from QEMU.
9:47 p.m.
Le dimanche 19 avril 2009 à 11:59 -0700, Steven Noonan a écrit :
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 1:24 AM, Laurent Vivier
<Laurent(a)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(a)uplinklabs.net>
wrote:
>> > On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier
<Laurent(a)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/e43daa3447b5ce4a2b05b2f32882e498911…
http://github.com/tycho/openbios/commit/7023b78a10f5632fd08d4749615efd3e73a…
9:53 p.m.
On Sun, Apr 19, 2009 at 12:47 PM, Laurent Vivier <Laurent(a)lvivier.info> wrote:
Le dimanche 19 avril 2009 à 11:59 -0700, Steven Noonan
a écrit :
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.
On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier
<Laurent(a)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(a)uplinklabs.net>
wrote:
>> > On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier
<Laurent(a)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/e43daa3447b5ce4a2b05b2f32882e498911…
http://github.com/tycho/openbios/commit/7023b78a10f5632fd08d4749615efd3e73a…
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]
10:01 p.m.
On Sun, Apr 19, 2009 at 12:47 PM, Laurent Vivier <Laurent(a)lvivier.info> wrote:
Le dimanche 19 avril 2009 à 11:59 -0700, Steven Noonan
a écrit :
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)?
On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier
<Laurent(a)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(a)uplinklabs.net>
wrote:
>> > On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier
<Laurent(a)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/e43daa3447b5ce4a2b05b2f32882e498911…
http://github.com/tycho/openbios/commit/7023b78a10f5632fd08d4749615efd3e73a…
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
10:21 p.m.
Le dimanche 19 avril 2009 à 13:01 -0700, Steven Noonan a écrit :
On Sun, Apr 19, 2009 at 12:47 PM, Laurent Vivier
<Laurent(a)lvivier.info> wrote:
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").
Le dimanche 19 avril 2009 à 11:59 -0700, Steven
Noonan a écrit :
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)? On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier
<Laurent(a)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(a)uplinklabs.net>
wrote:
>> > On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier
<Laurent(a)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/e43daa3447b5ce4a2b05b2f32882e498911…
http://github.com/tycho/openbios/commit/7023b78a10f5632fd08d4749615efd3e73a…
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
10:23 p.m.
On Sun, Apr 19, 2009 at 1:21 PM, Laurent Vivier <Laurent(a)vivier.eu> wrote:
Le dimanche 19 avril 2009 à 13:01 -0700, Steven Noonan
a écrit :
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."
On Sun, Apr 19, 2009 at 12:47 PM, Laurent Vivier
<Laurent(a)lvivier.info> wrote:
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"). Le dimanche 19 avril 2009 à 11:59 -0700, Steven
Noonan a écrit :
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)? On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier
<Laurent(a)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(a)uplinklabs.net>
wrote:
>> > On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier
<Laurent(a)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/e43daa3447b5ce4a2b05b2f32882e498911…
http://github.com/tycho/openbios/commit/7023b78a10f5632fd08d4749615efd3e73a…
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]
> >
> >
10:29 p.m.
Le dimanche 19 avril 2009 à 13:23 -0700, Steven Noonan a écrit :
On Sun, Apr 19, 2009 at 1:21 PM, Laurent Vivier
<Laurent(a)vivier.eu> wrote:
You can write it in C... I have written a Mach-O loader (but it seems
broken now)
Le dimanche 19 avril 2009 à 13:01 -0700, Steven
Noonan a écrit :
Ah, duh, that should've been obvious to me. I'm a Forth flunkie, so if
someone could implement these: On Sun, Apr 19, 2009 at 12:47 PM, Laurent Vivier
<Laurent(a)lvivier.info> wrote:
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"). Le dimanche 19 avril 2009 à 11:59 -0700, Steven
Noonan a écrit :
> On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier <Laurent(a)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(a)uplinklabs.net> wrote:
> >> > On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier
<Laurent(a)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/e43daa3447b5ce4a2b05b2f32882e498911…
> http://github.com/tycho/openbios/commit/7023b78a10f5632fd08d4749615efd3e73a…
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)? ( 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]
> >
> >
4048
days inactive
4455
days old
55 comments
13 participants
participants (13)
-
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