| Anton Komlev | affe14f | 2022-11-01 00:07:41 +0000 | [diff] [blame^] | 1 | ############# |
| 2 | Configuration |
| 3 | ############# |
| 4 | |
| 5 | .. Warning:: |
| 6 | |
| 7 | This is a temporay design document for review. |
| 8 | Once the design is settled down. |
| 9 | It will be converted to user/integration guides. |
| 10 | |
| 11 | .. toctree:: |
| 12 | :maxdepth: 1 |
| 13 | :glob: |
| 14 | |
| 15 | profiles/index |
| 16 | |
| 17 | TF-M is a complex project having many configuration options to adjust project |
| 18 | for a user needs. A user can select the desired set of services and fine-tune |
| 19 | them to user's requirements. There are 2 types of configuration options: |
| 20 | |
| 21 | 1. Building : to select which file or component to include into compilation. |
| 22 | These are options, usually used by a build system to enable/disable |
| 23 | modules, specify location of external dependency or other selection, |
| 24 | global to a project. These options shall be considered while adopting TF-M |
| 25 | to other build systems. |
| 26 | In the Base configuration table theses options have *Build* type. |
| 27 | |
| 28 | 2. Component tuning : to adjust a particular parameter to a desired value. |
| 29 | Those options are local to a component or externally referenced when |
| 30 | components are coupled. Usually, such options are located in C header |
| 31 | file. The Header File Config System has more details about it. |
| 32 | In the Base configuration table theses options have *Component* type. |
| 33 | |
| 34 | .. Note:: |
| 35 | Originally, TF-M used CMake variables for both building and component tuning |
| 36 | purposes. It was convenient to have a single system for both building and |
| 37 | component's configurations. To simplify and improve configurability and |
| 38 | better support build systems other than a CMake, TF-M introduced a header |
| 39 | file configuration and moved component options into a dedicated config headers. |
| 40 | |
| 41 | **************** |
| 42 | How to configure |
| 43 | **************** |
| 44 | |
| 45 | The default TF-M build includes the minimum set of components required in any |
| 46 | project: SPM and a selected platform. This is not very useful for any product |
| 47 | and desired services shall be enabled by a user. There are several independent |
| 48 | ways to configure TF-M. |
| 49 | |
| 50 | 1. Use profiles. There are 4 sets of predefined configurations for a elected |
| 51 | use cases, called profiles. A user can select a profile by providing |
| 52 | -DTFM_PROFILE=<profile file name>. |
| 53 | Each profiles represented by a pair of configuration files for |
| 54 | Building (CMake) options and Component options (.h file) |
| 55 | |
| 56 | 2. A custom profile. Another method is to take a profile as a base and manually |
| 57 | modify desired options. |
| 58 | |
| 59 | 3. Use KConfig system. This is recommended method especially for beginners. |
| 60 | KConfig ensurers that all selected options are consistent and valid. This |
| 61 | is new in v1.7.0 and it covers only SPM and PSA ervices. As an output |
| 62 | KConfig produces a pair of configuration files, similar to a profile. |
| 63 | |
| 64 | .. Note:: |
| 65 | In contrast, before TF-M v1.7.0, the default build includes all possible |
| 66 | features. With growing functionality, such rich default build became |
| 67 | unpractical by not fitting into every platform and confusing of big |
| 68 | memory requirements. |
| 69 | |
| 70 | ********** |
| 71 | Priorities |
| 72 | ********** |
| 73 | Note:: |
| 74 | |
| 75 | TODO: Need a secion on configuration Priorities |
| 76 | |
| 77 | |
| 78 | -------------- |
| 79 | |
| 80 | *Copyright (c) 2022, Arm Limited. All rights reserved.* |