Re: [Qemu-devel] [RFC 2/5] hw/arm: add very initial support for Canon DIGIC SoC

[Peter Crosthwaite]

Hi,


On Fri, Aug 30, 2013 at 6:16 AM, Peter Maydell <address@hidden> wrote:
>
> On 29 August 2013 20:36, Antony Pavlov <address@hidden> wrote:
> > On Thu, 29 Aug 2013 14:15:40 +0200
> > Andreas Färber <address@hidden> 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, exynos4210.
> > 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.nikkeibp.co.jp/english/NEWS_EN/20090218/165866/).
> > The authors removed the upper package with a chemical solution and exposed 
> > the chips.
> > The 'DIGIC 4' contains 3 chips in one package:
> >  * processor itself;

For clarity, do you mean SoC here?

>
> >  * 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.

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.

Regards,
Peter

>
> thanks
> -- PMM
>