From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lve9s-0001tu-LI for qemu-devel@nongnu.org; Sun, 19 Apr 2009 17:02:36 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lve9r-0001th-V2 for qemu-devel@nongnu.org; Sun, 19 Apr 2009 17:02:36 -0400 Received: from [199.232.76.173] (port=35671 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lve9r-0001te-RX for qemu-devel@nongnu.org; Sun, 19 Apr 2009 17:02:35 -0400 Received: from yw-out-1718.google.com ([74.125.46.155]:10107) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lve9r-0004SJ-5Z for qemu-devel@nongnu.org; Sun, 19 Apr 2009 17:02:35 -0400 Received: by yw-out-1718.google.com with SMTP id 9so985244ywk.82 for ; Sun, 19 Apr 2009 14:02:34 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1240174112.5659.40.camel@Quad> References: <1240129450.5671.7.camel@Quad> <1240171720.5659.11.camel@Quad> <1240172642.5659.25.camel@Quad> <1240174112.5659.40.camel@Quad> Date: Sun, 19 Apr 2009 14:02:33 -0700 Message-ID: From: Steven Noonan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Qemu-devel] Re: [OpenBIOS] QEMU OpenBIOS booting? Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: The OpenBIOS Mailinglist Cc: Alexander Graf , qemu-devel@nongnu.org On Sun, Apr 19, 2009 at 1:48 PM, Laurent Vivier wrote: > Le dimanche 19 avril 2009 =E0 13:33 -0700, Steven Noonan a =E9crit : >> On Sun, Apr 19, 2009 at 1:24 PM, Laurent Vivier wrot= e: >> > Le dimanche 19 avril 2009 =E0 13:14 -0700, Steven Noonan a =E9crit : >> >> On Sun, Apr 19, 2009 at 1:08 PM, Laurent Vivier wrote: >> >> > Le dimanche 19 avril 2009 =E0 13:00 -0700, Steven Noonan a =E9crit = : >> >> >> On Sun, Apr 19, 2009 at 12:23 PM, Blue Swirl wrote: >> >> >> > On 4/19/09, Steven Noonan wrote: >> >> >> >> On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier wrote: >> >> >> >> =A0> Le dimanche 19 avril 2009 =E0 00:50 -0700, Steven Noonan a= =E9crit : >> >> >> >> =A0>> On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan wrote: >> >> >> >> =A0>> > On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier wrote: >> >> >> >> =A0>> >> OpenBIOS is not able to boot MacOS X. >> >> >> >> =A0>> > >> >> >> [...] >> >> >> $=3D:>> XCOFF - load_xcoff: Loading 'System\Library\CoreServices\B= ootX' >> >> >> >> 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 56280= 00 (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 =A0 Ending Address =A0 =A0Purpose >> >> 0x00000000 =A0 =A00x00003FFF =A0 =A0Exception vectors. >> >> 0x00004000 =A0 =A00x03FFFFFF =A0 =A0Kernel image, boot structures, an= d drivers. >> > >> > I put there some memory allocation information. >> > >> >> 0x04000000 =A0 =A00x04FFFFFF =A0 =A0File load area. >> >> 0x05000000 =A0 =A00x053FFFFF =A0 =A0Simple read-time cache for file s= ystem >> >> metadata. Cache hits are serviced from memory, whereas cache misses >> >> result in disk access. >> >> 0x05400000 =A0 =A00x055FFFFF =A0 =A0Malloc zone: a simple memory allo= cator 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.g= z > > (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?