From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LvdYe-0007GG-DG for qemu-devel@nongnu.org; Sun, 19 Apr 2009 16:24:08 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LvdYa-0007Ec-Na for qemu-devel@nongnu.org; Sun, 19 Apr 2009 16:24:08 -0400 Received: from [199.232.76.173] (port=55937 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LvdYa-0007EZ-J4 for qemu-devel@nongnu.org; Sun, 19 Apr 2009 16:24:04 -0400 Received: from moutng.kundenserver.de ([212.227.126.177]:64628) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LvdYa-0007tQ-1I for qemu-devel@nongnu.org; Sun, 19 Apr 2009 16:24:04 -0400 From: Laurent Vivier In-Reply-To: References: <1239525550.5516.3.camel@Quad> <1240129450.5671.7.camel@Quad> <1240171720.5659.11.camel@Quad> Content-Type: text/plain; charset=utf-8 Date: Sun, 19 Apr 2009 22:24:02 +0200 Message-Id: <1240172642.5659.25.camel@Quad> Mime-Version: 1.0 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 Le dimanche 19 avril 2009 =C3=A0 13:14 -0700, Steven Noonan a =C3=A9crit : > On Sun, Apr 19, 2009 at 1:08 PM, Laurent Vivier wr= ote: > > Le dimanche 19 avril 2009 =C3=A0 13:00 -0700, Steven Noonan a =C3=A9cri= t : > >> On Sun, Apr 19, 2009 at 12:23 PM, Blue Swirl wr= ote: > >> > On 4/19/09, Steven Noonan wrote: > >> >> On Sun, Apr 19, 2009 at 1:24 AM, Laurent Vivier wrote: > >> >> > Le dimanche 19 avril 2009 =C3=A0 00:50 -0700, Steven Noonan a = =C3=A9crit : > >> >> >> On Tue, Apr 14, 2009 at 10:46 PM, Steven Noonan wrote: > >> >> >> > On Sun, Apr 12, 2009 at 1:39 AM, Laurent Vivier wrote: > >> >> >> >> OpenBIOS is not able to boot MacOS X. > >> >> >> > > >> [...] > >> $=3D:>> 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 (280= 00) > >> >> 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. > > >=20 > 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. > the wrong location. From the book "Mac OS X Internals: A Systems > Approach": >=20 > Table 45. BootX Logical Memory Map >=20 > 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...) > 0x05600000 0x057FFFFF BootX image. This should be "load-base" > 0x05800000 0x05FFFFFF Unused (occupied by the Open Firmware image). >=20 >=20 > 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). Regards, Laurent