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?
next prev parent 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).