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

[Blue Swirl]

On 10/1/07, Thiemo Seufer <address@hidden> wrote:
> 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.
>
> 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.
> >
> > > 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.
>
> 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.

Emulating microcode, or firmware blobs loaded to misc devices. Think
writing a BIOS for Transmeta, Alpha or a SoC.

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

Maybe. The CPU probes for cacheline size, checks for errata #42 vs
#45, reads debug registers, attempts to identify the bus speed by
comparing I/O access times, tries to verify the system using a TPM and
fails all cases. What can you do?