Gyorgy Szing | 5e429cb | 2019-12-03 20:39:55 +0100 | [diff] [blame^] | 1 | User Guide |
| 2 | ========== |
| 3 | |
| 4 | This guide describes how the framework features are supposed to be used, through |
| 5 | an example implementation for the |TF-A| project. Please refer to the `TF-A |
| 6 | repository`_ for the code. |
| 7 | |
| 8 | Root CMakeLists file |
| 9 | -------------------- |
| 10 | |
| 11 | The root CMakeLists file contains the following sections: |
| 12 | |
| 13 | #. Set required CMake version |
| 14 | |
| 15 | This is mandatory at the start of every CMake project. The framework |
| 16 | requires version 3.13 or newer. |
| 17 | |
| 18 | #. Set default build type |
| 19 | |
| 20 | Set the default value for ``CMAKE_BUILD_TYPE`` as a cache entry. This |
| 21 | ensures that the variable will have a value when it is not specified as a |
| 22 | command line argument. |
| 23 | |
| 24 | #. Set project root dir |
| 25 | |
| 26 | This is not strictly necessary, but makes referring to project relative |
| 27 | paths easier. Using ``CMAKE_CURRENT_LIST_DIR`` is recommended, it contains |
| 28 | the absolute path to the directory containing the currently processed file. |
| 29 | |
| 30 | #. Find the framework |
| 31 | |
| 32 | The framework is written as a CMake module, which can be used by |
| 33 | :cmake:command:`find_package`. This will take care of the version matching |
| 34 | and adding the framework dir to the module path. |
| 35 | |
| 36 | In the example, we try to find the framework at the parent directory of the |
| 37 | TF-A project dir and inside the TF-A project. If the framework is not |
| 38 | found, we clone the git repository using :cmake:module:`FetchContent`. The |
| 39 | path to the framework can also be provided as a command line option to |
| 40 | CMake, using ``-DTFACMF_DIR=<path to framework>``. |
| 41 | |
| 42 | #. Add project specific paths |
| 43 | |
| 44 | There are some CMake modules which are specific to the project, so cannot |
| 45 | be part of the generic framework (e.g. find fiptool). These should also be |
| 46 | added to the module path. |
| 47 | |
| 48 | #. Set CMake system parameters |
| 49 | |
| 50 | The framework provides a new platform called ``Embedded``. The project |
| 51 | should set :cmake:variable:`CMAKE_SYSTEM_NAME` to ``Embedded`` in order to |
| 52 | use the platform. This is an important step as this method is the only way |
| 53 | in CMake to ensure the correct output extension, library name |
| 54 | prefix/suffix, etc. |
| 55 | |
| 56 | :cmake:variable:`CMAKE_SYSTEM_PROCESSOR` should be set to ``arm``. This has |
| 57 | no particular effect, but it indicates that the project is cross-compiled. |
| 58 | |
| 59 | #. Include framework files |
| 60 | |
| 61 | It is more convenient to include the framework files here. The config and |
| 62 | target files included later will inherit the environment. |
| 63 | |
| 64 | #. Start CMake project |
| 65 | |
| 66 | The start of a CMake project, ``C`` and ``ASM`` languages should be |
| 67 | selected. |
| 68 | |
| 69 | #. Find platform module |
| 70 | |
| 71 | Currently for finding platform related config a minimal |
| 72 | :cmake:command:`find_package` module is implemented. These module files |
| 73 | describing the platform are located in the ``<TF-A root>/cmake/HwPlat`` |
| 74 | directory, which is added to :cmake:variable:`CMAKE_MODULE_PATH` in the |
| 75 | project specific paths section. |
| 76 | |
| 77 | A platform description file contains more :cmake:command:`find_package` |
| 78 | calls to find other external tools which are needed by the platform, and |
| 79 | sets the following global variables: |
| 80 | |
| 81 | * :cmake:variable:`HW_PLAT_CONFIG`: path to config file which contains |
| 82 | the :cmake:module:`group` for the platform options, |
| 83 | * :cmake:variable:`HW_PLAT_TARGET`: path to target file which contains |
| 84 | target creation, adding source files, etc. for the platform, |
| 85 | * :cmake:variable:`HW_PLAT_IMAGE`: path to file which describes the steps |
| 86 | of packaging the compiled binaries into an image (e.g. fiptool usage). |
| 87 | |
| 88 | The files indicated by these variables should be included in the relevant |
| 89 | sections of the root CMakeLists file, as described below. |
| 90 | |
| 91 | #. Include config files |
| 92 | |
| 93 | All the config files containing the settings groups have to be included. |
| 94 | These create and fill the groups with content, so in the target files we |
| 95 | can select which group to apply on which target. This means including the |
| 96 | :cmake:variable:`HW_PLAT_CONFIG` too. |
| 97 | |
| 98 | #. Include target files |
| 99 | |
| 100 | The target files selected for the current build have to be included. These |
| 101 | create the target and add source files, includes, etc. to the target. |
| 102 | Include :cmake:variable:`HW_PLAT_TARGET` in this section. |
| 103 | |
| 104 | Currently there is no solution provided to select which targets are |
| 105 | necessary, except adding/removing the include command in this section. A |
| 106 | better solution would be to decide based on the current build configuration |
| 107 | (from Kconfig?) so targets can be selected without modifying the CMakeLists |
| 108 | file. |
| 109 | |
| 110 | #. Include image files |
| 111 | |
| 112 | The files describing how to package the output binaries into an image can |
| 113 | be included here. Since this is platform specific, only |
| 114 | :cmake:variable:`HW_PLAT_IMAGE` should be used. |
| 115 | |
| 116 | Config file |
| 117 | ----------- |
| 118 | |
| 119 | The config files are located in the ``<TF-A root>/configs`` directory. Each |
| 120 | config file creates a :cmake:module:`group` using :cmake:command:`group_new` and |
| 121 | fills the group with content using :cmake:command:`group_add`. |
| 122 | |
| 123 | An important topic in the example is the difference between the ``CONFIG`` and |
| 124 | ``DEFINE`` types in a group. The idea is, that ``CONFIG`` is a parameter that |
| 125 | affects the build, i.e. what sources are necessary for a given target, etc. |
| 126 | while ``DEFINE`` is a simple C language define. Often a build option falls into |
| 127 | both categories, but not necessarily. For example, |
| 128 | |
| 129 | * ``ENABLE_AMU`` is a config, because it affects the build, it determines |
| 130 | whether ``amu.c`` is added to ``BL31`` or not. It is a define too, because |
| 131 | there is ``#if ENABLE_AMU`` conditional compilation in the C source, |
| 132 | |
| 133 | * ``FVP_MAX_PE_PER_CPU`` is a define only, because it does not affect the list |
| 134 | of files necessary for the build, |
| 135 | |
| 136 | * ``ENABLE_STACK_PROTECTOR`` is a config only, because it is never used in the |
| 137 | source code. |
| 138 | |
| 139 | Target file |
| 140 | ----------- |
| 141 | |
| 142 | A target file can be one of two types, ``CMakeLists.txt`` or ``<module |
| 143 | name>.cmake``. The former is for a module which is likely to be reused in other |
| 144 | projects and can be built stand-alone, the latter is a module which only has |
| 145 | meaning as part of the project. A ``CMakeLists.txt`` must contain a |
| 146 | :cmake:command:`project` command and has to be included using |
| 147 | :cmake:command:`add_subdirectory`, while a ``<module name>.cmake`` cannot start |
| 148 | a new project and the file is simply included with the :cmake:command:`include` |
| 149 | command. |
| 150 | |
| 151 | A target file uses the :cmake:module:`STGT` functions to create a target, add |
| 152 | groups to the target, add source files, etc. Please check the example code in |
| 153 | TF-A, e.g.: |
| 154 | |
| 155 | * ``bl*/bl*.cmake`` |
| 156 | * ``plat/arm/board/fvp/platform.cmake`` |
| 157 | * ``plat/arm/common/arm_common.cmake`` |
| 158 | * ``lib/libc/CMakeLists.txt`` |
| 159 | * etc. |
| 160 | |
| 161 | Image file |
| 162 | ---------- |
| 163 | |
| 164 | The purpose of this file is to package the output binaries into an image, using |
| 165 | the platform specific tools. The recommendation is to use |
| 166 | :cmake:command:`add_custom_target` which depends on the targets/files packaged |
| 167 | into the image. It is likely that ``ALL`` should be added to the command |
| 168 | options, since usually this image is the final output of the build, so no other |
| 169 | targets will depend on this therefore it would not be built without ``ALL``. |
| 170 | Please check the example in ``plat/arm/board/fvp/image.cmake``. |
| 171 | |
| 172 | .. todo:: Add support for ``install`` feature of CMake. |
| 173 | |
| 174 | -------------- |
| 175 | |
| 176 | .. _`TF-A repository`: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/ |
| 177 | |
| 178 | *Copyright (c) 2019-2020, Arm Limited and Contributors. All rights reserved.* |
| 179 | |
| 180 | SPDX-License-Identifier: BSD-3-Clause |