Re: [Qemu-devel] reset strategy?

[Peter Crosthwaite]

On Mon, Jun 29, 2015 at 12:26 AM, Liviu Ionescu <address@hidden> wrote:
>
>> On 29 Jun 2015, at 02:15, Peter Crosthwaite <address@hidden> wrote:
>>
>>>    cpu_reset(CPU(cm_state->cpu));
>>
>> This should be managed by the bootloader.
>
> you mean via 'boot.c: arm_load_kernel()'?
>
> I'm not using it, since on Cortex-M there is no kernel to load.
>
>>>    device_reset(cm_state->nvic);
>>>
>>>    if (cm_state->itm) {
>>>        device_reset(cm_state->itm);
>>>    }
>>
>> Are are these two devices really not connected to any bus?
>
> in hardware they obviously are somehow connected to the core.
>
> in my emulation, these devices are created with object_new() and not 
> connected to the sysbus or to any other bus.
>

how do they work?

>> Yes, but you shouldn't have to register resets from machine level
>> code. It should just happen via:
>>
>> vl.c:4412:    qemu_register_reset(qbus_reset_all_fn, sysbus_get_default());
>
> if I got it right, this is a qdev call that resets all devices on the sysbus.
>

Yes

> I'm trying to move away from qdev.
>

We are still heavily using qdev buses (at least in the ARM world) and
transitioning away from that is out of scope of your project. Patches
welcome if you want to eliminate qbus from QEMU, but that is a huge
tree-wide project.

> the question stands: in a post-qdev world, for MCUs, which have the 
> peripherals integrated with the core (what you call SoC), is it mandatory to 
> use buses or is it ok for each device to reset its children?
>

The way to think of it, is there are two hierarchies. The QOM
hierarchy and the qbus/qdev hierarchy. The SoC and machine containers
create a QOM hierarchy which is the bit we want to be "post qdev".
There is still however the bus interconnections which need to form a
valid qdev hierarchy. This should happen naturally using the parenting
ops from the various examples around hw/arm.

Regards,
Peter

>
> regards,
>
> Liviu
>
>