[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
[Qemu-devel] [PATCH v8 06/24] hw/arm: add FTPWMTMR010 timer support, Kuo-Jung Su, 2013/03/15
[Qemu-devel] [PATCH v8 04/24] hw/arm: add FTAHBC020 AHB controller support, Kuo-Jung Su, 2013/03/15
[Qemu-devel] [PATCH v8 08/24] hw/arm: add FTRTC011 RTC timer support, Kuo-Jung Su, 2013/03/15
[Qemu-devel] [PATCH v8 07/24] hw/arm: add FTWDT010 watchdog timer support, Kuo-Jung Su, 2013/03/15
- [Qemu-devel] [PATCH v8 00/24] hw/arm: add Faraday A369 SoC platform support, Kuo-Jung Su, 2013/03/15
- [Qemu-devel] [PATCH v8 01/24] target-arm: add Faraday ARMv5TE processors support, Kuo-Jung Su, 2013/03/15
- [Qemu-devel] [PATCH v8 02/24] hw/arm: add Faraday a369 SoC platform support, Kuo-Jung Su, 2013/03/15
- [Qemu-devel] [PATCH v8 04/24] hw/arm: add FTAHBC020 AHB controller support, Kuo-Jung Su, 2013/03/15
- [Qemu-devel] [PATCH v8 03/24] hw/arm: add FTINTC020 interrupt controller support, Kuo-Jung Su, 2013/03/15
- [Qemu-devel] [PATCH v8 06/24] hw/arm: add FTPWMTMR010 timer support, Kuo-Jung Su, 2013/03/15