2013/2/18 Andreas Färber <afaer...@suse.de>: > 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. >
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