From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lvdhr-0001ks-EO for qemu-devel@nongnu.org; Sun, 19 Apr 2009 16:33:39 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lvdhq-0001kb-K5 for qemu-devel@nongnu.org; Sun, 19 Apr 2009 16:33:38 -0400 Received: from [199.232.76.173] (port=43086 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lvdhq-0001kY-Gq for qemu-devel@nongnu.org; Sun, 19 Apr 2009 16:33:38 -0400 Received: from yw-out-1718.google.com ([74.125.46.155]:5390) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lvdhq-0000kE-3G for qemu-devel@nongnu.org; Sun, 19 Apr 2009 16:33:38 -0400 Received: by yw-out-1718.google.com with SMTP id 9so981258ywk.82 for ; Sun, 19 Apr 2009 13:33:37 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1240172642.5659.25.camel@Quad> References: <1240129450.5671.7.camel@Quad> <1240171720.5659.11.camel@Quad> <1240172642.5659.25.camel@Quad> Date: Sun, 19 Apr 2009 13:33:36 -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:24 PM, Laurent Vivier wrote: > Le dimanche 19 avril 2009 =E0 13:14 -0700, Steven Noonan a =E9crit : >> On Sun, Apr 19, 2009 at 1:08 PM, Laurent Vivier w= rote: >> > Le dimanche 19 avril 2009 =E0 13:00 -0700, Steven Noonan a =E9crit : >> >> On Sun, Apr 19, 2009 at 12:23 PM, Blue Swirl w= rote: >> >> > 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\Boot= X' >> >> >> 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 (28= 000) >> >> >> 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 =A0 Ending Address =A0 =A0Purpose >> 0x00000000 =A0 =A00x00003FFF =A0 =A0Exception vectors. >> 0x00004000 =A0 =A00x03FFFFFF =A0 =A0Kernel image, boot structures, and d= rivers. > > I put there some memory allocation information. > >> 0x04000000 =A0 =A00x04FFFFFF =A0 =A0File load area. >> 0x05000000 =A0 =A00x053FFFFF =A0 =A0Simple read-time cache for file syst= em >> metadata. Cache hits are serviced from memory, whereas cache misses >> result in disk access. >> 0x05400000 =A0 =A00x055FFFFF =A0 =A0Malloc zone: a simple memory allocat= or 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 =A0 =A00x057FFFFF =A0 =A0BootX image. > > This should be "load-base" > >> 0x05800000 =A0 =A00x05FFFFFF =A0 =A0Unused (occupied by the Open Firmwar= e 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?