Re: [Qemu-devel] [PATCH v8 05/24] hw/arm: add FTDDRII030 DDRII controller support

[Peter Maydell]

On 18 March 2013 09:56, Kuo-Jung Su <address@hidden> wrote:
> The FTDDRII030 is responsible for SDRAM initialization.
> Which means the DDRII SDRAM would not be stabilized until the
> SDRAM is correctly initialized.
> =>
> In QEMU, the memory_region_add_subregion() is used to perform this emulation.

If you want to model "sdram doesn't work unless it's inited"
(which is optional, often for qemu it's fine to just have
the RAM always work), then the right way to do this is
probably to have this device provide a memory region which
is a container and which the SoC always maps. Then this device
just maps the RAM into the container when the guest does the
DDR init. Having the device mess with its parent's address
space is a red flag that you're not modelling things right.

> The FTAHBC030 is responsible for AHB device management (base + window size)
> and also the special case for AHB remap of slave4 and slave6.
> =>
> In QEMU,
> 1. If SDRAM is initialized before activating AHB remap:
>     memory_region_del_subregion() must be called prior to
> memory_region_add_subregion().
>     And this is the reason why I need '.ddr_inited' and
> '.ahb_remapped' in SoC struct.
> 2. If SDRAM is not yet initialized while activating AHB remap:
>     Only memory_region_add_subregion() needs to be invoked.

If you're handling add/del subregion then you need to model
this so that the device that does the add/del is working on
a memory region container that it controls. Then it can have
a private data structure field which tracks what the state
of the mapped subregions is. This almost always turns out to
be the same way the hardware design is structured.

At the moment you have add/del going on in this device but
fields relating to what state the subregions are in are
at the top level soc state.

-- PMM