diff options
author | Joakim Bech | 2019-02-22 03:53:09 -0600 |
---|---|---|
committer | Jérôme Forissier | 2019-02-22 07:49:46 -0600 |
commit | 4bcd1aadb4ce95288e96203be9f2a22d2208553e (patch) | |
tree | a57ed23404daa331a11318cbc109b7134f747466 | |
parent | 3733864ba510e739de4c13a658836a7ea93b6e3a (diff) | |
download | ti-optee-test-4bcd1aadb4ce95288e96203be9f2a22d2208553e.tar.gz ti-optee-test-4bcd1aadb4ce95288e96203be9f2a22d2208553e.tar.xz ti-optee-test-4bcd1aadb4ce95288e96203be9f2a22d2208553e.zip |
docs: Remove current docs and link to the new location
All current documentation has been transferred to a new git called
optee_docs [1]. The output from optee_docs will be rendered using Sphinx
and hosted at optee.readthedocs.io [2]. The new documentation git will
also be part of the regular OP-TEE releases. For completeness, it will
also be included in our manifests making up a full OP-TEE developer
setup.
[1] https://github.com/OP-TEE/optee_docs
[2] https://optee.readthedocs.io
Signed-off-by: Joakim Bech <joakim.bech@linaro.org>
Acked-by: Jerome Forissier <jerome.forissier@linaro.org>
-rw-r--r-- | Notice.md | 4 | ||||
-rw-r--r-- | README.md | 150 |
2 files changed, 6 insertions, 148 deletions
diff --git a/Notice.md b/Notice.md deleted file mode 100644 index 1b25439..0000000 --- a/Notice.md +++ /dev/null | |||
@@ -1,4 +0,0 @@ | |||
1 | To avoid duplicating information we link to the Notice.md file in optee_os which | ||
2 | states the contributor agreement rules etc, i.e, optee_test follows what is | ||
3 | written in the Notice.md on the URL below | ||
4 | https://github.com/OP-TEE/optee_os/blob/master/Notice.md | ||
@@ -1,148 +1,10 @@ | |||
1 | # OP-TEE sanity testsuite | 1 | # OP-TEE sanity testsuite |
2 | The optee_test git contains the source code for the TEE sanity | 2 | This git contains source code for the test suite (xtest) used to test the |
3 | testsuite in Linux using the ARM(R) TrustZone(R) technology. | 3 | OP-TEE project. |
4 | It is distributed under the GPLv2 and BSD 2-clause open-source | ||
5 | licenses. | ||
6 | For a general overview of OP-TEE, please see the | ||
7 | [Notice.md](Notice.md) file. | ||
8 | 4 | ||
9 | ## License | 5 | All official OP-TEE documentation has moved to http://optee.readthedocs.io. The |
10 | The client applications (`optee_test/host/*`) are provided under the | 6 | information that used to be here in this git can be found under [optee_test]. |
11 | [GPL-2.0](http://opensource.org/licenses/GPL-2.0) license. | ||
12 | The user TAs (`optee_test/ta/*`) are provided under the | ||
13 | [BSD 2-Clause](http://opensource.org/licenses/BSD-2-Clause) license. | ||
14 | 7 | ||
8 | // OP-TEE core maintainers | ||
15 | 9 | ||
16 | ## Get and build the software | 10 | [optee_test]: https://optee.readthedocs.io/building/gits/optee_test.html |
17 | |||
18 | ### HOWTO build the testsuite | ||
19 | #### Standard tests | ||
20 | xtest test suite comes with a standard test suite, | ||
21 | freely available. When installing OP-TEE through the | ||
22 | [manifest](https://github.com/OP-TEE/optee_os/blob/master/README.md#6-repo-manifests), | ||
23 | the [build](https://github.com/OP-TEE/build) | ||
24 | component provides the `xtest` target which builds optee_test. | ||
25 | It makes use of the following environment variables: | ||
26 | * `CROSS_COMPILE_HOST`: the cross compiler used to compile the | ||
27 | Non-Secure Client Application (`host/xtest`) | ||
28 | * `CROSS_COMPILE_TA`: the cross compiler used to compile the | ||
29 | Trusted Applications (`ta`) | ||
30 | * `TA_DEV_KIT_DIR`: the path to the Trusted Application Dev Kit. | ||
31 | It can be found in optee_os repository, once optee_os has been compiled. | ||
32 | * `O`: the output repository | ||
33 | |||
34 | #### Extended test (Global Platform tests) | ||
35 | Developers can purchase the | ||
36 | [Global Platform Compliance Test suite](https://www.globalplatform.org/store.asp). | ||
37 | This test suite comes with .xml files describing the tests and | ||
38 | the Trusted Applications. | ||
39 | |||
40 | Standard tests can be extended with the Global Platform test suite. | ||
41 | The user must only: | ||
42 | * Install the Global Platform `xml` files in `$CFG_GP_PACKAGE_PATH` | ||
43 | * Run `make patch` (or call make `xtest-patch` from the `build` repository) | ||
44 | before compiling xtest. This must be run a single time after the installation | ||
45 | of OP-TEE. | ||
46 | |||
47 | This will: | ||
48 | * Create new Trusted Applications, that can be found in `ta/GP_xxx` | ||
49 | * Create new tests in `host/xtest`, as for example `xtest_9000.c` | ||
50 | * Patches `xtest_7000.c`, adding new tests. | ||
51 | |||
52 | Then the tests must be compiled with `CFG_GP_PACKAGE_PATH=<path>`. | ||
53 | |||
54 | It makes use of the following environment variable: | ||
55 | * `COMPILE_NS_USER`: `32` or `64` if application shall be compiled in 32 bits | ||
56 | mode on in 64 bits mode. If `COMPILE_NS_USER` is not specificed, build relies | ||
57 | on `CFG_ARM32_core=y` from OP-TEE core build to assume applications are in | ||
58 | 32 bits mode, Otherwise, 64 bits mode is assumed. | ||
59 | |||
60 | |||
61 | ### HOWTO run xtest | ||
62 | |||
63 | # all xtest | ||
64 | boot and execute on your target | ||
65 | $ ifconfig lo 127.0.0.1 | ||
66 | $ tee-supplicant & | ||
67 | $ xtest | ||
68 | |||
69 | # single xtest | ||
70 | boot and execute on your target | ||
71 | $ ifconfig lo 127.0.0.1 | ||
72 | $ tee-supplicant & | ||
73 | $ xtest <testnumber> (i.e.: xtest 1001) | ||
74 | |||
75 | # family xtest (i.e.: Family 1000) | ||
76 | boot and execute on your target | ||
77 | $ ifconfig lo 127.0.0.1 | ||
78 | $ tee-supplicant & | ||
79 | $ xtest _<family> (i.e.: xtest _1) | ||
80 | |||
81 | # running all benchmarks (secured storage, aes/sha) | ||
82 | boot and execute on your target | ||
83 | $ tee-supplicant & | ||
84 | $ xtest -t benchmark | ||
85 | |||
86 | # running single benchmark | ||
87 | boot and execute on your target | ||
88 | $ tee-supplicant & | ||
89 | $ xtest -t benchmark <benchmark_number> (i.e. xtest 2001) | ||
90 | |||
91 | ### HOWTO use SHA/AES benchmarking modules | ||
92 | It's also possible to run SHA/AES benchmarks by using sha-perf/aes-perf modules | ||
93 | within xtest. These modules allow to run custom benchmarks with user-defined | ||
94 | params. | ||
95 | |||
96 | # running sha-perf with default params | ||
97 | boot and execute on your target | ||
98 | $ tee-supplicant & | ||
99 | $ xtest --sha-perf | ||
100 | |||
101 | # getting usage details and list of possible options for sha-perf | ||
102 | $ xtest --sha-perf -h | ||
103 | |||
104 | #### Compiler flags | ||
105 | To be able to see the full command when building you could build using following | ||
106 | flag: | ||
107 | |||
108 | `$ make V=1` | ||
109 | |||
110 | To state where build files are stored use the `O` flag. | ||
111 | |||
112 | `$ make O=$HOME/foo` | ||
113 | |||
114 | By default `optee_test` expects that `optee_client` is located at the same | ||
115 | folder level. However if you build optee_client in another location, then you | ||
116 | also would need to use (or export) the following flag: | ||
117 | |||
118 | `$ make OPTEE_CLIENT_EXPORT=$HOME/my_new_location/out/export` | ||
119 | |||
120 | ## Coding standards | ||
121 | In this project we are trying to adhere to the same coding convention as used in | ||
122 | the Linux kernel (see | ||
123 | [CodingStyle](https://www.kernel.org/doc/Documentation/CodingStyle)). We achieve this by running | ||
124 | [checkpatch](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/scripts/checkpatch.pl) from Linux kernel. | ||
125 | However there are a few exceptions that we had to make since the code also | ||
126 | follows GlobalPlatform standards. The exceptions are as follows: | ||
127 | |||
128 | - CamelCase for GlobalPlatform types are allowed. | ||
129 | - And we also exclude checking third party code that we might use in this | ||
130 | project, such as LibTomCrypt, MPA, newlib (not in this particular git, but | ||
131 | those are also part of the complete TEE solution). The reason for excluding | ||
132 | and not fixing third party code is because we would probably deviate too much | ||
133 | from upstream and therefore it would be hard to rebase against those projects | ||
134 | later on (and we don't expect that it is easy to convince other software | ||
135 | projects to change coding style). | ||
136 | |||
137 | ### checkpatch | ||
138 | Since checkpatch is licensed under the terms of GNU GPL License Version 2, we | ||
139 | cannot include this script directly into this project. Therefore we have | ||
140 | written the Makefile so you need to explicitly point to the script by exporting | ||
141 | an environment variable, namely CHECKPATCH. So, suppose that the source code for | ||
142 | the Linux kernel is at `$HOME/devel/linux`, then you have to export like follows: | ||
143 | |||
144 | $ export CHECKPATCH=$HOME/devel/linux/scripts/checkpatch.pl | ||
145 | thereafter it should be possible to use one of the different checkpatch targets | ||
146 | in the [Makefile](Makefile). There are targets for checking all files, checking | ||
147 | against latest commit, against a certain base-commit etc. For the details, read | ||
148 | the [Makefile](Makefile). | ||