All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Hervé Poussineau" <hpoussin@reactos.org>
To: "Andreas Färber" <afaerber@suse.de>
Cc: "qemu-ppc@nongnu.org" <qemu-ppc@nongnu.org>,
	Alexander Graf <agraf@suse.de>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH 1/7] pci: add MPC105 PCI host bridge emulation
Date: Tue, 07 May 2013 07:48:46 +0200	[thread overview]
Message-ID: <518895BE.4060909@reactos.org> (raw)
In-Reply-To: <518831AE.1050303@suse.de>

Andreas Färber a écrit :
> Am 06.05.2013 22:57, schrieb Hervé Poussineau:
>> Alexander Graf a écrit :
>>> On 05/03/2013 07:57 AM, Hervé Poussineau wrote:
>>>> Alexander Graf a écrit :
>>>>> Am 02.05.2013 um 22:08 schrieb Hervé Poussineau <hpoussin@reactos.org>:
>>>>>
>>>>>> Non-contiguous I/O is not implemented.
>>>>>>
>>>>>> There is also somewhere a bug in the memory controller, which means
>>>>>> that some real firmwares may not detect the correct amount of memory.
>>>>>> This can be bypassed by adding '-m 1G' on the command line.
>>>>>>
>>>>>> Add x-auto-conf property, to automatically configure the memory
>>>>>> controller at startup. This will be required by OpenBIOS, which
>>>>>> doesn't know how to do it.
>>>>> Why not teach it? I'd prefer to see that logic in firmware.
>>>> Me too, but I'm not confident enough in my capabilities to do it.
>>> Huh? Why not? Most of the device initialization code in OpenBIOS
>>> happens in C, so you don't even have to touch Forth code :).
>>>
>>>> Autoconfiguration is only in one place of the code, so I think it can
>>>> be removed easily once OpenBIOS has this logic.
>>> I'd prefer if we could come up with a clean model from the start. It
>>> really shouldn't be hard at all.
>>>
>> I thought that for all other usages of OpenBIOS in QEMU, RAM was
>> supposed to be available as soon as machine was powered on.
>>
>> However, I checked OpenBIOS code:
>> One of the first things done in arch/ppc/qemu/start.S is to copy the
>> exception vectors. So, I should add code before it to detect memory
>> controller, detect ram size and configure memory controller?
> 
> No. Why? QEMU does not depend on the memory controller being
> initialized, only the OS might expect some registers to be filled in. So
> you should look at or add the MPC105 PHB initialization hook in
> OpenBIOS' PCI code, long after the memory is set up.

OpenBIOS depends of memory being available (at least the first KB/MB) 
even at its very startup, in arch/ppc/qemu/start.S. PCI initialization 
code comes much later.
At boot, MPC105 datasheet says that memory controller is not configured, 
ie you have to not use RAM in OpenBIOS before PCI initialization.

For other PPC targets (mac99, g3beige) using OpenBIOS, RAM is accessible 
at startup, so that's not a problem for OpenBIOS.

So, no, QEMU does not depend of the memory controller being initialized, 
but OpenBIOS depends of the RAM being accessible ways before PCI 
initialization.
I don't speak of the OS which might (or might not) expect some registers 
to be filled in.
x-auto-conf property correctly sets some registers, so that memory is 
available at startup (like on mac99, g3beige emulations).

Hervé

  reply	other threads:[~2013-05-07  5:48 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-02 20:08 [Qemu-devel] [PATCH 0/7] ppc/prep: add IBM RS/6000 43p machine Hervé Poussineau
2013-05-02 20:08 ` [Qemu-devel] [PATCH 1/7] pci: add MPC105 PCI host bridge emulation Hervé Poussineau
2013-05-02 21:01   ` [Qemu-devel] [Qemu-ppc] " Alexander Graf
2013-05-03  5:57     ` Hervé Poussineau
2013-05-06 15:01       ` Alexander Graf
2013-05-06 20:57         ` Hervé Poussineau
2013-05-06 22:16           ` Alexander Graf
2013-05-06 22:41           ` Andreas Färber
2013-05-07  5:48             ` Hervé Poussineau [this message]
2013-05-09 17:47               ` Blue Swirl
2013-05-02 20:08 ` [Qemu-devel] [PATCH 2/7] qom: handle registration of new types when initializing the first ones Hervé Poussineau
2013-05-03 11:46   ` Andreas Färber
2013-05-05  8:38     ` Hervé Poussineau
2013-05-02 20:09 ` [Qemu-devel] [PATCH 3/7] m48t59: move ISA ports/memory regions registration to QOM constructor Hervé Poussineau
2013-05-02 20:09 ` [Qemu-devel] [PATCH 4/7] m48t59: register a QOM type for each nvram type we support Hervé Poussineau
2013-05-02 21:29   ` Artyom Tarasenko
2013-05-03  5:50     ` Hervé Poussineau
2013-05-03 23:16       ` Artyom Tarasenko
2013-05-04  5:24         ` Hervé Poussineau
2013-05-02 20:09 ` [Qemu-devel] [PATCH 5/7] m48t59: add a Nvram interface Hervé Poussineau
2013-05-02 20:09 ` [Qemu-devel] [PATCH 6/7] prep: add IBM RS/6000 7248 (43p) machine emulation Hervé Poussineau
2013-05-02 20:09 ` [Qemu-devel] [PATCH 7/7] prep: QOM'ify System I/O Hervé Poussineau
2013-05-03 11:36   ` Andreas Färber
2013-05-04  9:38     ` Hervé Poussineau

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=518895BE.4060909@reactos.org \
    --to=hpoussin@reactos.org \
    --cc=afaerber@suse.de \
    --cc=agraf@suse.de \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.