On 2 April 2012 06:20, Peter A. G. Crosthwaite
<peter.crosthwa...@petalogix.com> wrote:
> Added linux smp support for the xilinx zynq platform (2x cpus are supported)
>
> Signed-off-by: Peter A. G. Crosthwaite <peter.crosthwa...@petalogix.com>
> ---
> hw/xilinx_zynq.c | 64 ++++++++++++++++++++++++++++++++++++++++++++---------
> 1 files changed, 53 insertions(+), 11 deletions(-)
>
> diff --git a/hw/xilinx_zynq.c b/hw/xilinx_zynq.c
> index 7290c64..56d0b96 100644
> --- a/hw/xilinx_zynq.c
> +++ b/hw/xilinx_zynq.c
> @@ -30,6 +30,42 @@
>
> #define IRQ_OFFSET 32 /* pic interrupts start from index 32 */
>
> +#define SMP_BOOT_ADDR 0x0fff0000
> +
> +static void zynq_reset_secondary(CPUARMState *env,
> + const struct arm_boot_info *info)
> +{
> + env->regs[15] = SMP_BOOT_ADDR;
> +}
> +
> +/* Entry point for secondary CPU */
> +static uint32_t zynq_smpboot[] = {
> + 0xe59f0020, /* ldr r0, privbase */
> + 0xe3a004FF, /* mov r0 = 0xFFFFFFF0 */
> + 0xe38008FF, /* orr ...*/
> + 0xe3800CFF, /* orr .... */
> + 0xe38000F0, /* orr ..... */
These four insns are a rather longwinded way of saying
0xe3e0000f /* ldr r0, =0xfffffff0 (mvn r0, #15) */
aren't they?
> + 0xe320f002, /* wfe */
> + 0xe5901000, /* ldr r1, [r0] */
> + 0xe1110001, /* tst r1, r1 */
> + 0x0afffffb, /* beq <wfe> */
> + 0xe12fff11, /* bx r1 */
> + 0,
> + 0
> +};
Who is responsible for resetting the 0xFFFFFFF0
location so that on reset the secondary CPUs don't
immediately leave their pen? It looks from a quick glance
like this is in the on-chip RAM, is that right?
(If it is in RAM, then maybe you should be using the
default_reset_secondary() rather than your own version?)
-- PMM
