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

[Jocelyn Mayer]

On Mon, 2007-10-01 at 19:36 +0300, 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.

gdbstub and monitor like features are available with (usually)
proprietary debug tools on most hardwares I know. Most of the
development environment have many more features than Qemu currently
implements. It would be really great if Qemu would be able to become a
tool that could replace all those proprietary tools, but we are really
very far from this point.
I've never seen snapshot and load/store features on real hardware but it
seems to be doable with available debug tools. I did things quite like
that with JTAG scripts sometimes (CPU, RAM and a few simple devices
initialisation, cause I would have been to lazy to do more !).
But I also have to admit those are features I never use in Qemu...

> 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 never said that it's a full accurate emulation. I just said 'the
closest as possible to the real machine'. Which means from the execution
context point of view it has to have the same behavior, not that we
emulate every internal hardware states. Having other behaviors that are
not present on the real hardware can be fun but it gives nothing in
terms of emulation.

>  I doubt Qemu CPU emulation can ever pass POST of real
> BIOSes.

This is an admission of failure...

>From my point of view, it's a requirement that Qemu would be able:
1/ to be used to develop new firmwares and systems
2/ to be as accurate as needed so a firmware developped under Qemu would
run without modification on real hardware (means, takes the binary
image, flash it and power on, it runs...)
3/ would be able to run proprietary firmware, especially when trying to
emulate some targets with non-documented "blackboxes" that cannot be
easily reimplemented in OSS firmwares due to a lack of documentation, or
to "discover" hardware on which it's not easy to find any available OSS
distribution.

As an example, my goal, while implementing PowerPC 4xx targets, is to
take raw binary proprietary flash images from misc vendors and (try to)
run them without modification. For now, I'm able to run one of those.
Each other one I would be able to run would proove the emulation is
getting more accurate and is going to become really usable for any
usage.
It's even almost the only way I have to do it because there are
currently not a single complete OSS environment which I can get from the
net and boot at once for validation.
But Qemu may also be a great chance to make people that cannot afford
having real development board go and develop for embedded targets (I
hope so !).

>  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 fully agree with that point of view. Then, validating open sources
firmwares means that you have to run the exact same image on your
emulated machine than the one you want to run on the real hardware. Or
you won't validate anything. Then, build your flash image and run, the
same way you would do if you do it on the real hardware...

Maybe we should add some JTAG (or anything like) emulation, to make this
easier ;-)

[...]