#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)

Capture.PNG (31.4 KB) - added by Massimiliano Patriarca on Dec 15, 2019 at 5:36:52 PM.

Download all attachments as: .zip

Change History (11)

comment:1 Changed on Nov 22, 2019 at 3:02:37 PM by Sebastian Huber

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?

comment:2 Changed on Nov 22, 2019 at 9:39:24 PM 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 Nov 23, 2019 at 9:18:52 AM by Massimiliano Patriarca

By the way it is not clear how the two APUs signals its ready to run...

comment:4 Changed on Nov 25, 2019 at 6:35:22 AM 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 Dec 12, 2019 at 7:23:46 PM by Massimiliano Patriarca

What variable/register is shared and in what source file
cache snooping is enabled. any other idea?

comment:6 Changed on Dec 13, 2019 at 6:01:52 AM by Sebastian Huber

Sorry, I am currently busy with other things and I soon go on holidays.

comment:7 Changed on Dec 13, 2019 at 6:02:57 AM by Sebastian Huber

Component: adminarch/arm
Milestone: Indefinite
Type: enhancementdefect
Version: 5

Changed on Dec 15, 2019 at 5:36:52 PM by Massimiliano Patriarca

Attachment: Capture.PNG added

comment:8 Changed on Dec 15, 2019 at 5:40:17 PM 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:9 Changed on Apr 20, 2020 at 4:35:33 PM by Massimiliano Patriarca

Nobody is working in smp?

comment:10 Changed on Apr 20, 2020 at 6:23:00 PM 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

Note: See TracTickets for help on using tickets.