Hi,
On Mon, Nov 14, 2016 at 9:01 AM, Peng Fan peng.fan@nxp.com wrote:
Hi Joakim,
-----Original Message----- From: Joakim Bech [mailto:joakim.bech@linaro.org] Sent: Monday, November 14, 2016 3:43 PM To: Jerome Forissier jerome.forissier@linaro.org Cc: Peng Fan peng.fan@nxp.com; tee-dev@lists.linaro.org Subject: Re: [Tee-dev] Introduce PSCI for OP-TEE ARM32
Peng, Jerome,
On Fri, Nov 11, 2016 at 09:29:44PM +0100, Jerome Forissier wrote:
Le 11 nov. 2016 10:30 AM, "Peng Fan" peng.fan@nxp.com a écrit :
Hi,
I am trying to implement TEE and support Linux power features.
There are several options to include power features and TEE
ATFW for ARM32.
Develop runtime service code in U-Boot like ATFW.
Integrate PSCI ARM32 in OP-TEE.
Option1, ATFW seems not support ARM32, such as A9/A7. And the AArch32
support, I think(not sure), is not for legacy ARM32 cores.
Indeed it seems that the main focus is ARMv8-A. FYI, the presentation made by ARM at Linaro Connect is at http://connect.linaro.org/resource/las16/las16-402/.
Yes, we had a chat with ARM at Connect and currently it seems like their plans only cover ARMv8-A (I cannot tell whether that will change later on). Having that said we also discussed whether we (Linaro security team) could bring in the related functionality as a PSCI library into ARMv7-A. Due to the architectural differences between ARMv8-A and ARMv7-A, that would mean that we would need to bring the PSCI related code for ARMv7-A directly into the OP-TEE code base. I.e, we're talking about option three in Peng's proposal above. This is something we've put on our to-do list and would like to start looking into this cycle (which lasts until next Linaro Connect in Feb/March -17).
I don't think we will start the working until the beginning of next year. If you'd need it sooner than what I've described above, then I wouldn't mind of you start working and with this and champion this work (of course we would like to be in the loop, both assisting and for discussion).
Having that said, what benefits would there be going with proposal one or two instead of option three? If we could gather a list of pro's and cons, I think we can make a better decision about how to actually do this.
I have did some basic verification about psci in op-tee. And I am happy to do some contribution. But rethinking about this, if we bind psci in op-tee, OP-TEE becomes mandatory for our software. if we want to make OP-TEE as an optional component, we may need to choose option 1 or 2.
As long as we're talking about PSCI and you have a secure world, you'll need to deal with the PSCI calls in monitor mode. That basically means in the secure monitor or integrated with the secure monitor. As far as I understand ARM-TF on Aarch32 will not provide a secure monitor as that is expected to be provided by the secure OS. The reason for that is that in contrast to Aarch64, monitor mode (which is the EL3 counterpart in Aarch32) shares MMU settings etc with secure EL1 so the trusted OS and the secure monitor can never be completely separated.
So with PSCI, one way or the other on Aarch32/ARMv7-A the trusted OS will need to be involved when starting/stopping cores. An advantage with option 3 is that the interface used by Linux/normal world is standardized and no special driver is needed.
Regards, Jens