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?