Re: [Qemu-devel] [PATCH v3 04/20] arm: add Faraday FTDDRII030 support

[Kuo-Jung Su]

2013/2/18 Andreas Färber <address@hidden>:
> Am 18.02.2013 10:31, schrieb Kuo-Jung Su:
>> 2013/2/8 Igor Mitsyanko <address@hidden>:
>>> On 02/06/2013 01:45 PM, Kuo-Jung Su wrote:
>>>
>>> +static void ftddrii030_reset(DeviceState *ds)
>>> +{
>>> +    SysBusDevice *busdev = SYS_BUS_DEVICE(ds);
>>> +    Ftddrii030State *s = FTDDRII030(FROM_SYSBUS(Ftddrii030State, busdev));
>>> +    FaradayMachState *mach = s->mach;
>>> +
>>> +    if (!mach) {
>>> +        hw_error("ftddrii030: mach is not yet initialized!\n");
>>> +        exit(1);
>>> +    }
>>> +
>>> +    if (mach->ddr_inited) {
>>> +        if (mach->ahb_remapped) {
>>>
>>>
>>> This assumes that DDRII controller will be reseted before AHBC, otherwise
>>> we'll end up with
>>> ROM and RAM mapped at 0x0 address after reset. I do not know if we can count
>>> on a specific device reset ordering,
>>> maybe someone else can clarify this.
>>>
>>>
>>
>> The reset sequence is controlled by
>>
>> static void
>> a369_board_reset(void *opaque)
>> {
>>     A369State *s = opaque;
>>
>>     device_reset(s->scu);
>>     device_reset(s->ddrc);
>>     device_reset(s->ahbc);
>>     cpu_reset(CPU(s->cpu));
>> }
>>
>> which is registered with qemu_register_reset() during a369_device_init().
>
> This may still lead to this reset handler executing first and then the
> three devices in unpredictable order again. Whether that causes any
> issues remains for you to check.
>
> sPAPR uses a QEMUMachine-level hook to override reset order of devices
> and CPUs, but still among devices no guarantees are made.
>

Got it, thanks

> Andreas
>
>
> --
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



-- 
Best wishes,
Kuo-Jung Su