Gyorgy Szing | db9783c | 2019-04-17 21:08:48 +0200 | [diff] [blame] | 1 | ################################### |
| 2 | Details for the platform/ext folder |
| 3 | ################################### |
| 4 | This folder has code that has been imported from other projects. This means the |
| 5 | files in this folder and subfolders have Apache 2.0 license which is different |
| 6 | to BSD 3.0 license applied to the parent TF-M project. |
| 7 | |
| 8 | .. Note:: |
| 9 | This folder is strictly Apache 2.0 with the exception of cmake files. |
| 10 | Maintainers should be consulted if this needs to be revisited. |
| 11 | |
| 12 | *********** |
| 13 | Sub-folders |
| 14 | *********** |
| 15 | |
| 16 | cmsis |
| 17 | ===== |
| 18 | This folder contains core and compiler specific header files imported from the |
| 19 | ``CMSIS_5`` project. |
| 20 | |
| 21 | common |
| 22 | ====== |
Raef Coles | a657a9c | 2019-10-24 14:36:43 +0100 | [diff] [blame] | 23 | |
| 24 | armclang and gcc |
| 25 | ---------------- |
| 26 | These contain the linker scripts used to configure the memory regions in TF-M |
| 27 | regions. |
| 28 | |
| 29 | cc312 |
| 30 | ----- |
| 31 | This folder contains cmake and code files to interact with the CC312 |
| 32 | cryptographic accelerator. Integrating a platform with the CC312 requires some |
| 33 | configuration, of which an example can be seen in the |
| 34 | ``platform/ext/musca_b1.cmake`` file. |
| 35 | |
| 36 | To configure the CC312 at build time, a few cmake arguments can be specified. |
| 37 | |
| 38 | - ``CRYPTO_HW_ACCELERATOR`` |
| 39 | - ``ON`` All possible mbedtls cryptographic operations will be offloaded to |
| 40 | the CC312 accelerator. |
| 41 | - ``OFF`` The cryptographic accelerator will be ignored and software |
| 42 | cryptography will be used. |
| 43 | |
| 44 | - ``CRYPTO_HW_ACCELERATOR_OTP_STATE`` |
| 45 | - ``DISABLED`` The HW accelerator will not use any data from its onboard OTP |
| 46 | (One Time Programmable) memory. |
| 47 | - ``PROVISIONING`` This special mode is used to program cryptographic |
| 48 | material into the OTP memory. When the flag is set TF-M will not boot, but |
| 49 | will instead program the hardware unique key, the root of trust private key |
| 50 | and the attestation private key into the OTP memory. This mode is not |
| 51 | compatible with |
| 52 | ``CRYPTO_HW_ACCELERATOR=ON``. |
| 53 | - ``ENABLED`` The HW accelerator will use the previously programmed data as |
| 54 | the hardware unique key, the root of trust private key and the attestation |
| 55 | private key. This mode requires ``CRYPTO_HW_ACCELERATOR=ON``. |
| 56 | |
| 57 | |
| 58 | .. Warning:: |
| 59 | |
| 60 | Provisioning **can not** be reversed, and data in the OTP memory **can not** |
| 61 | be changed once set. |
| 62 | |
Jamie Fox | c320228 | 2019-12-13 17:12:16 +0000 | [diff] [blame^] | 63 | template |
| 64 | -------- |
| 65 | This directory contains platform-independent dummy implementations of the |
| 66 | interfaces in ``platform/include``. These implementations can be built directly |
| 67 | for initial testing of a platform port, or used as a basic template for a real |
| 68 | implementation for a particular target. They **must not** be used in production |
| 69 | systems. |
| 70 | |
Raef Coles | a657a9c | 2019-10-24 14:36:43 +0100 | [diff] [blame] | 71 | other |
| 72 | ----- |
Jamie Fox | c320228 | 2019-12-13 17:12:16 +0000 | [diff] [blame^] | 73 | This folder also contains stdout redirection to UART and |
| 74 | ``tfm_mbedcrypto_config.h`` for all the targets. |
Gyorgy Szing | db9783c | 2019-04-17 21:08:48 +0200 | [diff] [blame] | 75 | |
| 76 | drivers |
| 77 | ======= |
| 78 | This folder contains the headers with CMSIS compliant driver definitions that |
| 79 | that TF-M project expects a target to provide. |
| 80 | |
| 81 | target_cfg.h |
| 82 | ------------ |
| 83 | This file is expected to define the following macros respectively. |
| 84 | |
| 85 | - ``TFM_DRIVER_STDIO`` - This macro should expand to a structure of type |
| 86 | ``ARM_DRIVER_USART``. TFM redirects its standard input and output to this |
| 87 | instance of USART. |
| 88 | - ``NS_DRIVER_STDIO`` - This macro should expand to a structure of type |
| 89 | ``ARM_DRIVER_USART``. Non-Secure application redirects its standard input and |
| 90 | output to this instance of USART. |
| 91 | |
| 92 | target |
| 93 | ====== |
| 94 | This folder contains the files for individual target. |
| 95 | |
| 96 | Flash layout header file |
| 97 | ------------------------ |
| 98 | Target must provide a header file, called ``flash_layout.h``, which defines the |
| 99 | information explained in the follow subsections. The defines must be named |
| 100 | as they are in the subsections. |
| 101 | |
| 102 | BL2 bootloader |
| 103 | ^^^^^^^^^^^^^^ |
| 104 | The BL2 bootloader requires the following definitions: |
| 105 | |
| 106 | - ``FLASH_BASE_ADDRESS`` - Defines the first valid address in the flash. |
| 107 | - ``FLASH_AREA_BL2_OFFSET`` - Defines the offset from the flash base address |
| 108 | where the BL2 - MCUBOOT area starts. |
| 109 | - ``FLASH_AREA_BL2_SIZE`` - Defines the size of the BL2 area. |
David Vincze | bb20798 | 2019-08-21 15:13:04 +0200 | [diff] [blame] | 110 | - ``FLASH_AREA_SCRATCH_OFFSET`` - Defines the offset from the flash base |
Gyorgy Szing | db9783c | 2019-04-17 21:08:48 +0200 | [diff] [blame] | 111 | address where the scratch area starts, which is used during image swapping. |
David Vincze | bb20798 | 2019-08-21 15:13:04 +0200 | [diff] [blame] | 112 | - ``FLASH_AREA_SCRATCH_SIZE`` - Defines the size of the scratch area. The |
Gyorgy Szing | db9783c | 2019-04-17 21:08:48 +0200 | [diff] [blame] | 113 | minimal size must be as the biggest sector size in the flash. |
| 114 | - ``FLASH_DEV_NAME`` - Specifies the flash device used by BL2. |
| 115 | |
David Vincze | bb20798 | 2019-08-21 15:13:04 +0200 | [diff] [blame] | 116 | The BL2 requires further definitions depending on the number of images, the |
| 117 | meaning of these macros are also slightly different: |
| 118 | |
| 119 | - Required definitions in case of 1 image (S and NS images are concatenated |
| 120 | and handled together as one binary blob): |
| 121 | |
| 122 | - ``FLASH_AREA_0_OFFSET`` - Defines the offset from the flash base address |
| 123 | where the primary image area starts, which hosts the active firmware |
| 124 | image. |
| 125 | - ``FLASH_AREA_0_SIZE`` - Defines the size of the primary image area. |
| 126 | - ``FLASH_AREA_2_OFFSET`` - Defines the offset from the flash base address |
| 127 | where the secondary image area starts, which is a placeholder for new |
| 128 | firmware images. |
| 129 | - ``FLASH_AREA_2_SIZE`` - Defines the size of the secondary image area. |
| 130 | |
| 131 | - Required definitions in case of 2 images (S and NS images are handled and |
| 132 | updated separately): |
| 133 | |
| 134 | - ``FLASH_AREA_0_OFFSET`` - Defines the offset from the flash base address |
| 135 | where the primary image areas start, which host the active firmware |
| 136 | images. It is also the offset of the primary (active) secure image area. |
| 137 | - ``FLASH_AREA_0_SIZE`` - Defines the size of the primary secure image area. |
| 138 | - ``FLASH_AREA_1_OFFSET`` - Defines the offset from the flash base address |
| 139 | where the primary (active) non-secure image area starts. |
| 140 | - ``FLASH_AREA_1_SIZE`` - Defines the size of the primary non-secure image |
| 141 | area. |
| 142 | - ``FLASH_AREA_2_OFFSET`` - Defines the offset from the flash base address |
| 143 | where the secondary image areas start, which are placeholders for new |
| 144 | firmware images. It is also the offset of the secondary secure image area. |
| 145 | - ``FLASH_AREA_2_SIZE`` - Defines the size of the secondary secure image |
| 146 | area. |
| 147 | - ``FLASH_AREA_3_OFFSET`` - Defines the offset from the flash base address |
| 148 | where the secondary non-secure image area starts. |
| 149 | - ``FLASH_AREA_3_SIZE`` - Defines the size of the secondary non-secure image |
| 150 | area. |
| 151 | |
| 152 | The table below shows a fraction of the flash layout in case of 2 and 1 |
| 153 | updatable images with the related flash areas that hold the firmware images: |
| 154 | |
| 155 | +-----------------------+--------------------+-----------------------+-----------------------------+ |
| 156 | | Image number: 2 | Image number: 1 | |
| 157 | +=======================+====================+=======================+=============================+ |
| 158 | | **Flash area** | **Content** | **Flash area** | **Content** | |
| 159 | +-----------------------+--------------------+-----------------------+-----------------------------+ |
| 160 | | FLASH_AREA_0 | | Secure image | FLASH_AREA_0 | | Secure + Non-secure image | |
| 161 | | | | primary slot | | | primary slot | |
| 162 | +-----------------------+--------------------+-----------------------+ + |
| 163 | | FLASH_AREA_1 | | Non-secure image | | | |
| 164 | | | | primary slot | | | |
| 165 | +-----------------------+--------------------+-----------------------+-----------------------------+ |
| 166 | | FLASH_AREA_2 | | Secure image | FLASH_AREA_2 | | Secure + Non-secure image | |
| 167 | | | | secondary slot | | | secondary slot | |
| 168 | +-----------------------+--------------------+-----------------------+ + |
| 169 | | FLASH_AREA_3 | | Non-secure image | | | |
| 170 | | | | secondary slot | | | |
| 171 | +-----------------------+--------------------+-----------------------+-----------------------------+ |
| 172 | | FLASH_AREA_SCRATCH | Scratch area | FLASH_AREA_SCRATCH | Scratch area | |
| 173 | +-----------------------+--------------------+-----------------------+-----------------------------+ |
| 174 | |
Raef Coles | a495259 | 2019-10-01 11:43:18 +0100 | [diff] [blame] | 175 | - ``IMAGE_EXECUTABLE_RAM_START`` - Defines the start of the region to which |
| 176 | images are allowed to be loaded. Only used if ``MCUBOOT_UPGRADE_STRATEGY`` is |
| 177 | configured to be ``RAM_LOADING``. |
| 178 | |
| 179 | - ``IMAGE_EXECUTABLE_RAM_SIZE`` - Defines the size of the region to which images |
| 180 | are allowed to be loaded. Only used if ``MCUBOOT_UPGRADE_STRATEGY`` is |
| 181 | configured to be ``RAM_LOADING``. |
| 182 | |
Gyorgy Szing | db9783c | 2019-04-17 21:08:48 +0200 | [diff] [blame] | 183 | Assemble tool |
| 184 | ^^^^^^^^^^^^^ |
Sverteczky, Marcell | 79ae915 | 2019-06-06 15:00:11 +0200 | [diff] [blame] | 185 | The ``assemble.py`` tool is used to concatenate secure and non-secure binary |
Gyorgy Szing | db9783c | 2019-04-17 21:08:48 +0200 | [diff] [blame] | 186 | to a single binary blob. It requires the following definitions: |
| 187 | |
| 188 | - ``SECURE_IMAGE_OFFSET`` - Defines the offset from the single binary blob base |
| 189 | address, where the secure image starts. |
| 190 | - ``SECURE_IMAGE_MAX_SIZE`` - Defines the maximum size of the secure image area. |
| 191 | - ``NON_SECURE_IMAGE_OFFSET`` - Defines the offset from the single binary blob |
| 192 | base address, where the non-secure image starts. |
| 193 | - ``NON_SECURE_IMAGE_MAX_SIZE`` - Defines the maximum size of the non-secure |
| 194 | image area. |
| 195 | |
Sverteczky, Marcell | 79ae915 | 2019-06-06 15:00:11 +0200 | [diff] [blame] | 196 | Image tool |
| 197 | ^^^^^^^^^^^^^ |
| 198 | The ``imgtool.py`` tool is used to handle the tasks related to signing the |
David Vincze | d8fbe0e | 2019-08-12 15:58:57 +0200 | [diff] [blame] | 199 | binary. It requires the following definition: |
Sverteczky, Marcell | 79ae915 | 2019-06-06 15:00:11 +0200 | [diff] [blame] | 200 | |
Raef Coles | a495259 | 2019-10-01 11:43:18 +0100 | [diff] [blame] | 201 | - ``IMAGE_LOAD_ADDRESS`` - Defines the address to where the image is loaded and |
| 202 | is executed from. Only used if ``MCUBOOT_UPGRADE_STRATEGY`` is configured to |
| 203 | be ``RAM_LOADING``. |
Sverteczky, Marcell | 79ae915 | 2019-06-06 15:00:11 +0200 | [diff] [blame] | 204 | |
Gyorgy Szing | db9783c | 2019-04-17 21:08:48 +0200 | [diff] [blame] | 205 | Secure Storage (SST) Service definitions |
| 206 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 207 | The SST service requires the following definitions: |
| 208 | |
| 209 | - ``SST_FLASH_AREA_ADDR`` - Defines the flash area address where the secure |
| 210 | store area starts. |
Vikas Katariya | 7d74ddb | 2019-09-19 11:59:57 +0100 | [diff] [blame] | 211 | - ``SST_FLASH_AREA_SIZE`` - Defines the size of the dedicated flash area |
| 212 | for secure storage. |
TudorCretu | ba8a3fa | 2019-07-22 10:05:12 +0100 | [diff] [blame] | 213 | - ``SST_SECTOR_SIZE`` - Defines the size of the external flash sectors. |
Vikas Katariya | 7d74ddb | 2019-09-19 11:59:57 +0100 | [diff] [blame] | 214 | - ``SST_SECTORS_PER_BLOCK`` - Defines the number of contiguous SST_SECTOR_SIZE |
| 215 | to form an SST_BLOCK_SIZE. |
Gyorgy Szing | db9783c | 2019-04-17 21:08:48 +0200 | [diff] [blame] | 216 | - ``SST_FLASH_DEV_NAME`` - Specifies the flash device used by SST to store the |
| 217 | data. |
| 218 | - ``SST_FLASH_PROGRAM_UNIT`` - Defines the smallest flash programmable unit in |
| 219 | bytes. |
| 220 | - ``SST_MAX_ASSET_SIZE`` - Defines the maximum asset size to be stored in the |
| 221 | SST area. |
| 222 | - ``SST_NUM_ASSETS`` - Defines the maximum number of assets to be stored in the |
| 223 | SST area. |
| 224 | |
| 225 | .. Note:: |
| 226 | |
| 227 | The sectors must be consecutive. |
| 228 | |
TudorCretu | ba8a3fa | 2019-07-22 10:05:12 +0100 | [diff] [blame] | 229 | Internal Trusted Storage (ITS) Service definitions |
| 230 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 231 | The ITS service requires the following definitions: |
| 232 | |
| 233 | - ``ITS_FLASH_AREA_ADDR`` - Defines the flash area address where the internal |
| 234 | trusted storage area starts. |
David Hu | 74977d2 | 2019-10-22 10:26:03 +0800 | [diff] [blame] | 235 | - ``ITS_FLASH_AREA_SIZE`` - Defines the size of the dedicated flash area for the |
| 236 | internal trusted storage. |
TudorCretu | ba8a3fa | 2019-07-22 10:05:12 +0100 | [diff] [blame] | 237 | - ``ITS_SECTOR_SIZE`` - Defines the size of the internal flash sectors. |
David Hu | 74977d2 | 2019-10-22 10:26:03 +0800 | [diff] [blame] | 238 | - ``ITS_SECTORS_PER_BLOCK`` - Defines the number of contiguous ITS_SECTOR_SIZE |
| 239 | to form an ITS_BLOCK_SIZE. |
TudorCretu | ba8a3fa | 2019-07-22 10:05:12 +0100 | [diff] [blame] | 240 | - ``ITS_FLASH_DEV_NAME`` - Specifies the internal flash device used by ITS to |
| 241 | store the data. |
| 242 | - ``ITS_FLASH_PROGRAM_UNIT`` - Defines the smallest flash programmable unit in |
| 243 | bytes. |
| 244 | - ``ITS_MAX_ASSET_SIZE`` - Defines the maximum asset size to be stored in the |
| 245 | ITS area. |
| 246 | - ``ITS_NUM_ASSETS`` - Defines the maximum number of assets to be stored in the |
| 247 | ITS area. |
| 248 | |
| 249 | .. Note:: |
| 250 | |
| 251 | The sectors must be consecutive. |
| 252 | |
Gyorgy Szing | db9783c | 2019-04-17 21:08:48 +0200 | [diff] [blame] | 253 | *************************************** |
| 254 | Expose target support for HW components |
| 255 | *************************************** |
| 256 | Services may require HW components to be supported by the target to enable some |
| 257 | features (e.g. SST service with rollback protection, etc). The following |
| 258 | definitions need to be set in the .cmake file if the target has the following |
| 259 | HW components: |
| 260 | |
| 261 | - ``TARGET_NV_COUNTERS_ENABLE`` - Specifies that the target has non-volatile |
| 262 | (NV) counters. |
| 263 | |
| 264 | -------------- |
| 265 | |
| 266 | *Copyright (c) 2017-2019, Arm Limited. All rights reserved.* |