From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42545) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VFSt9-0005BM-JU for qemu-devel@nongnu.org; Fri, 30 Aug 2013 13:53:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VFSt4-0001Cr-Nx for qemu-devel@nongnu.org; Fri, 30 Aug 2013 13:53:39 -0400 Received: from cantor2.suse.de ([195.135.220.15]:52205 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VFSt4-0001Cg-EW for qemu-devel@nongnu.org; Fri, 30 Aug 2013 13:53:34 -0400 Message-ID: <5220DC1A.1070103@suse.de> Date: Fri, 30 Aug 2013 19:53:30 +0200 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 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> In-Reply-To: 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 , Antony Pavlov Am 30.08.2013 07:07, schrieb Peter Crosthwaite: > 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, Devic= e 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. Personally I tend to (a) in this case. As I understood it, this SoC/PoP only occurs in cameras, not as a reusable component, so the amount of RAM and variant of the SoC is uniquely identified by the machine and we wouldn't know how else to name the PoP container object. A reason for (b) might be if multiple cameras contain the same pre-produced PoP - not sure if that is the case, and we only have one board for now. You are of course right that if we don't think about this now, we risk having future contributors copy-and-pasting code without reconsidering; but the struct defining the per-board RAM size is already set up for sharing code among boards, so I think instantiating them at machine level will not be a problem for now. Regards, Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg