tee

关于在OP-TEE中如何添加自己的TA和CA请参阅《2. OP-TEE中添加自己的TA和CA》，修改好对应的makefile,配置文件，UUID, commandID等等之后，完成一次完整的CA请求时在linux userspace端需要执行的操作依次如下 ：

1. 调用TEEC_InitializeContext函数打开op-tee驱动文件，获取到操作句柄并存放到TEE_Context类型的变量中。

2. 调用TEEC_OpenSession函数，通过获取到的TEE_Context类型的变量创建一个特定CA与特定TA之间进行通信的通道，如果TA image被存放在file system中，那个在创建session的时候，OP-TEE OS端还会将TA image从file system中加载到OP-TEE。

3. 初始化TEEC_Operation类型的变量，并根据实际需要借助TEEC_PARAM_TYPES宏来设定TEEC_Operation类型变量中paramTypes成员的值，该值规定传递到OP-TEE中的最多4个变量缓存或者是数据的作用（作为输入还是输出）。并且还要根据paramTypes的值设定对应的params[x]成员的值或者是指向的地址以及缓存的长度。

4. 使用已经创建好的session，TA与CA端规定的command ID以及配置好的TEEC_Operation类型变量作为参数调用TEEC_InvokeCommand函数来真正发起请求。 调用TEEC_InvokeCommand成功之后，剩下的事情就有OP-TEE和TA进行处理并将结果和相关的数据通过TEEC_Operation类型变量中的params成员返回给CA。

5. 调用成功之后如果不需要再次调用该TA则需要注销session和释放掉context，这两个操作一次通过调用TEEC_CloseSession函数和TEEC_FinalizeContext函数来实现。

在Linux端一次完整的CA接口调用过程如下图所示：

NOTE:

1. 注意在如果调用CA接口是一个service或者是一个常驻linux kernel且该接口会被多次调用的时候，在未将context和session释放掉的前提下，TEEC_InitializeContext和TEEC_OpenSession接口不要重复调用，否则会引起OP-TEE出错，因为每次执行initialize context和openssion的时候，OP-TEE都会划分一定的memory，如果在为释放已有资源的时候重复分配context和session，则会造成OP-TEE内存泄露。针对该情况可以在CA接口的实现时对执行初始化context和open session的操作添加一个flag进行控制，当该接口的context和session已经被初始化时则不需要重复操作，而且在调用完TEEC_InvokeCommand之后，如果service或者Process还需要调用该CA接口，则不建议立即释放context和session。详细情况请查阅测试代码（测试代码加了flag，但是对于调用完TEEC_InvokeCommand操作后的后续操作需要重新搞搞，以后会更新该代码）

2. 在使用过程过程中，一般会将CA接口打包成库文件给上层调用，也可以将该接口封装成JNI接口供JAVA层调用。

3. 关于上述几个TEEC接口的具体实现每家芯片厂商可能不一样，但对于用户来说都一样。下文将以OP-TEE的实现为准进行介绍。后续有时间可以讲讲海思和mstar添加TA和CA的方式