From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LvdBR-0005bD-V6 for qemu-devel@nongnu.org; Sun, 19 Apr 2009 16:00:10 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LvdBM-0005aK-F0 for qemu-devel@nongnu.org; Sun, 19 Apr 2009 16:00:08 -0400 Received: from [199.232.76.173] (port=33618 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LvdBM-0005aF-9j for qemu-devel@nongnu.org; Sun, 19 Apr 2009 16:00:04 -0400 Received: from mx20.gnu.org ([199.232.41.8]:50370) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LvdBL-0003Re-QE for qemu-devel@nongnu.org; Sun, 19 Apr 2009 16:00:04 -0400 Received: from mail-gx0-f176.google.com ([209.85.217.176]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LvdBK-0002m3-LH for qemu-devel@nongnu.org; Sun, 19 Apr 2009 16:00:02 -0400 Received: by gxk24 with SMTP id 24so3472836gxk.10 for ; Sun, 19 Apr 2009 13:00:00 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <1239525550.5516.3.camel@Quad> <1240129450.5671.7.camel@Quad> Date: Sun, 19 Apr 2009 13:00:00 -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 , Laurent Vivier , qemu-devel@nongnu.org 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 w= rote: >> =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>> > >> =A0>> > Well, that's a silly limitation. Is there a reason this isn't >> =A0>> > implemented? I see that the Mac-on-Linux OpenBIOS version has su= ch >> =A0>> > support, so it seems strange that the QEMU version does not. >> =A0>> >> =A0>> I don't know if anyone here is actually interested (this list seem= s >> =A0>> -very- quiet), but... >> =A0> >> =A0> Hi, >> =A0> >> =A0>> I've been hacking at OpenBIOS for a bit, and I got it to properly = read >> =A0>> Mac OS X discs (it kept failing because it would hit an Apple >> =A0>> Partition Map header instead of an HFS+ filesystem header). I'm >> =A0>> working on adding an XCOFF loader, too, so it should be able to bo= ot >> =A0>> Mac OS X soon. >> =A0> >> =A0> You can copy it from OpenHackWare. >> =A0> I made some tests and it seems to have some memory conflicts betwee= n >> =A0> MacOS kernel and OpenBIOS. >> =A0> >> =A0> Good Luck. >> =A0> >> >> >> Two more pre-XCOFF loader commits up: >> =A0http://github.com/tycho/openbios/commit/e43daa3447b5ce4a2b05b2f32882e= 49891156200 >> =A0http://github.com/tycho/openbios/commit/7023b78a10f5632fd08d4749615ef= d3e73ab1036 > > These look fine to me. > >> =A0And I have something (uncommitted) that at least -loads- the >> =A0CHRP-embedded XCOFF binaries now, but I am not sure what to do to >> =A0execute the result. With ELF, it seems you can just use the call_elf(= ) >> =A0function. I don't know PowerPC assembler (nor the XCOFF format) well >> =A0enough yet to know what would be necessary for a call_xcoff() >> =A0function. Anyone want to help out with this? > > Well, call_elf should work regardless of the format. The first and > second parameters will be passed verbatim to OS (Linux uses those for > initrd address and size), the third is the start address that should > be available for all formats. There's some more description near the > function call_elf in start.S. > > So I'd just add something like call_elf(0, 0, xcoff_start) somewhere. Ah, that did what it should've. I guess 'call_elf' is a misnomer? I'm not committing the XCOFF loader quite yet. I suspect it would be best to do refactor it to use a similar API to what the ELF loader has, and place it so that it could be shared with the other OpenBIOS targets (pearpc, mol, etc)... Would it be preferred to make the XCOFF loader QEMU-specific or should it be a common API like the ELF loader? So here's what I get when I try Mac OS X 10.4 (I've enabled a ton of debug output): Alcarin:qemu steven$ ppc-softmmu/qemu-system-ppc -L pc-bios -cdrom ~/Development/MacOSX-10.4.iso -boot d -M mac99 -nographic >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> OpenBIOS 1.0 [Apr 19 2009 19:39] >> Configuration device id QEMU version 1 machine id 1 >> CPUs: 1 >> Memory: 128M >> UUID: 00000000-0000-0000-0000-000000000000 >> CPU type PowerPC,G4 Welcome to OpenBIOS v1.0 built on Apr 19 2009 19:39 >> YABOOT - yaboot_startup: Entering boot, no path >> CHRP - try_chrp_script: Trying cd:0,ppc\bootinfo.txt >> MAC-PARTS: macparts_probe 4552 ?=3D 4552 >> MAC-PARTS: macparts_open 0 >> MAC-PARTS: macparts_get_info 0 2832209920 >> MAC-PARTS: macparts_block_size =3D 200 >> volume_read_wrapper: got sig 482b >> volume_read_wrapper: got sig 482b >> ELF - try_chrp_script: Can't open cd:0,ppc\bootinfo.txt >> CHRP - try_chrp_script: Trying cd:0,System\Library\CoreServices\BootX >> MAC-PARTS: macparts_probe 4552 ?=3D 4552 >> MAC-PARTS: macparts_open 0 >> MAC-PARTS: macparts_get_info 0 2832209920 >> MAC-PARTS: macparts_block_size =3D 200 >> volume_read_wrapper: got sig 482b >> volume_read_wrapper: got sig 482b >> CHRP - try_chrp_script: got bootscript >> load-base >> begin >> dup 6 " </CHRP" $=3D if >> 6 + dup 6 " -BOOT>" $=3D if >> 8 + true >> else >> false >> then >> else >> 1+ false >> then >> until >> ( xcoff-base ) >> load-size over load-base - - >> ( xcoff-base xcoff-size ) >> load-base swap move >> init-program go >> ELF - encode_bootpath: bootpath cd:0,\ bootargs $=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 (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. - Steven