Am 18.02.2013 10:31, schrieb Kuo-Jung Su:
> 2013/2/8 Igor Mitsyanko <i.mitsya...@gmail.com>:
>> 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.
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
