Hi Bin,

Did you check what psci_cpu_on_start is doing I would expect you have similar operations
when you want to bypass the psci cpu enable method.

Few things I can notice from code which you may have to explore:

Perform cache maintanence ahead of reading the target CPU state to ensure that the data is not stale.
Platform specific power on.
Store the re-entry information for the non-secure world - context management for CPU.

From: 빈성욱 via TF-A <tf-a@lists.trustedfirmware.org>
Sent: Wednesday, August 16, 2023 01:12
To: tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.org>
Subject: [TF-A] Question about Secondary CPU boot with spintable

I ported TF-A and OPTEE on multi-core SoC, and I checked that xtest passed on CPU0 without failure. However, I'm failing in secondary CPU boot, and I'd like to get some help.

I'm using ARMv8, and I'm using spintable as CPU enable method (not using PSCI FW). TF-A is in EL3.

What I did ...

1. I released secondary CPU reset from bl31_early_platform_setup2() during primary CPU cold booting

- set secondary CPU's RVBAR to bl31_entrypoint

- release secondary CPU reset

2. I implemeneted plat_secondary_cold_boot_setup(), which is spining until linux kernel updates cpu-release-addr. Once linux kernel updates cpu-release-addr, then it changes EL to EL1 and jumps to secondary_startup() in linux

3. But secondary core goes to panic. It seems to happen when linux invokes optee_probe()

Should I initialize some contexts (e.g. optee ..)? If so, where should I implement the corresponding codes? I'm wondering if I'm missing something, and I'd like to get some advice

Thanks,

--Bin