From: Blue Swirl <blauwirbel@gmail.com>
To: "Hervé Poussineau" <hpoussin@reactos.org>
Cc: "The OpenBIOS Mailinglist" <openbios@openbios.org>,
"qemu-ppc@nongnu.org" <qemu-ppc@nongnu.org>,
"Andreas Färber" <afaerber@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: Thu, 9 May 2013 17:47:10 +0000 [thread overview]
Message-ID: <CAAu8pHtJSAP2nDqnnii2hEVA75EHLMfeqUdMzsk6FcsJD8wLmg@mail.gmail.com> (raw)
In-Reply-To: <518895BE.4060909@reactos.org>
On Tue, May 7, 2013 at 5:48 AM, Hervé Poussineau <hpoussin@reactos.org> wrote:
> 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.
OpenBIOS for Sparc32 and Sparc64 does not use RAM before RAM size has
been read from fw_cfg. A check for QEMU signature is done and machine
ID is also read before that.
arch/sparc32/entry.S
arch/sparc64/entry.S
It should be easy to change PPC to check the machine ID before accessing RAM.
> At boot, MPC105 datasheet says that memory controller is not configured, ie
> you have to not use RAM in OpenBIOS before PCI initialization.
The memory controller should be initialized much earlier than PCI.
>
> 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é
>
next prev parent reply other threads:[~2013-05-09 17:47 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
2013-05-09 17:47 ` Blue Swirl [this message]
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=CAAu8pHtJSAP2nDqnnii2hEVA75EHLMfeqUdMzsk6FcsJD8wLmg@mail.gmail.com \
--to=blauwirbel@gmail.com \
--cc=afaerber@suse.de \
--cc=hpoussin@reactos.org \
--cc=openbios@openbios.org \
--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 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).