关于optee使用的一个不成熟的想法，肯定有比这个好太多的方案。
可能大家一看标题就有语病，为什么呢，下面说一下CA和linux应用程序的划分？
黄皮书的作者是这样定义：android内核就是Llinux,android只不过是在Linux的应用层运行了JAVA虚拟机，搭建了framwork层来为上层APK提供支撑起始所有操作最终都会回归到kernel层面来完成。对于android而言，整个android都属于normal world
对应于Linux来说，其应CA和Linux应用程序本来就是一个概念。
其实一般的linux应用程序完全可以在具体业务程序中把CA部分写进去就可以；为什么还会有此篇文章存在？
因为：我的业务应用代码非常庞大，他有自己的一套编译体系，这个编译的框架目前不支持op-tee的编译；
op-tee这块编译的话（其实包括运行环境的搭建我都是通过Yocto完成的），是在Yocto中完成的，目前也没有支持我的业务代码的编译；
可能也只有我才这么拧巴的搞ca和Linux之间的通信，也欢迎有其它方案的对我进行指导！
optee-ca和Linux 应用程序的编译
optee-ca通过yocto编译，单独对optee-example进行编译
bitbake optee-example -c clean
bitbake optee-example -c compile
注意：对修改的optee-example文件在你optee-examplexx.bb的源码路径中而且必须在该位置修改，但是编译完后的可执行文件确不在这里。配方会把源码和编译后的可执行文件搬到几个地方，注意区分。
Linux 代码编译：
注意板子是32位的,注意交叉编译链 如下：
arm-linu-gnueabihf-gcc xxx.c -o xxx
TCP-client 、TCP-server代码
这个获取的途径就太多了，也可以自己写；
通讯方式（已测试成功）
如下图：
通过本次测试
还确定了以下：
1.在yocto中可单独对optee-example进行编译，编译完把*.ca *ta复制到Linux系统中对应的位置即可；
2.使用网络通信，可解决两个执行程序间的通讯问题。
root@imx6qsabresd:/# find -name optee_example_*
/bin/optee_example_acipher
./usr/bin/optee_example_random
./usr/bin/optee_example_hotp
./usr/bin/optee_example_secure_storage
./usr/bin/optee_example_aes
./usr/bin/optee_example_hello_world
。。。
root@imx6qsabresd:/# find -name *.ta
./lib/optee_armtz/5dbac793-f574-4871-8ad3-04331ec17f24.ta
./lib/optee_armtz/5ce0c432-0ab0-40e5-a056-782ca0e6aba2.ta
./lib/optee_armtz/5b9e0e40-2636-11e1-ad9e-0002a5d5c51b.ta
./lib/optee_armtz/9aaaf200-2450-11e4-abe2-0002a5d5c51b.ta
./lib/optee_armtz/a4c04d50-f180-11e8-8eb2-f2801f1b9fd1.ta
。。。。。。