[Qemu-devel] reset strategy?

[Qemu-devel] reset strategy?

[Liviu Ionescu]

I migrated most of the qdev_* calls to object_* and device_* calls.

however, after I switched from qdev_create() to object_new(), I noticed that without the sysbus, there is no automated mechanism to reset the peripherals attached to the mcu.

my solution was to manually propagate the reset to all children devices (via device_reset()).

is this the planned reset strategy in a non-qdev environment? I read something about using interfaces for implementing buses, but I think that for propagating resets inside the cortex-m mcu's the additional complexity introduced by buses is not required.


regards,

Liviu

Re: [Qemu-devel] reset strategy?

[Peter Crosthwaite]

On Sat, Jun 27, 2015 at 1:19 AM, Liviu Ionescu <ilg@livius.net> wrote:
> I migrated most of the qdev_* calls to object_* and device_* calls.
>
> however, after I switched from qdev_create() to object_new(), I noticed that without the sysbus, there is no automated mechanism to reset the peripherals attached to the mcu.
>

Try this after object creation (see xlnx-zynqmp init fn):

    qdev_set_parent_bus(DEVICE(&s->gic), sysbus_get_default());

Note we are trying to phase out object_new in favor of embedding the
device structs in the SoC container, which would mean use of
object_initialise instead of object_new.

> my solution was to manually propagate the reset to all children devices (via device_reset()).
>
> is this the planned reset strategy in a non-qdev environment? I read something about using interfaces for implementing buses, but I think that for propagating resets inside the cortex-m mcu's the additional complexity introduced by buses is not required.
>

Ultimately that's a bug, the system wide reset should not depend on
qdev. I think I actually have a patch for it in Xilinx tree, let me
look around on Monday. But I would do the above change, as that also
solves other problems (mainly be able to use QOM links with the
objects pre-realize).

Regards,
Peter

>
> regards,
>
> Liviu
>
>

Re: [Qemu-devel] reset strategy?

[Liviu Ionescu]

> On 27 Jun 2015, at 21:03, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote:
> 
> Try this after object creation (see xlnx-zynqmp init fn):
> 
>    qdev_set_parent_bus(DEVICE(&s->gic), sysbus_get_default());

ah, sure, I already tried this, if I set the bus, everything works as before.


but probably my question was not clear enough.

my latest configuration uses no qdev_* calls at all, none of my objects are connected to sysbus, and apparently everything works without problems.

the reset strategy that I used was to register a reset callback for the MCU:

    CortexMState *cm_state = CORTEXM_MCU_STATE(dev);
    ....
    qemu_register_reset(cortexm_mcu_registered_reset_callback, cm_state);


static void cortexm_mcu_registered_reset_callback(void *opaque)
{
    DeviceState *dev = opaque;

    /* This will actually go to derived class reset. */
    device_reset(dev);
}


and in the object reset callback to explicitly reset all contained objects:

static void cortexm_mcu_reset_callback(DeviceState *dev)
{
    qemu_log_function_name();

    /* Call parent reset(). */
    cm_device_parent_reset(dev, TYPE_CORTEXM_MCU);

    CortexMState *cm_state = CORTEXM_MCU_STATE(dev);

#if defined(CONFIG_VERBOSE)
    if (verbosity_level >= VERBOSITY_COMMON) {
        printf("%s core reset.\n", cm_state->display_model);
    }
#endif

    /* 
     * Ensure the image is copied into memory before reset
     * fetches MSP & PC 
     */

    rom_reset(NULL);

    /* 
     * With the new image available, MSP & PC are correct
     * and execution will start. 
     */

    cpu_reset(CPU(cm_state->cpu));

    device_reset(cm_state->nvic);

    if (cm_state->itm) {
        device_reset(cm_state->itm);
    }
}

> Note we are trying to phase out object_new in favor of embedding the
> device structs in the SoC container, which would mean use of
> object_initialise instead of object_new.

any special reasons in favour of this?

in my configuration some of the contained objects are created conditionally, and it seemed more natural to dynamically allocate only the needed ones.

an extreme example is the STM32 objects, which should allocate space for all possible peripherals, for all STM32 families and sub-families, and object_initialise only the needed ones.

but I got your point, where possible I'll use statically allocated objects.

> Ultimately that's a bug, the system wide reset should not depend on
> qdev.

I did not check the code, but it seems it does not depend on qdev, if there are functions registered with qemu_register_reset(), they are called, regardless if connected to sysbus or not.


my conclusion is that, at least for my use case, we can get rid completely of qdev calls and sysbus, as long as each object explicitly resets all objects it creates, which is somehow expected.


regards,

Liviu

Re: [Qemu-devel] reset strategy?

[Peter Crosthwaite]

On Sat, Jun 27, 2015 at 12:52 PM, Liviu Ionescu <ilg@livius.net> wrote:
>
>> On 27 Jun 2015, at 21:03, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote:
>>
>> Try this after object creation (see xlnx-zynqmp init fn):
>>
>>    qdev_set_parent_bus(DEVICE(&s->gic), sysbus_get_default());
>
> ah, sure, I already tried this, if I set the bus, everything works as before.
>
>
> but probably my question was not clear enough.
>
> my latest configuration uses no qdev_* calls at all, none of my objects are connected to sysbus, and apparently everything works without problems.
>
> the reset strategy that I used was to register a reset callback for the MCU:
>
>     CortexMState *cm_state = CORTEXM_MCU_STATE(dev);
>     ....
>     qemu_register_reset(cortexm_mcu_registered_reset_callback, cm_state);
>
>
> static void cortexm_mcu_registered_reset_callback(void *opaque)
> {
>     DeviceState *dev = opaque;
>
>     /* This will actually go to derived class reset. */
>     device_reset(dev);
> }
>
>
> and in the object reset callback to explicitly reset all contained objects:
>
> static void cortexm_mcu_reset_callback(DeviceState *dev)
> {
>     qemu_log_function_name();
>
>     /* Call parent reset(). */
>     cm_device_parent_reset(dev, TYPE_CORTEXM_MCU);
>
>     CortexMState *cm_state = CORTEXM_MCU_STATE(dev);
>
> #if defined(CONFIG_VERBOSE)
>     if (verbosity_level >= VERBOSITY_COMMON) {
>         printf("%s core reset.\n", cm_state->display_model);
>     }
> #endif
>
>     /*
>      * Ensure the image is copied into memory before reset
>      * fetches MSP & PC
>      */
>
>     rom_reset(NULL);
>
>     /*
>      * With the new image available, MSP & PC are correct
>      * and execution will start.
>      */
>
>     cpu_reset(CPU(cm_state->cpu));

This should be managed by the bootloader.

>
>     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?

> }
>
>> Note we are trying to phase out object_new in favor of embedding the
>> device structs in the SoC container, which would mean use of
>> object_initialise instead of object_new.
>
> any special reasons in favour of this?
>

I'm not sure TBH, its well discussed on list though.

> in my configuration some of the contained objects are created conditionally, and it seemed more natural to dynamically allocate only the needed ones.
>
> an extreme example is the STM32 objects, which should allocate space for all possible peripherals, for all STM32 families and sub-families, and object_initialise only the needed ones.
>
> but I got your point, where possible I'll use statically allocated objects.
>
>> Ultimately that's a bug, the system wide reset should not depend on
>> qdev.
>
> I did not check the code, but it seems it does not depend on qdev, if there are functions registered with qemu_register_reset(), they are called, regardless if connected to sysbus or not.
>

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

Regards,
Peter

>
> my conclusion is that, at least for my use case, we can get rid completely of qdev calls and sysbus, as long as each object explicitly resets all objects it creates, which is somehow expected.
>
>
> regards,
>
> Liviu
>
>
>
>

Re: [Qemu-devel] reset strategy?

[Liviu Ionescu]

> On 29 Jun 2015, at 02:15, Peter Crosthwaite <peter.crosthwaite@xilinx.com> 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.

> 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.

I'm trying to move away from qdev. 

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?


regards,

Liviu

Re: [Qemu-devel] reset strategy?

[Peter Crosthwaite]

On Mon, Jun 29, 2015 at 12:26 AM, Liviu Ionescu <ilg@livius.net> wrote:
>
>> On 29 Jun 2015, at 02:15, Peter Crosthwaite <peter.crosthwaite@xilinx.com> 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
>
>

Re: [Qemu-devel] reset strategy?

[Liviu Ionescu]

> On 29 Jun 2015, at 20:37, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote:
> 
>>> Are are these two devices really not connected to any bus?
>> 
>> 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?

just fine (so far).

> 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.

since most of my code is practically started from scratch, I don't have any dependencies on busses and qdev, so I'll focus only on the QOM hierarchy and try to avoid qdev & co.


regards,

Liviu