Re: [Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?

Re: [Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?

[Laurent Vivier]

>In message: <f43fc5580904191144y1fd8e4d6m3321855d0c558250@mail.gmail.com>
>            Blue Swirl <blauwirbel@gmail.com> writes:
>: On 4/19/09, M. Warner Losh <imp@bsdimp.com> wrote:
>: > In message: <f488382f0904190128l4383a56eu67a2f16eb338e61c@mail.gmail.com>
>: >
>: >             Steven Noonan <steven@uplinklabs.net> writes:
>: >  : I eventually decided it made more
>: >  : sense to get QEMU working instead. I did notice that the pre-OpenBIOS
>: >  : version of QEMU was able to boot Mac OS X via Open Hack'Ware, so I was
>: >  : annoyed to find that OpenBIOS didn't have such support. So, I might as
>: >  : well add it.
>: >
>: >
>: > Open Hackware was barely enough to boot older versions of Linux.
>: >  Other operating systems that needed more extensive properties from the
>: >  OpenFirmware device tree failed to boot because they weren't present.
>: >  I was involved in a large effort to get FreeBSD/powerpc booting on
>: >  QEMU only to have it fail utterly because the amount of hacking on
>: >  OpenHackWare needed was rather large and mysterious...
>: 
>: This is what I get with OpenBIOS:
>: >> *** Boot failure! No secondary bootloader specified ***
>: 
>: 0 > boot cd:,\boot\loader cd:0
>: Consoles: Open Firmware console
>: 
>: FreeBSD/Open Firmware/PowerPC bootstrap loader, Revision 0.1
>: (root@xserve.lan.xcllnt.net, Thu Apr 16 18:47:58 UTC 2009)
>: Memory: 131072KB
>: Booted from: cd
>: 
>: Loading /boot/defaults/loader.conf
>: /boot/kernel/kernel data=0x4a4ce0+0x3d4e4 syms=[0x4+0x454f0+0x4+0x5a4b9]
>: /
>: Hit [Enter] to boot immediately, or any other key for command prompt.
>: Booting [/boot/kernel/kernel]...
>: Kernel entry at 0x13dac0 ...
>: panic: moea_bootstrap: no space to copy translations
>: Uptime: 1s
>
>That's similar to the one that I've seen as well.  The problem with
>this one, IIRC, is that FreeBSD/powerpc is trying to setup the memory
>translations for the MMU and the 'translations' property length is
>zero, or something like that...
>

It seems there is the same problem with the Haiku bootloader, I have a patch to correct this.

Laurent


-- 
--------------------- Laurent@vivier.eu  ---------------------
"Tout ce qui est impossible reste à accomplir"    Jules Verne
"Things are only impossible until they're not" Jean-Luc Picard

[Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?

[Andreas Färber]

Am 19.04.2009 um 09:50 schrieb Steven Noonan:

> On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan  
> <steven@uplinklabs.net> wrote:
>> On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier  
>> <Laurent@lvivier.info> wrote:
>>> OpenBIOS is not able to boot MacOS X.
>>
>> Well, that's a silly limitation. Is there a reason this isn't
>> implemented? I see that the Mac-on-Linux OpenBIOS version has such
>> support, so it seems strange that the QEMU version does not.
>
> I don't know if anyone here is actually interested (this list seems
> -very- quiet), but...
>
> I've been hacking at OpenBIOS for a bit, and I got it to properly read
> Mac OS X discs (it kept failing because it would hit an Apple
> Partition Map header instead of an HFS+ filesystem header). I'm
> working on adding an XCOFF loader, too, so it should be able to boot
> Mac OS X soon.
>
> Any chances I could get these changes merged to the main OpenBIOS tree
> once they're done?
>
> My current working repository is at http://github.com/tycho/openbios.
> I'm working on the macosx-boot branch. The relevant commit is here
> (patch also attached):
> http://github.com/tycho/openbios/commit/4722c8a01d186a08183de49759dc8b7b74cf41c9
>
> Thoughts?

Your work surely sounds interesting. However, making OpenBIOS boot  
from the disks is not everything there is to it. Alexander Graf had  
once posted a series of patches for making Mac OS X boot in QEMU,  
including changes/additions to device emulation. They were not merged,  
not sure about the status today.

One issue iirc was that you need to obtain some Apple ID from a real  
Mac of yours and pass that to QEMU for it to work.

Andreas

[Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?

[Steven Noonan]

On Sun, Apr 19, 2009 at 1:03 AM, Andreas Färber <andreas.faerber@web.de> wrote:
>
> Am 19.04.2009 um 09:50 schrieb Steven Noonan:
>
>> On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan <steven@uplinklabs.net>
>> wrote:
>>>
>>> On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier <Laurent@lvivier.info>
>>> wrote:
>>>>
>>>> OpenBIOS is not able to boot MacOS X.
>>>
>>> Well, that's a silly limitation. Is there a reason this isn't
>>> implemented? I see that the Mac-on-Linux OpenBIOS version has such
>>> support, so it seems strange that the QEMU version does not.
>>
>> I don't know if anyone here is actually interested (this list seems
>> -very- quiet), but...
>>
>> I've been hacking at OpenBIOS for a bit, and I got it to properly read
>> Mac OS X discs (it kept failing because it would hit an Apple
>> Partition Map header instead of an HFS+ filesystem header). I'm
>> working on adding an XCOFF loader, too, so it should be able to boot
>> Mac OS X soon.
>>
>> Any chances I could get these changes merged to the main OpenBIOS tree
>> once they're done?
>>
>> My current working repository is at http://github.com/tycho/openbios.
>> I'm working on the macosx-boot branch. The relevant commit is here
>> (patch also attached):
>>
>> http://github.com/tycho/openbios/commit/4722c8a01d186a08183de49759dc8b7b74cf41c9
>>
>> Thoughts?
>
> Your work surely sounds interesting. However, making OpenBIOS boot from the
> disks is not everything there is to it. Alexander Graf had once posted a
> series of patches for making Mac OS X boot in QEMU, including
> changes/additions to device emulation. They were not merged, not sure about
> the status today.
>
> One issue iirc was that you need to obtain some Apple ID from a real Mac of
> yours and pass that to QEMU for it to work.

Ah, thanks for that tip. I was completely oblivious to his work. But
from the looks of it, his work is x86-oriented. My intent was to get
the PowerPC version of Mac OS X running, which will probably be a bit
easier, particularly since QEMU already emulates the appropriate
hardware (g3bw, mac99). It's just a matter of getting OpenBIOS to boot
it, I think.

I was originally hacking PearPC into working order, and was going to
optimize it, but PearPC's code base is an absolute mess. It contains a
ridiculous number of horrible hacks, a very disorganized tree, and
it's slower than glacial movement. I eventually decided it made more
sense to get QEMU working instead. I did notice that the pre-OpenBIOS
version of QEMU was able to boot Mac OS X via Open Hack'Ware, so I was
annoyed to find that OpenBIOS didn't have such support. So, I might as
well add it.

[Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?

[Andreas Färber]

Am 19.04.2009 um 10:28 schrieb Steven Noonan:

> On Sun, Apr 19, 2009 at 1:03 AM, Andreas Färber <andreas.faerber@web.de 
> > wrote:
>>
>> Am 19.04.2009 um 09:50 schrieb Steven Noonan:
>>
>>> On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan <steven@uplinklabs.net 
>>> >
>>> wrote:
>>>>
>>>> On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier <Laurent@lvivier.info 
>>>> >
>>>> wrote:
>>>>>
>>>>> OpenBIOS is not able to boot MacOS X.
>>>>
>>>> Well, that's a silly limitation. Is there a reason this isn't
>>>> implemented? I see that the Mac-on-Linux OpenBIOS version has such
>>>> support, so it seems strange that the QEMU version does not.
>>>
>>> I don't know if anyone here is actually interested (this list seems
>>> -very- quiet), but...
>>>
>>> I've been hacking at OpenBIOS for a bit, and I got it to properly  
>>> read
>>> Mac OS X discs (it kept failing because it would hit an Apple
>>> Partition Map header instead of an HFS+ filesystem header). I'm
>>> working on adding an XCOFF loader, too, so it should be able to boot
>>> Mac OS X soon.
>>>
>>> Any chances I could get these changes merged to the main OpenBIOS  
>>> tree
>>> once they're done?
>>>
>>> My current working repository is at http://github.com/tycho/ 
>>> openbios.
>>> I'm working on the macosx-boot branch. The relevant commit is here
>>> (patch also attached):
>>>
>>> http://github.com/tycho/openbios/commit/4722c8a01d186a08183de49759dc8b7b74cf41c9
>>>
>>> Thoughts?
>>
>> Your work surely sounds interesting. However, making OpenBIOS boot  
>> from the
>> disks is not everything there is to it. Alexander Graf had once  
>> posted a
>> series of patches for making Mac OS X boot in QEMU, including
>> changes/additions to device emulation. They were not merged, not  
>> sure about
>> the status today.
>>
>> One issue iirc was that you need to obtain some Apple ID from a  
>> real Mac of
>> yours and pass that to QEMU for it to work.
>
> Ah, thanks for that tip. I was completely oblivious to his work. But
> from the looks of it, his work is x86-oriented. My intent was to get
> the PowerPC version of Mac OS X running, which will probably be a bit
> easier, particularly since QEMU already emulates the appropriate
> hardware (g3bw, mac99). It's just a matter of getting OpenBIOS to boot
> it, I think.

Wasn't there a recent revert from g3bw to g3beige machine emulation  
due to not fully supported devices?
Might raise some issues with Leopard, Tiger may work better.

Andreas

Re: [Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?

[M. Warner Losh]

In message: <f488382f0904190128l4383a56eu67a2f16eb338e61c@mail.gmail.com>
            Steven Noonan <steven@uplinklabs.net> writes:
: I eventually decided it made more
: sense to get QEMU working instead. I did notice that the pre-OpenBIOS
: version of QEMU was able to boot Mac OS X via Open Hack'Ware, so I was
: annoyed to find that OpenBIOS didn't have such support. So, I might as
: well add it.

Open Hackware was barely enough to boot older versions of Linux.
Other operating systems that needed more extensive properties from the
OpenFirmware device tree failed to boot because they weren't present.
I was involved in a large effort to get FreeBSD/powerpc booting on
QEMU only to have it fail utterly because the amount of hacking on
OpenHackWare needed was rather large and mysterious...

Warner

Re: [Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?

[Steven Noonan]

On Sun, Apr 19, 2009 at 10:47 AM, M. Warner Losh <imp@bsdimp.com> wrote:
> In message: <f488382f0904190128l4383a56eu67a2f16eb338e61c@mail.gmail.com>
>            Steven Noonan <steven@uplinklabs.net> writes:
> : I eventually decided it made more
> : sense to get QEMU working instead. I did notice that the pre-OpenBIOS
> : version of QEMU was able to boot Mac OS X via Open Hack'Ware, so I was
> : annoyed to find that OpenBIOS didn't have such support. So, I might as
> : well add it.
>
> Open Hackware was barely enough to boot older versions of Linux.
> Other operating systems that needed more extensive properties from the
> OpenFirmware device tree failed to boot because they weren't present.
> I was involved in a large effort to get FreeBSD/powerpc booting on
> QEMU only to have it fail utterly because the amount of hacking on
> OpenHackWare needed was rather large and mysterious...
>

Yes, Open Hack'Ware is as much a hack as PearPC is, in my opinion. It
uses very strange design decisions, which I suppose were inspired by
an "I'll do this later" attitude. For instance, in the CHRP script
'parser' it has, it will do a CRC of the boot script and then do a
table lookup to figure out what to do next, i.e.:

                    case 0xEA06C1A7:
                        /* MacOS 9.2 boot script:
                         * the XCOFF loader is embedded in the file...
                         */
                    case 0x53A95958:
                        /* iBook 2 restore CD (MacOS X 10.2) */
                        [snip]
                        goto out;
                    case 0x8d5acb86:
                        /* Darwin-7.01
                         * The executable file is embedded after the script
                         */
                        break;

Quite clearly, Open Hack'Ware was aptly named. It seems to have made
no effort to actually -execute- the CHRP boot-script, and instead just
do whatever would be necessary to get specific OSes working. Blech.

- Steven

Re: [Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?

[Blue Swirl]

On 4/19/09, M. Warner Losh <imp@bsdimp.com> wrote:
> In message: <f488382f0904190128l4383a56eu67a2f16eb338e61c@mail.gmail.com>
>
>             Steven Noonan <steven@uplinklabs.net> writes:
>  : I eventually decided it made more
>  : sense to get QEMU working instead. I did notice that the pre-OpenBIOS
>  : version of QEMU was able to boot Mac OS X via Open Hack'Ware, so I was
>  : annoyed to find that OpenBIOS didn't have such support. So, I might as
>  : well add it.
>
>
> Open Hackware was barely enough to boot older versions of Linux.
>  Other operating systems that needed more extensive properties from the
>  OpenFirmware device tree failed to boot because they weren't present.
>  I was involved in a large effort to get FreeBSD/powerpc booting on
>  QEMU only to have it fail utterly because the amount of hacking on
>  OpenHackWare needed was rather large and mysterious...

This is what I get with OpenBIOS:
>> *** Boot failure! No secondary bootloader specified ***

0 > boot cd:,\boot\loader cd:0
Consoles: Open Firmware console

FreeBSD/Open Firmware/PowerPC bootstrap loader, Revision 0.1
(root@xserve.lan.xcllnt.net, Thu Apr 16 18:47:58 UTC 2009)
Memory: 131072KB
Booted from: cd

Loading /boot/defaults/loader.conf
/boot/kernel/kernel data=0x4a4ce0+0x3d4e4 syms=[0x4+0x454f0+0x4+0x5a4b9]
/
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
Kernel entry at 0x13dac0 ...
panic: moea_bootstrap: no space to copy translations
Uptime: 1s

Re: [Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?

[M. Warner Losh]

In message: <f43fc5580904191144y1fd8e4d6m3321855d0c558250@mail.gmail.com>
            Blue Swirl <blauwirbel@gmail.com> writes:
: On 4/19/09, M. Warner Losh <imp@bsdimp.com> wrote:
: > In message: <f488382f0904190128l4383a56eu67a2f16eb338e61c@mail.gmail.com>
: >
: >             Steven Noonan <steven@uplinklabs.net> writes:
: >  : I eventually decided it made more
: >  : sense to get QEMU working instead. I did notice that the pre-OpenBIOS
: >  : version of QEMU was able to boot Mac OS X via Open Hack'Ware, so I was
: >  : annoyed to find that OpenBIOS didn't have such support. So, I might as
: >  : well add it.
: >
: >
: > Open Hackware was barely enough to boot older versions of Linux.
: >  Other operating systems that needed more extensive properties from the
: >  OpenFirmware device tree failed to boot because they weren't present.
: >  I was involved in a large effort to get FreeBSD/powerpc booting on
: >  QEMU only to have it fail utterly because the amount of hacking on
: >  OpenHackWare needed was rather large and mysterious...
: 
: This is what I get with OpenBIOS:
: >> *** Boot failure! No secondary bootloader specified ***
: 
: 0 > boot cd:,\boot\loader cd:0
: Consoles: Open Firmware console
: 
: FreeBSD/Open Firmware/PowerPC bootstrap loader, Revision 0.1
: (root@xserve.lan.xcllnt.net, Thu Apr 16 18:47:58 UTC 2009)
: Memory: 131072KB
: Booted from: cd
: 
: Loading /boot/defaults/loader.conf
: /boot/kernel/kernel data=0x4a4ce0+0x3d4e4 syms=[0x4+0x454f0+0x4+0x5a4b9]
: /
: Hit [Enter] to boot immediately, or any other key for command prompt.
: Booting [/boot/kernel/kernel]...
: Kernel entry at 0x13dac0 ...
: panic: moea_bootstrap: no space to copy translations
: Uptime: 1s

That's similar to the one that I've seen as well.  The problem with
this one, IIRC, is that FreeBSD/powerpc is trying to setup the memory
translations for the MMU and the 'translations' property length is
zero, or something like that...

Warner

Re: [Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?

[Blue Swirl]

On 4/20/09, M. Warner Losh <imp@bsdimp.com> wrote:
> In message: <f43fc5580904191144y1fd8e4d6m3321855d0c558250@mail.gmail.com>
>             Blue Swirl <blauwirbel@gmail.com> writes:
>
> : On 4/19/09, M. Warner Losh <imp@bsdimp.com> wrote:
>  : > In message: <f488382f0904190128l4383a56eu67a2f16eb338e61c@mail.gmail.com>
>  : >
>  : >             Steven Noonan <steven@uplinklabs.net> writes:
>  : >  : I eventually decided it made more
>  : >  : sense to get QEMU working instead. I did notice that the pre-OpenBIOS
>  : >  : version of QEMU was able to boot Mac OS X via Open Hack'Ware, so I was
>  : >  : annoyed to find that OpenBIOS didn't have such support. So, I might as
>  : >  : well add it.
>  : >
>  : >
>  : > Open Hackware was barely enough to boot older versions of Linux.
>  : >  Other operating systems that needed more extensive properties from the
>  : >  OpenFirmware device tree failed to boot because they weren't present.
>  : >  I was involved in a large effort to get FreeBSD/powerpc booting on
>  : >  QEMU only to have it fail utterly because the amount of hacking on
>  : >  OpenHackWare needed was rather large and mysterious...
>  :
>  : This is what I get with OpenBIOS:
>  : >> *** Boot failure! No secondary bootloader specified ***
>  :
>  : 0 > boot cd:,\boot\loader cd:0
>  : Consoles: Open Firmware console
>  :
>  : FreeBSD/Open Firmware/PowerPC bootstrap loader, Revision 0.1
>  : (root@xserve.lan.xcllnt.net, Thu Apr 16 18:47:58 UTC 2009)
>  : Memory: 131072KB
>  : Booted from: cd
>  :
>  : Loading /boot/defaults/loader.conf
>  : /boot/kernel/kernel data=0x4a4ce0+0x3d4e4 syms=[0x4+0x454f0+0x4+0x5a4b9]
>  : /
>  : Hit [Enter] to boot immediately, or any other key for command prompt.
>  : Booting [/boot/kernel/kernel]...
>  : Kernel entry at 0x13dac0 ...
>  : panic: moea_bootstrap: no space to copy translations
>  : Uptime: 1s
>
>
> That's similar to the one that I've seen as well.  The problem with
>  this one, IIRC, is that FreeBSD/powerpc is trying to setup the memory
>  translations for the MMU and the 'translations' property length is
>  zero, or something like that...

Right, the error comes from this line:
http://fxr.watson.org/fxr/source/powerpc/powerpc/mmu_oea.c?v=FREEBSD70#L825

Re: [Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?

[François Revol]

> On 4/20/09, M. Warner Losh <imp@bsdimp.com> wrote:
> > In message: <
> > f43fc5580904191144y1fd8e4d6m3321855d0c558250@mail.gmail.com>
> >             Blue Swirl <blauwirbel@gmail.com> writes:
> >
> > : On 4/19/09, M. Warner Losh <imp@bsdimp.com> wrote:
> >  : > In message: <
> > f488382f0904190128l4383a56eu67a2f16eb338e61c@mail.gmail.com>
> >  : >
> >  : >             Steven Noonan <steven@uplinklabs.net> writes:
> >  : >  : I eventually decided it made more
> >  : >  : sense to get QEMU working instead. I did notice that the
> > pre-OpenBIOS
> >  : >  : version of QEMU was able to boot Mac OS X via Open
> > Hack'Ware, so I was
> >  : >  : annoyed to find that OpenBIOS didn't have such support. So,
> > I might as
> >  : >  : well add it.
> >  : >
> >  : >
> >  : > Open Hackware was barely enough to boot older versions of
> > Linux.
> >  : >  Other operating systems that needed more extensive properties
> > from the
> >  : >  OpenFirmware device tree failed to boot because they weren't
> > present.
> >  : >  I was involved in a large effort to get FreeBSD/powerpc
> > booting on
> >  : >  QEMU only to have it fail utterly because the amount of
> > hacking on
> >  : >  OpenHackWare needed was rather large and mysterious...
> >  :
> >  : This is what I get with OpenBIOS:
> >  : >> *** Boot failure! No secondary bootloader specified ***
> >  :
> >  : 0 > boot cd:,\boot\loader cd:0
> >  : Consoles: Open Firmware console
> >  :
> >  : FreeBSD/Open Firmware/PowerPC bootstrap loader, Revision 0.1
> >  : (root@xserve.lan.xcllnt.net, Thu Apr 16 18:47:58 UTC 2009)
> >  : Memory: 131072KB
> >  : Booted from: cd
> >  :
> >  : Loading /boot/defaults/loader.conf
> >  : /boot/kernel/kernel data=0x4a4ce0+0x3d4e4 syms=[0x4+0x454f0+0x4+
> > 0x5a4b9]
> >  : /
> >  : Hit [Enter] to boot immediately, or any other key for command
> > prompt.
> >  : Booting [/boot/kernel/kernel]...
> >  : Kernel entry at 0x13dac0 ...
> >  : panic: moea_bootstrap: no space to copy translations
> >  : Uptime: 1s
> >
> >
> > That's similar to the one that I've seen as well.  The problem with
> >  this one, IIRC, is that FreeBSD/powerpc is trying to setup the
> > memory
> >  translations for the MMU and the 'translations' property length is
> >  zero, or something like that...
>
> Right, the error comes from this line:
> http://fxr.watson.org/fxr/source/powerpc/powerpc/mmu_oea.c?v=FREEBSD70#L825
>
FWIW, Haiku still stops somewhere at
http://dev.haiku-os.org/browser/haiku/trunk/src/system/boot/platform/openfirmware/arch/ppc/mmu.cpp#L968
...

[revol@debian ~/devel/haiku/trunk]$ qemu-system-ppc -nographic -serial
stdio -cdrom generated.ppc/haiku-boot-cd-ppc.iso -boot d
>> =============================================================
>> OpenBIOS 1.0 [Mar 31 2009 15:35]
>> Configuration device id QEMU version 1 machine id 2
>> CPUs: 1
>> Memory: 128M
>> UUID: 00000000-0000-0000-0000-000000000000
>> CPU type PowerPC,750
Welcome to OpenBIOS v1.0 built on Mar 31 2009 15:35


checking for memory...
0: base = 0x00000000, size = 134217728
1: empty region
total physical memory = 128 MB
suggested page table size = 1048576
need new page table, size = 1048576!
new table at: 0x07d00000
MSR: 0x00003030
found 4 translations
found page table!
no mapping for the exception handlers!

François.

[Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?

[Laurent Vivier]

Le dimanche 19 avril 2009 à 10:03 +0200, Andreas Färber a écrit :
> Am 19.04.2009 um 09:50 schrieb Steven Noonan:
> 
> > On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan  
> > <steven@uplinklabs.net> wrote:
> >> On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier  
> >> <Laurent@lvivier.info> wrote:
> >>> OpenBIOS is not able to boot MacOS X.
> >>
> >> Well, that's a silly limitation. Is there a reason this isn't
> >> implemented? I see that the Mac-on-Linux OpenBIOS version has such
> >> support, so it seems strange that the QEMU version does not.
> >
> > I don't know if anyone here is actually interested (this list seems
> > -very- quiet), but...
> >
> > I've been hacking at OpenBIOS for a bit, and I got it to properly read
> > Mac OS X discs (it kept failing because it would hit an Apple
> > Partition Map header instead of an HFS+ filesystem header). I'm
> > working on adding an XCOFF loader, too, so it should be able to boot
> > Mac OS X soon.
> >
> > Any chances I could get these changes merged to the main OpenBIOS tree
> > once they're done?
> >
> > My current working repository is at http://github.com/tycho/openbios.
> > I'm working on the macosx-boot branch. The relevant commit is here
> > (patch also attached):
> > http://github.com/tycho/openbios/commit/4722c8a01d186a08183de49759dc8b7b74cf41c9
> >
> > Thoughts?
> 
> Your work surely sounds interesting. However, making OpenBIOS boot  
> from the disks is not everything there is to it. Alexander Graf had  
> once posted a series of patches for making Mac OS X boot in QEMU,  
> including changes/additions to device emulation. They were not merged,  
> not sure about the status today.

Alexander made a work to boot Intel Mac OS X.
It works very well with KVM (I use it).

http://alex.csgraf.de/

See the HowTo http://d4wiki.goddamm.it/index.php/Howto:_Mac_OSX_on_KVM .

> One issue iirc was that you need to obtain some Apple ID from a real  
> Mac of yours and pass that to QEMU for it to work.

I don't think it is needed with powerPC MacOS X.
I seems OpenHackware was able to boot powerPC MacOS X. Perhaps we should
look at it.

Regards,
Laurent

[Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?

[Dave Willoughby]

On Apr 19, 2009, at 3:31 AM, Laurent Vivier wrote:

> Le dimanche 19 avril 2009 à 10:03 +0200, Andreas Färber a écrit :
>> Am 19.04.2009 um 09:50 schrieb Steven Noonan:
>>
>>> On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan
>>> <steven@uplinklabs.net> wrote:
>>>> On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier
>>>> <Laurent@lvivier.info> wrote:
>>>>> OpenBIOS is not able to boot MacOS X.
>>>>
>>>> Well, that's a silly limitation. Is there a reason this isn't
>>>> implemented? I see that the Mac-on-Linux OpenBIOS version has such
>>>> support, so it seems strange that the QEMU version does not.
>>>
>>> I don't know if anyone here is actually interested (this list seems
>>> -very- quiet), but...
>>>
>>> I've been hacking at OpenBIOS for a bit, and I got it to properly  
>>> read
>>> Mac OS X discs (it kept failing because it would hit an Apple
>>> Partition Map header instead of an HFS+ filesystem header). I'm
>>> working on adding an XCOFF loader, too, so it should be able to boot
>>> Mac OS X soon.
>>>
>>> Any chances I could get these changes merged to the main OpenBIOS  
>>> tree
>>> once they're done?
>>>
>>> My current working repository is at http://github.com/tycho/ 
>>> openbios.
>>> I'm working on the macosx-boot branch. The relevant commit is here
>>> (patch also attached):
>>> http://github.com/tycho/openbios/commit/4722c8a01d186a08183de49759dc8b7b74cf41c9
>>>
>>> Thoughts?
>>
>> Your work surely sounds interesting. However, making OpenBIOS boot
>> from the disks is not everything there is to it. Alexander Graf had
>> once posted a series of patches for making Mac OS X boot in QEMU,
>> including changes/additions to device emulation. They were not  
>> merged,
>> not sure about the status today.
>
> Alexander made a work to boot Intel Mac OS X.
> It works very well with KVM (I use it).
>
> 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?

I don't have the message in front of me now, but I think I was getting  
"device not found" when I used -hda /dev/sdc or -hda /dev/sdc1.

>
>
>> One issue iirc was that you need to obtain some Apple ID from a real
>> Mac of yours and pass that to QEMU for it to work.
>
> I don't think it is needed with powerPC MacOS X.
> I seems OpenHackware was able to boot powerPC MacOS X. Perhaps we  
> should
> look at it.
>
> Regards,
> Laurent
>
>
> -- 
> OpenBIOS                 http://openbios.org/
> Mailinglist:  http://lists.openbios.org/mailman/listinfo
> Free your System - May the Forth be with you

[Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?

[Alexander Graf]

Hi Dave,

On 20.05.2009, at 15:51, Dave Willoughby wrote:

>
> On Apr 19, 2009, at 3:31 AM, Laurent Vivier wrote:
>
>> Le dimanche 19 avril 2009 à 10:03 +0200, Andreas Färber a écrit :
>>
>> Alexander made a work to boot Intel Mac OS X.
>> It works very well with KVM (I use it).
>>
>> 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.

GPT formatted by Mac OS X? You need to have an MBR synced on it.

> Does anyone know if Alexander's kvm-osx-bootloader can boot real,  
> host managed HDDs, or is it dependent on something associated with  
> disk image files, created by qemu-img?

You boot the bootloader using -kernel which then reads the partition  
table. That has nothing to do with OpenBIOS and only remotely with  
qemu though, so if you still can't get it to work, please email me off- 
list :-).

Alex

[Qemu-devel] Re: QEMU OpenBIOS booting?

[Steven Noonan]

On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier <Laurent@lvivier.info> wrote:
> Le dimanche 19 avril 2009 à 00:50 -0700, Steven Noonan a écrit :
>> On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan <steven@uplinklabs.net> wrote:
>> > On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier <Laurent@lvivier.info> wrote:
>> >> OpenBIOS is not able to boot MacOS X.
>> >
>> > Well, that's a silly limitation. Is there a reason this isn't
>> > implemented? I see that the Mac-on-Linux OpenBIOS version has such
>> > support, so it seems strange that the QEMU version does not.
>>
>> I don't know if anyone here is actually interested (this list seems
>> -very- quiet), but...
>
> Hi,
>
>> I've been hacking at OpenBIOS for a bit, and I got it to properly read
>> Mac OS X discs (it kept failing because it would hit an Apple
>> Partition Map header instead of an HFS+ filesystem header). I'm
>> working on adding an XCOFF loader, too, so it should be able to boot
>> Mac OS X soon.
>
> You can copy it from OpenHackWare.
> I made some tests and it seems to have some memory conflicts between
> MacOS kernel and OpenBIOS.
>
> Good Luck.
>

Two more pre-XCOFF loader commits up:
http://github.com/tycho/openbios/commit/e43daa3447b5ce4a2b05b2f32882e49891156200
http://github.com/tycho/openbios/commit/7023b78a10f5632fd08d4749615efd3e73ab1036

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

[Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?

[Blue Swirl]

On 4/19/09, Steven Noonan <steven@uplinklabs.net> wrote:
> On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier <Laurent@lvivier.info> wrote:
>  > Le dimanche 19 avril 2009 à 00:50 -0700, Steven Noonan a écrit :
>  >> On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan <steven@uplinklabs.net> wrote:
>  >> > On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier <Laurent@lvivier.info> wrote:
>  >> >> OpenBIOS is not able to boot MacOS X.
>  >> >
>  >> > Well, that's a silly limitation. Is there a reason this isn't
>  >> > implemented? I see that the Mac-on-Linux OpenBIOS version has such
>  >> > support, so it seems strange that the QEMU version does not.
>  >>
>  >> I don't know if anyone here is actually interested (this list seems
>  >> -very- quiet), but...
>  >
>  > Hi,
>  >
>  >> I've been hacking at OpenBIOS for a bit, and I got it to properly read
>  >> Mac OS X discs (it kept failing because it would hit an Apple
>  >> Partition Map header instead of an HFS+ filesystem header). I'm
>  >> working on adding an XCOFF loader, too, so it should be able to boot
>  >> Mac OS X soon.
>  >
>  > You can copy it from OpenHackWare.
>  > I made some tests and it seems to have some memory conflicts between
>  > MacOS kernel and OpenBIOS.
>  >
>  > Good Luck.
>  >
>
>
> Two more pre-XCOFF loader commits up:
>  http://github.com/tycho/openbios/commit/e43daa3447b5ce4a2b05b2f32882e49891156200
>  http://github.com/tycho/openbios/commit/7023b78a10f5632fd08d4749615efd3e73ab1036

These look fine to me.

>  And I have something (uncommitted) that at least -loads- the
>  CHRP-embedded XCOFF binaries now, but I am not sure what to do to
>  execute the result. With ELF, it seems you can just use the call_elf()
>  function. I don't know PowerPC assembler (nor the XCOFF format) well
>  enough yet to know what would be necessary for a call_xcoff()
>  function. Anyone want to help out with this?

Well, call_elf should work regardless of the format. The first and
second parameters will be passed verbatim to OS (Linux uses those for
initrd address and size), the third is the start address that should
be available for all formats. There's some more description near the
function call_elf in start.S.

So I'd just add something like call_elf(0, 0, xcoff_start) somewhere.

[Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?

[Steven Noonan]

On Sun, Apr 19, 2009 at 12:23 PM, Blue Swirl <blauwirbel@gmail.com> wrote:
> On 4/19/09, Steven Noonan <steven@uplinklabs.net> wrote:
>> On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier <Laurent@lvivier.info> wrote:
>>  > Le dimanche 19 avril 2009 à 00:50 -0700, Steven Noonan a écrit :
>>  >> On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan <steven@uplinklabs.net> wrote:
>>  >> > On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier <Laurent@lvivier.info> wrote:
>>  >> >> OpenBIOS is not able to boot MacOS X.
>>  >> >
>>  >> > Well, that's a silly limitation. Is there a reason this isn't
>>  >> > implemented? I see that the Mac-on-Linux OpenBIOS version has such
>>  >> > support, so it seems strange that the QEMU version does not.
>>  >>
>>  >> I don't know if anyone here is actually interested (this list seems
>>  >> -very- quiet), but...
>>  >
>>  > Hi,
>>  >
>>  >> I've been hacking at OpenBIOS for a bit, and I got it to properly read
>>  >> Mac OS X discs (it kept failing because it would hit an Apple
>>  >> Partition Map header instead of an HFS+ filesystem header). I'm
>>  >> working on adding an XCOFF loader, too, so it should be able to boot
>>  >> Mac OS X soon.
>>  >
>>  > You can copy it from OpenHackWare.
>>  > I made some tests and it seems to have some memory conflicts between
>>  > MacOS kernel and OpenBIOS.
>>  >
>>  > Good Luck.
>>  >
>>
>>
>> Two more pre-XCOFF loader commits up:
>>  http://github.com/tycho/openbios/commit/e43daa3447b5ce4a2b05b2f32882e49891156200
>>  http://github.com/tycho/openbios/commit/7023b78a10f5632fd08d4749615efd3e73ab1036
>
> These look fine to me.
>
>>  And I have something (uncommitted) that at least -loads- the
>>  CHRP-embedded XCOFF binaries now, but I am not sure what to do to
>>  execute the result. With ELF, it seems you can just use the call_elf()
>>  function. I don't know PowerPC assembler (nor the XCOFF format) well
>>  enough yet to know what would be necessary for a call_xcoff()
>>  function. Anyone want to help out with this?
>
> Well, call_elf should work regardless of the format. The first and
> second parameters will be passed verbatim to OS (Linux uses those for
> initrd address and size), the third is the start address that should
> be available for all formats. There's some more description near the
> function call_elf in start.S.
>
> So I'd just add something like call_elf(0, 0, xcoff_start) somewhere.

Ah, that did what it should've. I guess 'call_elf' is a misnomer?

I'm not committing the XCOFF loader quite yet. I suspect it would be
best to do refactor it to use a similar API to what the ELF loader
has, and place it so that it could be shared with the other OpenBIOS
targets (pearpc, mol, etc)... Would it be preferred to make the XCOFF
loader QEMU-specific or should it be a common API like the ELF loader?

So here's what I get when I try Mac OS X 10.4 (I've enabled a ton of
debug output):


Alcarin:qemu steven$ ppc-softmmu/qemu-system-ppc -L pc-bios -cdrom
~/Development/MacOSX-10.4.iso -boot d -M mac99 -nographic

>> =============================================================
>> OpenBIOS 1.0 [Apr 19 2009 19:39]
>> Configuration device id QEMU version 1 machine id 1
>> CPUs: 1
>> Memory: 128M
>> UUID: 00000000-0000-0000-0000-000000000000
>> CPU type PowerPC,G4
Welcome to OpenBIOS v1.0 built on Apr 19 2009 19:39

>> YABOOT - yaboot_startup: Entering boot, no path
>> CHRP - try_chrp_script: Trying cd:0,ppc\bootinfo.txt
>> MAC-PARTS: macparts_probe 4552 ?= 4552
>> MAC-PARTS: macparts_open 0
>> MAC-PARTS: macparts_get_info 0 2832209920
>> MAC-PARTS: macparts_block_size = 200
>> volume_read_wrapper: got sig 482b
>> volume_read_wrapper: got sig 482b
>> ELF - try_chrp_script: Can't open cd:0,ppc\bootinfo.txt
>> CHRP - try_chrp_script: Trying cd:0,System\Library\CoreServices\BootX
>> MAC-PARTS: macparts_probe 4552 ?= 4552
>> MAC-PARTS: macparts_open 0
>> MAC-PARTS: macparts_get_info 0 2832209920
>> MAC-PARTS: macparts_block_size = 200
>> volume_read_wrapper: got sig 482b
>> volume_read_wrapper: got sig 482b
>> CHRP - try_chrp_script: got bootscript
>> load-base
>> begin
>>  dup 6 " &lt;/CHRP" $= if
>>   6 + dup 6 " -BOOT&gt;" $= 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

[Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?

[Laurent Vivier]

Le dimanche 19 avril 2009 à 13:00 -0700, Steven Noonan a écrit :
> On Sun, Apr 19, 2009 at 12:23 PM, Blue Swirl <blauwirbel@gmail.com> wrote:
> > On 4/19/09, Steven Noonan <steven@uplinklabs.net> wrote:
> >> On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier <Laurent@lvivier.info> wrote:
> >>  > Le dimanche 19 avril 2009 à 00:50 -0700, Steven Noonan a écrit :
> >>  >> On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan <steven@uplinklabs.net> wrote:
> >>  >> > On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier <Laurent@lvivier.info> wrote:
> >>  >> >> OpenBIOS is not able to boot MacOS X.
> >>  >> >
> [...]
> $=:>> XCOFF - load_xcoff: Loading 'System\Library\CoreServices\BootX'
> >> XCOFF - load_xcoff: XCOFF file with 3 sections entry:fff0a22c
> >> XCOFF - load_xcoff: Read next header (5c)
> >> XCOFF - load_xcoff: Load '.text' section from 5c d4 to 5600000 (28000)
> >> XCOFF - load_xcoff: Read next header (84)
> >> XCOFF - load_xcoff: Load '.data' section from 84 280d4 to 5628000 (2000)
> >> XCOFF - load_xcoff: Read next header (ac)
> >> XCOFF - load_xcoff: Erase '.bss' section at 562a000 size: 3a000
> >> ELF - transfer_control_to_elf: Starting ELF boot loader
> invalid/unsupported opcode: 02 - 0e - 0c (0b717b1c) 05616ed8 1
> invalid/unsupported opcode: 00 - 14 - 13 (000064e8) 000094d0 0
> Alcarin:qemu steven$
> 
> 
> So at least with my patches, we're getting what people with QEMU 0.8.0
> were getting: http://tinyurl.com/qemu080
> 
> So now what's left is resolving -why- that 'invalid/unsupported
> opcode' issue crops up.

I think the booloader is loaded at addresses overwriting some parts of
openbios.

Regards,
Laurent

[Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?

[Steven Noonan]

On Sun, Apr 19, 2009 at 1:08 PM, Laurent Vivier <Laurent@lvivier.info> wrote:
> Le dimanche 19 avril 2009 à 13:00 -0700, Steven Noonan a écrit :
>> On Sun, Apr 19, 2009 at 12:23 PM, Blue Swirl <blauwirbel@gmail.com> wrote:
>> > On 4/19/09, Steven Noonan <steven@uplinklabs.net> wrote:
>> >> On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier <Laurent@lvivier.info> wrote:
>> >>  > Le dimanche 19 avril 2009 à 00:50 -0700, Steven Noonan a écrit :
>> >>  >> On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan <steven@uplinklabs.net> wrote:
>> >>  >> > On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier <Laurent@lvivier.info> wrote:
>> >>  >> >> OpenBIOS is not able to boot MacOS X.
>> >>  >> >
>> [...]
>> $=:>> XCOFF - load_xcoff: Loading 'System\Library\CoreServices\BootX'
>> >> XCOFF - load_xcoff: XCOFF file with 3 sections entry:fff0a22c
>> >> XCOFF - load_xcoff: Read next header (5c)
>> >> XCOFF - load_xcoff: Load '.text' section from 5c d4 to 5600000 (28000)
>> >> XCOFF - load_xcoff: Read next header (84)
>> >> XCOFF - load_xcoff: Load '.data' section from 84 280d4 to 5628000 (2000)
>> >> XCOFF - load_xcoff: Read next header (ac)
>> >> XCOFF - load_xcoff: Erase '.bss' section at 562a000 size: 3a000
>> >> ELF - transfer_control_to_elf: Starting ELF boot loader
>> invalid/unsupported opcode: 02 - 0e - 0c (0b717b1c) 05616ed8 1
>> invalid/unsupported opcode: 00 - 14 - 13 (000064e8) 000094d0 0
>> Alcarin:qemu steven$
>>
>>
>> So at least with my patches, we're getting what people with QEMU 0.8.0
>> were getting: http://tinyurl.com/qemu080
>>
>> So now what's left is resolving -why- that 'invalid/unsupported
>> opcode' issue crops up.
>
> I think the booloader is loaded at addresses overwriting some parts of
> openbios.
>

That would make sense, but that tells me QEMU is loading OpenBIOS to
the wrong location. From the book "Mac OS X Internals: A Systems
Approach":

Table 45. BootX Logical Memory Map

Starting Address   Ending Address    Purpose
0x00000000    0x00003FFF    Exception vectors.
0x00004000    0x03FFFFFF    Kernel image, boot structures, and drivers.
0x04000000    0x04FFFFFF    File load area.
0x05000000    0x053FFFFF    Simple read-time cache for file system
metadata. Cache hits are serviced from memory, whereas cache misses
result in disk access.
0x05400000    0x055FFFFF    Malloc zone: a simple memory allocator is
implemented in BootX's libclite subproject. The starting and ending
addresses of this range define the block of memory used by the
allocator.
0x05600000    0x057FFFFF    BootX image.
0x05800000    0x05FFFFFF    Unused (occupied by the Open Firmware image).


So it should be loading OpenBIOS to address 0x05800000, and the BootX
image should load to 0x05600000 (the latter does as it should,
according to the debug output).

[Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?

[Laurent Vivier]

Le dimanche 19 avril 2009 à 13:14 -0700, Steven Noonan a écrit :
> On Sun, Apr 19, 2009 at 1:08 PM, Laurent Vivier <Laurent@lvivier.info> wrote:
> > Le dimanche 19 avril 2009 à 13:00 -0700, Steven Noonan a écrit :
> >> On Sun, Apr 19, 2009 at 12:23 PM, Blue Swirl <blauwirbel@gmail.com> wrote:
> >> > On 4/19/09, Steven Noonan <steven@uplinklabs.net> wrote:
> >> >> On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier <Laurent@lvivier.info> wrote:
> >> >>  > Le dimanche 19 avril 2009 à 00:50 -0700, Steven Noonan a écrit :
> >> >>  >> On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan <steven@uplinklabs.net> wrote:
> >> >>  >> > On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier <Laurent@lvivier.info> wrote:
> >> >>  >> >> OpenBIOS is not able to boot MacOS X.
> >> >>  >> >
> >> [...]
> >> $=:>> XCOFF - load_xcoff: Loading 'System\Library\CoreServices\BootX'
> >> >> XCOFF - load_xcoff: XCOFF file with 3 sections entry:fff0a22c
> >> >> XCOFF - load_xcoff: Read next header (5c)
> >> >> XCOFF - load_xcoff: Load '.text' section from 5c d4 to 5600000 (28000)
> >> >> XCOFF - load_xcoff: Read next header (84)
> >> >> XCOFF - load_xcoff: Load '.data' section from 84 280d4 to 5628000 (2000)
> >> >> XCOFF - load_xcoff: Read next header (ac)
> >> >> XCOFF - load_xcoff: Erase '.bss' section at 562a000 size: 3a000
> >> >> ELF - transfer_control_to_elf: Starting ELF boot loader
> >> invalid/unsupported opcode: 02 - 0e - 0c (0b717b1c) 05616ed8 1
> >> invalid/unsupported opcode: 00 - 14 - 13 (000064e8) 000094d0 0
> >> Alcarin:qemu steven$
> >>
> >>
> >> So at least with my patches, we're getting what people with QEMU 0.8.0
> >> were getting: http://tinyurl.com/qemu080
> >>
> >> So now what's left is resolving -why- that 'invalid/unsupported
> >> opcode' issue crops up.
> >
> > I think the booloader is loaded at addresses overwriting some parts of
> > openbios.
> >
> 
> That would make sense, but that tells me QEMU is loading OpenBIOS to

The problem is in OpenBios: I put some structures in memory without
knowing this... but this is not part of openfirmware specification.


> the wrong location. From the book "Mac OS X Internals: A Systems
> Approach":
> 
> Table 45. BootX Logical Memory Map
> 
> Starting Address   Ending Address    Purpose
> 0x00000000    0x00003FFF    Exception vectors.
> 0x00004000    0x03FFFFFF    Kernel image, boot structures, and drivers.

I put there some memory allocation information.

> 0x04000000    0x04FFFFFF    File load area.
> 0x05000000    0x053FFFFF    Simple read-time cache for file system
> metadata. Cache hits are serviced from memory, whereas cache misses
> result in disk access.
> 0x05400000    0x055FFFFF    Malloc zone: a simple memory allocator is
> implemented in BootX's libclite subproject. The starting and ending
> addresses of this range define the block of memory used by the
> allocator.

BootX should use openBIOS functions to allocate memory (as Yaboot
does...)

> 0x05600000    0x057FFFFF    BootX image.

This should be "load-base"

> 0x05800000    0x05FFFFFF    Unused (occupied by the Open Firmware image).
> 
> 
> So it should be loading OpenBIOS to address 0x05800000, and the BootX
> image should load to 0x05600000 (the latter does as it should,
> according to the debug output).

For the moment OpenBIOS is loaded at end physical memory and mapped at
end of space address (the reset vector is here).

Regards,
Laurent

[Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?

[Steven Noonan]

On Sun, Apr 19, 2009 at 1:24 PM, Laurent Vivier <Laurent@vivier.eu> wrote:
> Le dimanche 19 avril 2009 à 13:14 -0700, Steven Noonan a écrit :
>> On Sun, Apr 19, 2009 at 1:08 PM, Laurent Vivier <Laurent@lvivier.info> wrote:
>> > Le dimanche 19 avril 2009 à 13:00 -0700, Steven Noonan a écrit :
>> >> On Sun, Apr 19, 2009 at 12:23 PM, Blue Swirl <blauwirbel@gmail.com> wrote:
>> >> > On 4/19/09, Steven Noonan <steven@uplinklabs.net> wrote:
>> >> >> On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier <Laurent@lvivier.info> wrote:
>> >> >>  > Le dimanche 19 avril 2009 à 00:50 -0700, Steven Noonan a écrit :
>> >> >>  >> On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan <steven@uplinklabs.net> wrote:
>> >> >>  >> > On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier <Laurent@lvivier.info> wrote:
>> >> >>  >> >> OpenBIOS is not able to boot MacOS X.
>> >> >>  >> >
>> >> [...]
>> >> $=:>> XCOFF - load_xcoff: Loading 'System\Library\CoreServices\BootX'
>> >> >> XCOFF - load_xcoff: XCOFF file with 3 sections entry:fff0a22c
>> >> >> XCOFF - load_xcoff: Read next header (5c)
>> >> >> XCOFF - load_xcoff: Load '.text' section from 5c d4 to 5600000 (28000)
>> >> >> XCOFF - load_xcoff: Read next header (84)
>> >> >> XCOFF - load_xcoff: Load '.data' section from 84 280d4 to 5628000 (2000)
>> >> >> XCOFF - load_xcoff: Read next header (ac)
>> >> >> XCOFF - load_xcoff: Erase '.bss' section at 562a000 size: 3a000
>> >> >> ELF - transfer_control_to_elf: Starting ELF boot loader
>> >> invalid/unsupported opcode: 02 - 0e - 0c (0b717b1c) 05616ed8 1
>> >> invalid/unsupported opcode: 00 - 14 - 13 (000064e8) 000094d0 0
>> >> Alcarin:qemu steven$
>> >>
>> >>
>> >> So at least with my patches, we're getting what people with QEMU 0.8.0
>> >> were getting: http://tinyurl.com/qemu080
>> >>
>> >> So now what's left is resolving -why- that 'invalid/unsupported
>> >> opcode' issue crops up.
>> >
>> > I think the booloader is loaded at addresses overwriting some parts of
>> > openbios.
>> >
>>
>> That would make sense, but that tells me QEMU is loading OpenBIOS to
>
> The problem is in OpenBios: I put some structures in memory without
> knowing this... but this is not part of openfirmware specification.

Agreed, this seems to be an undocumented Apple-ism. But since OSes
other than Mac OS X run on PowerPC macs (i.e. BSD, Linux), I must
assume that they are aware of these quirks and don't hammer those
memory locations. Since that's the case, it may be wise to conform to
what Apple's Open Firmware does, even if it _is_ undocumented.

How easy would it be to get OpenBIOS to load to the position Mac OS X
and BootX expect it to be? Based on what the book says, there are 8MB
of memory available to the Open Firmware, would that be enough for the
OpenBIOS executable image and any allocations it would need to
perform?

>
>> the wrong location. From the book "Mac OS X Internals: A Systems
>> Approach":
>>
>> Table 45. BootX Logical Memory Map
>>
>> Starting Address   Ending Address    Purpose
>> 0x00000000    0x00003FFF    Exception vectors.
>> 0x00004000    0x03FFFFFF    Kernel image, boot structures, and drivers.
>
> I put there some memory allocation information.
>
>> 0x04000000    0x04FFFFFF    File load area.
>> 0x05000000    0x053FFFFF    Simple read-time cache for file system
>> metadata. Cache hits are serviced from memory, whereas cache misses
>> result in disk access.
>> 0x05400000    0x055FFFFF    Malloc zone: a simple memory allocator is
>> implemented in BootX's libclite subproject. The starting and ending
>> addresses of this range define the block of memory used by the
>> allocator.
>
> BootX should use openBIOS functions to allocate memory (as Yaboot
> does...)

Apparently BootX is tricky that way. I don't have the BootX source
code, so I can't verify the author's statement, but I would guess he
knows what he's talking about.

>> 0x05600000    0x057FFFFF    BootX image.
>
> This should be "load-base"
>
>> 0x05800000    0x05FFFFFF    Unused (occupied by the Open Firmware image).
>>
>>
>> So it should be loading OpenBIOS to address 0x05800000, and the BootX
>> image should load to 0x05600000 (the latter does as it should,
>> according to the debug output).
>
> For the moment OpenBIOS is loaded at end physical memory and mapped at
> end of space address (the reset vector is here).
>

Alright, is that location part of the official specification? If so,
good, then we could use that memory for any allocations OpenBIOS would
need to do. If not, then who's to say that location won't get hammered
by the OS or boot loader?

[Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?

[Laurent Vivier]

Le dimanche 19 avril 2009 à 13:33 -0700, Steven Noonan a écrit :
> On Sun, Apr 19, 2009 at 1:24 PM, Laurent Vivier <Laurent@vivier.eu> wrote:
> > Le dimanche 19 avril 2009 à 13:14 -0700, Steven Noonan a écrit :
> >> On Sun, Apr 19, 2009 at 1:08 PM, Laurent Vivier <Laurent@lvivier.info> wrote:
> >> > Le dimanche 19 avril 2009 à 13:00 -0700, Steven Noonan a écrit :
> >> >> On Sun, Apr 19, 2009 at 12:23 PM, Blue Swirl <blauwirbel@gmail.com> wrote:
> >> >> > On 4/19/09, Steven Noonan <steven@uplinklabs.net> wrote:
> >> >> >> On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier <Laurent@lvivier.info> wrote:
> >> >> >>  > Le dimanche 19 avril 2009 à 00:50 -0700, Steven Noonan a écrit :
> >> >> >>  >> On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan <steven@uplinklabs.net> wrote:
> >> >> >>  >> > On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier <Laurent@lvivier.info> wrote:
> >> >> >>  >> >> OpenBIOS is not able to boot MacOS X.
> >> >> >>  >> >
> >> >> [...]
> >> >> $=:>> XCOFF - load_xcoff: Loading 'System\Library\CoreServices\BootX'
> >> >> >> XCOFF - load_xcoff: XCOFF file with 3 sections entry:fff0a22c
> >> >> >> XCOFF - load_xcoff: Read next header (5c)
> >> >> >> XCOFF - load_xcoff: Load '.text' section from 5c d4 to 5600000 (28000)
> >> >> >> XCOFF - load_xcoff: Read next header (84)
> >> >> >> XCOFF - load_xcoff: Load '.data' section from 84 280d4 to 5628000 (2000)
> >> >> >> XCOFF - load_xcoff: Read next header (ac)
> >> >> >> XCOFF - load_xcoff: Erase '.bss' section at 562a000 size: 3a000
> >> >> >> ELF - transfer_control_to_elf: Starting ELF boot loader
> >> >> invalid/unsupported opcode: 02 - 0e - 0c (0b717b1c) 05616ed8 1
> >> >> invalid/unsupported opcode: 00 - 14 - 13 (000064e8) 000094d0 0
> >> >> Alcarin:qemu steven$
> >> >>
> >> >>
> >> >> So at least with my patches, we're getting what people with QEMU 0.8.0
> >> >> were getting: http://tinyurl.com/qemu080
> >> >>
> >> >> So now what's left is resolving -why- that 'invalid/unsupported
> >> >> opcode' issue crops up.
> >> >
> >> > I think the booloader is loaded at addresses overwriting some parts of
> >> > openbios.
> >> >
> >>
> >> That would make sense, but that tells me QEMU is loading OpenBIOS to
> >
> > The problem is in OpenBios: I put some structures in memory without
> > knowing this... but this is not part of openfirmware specification.
> 
> Agreed, this seems to be an undocumented Apple-ism. But since OSes
> other than Mac OS X run on PowerPC macs (i.e. BSD, Linux), I must

AIX is also using OpenFirmware / PPC / CHRP, and I think they don't care
of Apple-ism.

> assume that they are aware of these quirks and don't hammer those
> memory locations. Since that's the case, it may be wise to conform to
> what Apple's Open Firmware does, even if it _is_ undocumented.

'Yes, we can' (R).

> How easy would it be to get OpenBIOS to load to the position Mac OS X
> and BootX expect it to be? Based on what the book says, there are 8MB
> of memory available to the Open Firmware, would that be enough for the
> OpenBIOS executable image and any allocations it would need to
> perform?
> 
> >
> >> the wrong location. From the book "Mac OS X Internals: A Systems
> >> Approach":
> >>
> >> Table 45. BootX Logical Memory Map
> >>
> >> Starting Address   Ending Address    Purpose
> >> 0x00000000    0x00003FFF    Exception vectors.
> >> 0x00004000    0x03FFFFFF    Kernel image, boot structures, and drivers.
> >
> > I put there some memory allocation information.
> >
> >> 0x04000000    0x04FFFFFF    File load area.
> >> 0x05000000    0x053FFFFF    Simple read-time cache for file system
> >> metadata. Cache hits are serviced from memory, whereas cache misses
> >> result in disk access.
> >> 0x05400000    0x055FFFFF    Malloc zone: a simple memory allocator is
> >> implemented in BootX's libclite subproject. The starting and ending
> >> addresses of this range define the block of memory used by the
> >> allocator.
> >
> > BootX should use openBIOS functions to allocate memory (as Yaboot
> > does...)
> 
> Apparently BootX is tricky that way. I don't have the BootX source
> code, so I can't verify the author's statement, but I would guess he
> knows what he's talking about.

Look here:

http://www.opensource.apple.com/darwinsource/tarballs/apsl/BootX-81.tar.gz

(You need an Apple Developer ID)

Regards,
Laurent

[Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?

[Steven Noonan]

On Sun, Apr 19, 2009 at 1:48 PM, Laurent Vivier <Laurent@vivier.eu> wrote:
> Le dimanche 19 avril 2009 à 13:33 -0700, Steven Noonan a écrit :
>> On Sun, Apr 19, 2009 at 1:24 PM, Laurent Vivier <Laurent@vivier.eu> wrote:
>> > Le dimanche 19 avril 2009 à 13:14 -0700, Steven Noonan a écrit :
>> >> On Sun, Apr 19, 2009 at 1:08 PM, Laurent Vivier <Laurent@lvivier.info> wrote:
>> >> > Le dimanche 19 avril 2009 à 13:00 -0700, Steven Noonan a écrit :
>> >> >> On Sun, Apr 19, 2009 at 12:23 PM, Blue Swirl <blauwirbel@gmail.com> wrote:
>> >> >> > On 4/19/09, Steven Noonan <steven@uplinklabs.net> wrote:
>> >> >> >> On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier <Laurent@lvivier.info> wrote:
>> >> >> >>  > Le dimanche 19 avril 2009 à 00:50 -0700, Steven Noonan a écrit :
>> >> >> >>  >> On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan <steven@uplinklabs.net> wrote:
>> >> >> >>  >> > On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier <Laurent@lvivier.info> wrote:
>> >> >> >>  >> >> OpenBIOS is not able to boot MacOS X.
>> >> >> >>  >> >
>> >> >> [...]
>> >> >> $=:>> XCOFF - load_xcoff: Loading 'System\Library\CoreServices\BootX'
>> >> >> >> XCOFF - load_xcoff: XCOFF file with 3 sections entry:fff0a22c
>> >> >> >> XCOFF - load_xcoff: Read next header (5c)
>> >> >> >> XCOFF - load_xcoff: Load '.text' section from 5c d4 to 5600000 (28000)
>> >> >> >> XCOFF - load_xcoff: Read next header (84)
>> >> >> >> XCOFF - load_xcoff: Load '.data' section from 84 280d4 to 5628000 (2000)
>> >> >> >> XCOFF - load_xcoff: Read next header (ac)
>> >> >> >> XCOFF - load_xcoff: Erase '.bss' section at 562a000 size: 3a000
>> >> >> >> ELF - transfer_control_to_elf: Starting ELF boot loader
>> >> >> invalid/unsupported opcode: 02 - 0e - 0c (0b717b1c) 05616ed8 1
>> >> >> invalid/unsupported opcode: 00 - 14 - 13 (000064e8) 000094d0 0
>> >> >> Alcarin:qemu steven$
>> >> >>
>> >> >>
>> >> >> So at least with my patches, we're getting what people with QEMU 0.8.0
>> >> >> were getting: http://tinyurl.com/qemu080
>> >> >>
>> >> >> So now what's left is resolving -why- that 'invalid/unsupported
>> >> >> opcode' issue crops up.
>> >> >
>> >> > I think the booloader is loaded at addresses overwriting some parts of
>> >> > openbios.
>> >> >
>> >>
>> >> That would make sense, but that tells me QEMU is loading OpenBIOS to
>> >
>> > The problem is in OpenBios: I put some structures in memory without
>> > knowing this... but this is not part of openfirmware specification.
>>
>> Agreed, this seems to be an undocumented Apple-ism. But since OSes
>> other than Mac OS X run on PowerPC macs (i.e. BSD, Linux), I must
>
> AIX is also using OpenFirmware / PPC / CHRP, and I think they don't care
> of Apple-ism.
>
>> assume that they are aware of these quirks and don't hammer those
>> memory locations. Since that's the case, it may be wise to conform to
>> what Apple's Open Firmware does, even if it _is_ undocumented.
>
> 'Yes, we can' (R).
>
>> How easy would it be to get OpenBIOS to load to the position Mac OS X
>> and BootX expect it to be? Based on what the book says, there are 8MB
>> of memory available to the Open Firmware, would that be enough for the
>> OpenBIOS executable image and any allocations it would need to
>> perform?
>>
>> >
>> >> the wrong location. From the book "Mac OS X Internals: A Systems
>> >> Approach":
>> >>
>> >> Table 45. BootX Logical Memory Map
>> >>
>> >> Starting Address   Ending Address    Purpose
>> >> 0x00000000    0x00003FFF    Exception vectors.
>> >> 0x00004000    0x03FFFFFF    Kernel image, boot structures, and drivers.
>> >
>> > I put there some memory allocation information.
>> >
>> >> 0x04000000    0x04FFFFFF    File load area.
>> >> 0x05000000    0x053FFFFF    Simple read-time cache for file system
>> >> metadata. Cache hits are serviced from memory, whereas cache misses
>> >> result in disk access.
>> >> 0x05400000    0x055FFFFF    Malloc zone: a simple memory allocator is
>> >> implemented in BootX's libclite subproject. The starting and ending
>> >> addresses of this range define the block of memory used by the
>> >> allocator.
>> >
>> > BootX should use openBIOS functions to allocate memory (as Yaboot
>> > does...)
>>
>> Apparently BootX is tricky that way. I don't have the BootX source
>> code, so I can't verify the author's statement, but I would guess he
>> knows what he's talking about.
>
> Look here:
>
> http://www.opensource.apple.com/darwinsource/tarballs/apsl/BootX-81.tar.gz
>
> (You need an Apple Developer ID)
>

Aha. From sl.h:

/*

Memory Map:  assumed 96 MB (temporarily bumping to 112 MB for 4359362)

Physical Address

Open Firmware Version    3x, 4x, ...
00000000 - 00003FFF  :   Exception Vectors
00004000 - 057FFFFF  :   Free Memory
// 05800000 - 05FFFFFF  :   OF Image (top 8 MB reserved) [96 MB map]
06800000 - 06FFFFFF  :   OF Image (top 8 MB reserved) [112 MB map]


Logical Address

// 96 MB map (currently unused - 4363357 tracks re-adoption)
00000000 - 00003FFF  : Exception Vectors
00004000 - 03FFFFFF  : Kernel Image, Boot Struct and Drivers (~64 MB)
04000000 - 04FFFFFF  : File Load Area (16 MB) 	[80 MB]
05000000 - 053FFFFF  : FS Cache    (4 MB)  	[84 MB]
05400000 - 055FFFFF  : Malloc Zone (2 MB)	[86 MB]
05600000 - 057FFFFF  : BootX Image (2 MB)	[88 MB]
05800000 - 05FFFFFF  : Unused/OF   (8 MB)	[96 MB]

// 112 MB map (per 4359362)
00000000 - 00003FFF  : Exception Vectors
00004000 - 03FFFFFF  : Kernel Image, Boot Struct and Drivers (~64 MB)
04000000 - 05FFFFFF  : File Load Area (32 MB) 	[96 MB]
06000000 - 063FFFFF  : FS Cache    (4 MB)  	[100 MB]
06400000 - 065FFFFF  : Malloc Zone (2 MB)	[102 MB]
06600000 - 067FFFFF  : BootX Image (2 MB)	[104 MB]
06800000 - 06FFFFFF  : Unused/OF   (8 MB)	[112 MB]
*/


The 96MB map looks like what we're trying to conform to. I wonder what
this "4359362" they refer to is? An internal bug number or document
number?

[Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?

[Steven Noonan]

On Sun, Apr 19, 2009 at 2:02 PM, Steven Noonan <steven@uplinklabs.net> wrote:
> On Sun, Apr 19, 2009 at 1:48 PM, Laurent Vivier <Laurent@vivier.eu> wrote:
>> Le dimanche 19 avril 2009 à 13:33 -0700, Steven Noonan a écrit :
>>> On Sun, Apr 19, 2009 at 1:24 PM, Laurent Vivier <Laurent@vivier.eu> wrote:
>>> > Le dimanche 19 avril 2009 à 13:14 -0700, Steven Noonan a écrit :
>>> > The problem is in OpenBios: I put some structures in memory without
>>> > knowing this... but this is not part of openfirmware specification.
>>>
>>> Agreed, this seems to be an undocumented Apple-ism. But since OSes
>>> other than Mac OS X run on PowerPC macs (i.e. BSD, Linux), I must
>>
>> AIX is also using OpenFirmware / PPC / CHRP, and I think they don't care
>> of Apple-ism.
>>
>>> assume that they are aware of these quirks and don't hammer those
>>> memory locations. Since that's the case, it may be wise to conform to
>>> what Apple's Open Firmware does, even if it _is_ undocumented.
>>
>> 'Yes, we can' (R).
>>
>>> How easy would it be to get OpenBIOS to load to the position Mac OS X
>>> and BootX expect it to be? Based on what the book says, there are 8MB
>>> of memory available to the Open Firmware, would that be enough for the
>>> OpenBIOS executable image and any allocations it would need to
>>> perform?
>>>
>>> >
>>> >> the wrong location. From the book "Mac OS X Internals: A Systems
>>> >> Approach":
>>> >>
>>> >> Table 45. BootX Logical Memory Map
>>> >>
>>> >> Starting Address   Ending Address    Purpose
>>> >> 0x00000000    0x00003FFF    Exception vectors.
>>> >> 0x00004000    0x03FFFFFF    Kernel image, boot structures, and drivers.
>>> >
>>> > I put there some memory allocation information.
>>> >
>>> >> 0x04000000    0x04FFFFFF    File load area.
>>> >> 0x05000000    0x053FFFFF    Simple read-time cache for file system
>>> >> metadata. Cache hits are serviced from memory, whereas cache misses
>>> >> result in disk access.
>>> >> 0x05400000    0x055FFFFF    Malloc zone: a simple memory allocator is
>>> >> implemented in BootX's libclite subproject. The starting and ending
>>> >> addresses of this range define the block of memory used by the
>>> >> allocator.
>>> >
>>> > BootX should use openBIOS functions to allocate memory (as Yaboot
>>> > does...)
>>>
>>> Apparently BootX is tricky that way. I don't have the BootX source
>>> code, so I can't verify the author's statement, but I would guess he
>>> knows what he's talking about.
>>
>> Look here:
>>
>> http://www.opensource.apple.com/darwinsource/tarballs/apsl/BootX-81.tar.gz
>>
>> (You need an Apple Developer ID)
>>
>
> Aha. From sl.h:
>
> /*
>
> Memory Map:  assumed 96 MB (temporarily bumping to 112 MB for 4359362)
>
> Physical Address
>
> Open Firmware Version    3x, 4x, ...
> 00000000 - 00003FFF  :   Exception Vectors
> 00004000 - 057FFFFF  :   Free Memory
> // 05800000 - 05FFFFFF  :   OF Image (top 8 MB reserved) [96 MB map]
> 06800000 - 06FFFFFF  :   OF Image (top 8 MB reserved) [112 MB map]
>
>
> Logical Address
>
> // 96 MB map (currently unused - 4363357 tracks re-adoption)
> 00000000 - 00003FFF  : Exception Vectors
> 00004000 - 03FFFFFF  : Kernel Image, Boot Struct and Drivers (~64 MB)
> 04000000 - 04FFFFFF  : File Load Area (16 MB)   [80 MB]
> 05000000 - 053FFFFF  : FS Cache    (4 MB)       [84 MB]
> 05400000 - 055FFFFF  : Malloc Zone (2 MB)       [86 MB]
> 05600000 - 057FFFFF  : BootX Image (2 MB)       [88 MB]
> 05800000 - 05FFFFFF  : Unused/OF   (8 MB)       [96 MB]
>
> // 112 MB map (per 4359362)
> 00000000 - 00003FFF  : Exception Vectors
> 00004000 - 03FFFFFF  : Kernel Image, Boot Struct and Drivers (~64 MB)
> 04000000 - 05FFFFFF  : File Load Area (32 MB)   [96 MB]
> 06000000 - 063FFFFF  : FS Cache    (4 MB)       [100 MB]
> 06400000 - 065FFFFF  : Malloc Zone (2 MB)       [102 MB]
> 06600000 - 067FFFFF  : BootX Image (2 MB)       [104 MB]
> 06800000 - 06FFFFFF  : Unused/OF   (8 MB)       [112 MB]
> */
>
>
> The 96MB map looks like what we're trying to conform to. I wonder what
> this "4359362" they refer to is? An internal bug number or document
> number?
>

OK, so I guess we should use the 112MB map, since the other one says
"currently unused", which reads to me as "deprecated".

So I'm looking into changing it to load to the position Apple's Open
Firmware would. Do these values seem right to you? (it's intentionally
space-smashed to prevent someone applying this to mainline)

	diff --git a/arch/ppc/qemu/ldscript b/arch/ppc/qemu/ldscript
	index 66fcbcd..8fdf654 100644
	--- a/arch/ppc/qemu/ldscript
	+++ b/arch/ppc/qemu/ldscript
	@@ -3,15 +3,15 @@ OUTPUT_ARCH(powerpc)
	
	 /* Initial load address
	  */
	-BASE_ADDR = 0xfff00000;
	+BASE_ADDR = 0x06800000;
	
	-/* As NVRAM is at 0xfff04000, the .text needs to be after that
	+/* As NVRAM is at 0x06804000, the .text needs to be after that
	  */
	-TEXT_ADDR = 0xfff08000;
	+TEXT_ADDR = 0x06808000;
	
	 /* Hard reset vector address
	  */
	-HRESET_ADDR = 0xfffffffc;
	+HRESET_ADDR = 0x06ffffff;
	
	 CSTACK_SIZE = 32768;   /* client stack size */

The only issue with doing things this way is now to figure out what to
change this to:

#define FREE_BASE		0x00004000

My first thought was to utilize all 8MB of the space that Apple says
we can have, and use any space after the OpenBIOS image. My second
thought was: how do we know where the OpenBIOS executable image ends?

Any ideas?

[Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?

[Steven Noonan]

On Sun, Apr 19, 2009 at 2:32 PM, Steven Noonan <steven@uplinklabs.net> wrote:
> On Sun, Apr 19, 2009 at 2:02 PM, Steven Noonan <steven@uplinklabs.net> wrote:
>> On Sun, Apr 19, 2009 at 1:48 PM, Laurent Vivier <Laurent@vivier.eu> wrote:
>>> Le dimanche 19 avril 2009 à 13:33 -0700, Steven Noonan a écrit :
>>>> On Sun, Apr 19, 2009 at 1:24 PM, Laurent Vivier <Laurent@vivier.eu> wrote:
>>>> > Le dimanche 19 avril 2009 à 13:14 -0700, Steven Noonan a écrit :
>>>> > The problem is in OpenBios: I put some structures in memory without
>>>> > knowing this... but this is not part of openfirmware specification.
>>>>
>>>> Agreed, this seems to be an undocumented Apple-ism. But since OSes
>>>> other than Mac OS X run on PowerPC macs (i.e. BSD, Linux), I must
>>>
>>> AIX is also using OpenFirmware / PPC / CHRP, and I think they don't care
>>> of Apple-ism.
>>>
>>>> assume that they are aware of these quirks and don't hammer those
>>>> memory locations. Since that's the case, it may be wise to conform to
>>>> what Apple's Open Firmware does, even if it _is_ undocumented.
>>>
>>> 'Yes, we can' (R).
>>>
>>>> How easy would it be to get OpenBIOS to load to the position Mac OS X
>>>> and BootX expect it to be? Based on what the book says, there are 8MB
>>>> of memory available to the Open Firmware, would that be enough for the
>>>> OpenBIOS executable image and any allocations it would need to
>>>> perform?
>>>>
>>>> >
>>>> >> the wrong location. From the book "Mac OS X Internals: A Systems
>>>> >> Approach":
>>>> >>
>>>> >> Table 45. BootX Logical Memory Map
>>>> >>
>>>> >> Starting Address   Ending Address    Purpose
>>>> >> 0x00000000    0x00003FFF    Exception vectors.
>>>> >> 0x00004000    0x03FFFFFF    Kernel image, boot structures, and drivers.
>>>> >
>>>> > I put there some memory allocation information.
>>>> >
>>>> >> 0x04000000    0x04FFFFFF    File load area.
>>>> >> 0x05000000    0x053FFFFF    Simple read-time cache for file system
>>>> >> metadata. Cache hits are serviced from memory, whereas cache misses
>>>> >> result in disk access.
>>>> >> 0x05400000    0x055FFFFF    Malloc zone: a simple memory allocator is
>>>> >> implemented in BootX's libclite subproject. The starting and ending
>>>> >> addresses of this range define the block of memory used by the
>>>> >> allocator.
>>>> >
>>>> > BootX should use openBIOS functions to allocate memory (as Yaboot
>>>> > does...)
>>>>
>>>> Apparently BootX is tricky that way. I don't have the BootX source
>>>> code, so I can't verify the author's statement, but I would guess he
>>>> knows what he's talking about.
>>>
>>> Look here:
>>>
>>> http://www.opensource.apple.com/darwinsource/tarballs/apsl/BootX-81.tar.gz
>>>
>>> (You need an Apple Developer ID)
>>>
>>
>> Aha. From sl.h:
>>
>> /*
>>
>> Memory Map:  assumed 96 MB (temporarily bumping to 112 MB for 4359362)
>>
>> Physical Address
>>
>> Open Firmware Version    3x, 4x, ...
>> 00000000 - 00003FFF  :   Exception Vectors
>> 00004000 - 057FFFFF  :   Free Memory
>> // 05800000 - 05FFFFFF  :   OF Image (top 8 MB reserved) [96 MB map]
>> 06800000 - 06FFFFFF  :   OF Image (top 8 MB reserved) [112 MB map]
>>
>>
>> Logical Address
>>
>> // 96 MB map (currently unused - 4363357 tracks re-adoption)
>> 00000000 - 00003FFF  : Exception Vectors
>> 00004000 - 03FFFFFF  : Kernel Image, Boot Struct and Drivers (~64 MB)
>> 04000000 - 04FFFFFF  : File Load Area (16 MB)   [80 MB]
>> 05000000 - 053FFFFF  : FS Cache    (4 MB)       [84 MB]
>> 05400000 - 055FFFFF  : Malloc Zone (2 MB)       [86 MB]
>> 05600000 - 057FFFFF  : BootX Image (2 MB)       [88 MB]
>> 05800000 - 05FFFFFF  : Unused/OF   (8 MB)       [96 MB]
>>
>> // 112 MB map (per 4359362)
>> 00000000 - 00003FFF  : Exception Vectors
>> 00004000 - 03FFFFFF  : Kernel Image, Boot Struct and Drivers (~64 MB)
>> 04000000 - 05FFFFFF  : File Load Area (32 MB)   [96 MB]
>> 06000000 - 063FFFFF  : FS Cache    (4 MB)       [100 MB]
>> 06400000 - 065FFFFF  : Malloc Zone (2 MB)       [102 MB]
>> 06600000 - 067FFFFF  : BootX Image (2 MB)       [104 MB]
>> 06800000 - 06FFFFFF  : Unused/OF   (8 MB)       [112 MB]
>> */
>>
>>
>> The 96MB map looks like what we're trying to conform to. I wonder what
>> this "4359362" they refer to is? An internal bug number or document
>> number?
>>
>
> OK, so I guess we should use the 112MB map, since the other one says
> "currently unused", which reads to me as "deprecated".
>
> So I'm looking into changing it to load to the position Apple's Open
> Firmware would. Do these values seem right to you? (it's intentionally
> space-smashed to prevent someone applying this to mainline)
>
>        diff --git a/arch/ppc/qemu/ldscript b/arch/ppc/qemu/ldscript
>        index 66fcbcd..8fdf654 100644
>        --- a/arch/ppc/qemu/ldscript
>        +++ b/arch/ppc/qemu/ldscript
>        @@ -3,15 +3,15 @@ OUTPUT_ARCH(powerpc)
>
>         /* Initial load address
>          */
>        -BASE_ADDR = 0xfff00000;
>        +BASE_ADDR = 0x06800000;
>
>        -/* As NVRAM is at 0xfff04000, the .text needs to be after that
>        +/* As NVRAM is at 0x06804000, the .text needs to be after that
>          */
>        -TEXT_ADDR = 0xfff08000;
>        +TEXT_ADDR = 0x06808000;
>
>         /* Hard reset vector address
>          */
>        -HRESET_ADDR = 0xfffffffc;
>        +HRESET_ADDR = 0x06ffffff;
>
>         CSTACK_SIZE = 32768;   /* client stack size */

With the above numbers, I get linker problems:

target/arch/ppc/qemu/start.o: In function `vector__0x300':
(.text.vectors+0x384): relocation truncated to fit: R_PPC_ADDR24
against `.text.vectors'+c
target/arch/ppc/qemu/start.o: In function `vector__0x400':
(.text.vectors+0x484): relocation truncated to fit: R_PPC_ADDR24
against `.text.vectors'+c

I don't see why it'd do that.

>
> The only issue with doing things this way is now to figure out what to
> change this to:
>
> #define FREE_BASE               0x00004000
>
> My first thought was to utilize all 8MB of the space that Apple says
> we can have, and use any space after the OpenBIOS image. My second
> thought was: how do we know where the OpenBIOS executable image ends?
>
> Any ideas?
>

[Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?

[Steven Noonan]

On Sun, Apr 19, 2009 at 3:28 PM, Steven Noonan <steven@uplinklabs.net> wrote:
> On Sun, Apr 19, 2009 at 2:32 PM, Steven Noonan <steven@uplinklabs.net> wrote:
>> On Sun, Apr 19, 2009 at 2:02 PM, Steven Noonan <steven@uplinklabs.net> wrote:
>>> On Sun, Apr 19, 2009 at 1:48 PM, Laurent Vivier <Laurent@vivier.eu> wrote:
>>>> Le dimanche 19 avril 2009 à 13:33 -0700, Steven Noonan a écrit :
>>>>> On Sun, Apr 19, 2009 at 1:24 PM, Laurent Vivier <Laurent@vivier.eu> wrote:
>>>>> > Le dimanche 19 avril 2009 à 13:14 -0700, Steven Noonan a écrit :
>>>>> > The problem is in OpenBios: I put some structures in memory without
>>>>> > knowing this... but this is not part of openfirmware specification.
>>>>>
>>>>> Agreed, this seems to be an undocumented Apple-ism. But since OSes
>>>>> other than Mac OS X run on PowerPC macs (i.e. BSD, Linux), I must
>>>>
>>>> AIX is also using OpenFirmware / PPC / CHRP, and I think they don't care
>>>> of Apple-ism.
>>>>
>>>>> assume that they are aware of these quirks and don't hammer those
>>>>> memory locations. Since that's the case, it may be wise to conform to
>>>>> what Apple's Open Firmware does, even if it _is_ undocumented.
>>>>
>>>> 'Yes, we can' (R).
>>>>
>>>>> How easy would it be to get OpenBIOS to load to the position Mac OS X
>>>>> and BootX expect it to be? Based on what the book says, there are 8MB
>>>>> of memory available to the Open Firmware, would that be enough for the
>>>>> OpenBIOS executable image and any allocations it would need to
>>>>> perform?
>>>>>
>>>>> >
>>>>> >> the wrong location. From the book "Mac OS X Internals: A Systems
>>>>> >> Approach":
>>>>> >>
>>>>> >> Table 45. BootX Logical Memory Map
>>>>> >>
>>>>> >> Starting Address   Ending Address    Purpose
>>>>> >> 0x00000000    0x00003FFF    Exception vectors.
>>>>> >> 0x00004000    0x03FFFFFF    Kernel image, boot structures, and drivers.
>>>>> >
>>>>> > I put there some memory allocation information.
>>>>> >
>>>>> >> 0x04000000    0x04FFFFFF    File load area.
>>>>> >> 0x05000000    0x053FFFFF    Simple read-time cache for file system
>>>>> >> metadata. Cache hits are serviced from memory, whereas cache misses
>>>>> >> result in disk access.
>>>>> >> 0x05400000    0x055FFFFF    Malloc zone: a simple memory allocator is
>>>>> >> implemented in BootX's libclite subproject. The starting and ending
>>>>> >> addresses of this range define the block of memory used by the
>>>>> >> allocator.
>>>>> >
>>>>> > BootX should use openBIOS functions to allocate memory (as Yaboot
>>>>> > does...)
>>>>>
>>>>> Apparently BootX is tricky that way. I don't have the BootX source
>>>>> code, so I can't verify the author's statement, but I would guess he
>>>>> knows what he's talking about.
>>>>
>>>> Look here:
>>>>
>>>> http://www.opensource.apple.com/darwinsource/tarballs/apsl/BootX-81.tar.gz
>>>>
>>>> (You need an Apple Developer ID)
>>>>
>>>
>>> Aha. From sl.h:
>>>
>>> /*
>>>
>>> Memory Map:  assumed 96 MB (temporarily bumping to 112 MB for 4359362)
>>>
>>> Physical Address
>>>
>>> Open Firmware Version    3x, 4x, ...
>>> 00000000 - 00003FFF  :   Exception Vectors
>>> 00004000 - 057FFFFF  :   Free Memory
>>> // 05800000 - 05FFFFFF  :   OF Image (top 8 MB reserved) [96 MB map]
>>> 06800000 - 06FFFFFF  :   OF Image (top 8 MB reserved) [112 MB map]
>>>
>>>
>>> Logical Address
>>>
>>> // 96 MB map (currently unused - 4363357 tracks re-adoption)
>>> 00000000 - 00003FFF  : Exception Vectors
>>> 00004000 - 03FFFFFF  : Kernel Image, Boot Struct and Drivers (~64 MB)
>>> 04000000 - 04FFFFFF  : File Load Area (16 MB)   [80 MB]
>>> 05000000 - 053FFFFF  : FS Cache    (4 MB)       [84 MB]
>>> 05400000 - 055FFFFF  : Malloc Zone (2 MB)       [86 MB]
>>> 05600000 - 057FFFFF  : BootX Image (2 MB)       [88 MB]
>>> 05800000 - 05FFFFFF  : Unused/OF   (8 MB)       [96 MB]
>>>
>>> // 112 MB map (per 4359362)
>>> 00000000 - 00003FFF  : Exception Vectors
>>> 00004000 - 03FFFFFF  : Kernel Image, Boot Struct and Drivers (~64 MB)
>>> 04000000 - 05FFFFFF  : File Load Area (32 MB)   [96 MB]
>>> 06000000 - 063FFFFF  : FS Cache    (4 MB)       [100 MB]
>>> 06400000 - 065FFFFF  : Malloc Zone (2 MB)       [102 MB]
>>> 06600000 - 067FFFFF  : BootX Image (2 MB)       [104 MB]
>>> 06800000 - 06FFFFFF  : Unused/OF   (8 MB)       [112 MB]
>>> */
>>>
>>>
>>> The 96MB map looks like what we're trying to conform to. I wonder what
>>> this "4359362" they refer to is? An internal bug number or document
>>> number?
>>>
>>
>> OK, so I guess we should use the 112MB map, since the other one says
>> "currently unused", which reads to me as "deprecated".
>>
>> So I'm looking into changing it to load to the position Apple's Open
>> Firmware would. Do these values seem right to you? (it's intentionally
>> space-smashed to prevent someone applying this to mainline)
>>
>>        diff --git a/arch/ppc/qemu/ldscript b/arch/ppc/qemu/ldscript
>>        index 66fcbcd..8fdf654 100644
>>        --- a/arch/ppc/qemu/ldscript
>>        +++ b/arch/ppc/qemu/ldscript
>>        @@ -3,15 +3,15 @@ OUTPUT_ARCH(powerpc)
>>
>>         /* Initial load address
>>          */
>>        -BASE_ADDR = 0xfff00000;
>>        +BASE_ADDR = 0x06800000;
>>
>>        -/* As NVRAM is at 0xfff04000, the .text needs to be after that
>>        +/* As NVRAM is at 0x06804000, the .text needs to be after that
>>          */
>>        -TEXT_ADDR = 0xfff08000;
>>        +TEXT_ADDR = 0x06808000;
>>
>>         /* Hard reset vector address
>>          */
>>        -HRESET_ADDR = 0xfffffffc;
>>        +HRESET_ADDR = 0x06ffffff;
>>
>>         CSTACK_SIZE = 32768;   /* client stack size */
>
> With the above numbers, I get linker problems:
>
> target/arch/ppc/qemu/start.o: In function `vector__0x300':
> (.text.vectors+0x384): relocation truncated to fit: R_PPC_ADDR24
> against `.text.vectors'+c
> target/arch/ppc/qemu/start.o: In function `vector__0x400':
> (.text.vectors+0x484): relocation truncated to fit: R_PPC_ADDR24
> against `.text.vectors'+c
>
> I don't see why it'd do that.
>


What the hell? Why would this change resolve it?

	diff --git a/arch/ppc/qemu/start.S b/arch/ppc/qemu/start.S
	index 66df9a2..108fd9b 100644
	--- a/arch/ppc/qemu/start.S
	+++ b/arch/ppc/qemu/start.S
	@@ -206,7 +206,7 @@ VECTOR( 0x300, "DSI" ):
	        addi    r3,r3,LO(dsi_exception)
	        mtctr   r3
	        bctrl
	-       ba      exception_return
	+       b       exception_return
	
	 VECTOR( 0x400, "ISI" ):
	        EXCEPTION_PREAMBLE
	@@ -214,7 +214,7 @@ VECTOR( 0x400, "ISI" ):
	        addi    r3,r3,LO(isi_exception)
	        mtctr   r3
	        bctrl
	-       ba      exception_return
	+       b       exception_return
	
	        ILLEGAL_VECTOR( 0x500 )
	        ILLEGAL_VECTOR( 0x600 )


>>
>> The only issue with doing things this way is now to figure out what to
>> change this to:
>>
>> #define FREE_BASE               0x00004000
>>
>> My first thought was to utilize all 8MB of the space that Apple says
>> we can have, and use any space after the OpenBIOS image. My second
>> thought was: how do we know where the OpenBIOS executable image ends?
>>
>> Any ideas?
>>
>

Re: [Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?

[malc]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3445 bytes --]

On Sun, 19 Apr 2009, Steven Noonan wrote:

> On Sun, Apr 19, 2009 at 3:28 PM, Steven Noonan <steven@uplinklabs.net> wrote:
> > On Sun, Apr 19, 2009 at 2:32 PM, Steven Noonan <steven@uplinklabs.net> wrote:
> >> On Sun, Apr 19, 2009 at 2:02 PM, Steven Noonan <steven@uplinklabs.net> wrote:
> >>> On Sun, Apr 19, 2009 at 1:48 PM, Laurent Vivier <Laurent@vivier.eu> wrote:
> >>>> Le dimanche 19 avril 2009 ? 13:33 -0700, Steven Noonan a ?crit :
> >>>>> On Sun, Apr 19, 2009 at 1:24 PM, Laurent Vivier <Laurent@vivier.eu> wrote:
> >>>>> > Le dimanche 19 avril 2009 ? 13:14 -0700, Steven Noonan a ?crit :
> >>>>> > The problem is in OpenBios: I put some structures in memory without
> >>>>> > knowing this... but this is not part of openfirmware specification.

[..snip..]

> >>
> >>        diff --git a/arch/ppc/qemu/ldscript b/arch/ppc/qemu/ldscript
> >>        index 66fcbcd..8fdf654 100644
> >>        --- a/arch/ppc/qemu/ldscript
> >>        +++ b/arch/ppc/qemu/ldscript
> >>        @@ -3,15 +3,15 @@ OUTPUT_ARCH(powerpc)
> >>
> >>         /* Initial load address
> >>          */
> >>        -BASE_ADDR = 0xfff00000;
> >>        +BASE_ADDR = 0x06800000;
> >>
> >>        -/* As NVRAM is at 0xfff04000, the .text needs to be after that
> >>        +/* As NVRAM is at 0x06804000, the .text needs to be after that
> >>          */
> >>        -TEXT_ADDR = 0xfff08000;
> >>        +TEXT_ADDR = 0x06808000;
> >>
> >>         /* Hard reset vector address
> >>          */
> >>        -HRESET_ADDR = 0xfffffffc;
> >>        +HRESET_ADDR = 0x06ffffff;
> >>
> >>         CSTACK_SIZE = 32768;   /* client stack size */
> >
> > With the above numbers, I get linker problems:
> >
> > target/arch/ppc/qemu/start.o: In function `vector__0x300':
> > (.text.vectors+0x384): relocation truncated to fit: R_PPC_ADDR24
> > against `.text.vectors'+c
> > target/arch/ppc/qemu/start.o: In function `vector__0x400':
> > (.text.vectors+0x484): relocation truncated to fit: R_PPC_ADDR24
> > against `.text.vectors'+c
> >
> > I don't see why it'd do that.
> >
> 
> 
> What the hell? Why would this change resolve it?
> 
> 	diff --git a/arch/ppc/qemu/start.S b/arch/ppc/qemu/start.S
> 	index 66df9a2..108fd9b 100644
> 	--- a/arch/ppc/qemu/start.S
> 	+++ b/arch/ppc/qemu/start.S
> 	@@ -206,7 +206,7 @@ VECTOR( 0x300, "DSI" ):
> 	        addi    r3,r3,LO(dsi_exception)
> 	        mtctr   r3
> 	        bctrl
> 	-       ba      exception_return
> 	+       b       exception_return
> 	

Because exception_return's address (now near 0x06808000) doesn't fit
into 26 bit sign extended AA field.

> 	 VECTOR( 0x400, "ISI" ):
> 	        EXCEPTION_PREAMBLE
> 	@@ -214,7 +214,7 @@ VECTOR( 0x400, "ISI" ):
> 	        addi    r3,r3,LO(isi_exception)
> 	        mtctr   r3
> 	        bctrl
> 	-       ba      exception_return
> 	+       b       exception_return
> 	
> 	        ILLEGAL_VECTOR( 0x500 )
> 	        ILLEGAL_VECTOR( 0x600 )
> 
> 
> >>
> >> The only issue with doing things this way is now to figure out what to
> >> change this to:
> >>
> >> #define FREE_BASE               0x00004000
> >>
> >> My first thought was to utilize all 8MB of the space that Apple says
> >> we can have, and use any space after the OpenBIOS image. My second
> >> thought was: how do we know where the OpenBIOS executable image ends?
> >>
> >> Any ideas?
> >>
> >
> 
> 

-- 
mailto:av1474@comtv.ru

[Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?

[Steven Noonan]

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

[Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?

[Steven Noonan]

On Sun, Apr 19, 2009 at 8:27 PM, Steven Noonan <steven@uplinklabs.net> wrote:
> So I decided a better idea was to keep the OpenBIOS ROM where it is
> and then instead use the location 0x06800000 for the memory
> allocations so that the 0x4000 block doesn't get smashed. It was far
> more feasible than moving where the ROM is stored, and I don't think
> anything cares about the contents of 0x06800000 to 06FFFFFF anyway.
>
> Also, the reason I was getting "invalid opcode" was because Open
> Hack'Ware's XCOFF loader didn't take into account some other unknown
> variable which PearPC accounted for. I added the necessary code to
> make that work.
>
> So now instead of an invalid opcode, we get this (which I don't know
> how to debug. it looks like a Forth exception):
>
> Alcarin:qemu steven$ make -C ppc-softmmu &&
> ppc-softmmu/qemu-system-ppc -L pc-bios -cdrom
> ~/Development/MacOSX-10.4.iso -boot d -M mac99 -nographic
> make: Nothing to be done for `all'.
>
>>> =============================================================
>>> OpenBIOS 1.0 [Apr 20 2009 03:23]
>>> Configuration device id QEMU version 1 machine id 1
>>> CPUs: 1
>>> Memory: 128M
>>> UUID: 00000000-0000-0000-0000-000000000000
>>> CPU type PowerPC,G4
> Welcome to OpenBIOS v1.0 built on Apr 20 2009 03:23
>
>>> YABOOT - yaboot_startup: Entering boot, no path
>>> CHRP - try_chrp_script: Trying cd:0,ppc\bootinfo.txt
>>> MAC-PARTS: macparts_probe 4552 ?= 4552
>>> MAC-PARTS: macparts_open 0
>>> MAC-PARTS: macparts_get_info 0 2832209920
>>> MAC-PARTS: macparts_block_size = 200
>>> ELF - try_chrp_script: Can't open cd:0,ppc\bootinfo.txt
>>> CHRP - try_chrp_script: Trying cd:0,System\Library\CoreServices\BootX
>>> MAC-PARTS: macparts_probe 4552 ?= 4552
>>> MAC-PARTS: macparts_open 0
>>> MAC-PARTS: macparts_get_info 0 2832209920
>>> MAC-PARTS: macparts_block_size = 200
>>> CHRP - try_chrp_script: got bootscript
>>> load-base
>>> begin
>>>  dup 6 " &lt;/CHRP" $= if
>>>   6 + dup 6 " -BOOT&gt;" $= if
>>>    8 + true
>>>   else
>>>    false
>>>   then
>>>  else
>>>   1+ false
>>>  then
>>> until
>>> ( xcoff-base )
>>> load-size over load-base - -
>>> ( xcoff-base xcoff-size )
>>> load-base swap move
>>> init-program go
>
>>> ELF - encode_bootpath: bootpath cd:0,<NULL>\ bootargs <NULL>
> $=:>> XCOFF - load_xcoff: Loading 'System\Library\CoreServices\BootX'
>>> XCOFF - load_xcoff: XCOFF file with 3 sections entry:05616ecc
>>> XCOFF - load_xcoff: Read next header (5c)
>>> XCOFF - load_xcoff: Load '.text' section from 5c d4 to 5600000 (28000)
>>> XCOFF - load_xcoff: Found entry point offset in '.text': 94112
>>> XCOFF - load_xcoff: Read next header (84)
>>> XCOFF - load_xcoff: Load '.data' section from 84 280d4 to 5628000 (2000)
>>> XCOFF - load_xcoff: Read next header (ac)
>>> XCOFF - load_xcoff: Erase '.bss' section at 562a000 size: 3a000
>>> XCOFF - load_xcoff: Found actual entry point: 05600adc
>>> ELF - transfer_control_to_elf: Starting ELF boot loader
> unselect-dev:interpret: exception -13 caught
> EXIT
> 0 > Killed
>
> Any ideas?
>

Also, my most recent changes are committed and pushed for public viewing:
http://github.com/tycho/openbios/commits/macosx-boot

Steven Noonan (3):
      ofmem: don't clobber the position that Mac OS X's kernel resides in
      kernel/internal.c: incorrectly uses %x format where %lx is needed
      qemu/main.c: load embedded XCOFF binaries in CHRP scripts

- Steven

[Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?

[Alexander Graf]

On 20.04.2009, at 05:50, Steven Noonan wrote:

> On Sun, Apr 19, 2009 at 8:27 PM, Steven Noonan  
> <steven@uplinklabs.net> wrote:
>> So I decided a better idea was to keep the OpenBIOS ROM where it is
>> and then instead use the location 0x06800000 for the memory
>> allocations so that the 0x4000 block doesn't get smashed. It was far
>> more feasible than moving where the ROM is stored, and I don't think
>> anything cares about the contents of 0x06800000 to 06FFFFFF anyway.
>>
>> Also, the reason I was getting "invalid opcode" was because Open
>> Hack'Ware's XCOFF loader didn't take into account some other unknown
>> variable which PearPC accounted for. I added the necessary code to
>> make that work.
>>
>> So now instead of an invalid opcode, we get this (which I don't know
>> how to debug. it looks like a Forth exception):
>>
>> Alcarin:qemu steven$ make -C ppc-softmmu &&
>> ppc-softmmu/qemu-system-ppc -L pc-bios -cdrom
>> ~/Development/MacOSX-10.4.iso -boot d -M mac99 -nographic
>> make: Nothing to be done for `all'.
>>
>>>> =============================================================
>>>> OpenBIOS 1.0 [Apr 20 2009 03:23]
>>>> Configuration device id QEMU version 1 machine id 1
>>>> CPUs: 1
>>>> Memory: 128M
>>>> UUID: 00000000-0000-0000-0000-000000000000
>>>> CPU type PowerPC,G4
>> Welcome to OpenBIOS v1.0 built on Apr 20 2009 03:23
>>
>>>> YABOOT - yaboot_startup: Entering boot, no path
>>>> CHRP - try_chrp_script: Trying cd:0,ppc\bootinfo.txt
>>>> MAC-PARTS: macparts_probe 4552 ?= 4552
>>>> MAC-PARTS: macparts_open 0
>>>> MAC-PARTS: macparts_get_info 0 2832209920
>>>> MAC-PARTS: macparts_block_size = 200
>>>> ELF - try_chrp_script: Can't open cd:0,ppc\bootinfo.txt
>>>> CHRP - try_chrp_script: Trying cd:0,System\Library\CoreServices 
>>>> \BootX
>>>> MAC-PARTS: macparts_probe 4552 ?= 4552
>>>> MAC-PARTS: macparts_open 0
>>>> MAC-PARTS: macparts_get_info 0 2832209920
>>>> MAC-PARTS: macparts_block_size = 200
>>>> CHRP - try_chrp_script: got bootscript
>>>> load-base
>>>> begin
>>>>  dup 6 " &lt;/CHRP" $= if
>>>>   6 + dup 6 " -BOOT&gt;" $= if
>>>>    8 + true
>>>>   else
>>>>    false
>>>>   then
>>>>  else
>>>>   1+ false
>>>>  then
>>>> until
>>>> ( xcoff-base )
>>>> load-size over load-base - -
>>>> ( xcoff-base xcoff-size )
>>>> load-base swap move
>>>> init-program go
>>
>>>> ELF - encode_bootpath: bootpath cd:0,<NULL>\ bootargs <NULL>
>> $=:>> XCOFF - load_xcoff: Loading 'System\Library\CoreServices\BootX'
>>>> XCOFF - load_xcoff: XCOFF file with 3 sections entry:05616ecc
>>>> XCOFF - load_xcoff: Read next header (5c)
>>>> XCOFF - load_xcoff: Load '.text' section from 5c d4 to 5600000  
>>>> (28000)
>>>> XCOFF - load_xcoff: Found entry point offset in '.text': 94112
>>>> XCOFF - load_xcoff: Read next header (84)
>>>> XCOFF - load_xcoff: Load '.data' section from 84 280d4 to 5628000  
>>>> (2000)
>>>> XCOFF - load_xcoff: Read next header (ac)
>>>> XCOFF - load_xcoff: Erase '.bss' section at 562a000 size: 3a000
>>>> XCOFF - load_xcoff: Found actual entry point: 05600adc
>>>> ELF - transfer_control_to_elf: Starting ELF boot loader
>> unselect-dev:interpret: exception -13 caught
>> EXIT
>> 0 > Killed
>>
>> Any ideas?
>>
>
> Also, my most recent changes are committed and pushed for public  
> viewing:
> http://github.com/tycho/openbios/commits/macosx-boot

Wow - I just returned from vacation and that's what I found in my  
inbox! What a nice surprise. This fits along really well with my  
efforts to get KVM running on POWER ;-).

So - have you made any progress since then?

Alex

[Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?

[Laurent Vivier]

Le dimanche 19 avril 2009 à 11:59 -0700, Steven Noonan a écrit :
> On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier <Laurent@lvivier.info> wrote:
> > Le dimanche 19 avril 2009 à 00:50 -0700, Steven Noonan a écrit :
> >> On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan <steven@uplinklabs.net> wrote:
> >> > On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier <Laurent@lvivier.info> wrote:
> >> >> OpenBIOS is not able to boot MacOS X.
> >> >
> >> > Well, that's a silly limitation. Is there a reason this isn't
> >> > implemented? I see that the Mac-on-Linux OpenBIOS version has such
> >> > support, so it seems strange that the QEMU version does not.
> >>
> >> I don't know if anyone here is actually interested (this list seems
> >> -very- quiet), but...
> >
> > Hi,
> >
> >> I've been hacking at OpenBIOS for a bit, and I got it to properly read
> >> Mac OS X discs (it kept failing because it would hit an Apple
> >> Partition Map header instead of an HFS+ filesystem header). I'm
> >> working on adding an XCOFF loader, too, so it should be able to boot
> >> Mac OS X soon.
> >
> > You can copy it from OpenHackWare.
> > I made some tests and it seems to have some memory conflicts between
> > MacOS kernel and OpenBIOS.

In fact what I have is a Mach-O loader which load mach_kernel from "/".

> > Good Luck.
> >
> 
> Two more pre-XCOFF loader commits up:
> http://github.com/tycho/openbios/commit/e43daa3447b5ce4a2b05b2f32882e49891156200
> http://github.com/tycho/openbios/commit/7023b78a10f5632fd08d4749615efd3e73ab1036

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 " &lt;/CHRP" $= if
  6 + dup 6 " -BOOT&gt;" $= 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

[Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?

[Steven Noonan]

On Sun, Apr 19, 2009 at 12:47 PM, Laurent Vivier <Laurent@lvivier.info> wrote:
> Le dimanche 19 avril 2009 à 11:59 -0700, Steven Noonan a écrit :
>> On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier <Laurent@lvivier.info> wrote:
>> > Le dimanche 19 avril 2009 à 00:50 -0700, Steven Noonan a écrit :
>> >> On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan <steven@uplinklabs.net> wrote:
>> >> > On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier <Laurent@lvivier.info> wrote:
>> >> >> OpenBIOS is not able to boot MacOS X.
>> >> >
>> >> > Well, that's a silly limitation. Is there a reason this isn't
>> >> > implemented? I see that the Mac-on-Linux OpenBIOS version has such
>> >> > support, so it seems strange that the QEMU version does not.
>> >>
>> >> I don't know if anyone here is actually interested (this list seems
>> >> -very- quiet), but...
>> >
>> > Hi,
>> >
>> >> I've been hacking at OpenBIOS for a bit, and I got it to properly read
>> >> Mac OS X discs (it kept failing because it would hit an Apple
>> >> Partition Map header instead of an HFS+ filesystem header). I'm
>> >> working on adding an XCOFF loader, too, so it should be able to boot
>> >> Mac OS X soon.
>> >
>> > You can copy it from OpenHackWare.
>> > I made some tests and it seems to have some memory conflicts between
>> > MacOS kernel and OpenBIOS.
>
> In fact what I have is a Mach-O loader which load mach_kernel from "/".
>
>> > Good Luck.
>> >
>>
>> Two more pre-XCOFF loader commits up:
>> http://github.com/tycho/openbios/commit/e43daa3447b5ce4a2b05b2f32882e49891156200
>> http://github.com/tycho/openbios/commit/7023b78a10f5632fd08d4749615efd3e73ab1036
>
> Seems good but do you really need to check for embedded XCOFF in this
> patch and are you really able to execute the boot-script ?

Yes, it does properly execute the boot-script.

And no, it doesn't actually _check_ for an XCOFF, despite the comment
I added. I suppose these lines could be removed from that patch:

+
+    /* check for an embedded XCOFF binary */
+
+    /* eat newline */
+    if (read_io(fd, tagbuf, 1) < 0)
+        goto badf;
+
+    /* eat '\x04', ASCII 'end-of-transmission' */
+    if (read_io(fd, tagbuf, 1) < 0)
+        goto badf;
+
+    /* next bytes should be XCOFF magic */
+
+    /* TODO: Add XCOFF loader here. */
+

But they don't have any side effects. They are essentially just prep
work for loading an embedded XCOFF which would begin after consuming
the two bytes after the CHRP-BOOT block.

>
> In Panther Install CD, BootX is:
>
> <CHRP-BOOT>
> <COMPATIBLE>
> MacRISC MacRISC3 MacRISC4
> </COMPATIBLE>
> <DESCRIPTION>
> Boot Loader for Mac OS X.
> </DESCRIPTION>
> <OS-BADGE-ICONS>
> </OS-BADGE-ICONS>
> <BOOT-SCRIPT>
> ...
> <BOOT-SCRIPT>
> load-base
> begin
>  dup 6 " &lt;/CHRP" $= if
>  6 + dup 6 " -BOOT&gt;" $= 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]
>
>

[Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?

[Steven Noonan]

On Sun, Apr 19, 2009 at 12:47 PM, Laurent Vivier <Laurent@lvivier.info> wrote:
> Le dimanche 19 avril 2009 à 11:59 -0700, Steven Noonan a écrit :
>> On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier <Laurent@lvivier.info> wrote:
>> > Le dimanche 19 avril 2009 à 00:50 -0700, Steven Noonan a écrit :
>> >> On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan <steven@uplinklabs.net> wrote:
>> >> > On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier <Laurent@lvivier.info> wrote:
>> >> >> OpenBIOS is not able to boot MacOS X.
>> >> >
>> >> > Well, that's a silly limitation. Is there a reason this isn't
>> >> > implemented? I see that the Mac-on-Linux OpenBIOS version has such
>> >> > support, so it seems strange that the QEMU version does not.
>> >>
>> >> I don't know if anyone here is actually interested (this list seems
>> >> -very- quiet), but...
>> >
>> > Hi,
>> >
>> >> I've been hacking at OpenBIOS for a bit, and I got it to properly read
>> >> Mac OS X discs (it kept failing because it would hit an Apple
>> >> Partition Map header instead of an HFS+ filesystem header). I'm
>> >> working on adding an XCOFF loader, too, so it should be able to boot
>> >> Mac OS X soon.
>> >
>> > You can copy it from OpenHackWare.
>> > I made some tests and it seems to have some memory conflicts between
>> > MacOS kernel and OpenBIOS.
>
> In fact what I have is a Mach-O loader which load mach_kernel from "/".
>
>> > Good Luck.
>> >
>>
>> Two more pre-XCOFF loader commits up:
>> http://github.com/tycho/openbios/commit/e43daa3447b5ce4a2b05b2f32882e49891156200
>> http://github.com/tycho/openbios/commit/7023b78a10f5632fd08d4749615efd3e73ab1036
>
> Seems good but do you really need to check for embedded XCOFF in this
> patch and are you really able to execute the boot-script ?

Oh, I should say that it does _execute_ the boot-script, but I don't
know if it's properly handled by the Forth interpreter. Any idea what
the boot-script you cite is supposed to actually _do_ (I gave up
trying to read Forth at around 3 AM last night)?

>
> In Panther Install CD, BootX is:
>
> <CHRP-BOOT>
> <COMPATIBLE>
> MacRISC MacRISC3 MacRISC4
> </COMPATIBLE>
> <DESCRIPTION>
> Boot Loader for Mac OS X.
> </DESCRIPTION>
> <OS-BADGE-ICONS>
> </OS-BADGE-ICONS>
> <BOOT-SCRIPT>
> ...
> <BOOT-SCRIPT>
> load-base
> begin
>  dup 6 " &lt;/CHRP" $= if
>  6 + dup 6 " -BOOT&gt;" $= 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

[Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?

[Laurent Vivier]

Le dimanche 19 avril 2009 à 13:01 -0700, Steven Noonan a écrit :
> On Sun, Apr 19, 2009 at 12:47 PM, Laurent Vivier <Laurent@lvivier.info> wrote:
> > Le dimanche 19 avril 2009 à 11:59 -0700, Steven Noonan a écrit :
> >> On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier <Laurent@lvivier.info> wrote:
> >> > Le dimanche 19 avril 2009 à 00:50 -0700, Steven Noonan a écrit :
> >> >> On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan <steven@uplinklabs.net> wrote:
> >> >> > On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier <Laurent@lvivier.info> wrote:
> >> >> >> OpenBIOS is not able to boot MacOS X.
> >> >> >
> >> >> > Well, that's a silly limitation. Is there a reason this isn't
> >> >> > implemented? I see that the Mac-on-Linux OpenBIOS version has such
> >> >> > support, so it seems strange that the QEMU version does not.
> >> >>
> >> >> I don't know if anyone here is actually interested (this list seems
> >> >> -very- quiet), but...
> >> >
> >> > Hi,
> >> >
> >> >> I've been hacking at OpenBIOS for a bit, and I got it to properly read
> >> >> Mac OS X discs (it kept failing because it would hit an Apple
> >> >> Partition Map header instead of an HFS+ filesystem header). I'm
> >> >> working on adding an XCOFF loader, too, so it should be able to boot
> >> >> Mac OS X soon.
> >> >
> >> > You can copy it from OpenHackWare.
> >> > I made some tests and it seems to have some memory conflicts between
> >> > MacOS kernel and OpenBIOS.
> >
> > In fact what I have is a Mach-O loader which load mach_kernel from "/".
> >
> >> > Good Luck.
> >> >
> >>
> >> Two more pre-XCOFF loader commits up:
> >> http://github.com/tycho/openbios/commit/e43daa3447b5ce4a2b05b2f32882e49891156200
> >> http://github.com/tycho/openbios/commit/7023b78a10f5632fd08d4749615efd3e73ab1036
> >
> > Seems good but do you really need to check for embedded XCOFF in this
> > patch and are you really able to execute the boot-script ?
> 
> Oh, I should say that it does _execute_ the boot-script, but I don't
> know if it's properly handled by the Forth interpreter. Any idea what
> the boot-script you cite is supposed to actually _do_ (I gave up
> trying to read Forth at around 3 AM last night)?

I think the script seeks in itself the address of the embedded XCOFF
(after "-BOOT"), computes it size, copies it to load-base, initializes
it ("init-program") and executes it ("go").

> >
> > In Panther Install CD, BootX is:
> >
> > <CHRP-BOOT>
> > <COMPATIBLE>
> > MacRISC MacRISC3 MacRISC4
> > </COMPATIBLE>
> > <DESCRIPTION>
> > Boot Loader for Mac OS X.
> > </DESCRIPTION>
> > <OS-BADGE-ICONS>
> > </OS-BADGE-ICONS>
> > <BOOT-SCRIPT>
> > ...
> > <BOOT-SCRIPT>
> > load-base
> > begin
> >  dup 6 " &lt;/CHRP" $= if
> >  6 + dup 6 " -BOOT&gt;" $= 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
> 

[Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?

[Steven Noonan]

On Sun, Apr 19, 2009 at 1:21 PM, Laurent Vivier <Laurent@vivier.eu> wrote:
> Le dimanche 19 avril 2009 à 13:01 -0700, Steven Noonan a écrit :
>> On Sun, Apr 19, 2009 at 12:47 PM, Laurent Vivier <Laurent@lvivier.info> wrote:
>> > Le dimanche 19 avril 2009 à 11:59 -0700, Steven Noonan a écrit :
>> >> On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier <Laurent@lvivier.info> wrote:
>> >> > Le dimanche 19 avril 2009 à 00:50 -0700, Steven Noonan a écrit :
>> >> >> On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan <steven@uplinklabs.net> wrote:
>> >> >> > On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier <Laurent@lvivier.info> wrote:
>> >> >> >> OpenBIOS is not able to boot MacOS X.
>> >> >> >
>> >> >> > Well, that's a silly limitation. Is there a reason this isn't
>> >> >> > implemented? I see that the Mac-on-Linux OpenBIOS version has such
>> >> >> > support, so it seems strange that the QEMU version does not.
>> >> >>
>> >> >> I don't know if anyone here is actually interested (this list seems
>> >> >> -very- quiet), but...
>> >> >
>> >> > Hi,
>> >> >
>> >> >> I've been hacking at OpenBIOS for a bit, and I got it to properly read
>> >> >> Mac OS X discs (it kept failing because it would hit an Apple
>> >> >> Partition Map header instead of an HFS+ filesystem header). I'm
>> >> >> working on adding an XCOFF loader, too, so it should be able to boot
>> >> >> Mac OS X soon.
>> >> >
>> >> > You can copy it from OpenHackWare.
>> >> > I made some tests and it seems to have some memory conflicts between
>> >> > MacOS kernel and OpenBIOS.
>> >
>> > In fact what I have is a Mach-O loader which load mach_kernel from "/".
>> >
>> >> > Good Luck.
>> >> >
>> >>
>> >> Two more pre-XCOFF loader commits up:
>> >> http://github.com/tycho/openbios/commit/e43daa3447b5ce4a2b05b2f32882e49891156200
>> >> http://github.com/tycho/openbios/commit/7023b78a10f5632fd08d4749615efd3e73ab1036
>> >
>> > Seems good but do you really need to check for embedded XCOFF in this
>> > patch and are you really able to execute the boot-script ?
>>
>> Oh, I should say that it does _execute_ the boot-script, but I don't
>> know if it's properly handled by the Forth interpreter. Any idea what
>> the boot-script you cite is supposed to actually _do_ (I gave up
>> trying to read Forth at around 3 AM last night)?
>
> I think the script seeks in itself the address of the embedded XCOFF
> (after "-BOOT"), computes it size, copies it to load-base, initializes
> it ("init-program") and executes it ("go").

Ah, duh, that should've been obvious to me. I'm a Forth flunkie, so if
someone could implement these:

  ( xcoff-base )
  load-size over load-base - -
  ( xcoff-base xcoff-size )
  load-base swap move
  init-program go

Then we'd be doing what we -really- should be doing instead of my
hackish "oh, there's an XCOFF here! let's load it."

>
>> >
>> > In Panther Install CD, BootX is:
>> >
>> > <CHRP-BOOT>
>> > <COMPATIBLE>
>> > MacRISC MacRISC3 MacRISC4
>> > </COMPATIBLE>
>> > <DESCRIPTION>
>> > Boot Loader for Mac OS X.
>> > </DESCRIPTION>
>> > <OS-BADGE-ICONS>
>> > </OS-BADGE-ICONS>
>> > <BOOT-SCRIPT>
>> > ...
>> > <BOOT-SCRIPT>
>> > load-base
>> > begin
>> >  dup 6 " &lt;/CHRP" $= if
>> >  6 + dup 6 " -BOOT&gt;" $= 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]
>> >
>> >

[Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting?

[Laurent Vivier]

Le dimanche 19 avril 2009 à 13:23 -0700, Steven Noonan a écrit :
> On Sun, Apr 19, 2009 at 1:21 PM, Laurent Vivier <Laurent@vivier.eu> wrote:
> > Le dimanche 19 avril 2009 à 13:01 -0700, Steven Noonan a écrit :
> >> On Sun, Apr 19, 2009 at 12:47 PM, Laurent Vivier <Laurent@lvivier.info> wrote:
> >> > Le dimanche 19 avril 2009 à 11:59 -0700, Steven Noonan a écrit :
> >> >> On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier <Laurent@lvivier.info> wrote:
> >> >> > Le dimanche 19 avril 2009 à 00:50 -0700, Steven Noonan a écrit :
> >> >> >> On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan <steven@uplinklabs.net> wrote:
> >> >> >> > On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier <Laurent@lvivier.info> wrote:
> >> >> >> >> OpenBIOS is not able to boot MacOS X.
> >> >> >> >
> >> >> >> > Well, that's a silly limitation. Is there a reason this isn't
> >> >> >> > implemented? I see that the Mac-on-Linux OpenBIOS version has such
> >> >> >> > support, so it seems strange that the QEMU version does not.
> >> >> >>
> >> >> >> I don't know if anyone here is actually interested (this list seems
> >> >> >> -very- quiet), but...
> >> >> >
> >> >> > Hi,
> >> >> >
> >> >> >> I've been hacking at OpenBIOS for a bit, and I got it to properly read
> >> >> >> Mac OS X discs (it kept failing because it would hit an Apple
> >> >> >> Partition Map header instead of an HFS+ filesystem header). I'm
> >> >> >> working on adding an XCOFF loader, too, so it should be able to boot
> >> >> >> Mac OS X soon.
> >> >> >
> >> >> > You can copy it from OpenHackWare.
> >> >> > I made some tests and it seems to have some memory conflicts between
> >> >> > MacOS kernel and OpenBIOS.
> >> >
> >> > In fact what I have is a Mach-O loader which load mach_kernel from "/".
> >> >
> >> >> > Good Luck.
> >> >> >
> >> >>
> >> >> Two more pre-XCOFF loader commits up:
> >> >> http://github.com/tycho/openbios/commit/e43daa3447b5ce4a2b05b2f32882e49891156200
> >> >> http://github.com/tycho/openbios/commit/7023b78a10f5632fd08d4749615efd3e73ab1036
> >> >
> >> > Seems good but do you really need to check for embedded XCOFF in this
> >> > patch and are you really able to execute the boot-script ?
> >>
> >> Oh, I should say that it does _execute_ the boot-script, but I don't
> >> know if it's properly handled by the Forth interpreter. Any idea what
> >> the boot-script you cite is supposed to actually _do_ (I gave up
> >> trying to read Forth at around 3 AM last night)?
> >
> > I think the script seeks in itself the address of the embedded XCOFF
> > (after "-BOOT"), computes it size, copies it to load-base, initializes
> > it ("init-program") and executes it ("go").
> 
> Ah, duh, that should've been obvious to me. I'm a Forth flunkie, so if
> someone could implement these:

You can write it in C... I have written a Mach-O loader (but it seems
broken now)

>   ( xcoff-base )
>   load-size over load-base - -
>   ( xcoff-base xcoff-size )
>   load-base swap move
>   init-program go
> 
> Then we'd be doing what we -really- should be doing instead of my
> hackish "oh, there's an XCOFF here! let's load it."

This explains why OpenHackware is written as it is.

> >
> >> >
> >> > In Panther Install CD, BootX is:
> >> >
> >> > <CHRP-BOOT>
> >> > <COMPATIBLE>
> >> > MacRISC MacRISC3 MacRISC4
> >> > </COMPATIBLE>
> >> > <DESCRIPTION>
> >> > Boot Loader for Mac OS X.
> >> > </DESCRIPTION>
> >> > <OS-BADGE-ICONS>
> >> > </OS-BADGE-ICONS>
> >> > <BOOT-SCRIPT>
> >> > ...
> >> > <BOOT-SCRIPT>
> >> > load-base
> >> > begin
> >> >  dup 6 " &lt;/CHRP" $= if
> >> >  6 + dup 6 " -BOOT&gt;" $= 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]
> >> >
> >> >
>