From: Thiemo Seufer <ths@networkno.de>
To: Blue Swirl <blauwirbel@gmail.com>
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:57:41 +0100 [thread overview]
Message-ID: <20071001215741.GA16772@networkno.de> (raw)
In-Reply-To: <f43fc5580710011231y6c2a6410od063eed44de22989@mail.gmail.com>
Blue Swirl wrote:
[snip]
> > > 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,
Writing the emulation for a transmeta is IMHO more challenging than
writing the "BIOS". Btw, if you are interested in the x86 mode, you can
handle the transmeta just as a x86 variant (with a much more standard BIOS).
> Alpha or a SoC.
Writing "Firmware for a SoC" is part of my dayjob.
> > > 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?
Improve the emulation to handle at least one probing path.
Thiemo
next prev parent reply other threads:[~2007-10-01 21:57 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
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 [this message]
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=20071001215741.GA16772@networkno.de \
--to=ths@networkno.de \
--cc=blauwirbel@gmail.com \
--cc=l_indien@magic.fr \
--cc=qemu-devel@nongnu.org \
/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).