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

[Peter Maydell]

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

thanks
-- PMM