qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "J. Mayer" <l_indien@magic.fr>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] powerpc system emulation and the need for ppc-rom.bin (firmware)
Date: Fri, 11 Jun 2004 00:27:22 +0200	[thread overview]
Message-ID: <1086906442.19565.17183.camel@rapid> (raw)
In-Reply-To: <40C8CCCE.8030705@olifantasia.com>

On Thu, 2004-06-10 at 23:04, Martin wrote:
> Jocelyn mentioned some time ago that powerpc (system)emulation could be 
> broken at the moment because there are some majore changes in progress.

Me ? It's being a long time I didn't post here... I think Fabrice said
this...

> At the moment it does build just fine only it is not usable because it 
> thinks it needs a powerpc rom bios (firmware)

I didn't notice that Fabrice didn't commit the BIOS image. I'll ask him
to do it, if he still have a version which can boot the PREP target with
the current CVS code.
My work version can't (I'm focusing on Mac emulation).

> This loading is done in hw/ppc_prep.c (and hw/ppc_chrp.c)
> up and until revision 1.10 of ppc_prep.c the loading was done in the 
> else part of if(linux_boot)
> In other words, if you load a linux kernel directly you don't need 
> ppc_rom.bin
> 
> from version 1.11 and on qemu always tries to load ppc_rom.bin (and 
> always fails because it is not there: "could not load PPC PREP bios 
> '/usr/local/share/qemu/ppc_rom.bin'")
> 
> Is there a special reason for this?

I think the linux_boot case has been broken for a long time for the PPC
target. The next working versions will always need a BIOS, like i386
target does, to probe and initialize some hardware, then load and start
a boot image from disk or memory. The memory image is just another boot
device, seen from BIOS side.

> Otherwise I would suggest moving it back in the else clause so we can 
> still use recent cvs snapshots (with new features and bugfixes like pci 
> support)
> It would of course also be great if a (working) ppc_rom firmware would 
> be available.
> How is the progress on this going?
> Jocelyn, what are you using at the moment, an existing firmware for a 
> real device or an opensource openfirmware implementation?

I'm currently hacking a BIOS I wrote last year in order to boot Linux.
At this time, it was completely host-sided. I ported it to be PPC
native. I'm currently working on PCI integration and dynamic OF tree
updates.
It's not a real Open-Firmware as it knows nothing about Forth but can
"emulate" the standard OF and RTAS interfaces. It can also handle some
known requests from MacOS and friends (calls to "interpret" method): the
needed results are hardcoded in C.
It also can be used as a conventional firmware, with no OF support
(which is optional for PREP).

> I also found that there is a new commandline option -prep
> I think this chooses between prep and chrp emulation.
> How different are the two emulations at the moment?

Some Mac devices have been included (I think) in the repository by
Fabrice (cuda, ADB, PCI for PREP). I also added Open-Pic and I'm
currently trying to get a configuration near mac99 machines,
implementing BIOS support at the same time.
Chrp is just Mac, for now... RS6000, and others could come later if some
ones really want it :-)

I hope I'll be able to send patches and a new functional BIOS with PCI
support to Fabrice in a few days so the real work (ie debugging...) will
start.

-- 
J. Mayer <l_indien@magic.fr>
Never organized

      reply	other threads:[~2004-06-10 22:28 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-10 21:04 [Qemu-devel] powerpc system emulation and the need for ppc-rom.bin (firmware) Martin
2004-06-10 22:27 ` J. Mayer [this message]

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=1086906442.19565.17183.camel@rapid \
    --to=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).