Re: [Qemu-devel] [RFC v1 2/2] arm: boot: Add EL jump-down code for Linux

[Peter Crosthwaite <peter.crosthwaite@xilinx.com>]

On Tue, Sep 2, 2014 at 9:12 AM, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 2 September 2014 00:06, Peter Crosthwaite
> <peter.crosthwaite@xilinx.com> wrote:
>> On Tue, Sep 2, 2014 at 8:56 AM, Peter Maydell <peter.maydell@linaro.org> wrote:
>>> Surely there's already a reset order dependency, because
>>> both the arm-boot reset hook and CPU reset proper want
>>> to initialise the PC ?
>
>> Yes. I had a PC specific solution to this though when it became a
>> problem. I have another series that made the reset ordering a little
>> less predictable (specifically implementation of CPU reset GPIOs)
>
> 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.

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);

You then QOMify the bootloader and get rid of these explicit
bootloader cpu_reset calls.

Regards,
Peter

> Thinking about reset gives me a headache, though.
>
> thanks
> -- PMM
>