Hi Bin,
TF-A will do all of the context management (and dispatching to OPTEE) for you if you use PSCI. And PSCI is required anyway if you ever want to do CPU/system suspend.
On 8/21/23 10:47, Dan Handley via TF-A wrote:
Like Jeremy says, I would strongly recommend using PSCI, even if this is backed by a spintable in your platform implementation. This is what some upstream platforms do (e.g. RPI3).
Since this platform appears to provide software control over CPU reset, there is no need for a spin table at all.
If your platform does not automatically release secondary CPUs at the same time as releasing the primary and you've programmed the secondary CPU's RVBAR, then there's no need to implement plat_secondary_cold_boot_setup() (or you could just provide a dummy implementation).
Specifically, you can set COLD_BOOT_SINGLE_CPU := 1.
The RVBAR should be programmed in your plat_setup_psci_ops() implementation, because in this case the EL3 entry point for secondary CPUs is different from the BL31 entry point used by the primary CPU.
Your implementation of pwr_domain_on could release the secondary CPUs from reset the first time it is called. On subsequent calls, you could release the CPU from the spintable. Your implementation of pwr_domain_pwr_down_wfi could put the CPUs into the spintable.
Or it could put the CPU back into reset. Then pwr_domain_on does not need any special case for the first time a CPU is turned on.
Regards, Samuel