![[RTEMS Logo]](/images/logo.png){kind=logo}
Opened on 11/20/19 at 21:41:30
Last modified on 04/20/20 at 18:23:00
#3824 new defect
SMP for Ultrascale +
| Reported by: | Massimiliano Patriarca | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | Indefinite |
| Component: | arch/arm | Version: | 5 |
| Severity: | normal | Keywords: | |
| Cc: | Blocked By: | ||
| Blocking: |
Description
Hi, i have successfully kicked the second APU on ultrascale+ ZCU102, but both processors are looping inside the function Per_CPU_State_wait for_non_initial_state().
I think something is missing in the configuration/initialization.
has the SMP code been tested in A53 running Aarch32 state (i.e. the Zynq U+ from xilinx) ?
Attachments (1)
Change History (11)
comment:1 Changed on 11/22/19 at 15:02:37 by Sebastian Huber
comment:2 Changed on 11/22/19 at 21:39:24 by Massimiliano Patriarca
I must include some other infos.
The system is initialized through the debugger (JTAG mode) , APU0 load the fsbl@aarch32, load the programmable logic and then is breaked @ fsbl_loop().
Then the debugger stores the following instruction into OCM: (AR# 46911)
0xFFFFFF00: mvn r0, #15
0xFFFFFF04: mov r1
0xFFFFFF08: str r1, [r0]
0xFFFFFF0C: wfe
0xFFFFFF10: ldr r2, [r0]
0xFFFFFF14: cmp r2, r1
0xFFFFFF18: beq 0xc
0xFFFFFF1C: mov pc
then the debugger loads the smp examples to ram, and start both the processor.
APU0 start the second processor and wait inside the function Per_CPU_State_wait for_non_initial_state().
APU1 start executing the _start normally and the stalls into the function Per_CPU_State_wait for_non_initial_state().
i can upload the lauterbach trace if necessary
-M
comment:3 Changed on 11/23/19 at 09:18:52 by Massimiliano Patriarca
By the way it is not clear how the two APUs signals its ready to run...
comment:4 Changed on 11/25/19 at 06:35:22 by Sebastian Huber
The higher level SMP start assumes that the mutable data is cache-coherent. For the CPU states see:
https://git.rtems.org/rtems/tree/cpukit/include/rtems/score/percpu.h#n96
comment:5 Changed on 12/12/19 at 19:23:46 by Massimiliano Patriarca
What variable/register is shared and in what source file
cache snooping is enabled. any other idea?
comment:6 Changed on 12/13/19 at 06:01:52 by Sebastian Huber
Sorry, I am currently busy with other things and I soon go on holidays.
comment:7 Changed on 12/13/19 at 06:02:57 by Sebastian Huber
| Component: | admin → arch/arm |
|---|---|
| Milestone: | → Indefinite |
| Type: | enhancement → defect |
| Version: | → 5 |
Changed on 12/15/19 at 17:36:52 by Massimiliano Patriarca
| Attachment: | Capture.PNG added |
|---|
comment:8 Changed on 12/15/19 at 17:40:17 by Massimiliano Patriarca
It appears that bsp_start_clear_bss() execution of APU1 clears the _Per_CPU_Information of both processors. disabling - but only for testing purpose - _bsp_start_clear_bss() doesn't solve the issue. Is there something missing of SMP in general?
thanks
comment:10 Changed on 04/20/20 at 18:23:00 by Sebastian Huber
Sorry, I don't have time to fix this very specific issue in my spare time.
https://docs.rtems.org/branches/master/user/support/bugs.html#nobody-fixes-my-bug
In case both processors loop in this function, then this is probably a problem with the cache, MMU, or memory controller setup. Which state to the processor see and which state do they expect?