On 2 September 2014 00:22, Peter Crosthwaite <peter.crosthwa...@xilinx.com> wrote: > On Tue, Sep 2, 2014 at 9:12 AM, Peter Maydell <peter.mayd...@linaro.org> > wrote: >> Actually, I'm confused now where the reset ordering issue comes >> in, because (ignoring realize, which will call reset) as far as I >> could make out the only place that the ARM CPU reset gets >> called is when the do_cpu_reset() hook in boot.c calls >> cpu_reset(CPU(cpu)) explicitly. This is unfortunate because >> it means if you didn't use -kernel then we won't reset the CPU > > Yeh, my setup fixes this via assertion of an actual CPU reset GPIO > that connects to cpu_reset(). so I guess for me this problem is solved > ... > >> if you do a system reset after first bootup...but on the other >> hand it means there's no reset order issue? >> > > ... but then the solution introduces the reset order issue for me.
Aha. (I haven't figured out how we ought to have the cpu reset get called on system reset yet -- I was vaguely under the impression that all QOM/qdev devices got their reset hook called, but obviously not.) > The other solution worth discussing now is whether we simply want to > acknowledge that devs can have reset order deps and that's ok. > Implementing on the qdev level: > > void qdev_register_reset_dep(DeviceState *dependant, Device *dependee); I guess the question is what devices have a reset dependency other than this odd bootloader special case? (I should try to dig our previous discussions out of the list archives tomorrow.) > You then QOMify the bootloader and get rid of these explicit > bootloader cpu_reset calls. It would certainly be nice not to have the somewhat funky bootloader handling of reset... -- PMM
