Problems SMP an new SoC(ARM64: Cortex-A53) based board. #92278
Replies: 5 comments 3 replies
-
Cc @wearyzen |
Beta Was this translation helpful? Give feedback.
-
Hi @dylan-hong-nc there is a qemu board https://github.com/zephyrproject-rtos/zephyr/blob/main/boards/qemu/cortex_a53/qemu_cortex_a53_qemu_cortex_a53_smp.yaml which is tested in ci and doesn't show any failure. I tried |
Beta Was this translation helpful? Give feedback.
-
Hi @wearyzen. I got a raspberry pi5 and tried running 'tests/kernel/smp' with SMP related options added. The symptoms are different from the SoC under test, but it seems that the threads do not work properly in the SMP environment.
Are there any tuning points that can be applied? I am sharing the changes applied to apply SMP to the Raspberry Pi 5 as a patch file. [Full Log]
|
Beta Was this translation helpful? Give feedback.
-
Hi @dylan-hong-nc rpi doesn't seem to have smp support yet and I am not an expert on aarch64 so, I am not sure if your changes would be enough. |
Beta Was this translation helpful? Give feedback.
-
Hi @wearyzen. I have written about the causes and solutions to this phenomenon on the following pages. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Environment
For reference, the same TF-A is shared and used by Linux and commercial rtos.
Describe Problem
Hello, this is my first time contacting you.
We are porting zephyr v4.1.0 to our SoC and are having trouble with SMP bring-up.
For testing, I built and ran the test code in the following path:
tests/kernel/smp
However, the test stops after the log below.
The location where the test stops is different each time you test.
After quite some time of debugging, I found out via jtag debugger that the flush_owned_fpu function in arch/arm64/core/fpu.c was stuck in an infinite loop due to while (atomic_ptr_get(&_kernel.cpus[i].arch.fpu_owner) == thread).

I inserted the following memory dump code to analyze the cause.
I checked the buffer printed to the memory and confirmed that it was recorded as follows.
(I set it to record all cores from 0 to 3, but the cores actually recorded were 0 and 1.)
[CPU-0]

[CPU-1]

I ran the test with FPU_SHARING disabled with
CONFIG_FPU_SHARING=n
because fpu_ipi didn't seem to work properly. The test went through to the end as follows:However, the test_smp_ipi test fails.
(If I repeat the test, it often succeeds.)
I tried running the shell (not smp test) with FPU_SHARING disabled and the options below.
As an experiment, I tried entering kernel sleep 100 as shell input, but it did not wake up from sleep.
However, I confirmed that if I apply the scheduling options below, it wakes up normally regardless of the sleep value.
Unfortunately, I tried re-enabling FPU_SHARING while keeping this option enabled, but the result was the same.
What else can I test?
Does SMP work properly on other ARM64 based boards?
I've attached some of my config files.
Please help,
Thank you.
zephyr_smp_debug.zip
++++++++++++++++++++++++++
I tried to reflect the changes
ARM64_DCACHE_ALL_OPS
,ARM64_BOOT_DISABLE_DCACHE
andarm/arm64/core/switch.S
from the main branch to my workspace, but it didn't give me any meaningful results.When jumping from u-boot to zephyr I used the following commands:
Beta Was this translation helpful? Give feedback.
All reactions