From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:60487) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZalm-0003Jh-AA for qemu-devel@nongnu.org; Tue, 07 May 2013 01:48:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UZall-0007yc-3g for qemu-devel@nongnu.org; Tue, 07 May 2013 01:48:58 -0400 Message-ID: <518895BE.4060909@reactos.org> Date: Tue, 07 May 2013 07:48:46 +0200 From: =?UTF-8?B?SGVydsOpIFBvdXNzaW5lYXU=?= MIME-Version: 1.0 References: <1367525344-7755-1-git-send-email-hpoussin@reactos.org> <1367525344-7755-2-git-send-email-hpoussin@reactos.org> <30C12B1E-5007-4B74-9A14-8F21C2D1F369@suse.de> <518351BA.1060603@reactos.org> <5187C5CA.2060805@suse.de> <5188194D.7010101@reactos.org> <518831AE.1050303@suse.de> In-Reply-To: <518831AE.1050303@suse.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH 1/7] pci: add MPC105 PCI host bridge emulation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= Cc: "qemu-ppc@nongnu.org" , Alexander Graf , "qemu-devel@nongnu.org" Andreas F=C3=A4rber a =C3=A9crit : > Am 06.05.2013 22:57, schrieb Herv=C3=A9 Poussineau: >> Alexander Graf a =C3=A9crit : >>> On 05/03/2013 07:57 AM, Herv=C3=A9 Poussineau wrote: >>>> Alexander Graf a =C3=A9crit : >>>>> Am 02.05.2013 um 22:08 schrieb Herv=C3=A9 Poussineau : >>>>> >>>>>> Non-contiguous I/O is not implemented. >>>>>> >>>>>> There is also somewhere a bug in the memory controller, which mean= s >>>>>> that some real firmwares may not detect the correct amount of memo= ry. >>>>>> 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 ca= n >>>> 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? >=20 > No. Why? QEMU does not depend on the memory controller being > initialized, only the OS might expect some registers to be filled in. S= o > 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)=20 even at its very startup, in arch/ppc/qemu/start.S. PCI initialization=20 code comes much later. At boot, MPC105 datasheet says that memory controller is not configured,=20 ie you have to not use RAM in OpenBIOS before PCI initialization. For other PPC targets (mac99, g3beige) using OpenBIOS, RAM is accessible=20 at startup, so that's not a problem for OpenBIOS. So, no, QEMU does not depend of the memory controller being initialized,=20 but OpenBIOS depends of the RAM being accessible ways before PCI=20 initialization. I don't speak of the OS which might (or might not) expect some registers=20 to be filled in. x-auto-conf property correctly sets some registers, so that memory is=20 available at startup (like on mac99, g3beige emulations). Herv=C3=A9