qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Kuo-Jung Su
Subject: Re: [Qemu-devel] [PATCH v8 05/24] hw/arm: add FTDDRII030 DDRII controller support
Date: Tue, 19 Mar 2013 13:15:07 +0800

2013/3/18 Peter Maydell <address@hidden>:
> 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.
>

Got it, thanks.
It sounds like a good idea to me, I'll try to model the ftddrii030 in that way.

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

Got it, thanks

> -- PMM



--
Best wishes,
Kuo-Jung Su



reply via email to

[Prev in Thread] Current Thread [Next in Thread]