From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34055) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VFJpe-0006LO-9V for qemu-devel@nongnu.org; Fri, 30 Aug 2013 04:13:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VFJpa-0004RD-7C for qemu-devel@nongnu.org; Fri, 30 Aug 2013 04:13:26 -0400 Received: from mail-lb0-x22b.google.com ([2a00:1450:4010:c04::22b]:44851) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VFJpZ-0004R7-QK for qemu-devel@nongnu.org; Fri, 30 Aug 2013 04:13:22 -0400 Received: by mail-lb0-f171.google.com with SMTP id u14so1583526lbd.2 for ; Fri, 30 Aug 2013 01:13:20 -0700 (PDT) Date: Fri, 30 Aug 2013 12:10:59 +0400 From: Antony Pavlov Message-Id: <20130830121059.1ad74ed39b869a701362e5c5@gmail.com> In-Reply-To: References: <1377768833-11400-1-git-send-email-antonynpavlov@gmail.com> <1377768833-11400-3-git-send-email-antonynpavlov@gmail.com> <521F3B6C.6040207@suse.de> <20130829233623.b05e3fe616e160dff7fa5a50@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC 2/5] hw/arm: add very initial support for Canon DIGIC SoC List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite Cc: Peter Maydell , Giovanni Condello , g3gg0 , Alex Dumitrache , QEMU Developers , Paul Brook , Paolo Bonzini , Andreas =?ISO-8859-1?Q?F=E4rber?= On Fri, 30 Aug 2013 15:07:49 +1000 Peter Crosthwaite wrote: > Hi, >=20 >=20 > On Fri, Aug 30, 2013 at 6:16 AM, Peter Maydell = wrote: > > > > On 29 August 2013 20:36, Antony Pavlov wrote: > > > On Thu, 29 Aug 2013 14:15:40 +0200 > > > Andreas F=E4rber wrote: > > >> DigicState should be a QOM type derived from TYPE_DEVICE. Since you'= re > > >> hardcoding the CPU type, please use object_initialize() to create it > > >> in-place - note we're about to extend that function but rebase will = be > > >> trivial. > > > > > > I have just examinied platforms with hardcoded cpu: pxa2xx, exynos421= 0. > > > They don't use object_initialize(). > > > > You'll find that QEMU is full of old code that hasn't been updated > > to the current "best practice". pxa2xx in particular is pretty elderly > > and probably a bad example to copy from. object_initialize() > > is pretty new, which is why you can't find many examples yet. > > > > >> Is the RAM on the board or on the SoC? It's in DigicState but > > >> initialized from the board init. If it's on the SoC, then > > >> _add_subregion and _register_ram_global should be in its realizefn. > > >> Otherwise please separate it from the SoC state. > > > > > > It's not a trivial question! > > > See "Digging Into 'DIGIC 4' Image Processor (2)" (http://techon.nikke= ibp.co.jp/english/NEWS_EN/20090218/165866/). > > > The authors removed the upper package with a chemical solution and ex= posed the chips. > > > The 'DIGIC 4' contains 3 chips in one package: > > > * processor itself; >=20 > For clarity, do you mean SoC here? >=20 > > > > > * 64-Mbit NOR flash memory, the "K8P6415UQB" (note that I have found= another flash K8P3215UQB on my Canon A1100: Manufacturer ID: 0xEC, Device = ID: 0x7E0301); > > > * 512-Mbit SDRAM, the "K4X51323PE" (just the same 64 M RAM as I see = with barebox). > > > > > > So we can assume taht these memory chips are inalienable parts of the= SoC. > > > > Package-on-Package is really just a funky way of connecting > > up separate components (the layers are only connected > > together at PCB assembly time, wikipedia tells me), and > > indeed you can have different component combinations > > (as you've found with the flash memory). So I would suggest > > that either: > > (a) just model them all as separate components > > (SoC, memory, flash) instantiated by the board > > (b) model them as separate components, and have a > > "container" component which puts them together and > > then the board just instantiates that. > > > > Whether (b) is worthwhile depends on whether we > > expect to have lots of boards that differ but have the > > same PoP stack. I suspect (a) is better. >=20 > I like (b). If something is sold, branded or soldered as a self > contained package then I think its worth having its own device. FWIW, > I want to do this with Zynq sooner or later as its a SoC that's > modelled as a board. The current RFCv1 patch series tends to (a). So I'll keep this till RFCv2 c= ode review :) --=A0 Best regards, =A0 Antony Pavlov