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

[Steven Noonan <steven@uplinklabs.net>]

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?