From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IcNUD-0004VC-J1 for qemu-devel@nongnu.org; Mon, 01 Oct 2007 11:47:09 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IcNUC-0004TT-1m for qemu-devel@nongnu.org; Mon, 01 Oct 2007 11:47:09 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IcNUB-0004TE-Oh for qemu-devel@nongnu.org; Mon, 01 Oct 2007 11:47:07 -0400 Received: from honiara.magic.fr ([195.154.193.36]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IcNUB-0007sr-4u for qemu-devel@nongnu.org; Mon, 01 Oct 2007 11:47:07 -0400 Received: from [172.17.17.137] (gw.netgem.com [195.68.2.34]) by honiara.magic.fr (8.13.1/8.13.1) with ESMTP id l91Fl2hr017863 for ; Mon, 1 Oct 2007 17:47:03 +0200 Subject: Re: [Qemu-devel] qemu/pc-bios ppc_rom.bin From: Jocelyn Mayer In-Reply-To: References: <47009C20.7000809@qumranet.com> <1191222768.16080.0.camel@bxl-cdrw.bxl.cronos-technologies.com> <36FA7E24-859B-4033-BB37-2C8453D81677@web.de> Content-Type: text/plain; charset=ISO-8859-15 Date: Mon, 01 Oct 2007 17:47:04 +0200 Message-Id: <1191253624.3514.56.camel@jma4.dev.netgem.com> Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Reply-To: l_indien@magic.fr, qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Mon, 2007-10-01 at 17:55 +0300, Blue Swirl wrote: > On 10/1/07, Andreas F=E4rber wrote: > > > > Am 01.10.2007 um 09:12 schrieb Bob Deblier: > > > > > Ideally we should have an OpenBIOS compiled for QEMU/PPC. Is anyone > > > working on this? > > > > I had looked into this recently but it turned out that PearPC and > > others using OpenBIOS/ppc use an ELF format OpenBIOS binary that is > > incompatible with QEMU, expecting some raw image. I have no idea how > > to go about this; the (working) sparc version uses some "weird" > > assembler initializations. ;-) >=20 > You can use: > objcopy -O binary in.elf out.bin >=20 > Alternatively, Qemu could be enhanced to try loading ELF first and > binary if that fails. This is even not an option. With "normal" full system emulation, Qemu boots like real hardware does. I don't know any CPU able to load ELF images. As the goal is to emulate real hardware, what is to be given is a ROM image, able to boot a real machine. You can try to ehance the -kernel option to do weird hacks if you like but the CPU state at the start of a normal boot process should be as near as possible as a real CPU after a hard reset. Any other behavior is a bug to fix asap. Imho Qemu can be a very great development tool (and I already used it for this purpose), not just a geek toy, then hacks that do not reflect what real hardware does have to be avoided any time it's possible. Then, adding an ELF loader in the CPU initialisation code seems to be a nonsense. The goal to achieve, imho, is to be able to run real ROM images extracted from real machine, not to "extend" the CPU features with stuffs that has no reality (and are even not useful as long as no machine would never accept to boot on this "firmware").