On 18 March 2013 09:56, Kuo-Jung Su <dant...@gmail.com> 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