qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] qemu/pc-bios ppc_rom.bin


From: Fabrice Bellard
Subject: Re: [Qemu-devel] qemu/pc-bios ppc_rom.bin
Date: Mon, 01 Oct 2007 22:23:31 +0200
User-agent: Thunderbird 1.5.0.9 (X11/20070212)

Blue Swirl wrote:
On 10/1/07, Jocelyn Mayer <address@hidden> wrote:
On Mon, 2007-10-01 at 17:55 +0300, Blue Swirl wrote:
On 10/1/07, Andreas Färber <address@hidden> 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. ;-)
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.

The effect is exactly the same from the emulated CPU perspective. With
ELF image we gain symbols in the out_asm dump.

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").

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.

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 blobs.
Making open source BIOSes a viable alternative is in my opinion a much
more important goal.

I know at least one real PC BIOS which "almost" work in QEMU. "almost" because a few fixes are needed in the PIIX3 bridge and I never found the time to publish them. Another point was the timing accuracy which made the BIOS hang sometimes, but it can also be solved.

[...]

Fabrice.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]