Hi, experts, We seem to have solved the problem. This problem is not caused by the load_address of optee, but by the security space configured in the ATF. It seems that the security space we have configured is too large. And why will it causes the problem needs to be further identified. Regards, Yuye. ------------------------------------------------------------------ 发件人：梅建强(禹夜) meijianqiang.mjq@alibaba-inc.com 发送时间：2023年3月22日(星期三) 11:50 收件人：Olivier Deprez Olivier.Deprez@arm.com; Jens Wiklander jens.wiklander@linaro.org 抄　送：hafnium hafnium@lists.trustedfirmware.org; op-tee op-tee@lists.trustedfirmware.org 主　题：load optee at 36bit address Hi, experts, We are currently moving optee to a 36bit address to boot with environment that hafnium runs at sel2 as spmc and optee runs at sel1 as sp. Now we have moved hafnium to 0x880000000 and run successfully. Then we tried moving optee to a 36bit address (0x89000000) as well. Although hafnium and optee were successfully initialized on the primary cpu, psci_cpu_on does not seem to be entered into when the secondary cpu is started. The error is as follows: https://github.com/OP-TEE/optee_os/issues/5895 <https://github.com/OP-TEE/optee_os/issues/5895 > Is there any difference between the two cases where hafnium and optee initialize the secondary cpu with different load_address? The log print shows that the secondary cpu has not entered hafnium. Could Hafnium be affected by the 36bit address when dealing with psci related transactions? Regards, Yuye.