[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 <address@hidden> wrote:
> > Le dimanche 19 avril 2009 à 13:14 -0700, Steven Noonan a écrit :
> >> On Sun, Apr 19, 2009 at 1:08 PM, Laurent Vivier <address@hidden> wrote:
> >> > Le dimanche 19 avril 2009 à 13:00 -0700, Steven Noonan a écrit :
> >> >> On Sun, Apr 19, 2009 at 12:23 PM, Blue Swirl <address@hidden> wrote:
> >> >> > On 4/19/09, Steven Noonan <address@hidden> wrote:
> >> >> >> On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier <address@hidden> 
> >> >> >> wrote:
> >> >> >>  > Le dimanche 19 avril 2009 à 00:50 -0700, Steven Noonan a écrit :
> >> >> >>  >> On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan <address@hidden> 
> >> >> >> wrote:
> >> >> >>  >> > On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier 
> >> >> >> <address@hidden> 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