On 4 October 2012 01:16, Peter Crosthwaite
<peter.crosthwa...@petalogix.com> wrote:
> @@ -400,6 +404,20 @@ static void zynq_slcr_write(void *opaque,
> target_phys_addr_t offset,
> goto bad_reg;
> }
> s->reset[(offset - 0x200) / 4] = val;
> + if (offset - 0x200 == A9_CPU * 4) { /* CPU Reset */
> + for (i = 0; i < NUM_CPUS && s->cpus[i]; ++i) {
> + bool is_rst = val & (1 << (A9_CPU_RST_CTRL_RST_SHIFT +
> i));
> + bool is_clkstop = val &
> + (1 << (A9_CPU_RST_CTRL_CLKSTOP_SHIFT +
> i));
> + if (is_rst) {
> +
> CPU_GET_CLASS(CPU(s->cpus[i]))->reset(CPU(s->cpus[i]));
> + DB_PRINT("resetting cpu %d\n", i);
> + }
> + s->cpus[i]->env.halted = is_rst || is_clkstop;
> + DB_PRINT("%shalting cpu %d\n", s->cpus[i]->env.halted ?
> + "" : "un", i);
> + }
> + }
We don't support per-CPU reset right now, and I don't think this is the
right approach. This external device shouldn't be reaching into the
implementation of the CPU object like this.
My suggestion would be to expose an inbound GPIO line on the CPU object
(corresponding to the hardware's per-CPU reset lines) and then have an
appropriate implementation inside the CPU. (In general QEMU doesn't really
handle reset very cleanly IMHO.)
Not sure how much sense it makes to model the 'stop the CPU clock' stuff
within QEMU -- probably depends whether there are any programmer-visible
consequences.
-- PMM
