On 2 January 2014 07:31, Peter Crosthwaite <peter.crosthwa...@xilinx.com> wrote:
> The SLCR needs to be able to reset the CPUs, so link the CPUs to the
> SLCR.
> @@ -496,10 +500,17 @@ static const MemoryRegionOps slcr_ops = {
> static int zynq_slcr_init(SysBusDevice *dev)
> {
> ZynqSLCRState *s = ZYNQ_SLCR(dev);
> + int i;
>
> memory_region_init_io(&s->iomem, OBJECT(s), &slcr_ops, s, "slcr",
> 0x1000);
> sysbus_init_mmio(dev, &s->iomem);
>
> + for (i = 0; i < NUM_CPUS; ++i) {
> + gchar *name = g_strdup_printf("cpu%d", i);
> + object_property_add_link(OBJECT(dev), name, TYPE_CPU,
> + (Object **)&s->cpus[i], NULL);
> + g_free(name);
> + }
This is where we get into the nasty questions of how
we ought to be modelling reset. I don't think that
reset controllers ought to work by having direct links
to a pile of QOM device objects. I'd much rather we tried
to work towards modelling this the way the hardware does,
ie a QOM device has one or more inbound GPIO lines
corresponding to the hardware's reset signals, and the
SoC or board wires those up to the reset controller
appropriately.
thanks
-- PMM
