Using multiple core on Zynq

Question

Until today I was programming on a single core, now I need to run my codes on multiple core. I'm researching for about 1 week and had some questions about this.

I'm using Zynq 702, Arm DS-5 and Dstream by the way. And I'm trying to achive this while I'm using my already present codes running on Core0.

---

I really did nothing on core1, just connected to it and just want to observe that it jumps to 0xFFFFFFF0 and to the value of this address. I didn't set any interrupt handler that targets core1. Is it OK with my only "observe" situation? Or I really need some configurations to be set? How can I achieve this by the easiest way?

---

I connect to core1 and observe its state while my program continues on core0. There is no application running on core1 by the way.. It goes up to address 0x300, at this address there is a WFE command and right after it there is a B(ranch) command which is branching to 0x300 again. This is like a loop and my code stays about 0.5Second on WFE command, jumps to next instruction B and branch to the WFE again......

I think core1 should stay right there after executing WFE command unless I send an EVENT, not to execute following B(ranch) command right? If so, does it mean core1 is getting evets periodicly from somewhere? Does connecting the board with Dstream Debugger causes EVENTs ?

---

If I set the value of address 0xFFFFFFF0, what makes the core1 to jump to the address at 0xFFFFFFF0, Is a simple SEV command enough while core1 is in the WFE/WFI state? If 0xFFFFFFF0 has a value of 0x00000000, then what happens? Does Core1 go back to the calling WFE/WFI again? Or something else?

Misprision

Answer 1

If core1 is in an WFE loop (state) the SEV cmd on core0 wakes up core1. If you enter WFE, you go into standby and the SEV is a wakeup, a request from the SCU can also do a wakeup (for a cache coherency operation in an MP system).

note: After APU reset, core1 is in an WFE state, executing code from 0xFFFFFE00 to 0xFFFFFFF0

After boot, core1 is in an WFE state. If core1 gets an SEV it jumps to the address stored at 0xFFFFFFF0. If you update the destination address after the SEV, then core1 returns to the WFE state. This is because 0xFFFFFFF0 has the address of the WFE instruction.

The correct "startup sequence" is:

1. Write the address of the core1 app to 0xFFFFFFF0
2. Execute the SEV instruction

(Have a look at page 158 (6.1.10) in the Zynq-7000 All Programmable SoC Technical Reference Manual)

If 0xFFFFFFF0 has a value of 0x00000000 you will get unpredictable results. (depending on your cpu state).

Merimerida

Answer 2

In my case (Cyclone V SoC) after cold reset CPU1 have "hold in reset" state. For starting CPU1 from CPU0 I add code to Reset_Handler:

;System Manager addr is 0xFFD08000
LDR r0, =0xFFD080C4 ;cpu1startaddr
MOV r1, #0x02000000 ;start addr from linker script
STR r1, [r0]
;Reset Manager add is 0xFFD05000
LDR r0, =0xFFD05010 ;MPU Module Reset Register
MOV r1, #0
STR r1, [r0] ; write 0 to power_on cpu1

Spontaneity