[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [PATCH 1/7] pci: add MPC105 PCI host bridge emulation

From: Blue Swirl
Subject: Re: [Qemu-ppc] [PATCH 1/7] pci: add MPC105 PCI host bridge emulation
Date: Thu, 9 May 2013 17:47:10 +0000

On Tue, May 7, 2013 at 5:48 AM, Hervé Poussineau <address@hidden> 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
>>>>>> <address@hidden>:
>>>>>>> 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.

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é

reply via email to

[Prev in Thread] Current Thread [Next in Thread]