From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IcRpu-0001Pb-E2 for qemu-devel@nongnu.org; Mon, 01 Oct 2007 16:25:50 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IcRps-0001O7-Of for qemu-devel@nongnu.org; Mon, 01 Oct 2007 16:25:49 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IcRps-0001Nv-IZ for qemu-devel@nongnu.org; Mon, 01 Oct 2007 16:25:48 -0400 Received: from sp604002mt.neufgp.fr ([84.96.92.61] helo=sMtp.neuf.fr) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IcRps-0000QP-8Z for qemu-devel@nongnu.org; Mon, 01 Oct 2007 16:25:48 -0400 Received: from [84.102.211.220] by sp604002mt.gpm.neuf.ld (Sun Java System Messaging Server 6.2-5.05 (built Feb 16 2006)) with ESMTP id <0JP900A8W1ZUAD61@sp604002mt.gpm.neuf.ld> for qemu-devel@nongnu.org; Mon, 01 Oct 2007 22:23:55 +0200 (CEST) Date: Mon, 01 Oct 2007 22:23:31 +0200 From: Fabrice Bellard Subject: Re: [Qemu-devel] qemu/pc-bios ppc_rom.bin In-reply-to: Message-id: <47015743.1060005@bellard.org> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: QUOTED-PRINTABLE 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> Reply-To: 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 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=C3=A4rber wrote: >>>> Am 01.10.2007 um 09:12 schrieb Bob Deblier: >>>> >>>>> Ideally we should have an OpenBIOS compiled for QEMU/PPC. Is an= yone >>>>> working on this? >>>> I had looked into this recently but it turned out that PearPC an= d >>>> 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 an= d >>> binary if that fails. >> This is even not an option. With "normal" full system emulation, Q= emu >> boots like real hardware does. I don't know any CPU able to load E= LF >> images. As the goal is to emulate real hardware, what is to be giv= en is >> a ROM image, able to boot a real machine. >=20 > The effect is exactly the same from the emulated CPU perspective. W= ith > 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 behav= ior 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 ref= lect >> 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 featur= es >> with stuffs that has no reality (and are even not useful as long a= s 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. N= o > real hardware has any of these, or perhaps you could do similar thi= ngs > 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. Real BIOSes are also closed source, proprietary binary blob= s. > Making open source BIOSes a viable alternative is in my opinion a m= uch > more important goal. I know at least one real PC BIOS which "almost" work in QEMU. "almost= "=20 because a few fixes are needed in the PIIX3 bridge and I never found = the=20 time to publish them. Another point was the timing accuracy which mad= e=20 the BIOS hang sometimes, but it can also be solved. > [...] Fabrice.