Hi, Govindrj R,

Thanks for providing the points where I can dig into more.
Yes, I took a look at the code related to PSCI and I realized that I may need to add similar operation like psci_cpu_on_start. (we may want opteed_cpu_on_finish_handler() to be finally called on TF-A?) But I have no confidence and I am asking about what I really do. Depends on the CPU enable method, SMP boot flow seems to differ. As for spintable method, I guess that I need to create new interface which triggers optee context initialization on secondary cores.

Based on this, what I'm curious is if I need to add something to linux kernel or only need to implement something in TF-A or donot need to add anything... (and where I need to implement it if I need to create something) If there is a reference code, it will be the best :) 

If I understand wrongly or miss somthing else, please let me know.

Thanks,
--Bin

2023년 8월 17일 (목) 오전 7:23, Govindraj Raja <Govindraj.Raja@arm.com>님이 작성:
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.

--

Thanks,

Govindraj R


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
 
Hi 

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