On Sat, Jun 27, 2015 at 12:52 PM, Liviu Ionescu <i...@livius.net> wrote:
>
>> On 27 Jun 2015, at 21:03, Peter Crosthwaite <peter.crosthwa...@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
>
>
>
>
