From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IcQRa-0002mW-2d for qemu-devel@nongnu.org; Mon, 01 Oct 2007 14:56:38 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IcQRV-0002jX-4p for qemu-devel@nongnu.org; Mon, 01 Oct 2007 14:56:37 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IcQRV-0002jS-1u for qemu-devel@nongnu.org; Mon, 01 Oct 2007 14:56:33 -0400 Received: from phoenix.bawue.net ([193.7.176.60] helo=mail.bawue.net) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IcQRU-0001wk-BI for qemu-devel@nongnu.org; Mon, 01 Oct 2007 14:56:32 -0400 Date: Mon, 1 Oct 2007 19:56:27 +0100 From: Thiemo Seufer Subject: Re: [Qemu-devel] qemu/pc-bios ppc_rom.bin Message-ID: <20071001185627.GI13317@networkno.de> References: <47009C20.7000809@qumranet.com> <1191222768.16080.0.camel@bxl-cdrw.bxl.cronos-technologies.com> <36FA7E24-859B-4033-BB37-2C8453D81677@web.de> <1191253624.3514.56.camel@jma4.dev.netgem.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: l_indien@magic.fr, qemu-devel@nongnu.org Blue Swirl wrote: > On 10/1/07, Jocelyn Mayer wrote: > > 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 anyo= ne > > > > > 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. ;-) > > > > > > You can use: > > > objcopy -O binary in.elf out.bin > > > > > > 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. FWIW, I don't regard the on-disk format of the BIOS as essential, as long as the emulated CPU sees the same bits as a real cpu does. Accepting ELF as a (possibly alternative) container for a BIOS image is a matter of convenience. > The effect is exactly the same from the emulated CPU perspective. With > ELF image we gain symbols in the out_asm dump. >=20 > > 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"). >=20 > Qemu is not limited to just hardware emulation. Please consider for > example snapshot load/save support, built-in gdbstub and monitor. No > real hardware has any of these, or perhaps you could do similar things > with ICE or JTAG. >=20 > Qemu is not also aimed for 100% accurate emulation of the hardware. > There are no caches or cycle counters and hardware devices run > unrealistically fast from CPU standpoint. Emulating performance > counters or the errata the most CPUs have would be extremely > difficult. I doubt Qemu CPU emulation can ever pass POST of real > BIOSes. I am working on making the Malta emulation boot a unaltered YAMON image. I don't see why a PC BIOS would be harder to accomodate. > Real BIOSes are also closed source, proprietary binary blobs. At least YAMON, CFE and PMON are not closed source. YAMON has a funny license which - I hope - will change. > Making open source BIOSes a viable alternative is in my opinion a much > more important goal. The one doesn't exclude the other. That said, I regard the ability to boot unaltered real-world firmare as an important test of the quality of a system emulation. Thiemo