Hi Pascal, Thanks for the explanation. I was not aware of this. Now it makes much more sense. Agree then that we should change the name when we merge everything. Best, Javier
On 16 Mar 2015, at 12:22, Pascal Brand pascal.brand@linaro.org wrote:
Hi Javier,
OP-TEE is *not* TrustZone centric. What we have on github only contains TZ code as it is driven by Linaro, which focus on arm architecture. But the code is split into generic code and arm code.
In STM, we are using OP-TEE for TZ GP TEE and for a dedicated secure copro (LX / st231). The source code is under the same repo, with an extra architecture. Same on the linux driver side. We are using the OPTEE one, and have added a specific backend which targets our specific copro, which is not TrustZone.
Best regards, Pascal.
On 16 March 2015 at 11:11, Javier González <javigon.napster@gmail.com mailto:javigon.napster@gmail.com> wrote: Hi, I guess we can move development in the future. For now, my understanding is that OP-TEE is also TrustZone-centric "The optee_os git, contains the source code for the TEE in Linux using the ARM(R) TrustZone(R) technology.”
But of course, if we want to abstract TrustZone we can call it TEE generic driver (even though TEE is tightly coupled with TrustZone as for today)
Best, Javier
On 16 Mar 2015, at 09:47, Pascal Brand <pascal.brand@linaro.org mailto:pascal.brand@linaro.org> wrote:
Hi,
I've just noticed (a little bit late) that https://github.com/TrustZoneGenericDriver/linux https://github.com/TrustZoneGenericDriver/linux has TrustZone in the name, whereas we do not want a TrustZone only driver (the generic driver will not be TrustZone). I think it is ok to use this github as this is just temporary, to help us prototyping, but I just wanted to emphasize this.
Regards, Pascal.
On 16 March 2015 at 07:49, Jens Wiklander <jens.wiklander@linaro.org mailto:jens.wiklander@linaro.org> wrote: Hi Pascal,
On Sat, Mar 14, 2015 at 12:14:27PM +0100, Pascal Brand wrote:
Hello,
There are lots of uint64_t in the proposal, and I wonder how it will behaves on 32bits platforms, in terms of performances, ease to use,...
This interface is not intended to be used directly by client code, instead it's supposed to be wrapped in a client lib. I'm trying to follow the guide lines in https://www.kernel.org/doc/Documentation/ioctl/botching-up-ioctls.txt https://www.kernel.org/doc/Documentation/ioctl/botching-up-ioctls.txt to avoid the need of having one 64-bit and one 32-bit api.
-- Regards, Jens