qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "J. Mayer" <l_indien@magic.fr>
To: qemu-devel@nongnu.org
Cc: daimon55@free.fr
Subject: Re: [Qemu-devel] Re: Re: Open Hack'Ware test image.
Date: Wed, 23 Feb 2005 03:54:31 +0100	[thread overview]
Message-ID: <1109127271.13299.313.camel@rapid> (raw)
In-Reply-To: <1109114060.6488.27.camel@localhost.localdomain>

On Wed, 2005-02-23 at 00:14, Thayne Harbaugh wrote:
> On Tue, 2005-02-22 at 22:53 +0100, Ronald wrote:
> > Le Tue, 22 Feb 2005 14:02:35 -0700, Thayne Harbaugh a écrit :
> > 
> > > You shouldn't even worry about making
> > > PReP unstable by adding support for the PCI host bridge to either qemu or
> > > OHW because PReP isn't stable now - it doesn't even boot without the host
> > > bridge.
> > 
> > Sorry but prep works fine for me, that's even the only ppc emulation mode
> > I can use.
> 
> You've applied the "Raven" host bridge patch and it breaks your PReP?
> 
> Until someone can tell me that having a correct PCI host bridge actually
> breaks something I'll continue to ask that the patch be applied.  I
> believe fixes some problems and that even in the working situations it
> makes things more correct.  Real PReP hardware has a PCI host bridge -
> whether it's the Motorola Raven, Eagle, Grackle or whatever.
> 
> If someone can show that having a correct PCI host bridge breaks
> something then I'll either rework the patch or drop it.  I know that I
> have created some broken patches before (HFS comes to mind) and I don't
> have a problem rethinking.

You're absolutely right, having no PCI host bridge is not correct but
should not prevent OSes to run then is not a problem for Linux.

There is absolutely no reason that your patch may break anything. It may
also help some other OSes to run.

The only problem here is that qemu & OpenHackWare have to stay
synchronised on this point. As the OHW used in qemu CVS is 0.3 and as it
does not recognize Raven bridge, then qemu has to stay with its current
configuration or the PCI bus won't get initialized by the BIOS, and this
may break the target (even if it's not sure).
When OHW 0.4 will be stable and will be committed in qemu CVS, then qemu
will have to apply the patch so PREP will still not be broken, for the
same reason.
In the meantime, people who want to test PREP target with OHW 0.4
preview need to apply the Raven patch to qemu.

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

  reply	other threads:[~2005-02-23  3:30 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-22 11:45 [Qemu-devel] Open Hack'Ware test image J. Mayer
2005-02-22 15:07 ` [Qemu-devel] " Ronald
2005-02-22 18:20 ` Thayne Harbaugh
2005-02-22 18:58   ` Fabrice Bellard
2005-02-22 21:02     ` Thayne Harbaugh
2005-02-22 21:53       ` [Qemu-devel] " Ronald
2005-02-22 23:14         ` Thayne Harbaugh
2005-02-23  2:54           ` J. Mayer [this message]
2005-02-22 22:01       ` [Qemu-devel] " J. Mayer

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=1109127271.13299.313.camel@rapid \
    --to=l_indien@magic.fr \
    --cc=daimon55@free.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).