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: J. Mayer
Subject: Re: [Qemu-devel] qemu/pc-bios ppc_rom.bin
Date: Mon, 01 Oct 2007 21:53:20 +0200

On Mon, 2007-10-01 at 22:31 +0300, Blue Swirl wrote:
> 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.

If it would really bring extra features, why not. But what does booting
from ELF brings ? Debug symbols ? GDB is the right tool to use them and
does not need the boot to be from an ELF file. Symbols in qemu.log are
not so useful as, at least for me, it is an great help to debug qemu
itself, but not very useful to debug the running code, excluding maybe
for the starter code, for which you can easily follow the asm code.

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

Being thinking of this for Alpha for a long time (and even started...).
Hope someday I (or someone else) will have the motivation to really do
it ! But Alpha is quite easy as it's quite well documented... I admit it
may be quite impossible for Transmeta...

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

Most of the actual issues are in the chipset and it seems to me that the
less documented platforms are PC and Macs. A lot of other architectures
use quite well documented features and hardcoding some 'answers' can
often be sufficient to please the firmware. And even PowerPC Macs have a
great advantage: the firmware drivers are written in Forth, which is a
great help to understand what to do...
Then, yes, emulating PC chipsets is a real nightmare. But doing this for
a lot of other platforms, for which there is only a few or none open
source firmware or even OS running on, is really doable and is even a
requested feature by some hardware / software developpers.

-- 
J. Mayer <address@hidden>
Never organized





reply via email to

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