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

[Fabrice Bellard <fabrice@bellard.org>]

Blue Swirl wrote:
> On 10/1/07, Jocelyn Mayer <l_indien@magic.fr> wrote:
>> On Mon, 2007-10-01 at 17:55 +0300, Blue Swirl wrote:
>>> On 10/1/07, Andreas Färber <andreas.faerber@web.de> 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.