qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Blue Swirl" <blauwirbel@gmail.com>
To: Thiemo Seufer <ths@networkno.de>
Cc: l_indien@magic.fr, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] qemu/pc-bios ppc_rom.bin
Date: Mon, 1 Oct 2007 22:31:06 +0300	[thread overview]
Message-ID: <f43fc5580710011231y6c2a6410od063eed44de22989@mail.gmail.com> (raw)
In-Reply-To: <20071001185627.GI13317@networkno.de>

On 10/1/07, Thiemo Seufer <ths@networkno.de> wrote:
> 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.
>
> 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?

  reply	other threads:[~2007-10-01 19:31 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-01  6:44 [Qemu-devel] qemu/pc-bios ppc_rom.bin Jocelyn Mayer
2007-10-01  7:05 ` Avi Kivity
2007-10-01  7:12   ` Bob Deblier
2007-10-01 11:40     ` Aurelien Jarno
2007-10-01 12:11       ` Bob Deblier
2007-10-01 13:24     ` Andreas Färber
2007-10-01 14:55       ` Blue Swirl
2007-10-01 15:47         ` Jocelyn Mayer
2007-10-01 16:36           ` Blue Swirl
2007-10-01 17:24             ` Jocelyn Mayer
2007-10-01 18:56             ` Thiemo Seufer
2007-10-01 19:31               ` Blue Swirl [this message]
2007-10-01 19:53                 ` J. Mayer
2007-10-01 20:36                 ` Aurelien Jarno
2007-10-01 21:20                   ` Laurent Desnogues
2007-10-01 21:57                 ` Thiemo Seufer
2007-10-05 19:23                   ` Natalia Portillo
2007-10-06  8:28                     ` Blue Swirl
2007-10-01 20:23             ` Fabrice Bellard
2007-10-01 18:17   ` J. Mayer
  -- strict thread matches above, loose matches on Subject: below --
2005-04-06 23:06 Fabrice Bellard
2005-03-13 16:51 Fabrice Bellard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f43fc5580710011231y6c2a6410od063eed44de22989@mail.gmail.com \
    --to=blauwirbel@gmail.com \
    --cc=l_indien@magic.fr \
    --cc=qemu-devel@nongnu.org \
    --cc=ths@networkno.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).