blob: c5a97f6d704489c4123efb3c1be5716dbaa416a9 [file] [log] [blame]
Gyorgy Szingdb9783c2019-04-17 21:08:48 +02001###################################
2Details for the platform/ext folder
3###################################
4This folder has code that has been imported from other projects. This means the
5files in this folder and subfolders have Apache 2.0 license which is different
6to 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***********
13Sub-folders
14***********
15
16cmsis
17=====
18This folder contains core and compiler specific header files imported from the
19``CMSIS_5`` project.
20
21common
22======
Raef Colesa657a9c2019-10-24 14:36:43 +010023
24armclang and gcc
25----------------
26These contain the linker scripts used to configure the memory regions in TF-M
27regions.
28
29cc312
30-----
31This folder contains cmake and code files to interact with the CC312
32cryptographic accelerator. Integrating a platform with the CC312 requires some
33configuration, of which an example can be seen in the
34``platform/ext/musca_b1.cmake`` file.
35
36To 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 Foxc3202282019-12-13 17:12:16 +000063template
64--------
65This directory contains platform-independent dummy implementations of the
66interfaces in ``platform/include``. These implementations can be built directly
67for initial testing of a platform port, or used as a basic template for a real
68implementation for a particular target. They **must not** be used in production
69systems.
70
Raef Colesa657a9c2019-10-24 14:36:43 +010071other
72-----
Jamie Foxc3202282019-12-13 17:12:16 +000073This folder also contains stdout redirection to UART and
74``tfm_mbedcrypto_config.h`` for all the targets.
Gyorgy Szingdb9783c2019-04-17 21:08:48 +020075
76drivers
77=======
78This folder contains the headers with CMSIS compliant driver definitions that
79that TF-M project expects a target to provide.
80
81target_cfg.h
82------------
83This 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
92target
93======
94This folder contains the files for individual target.
95
96Flash layout header file
97------------------------
98Target must provide a header file, called ``flash_layout.h``, which defines the
99information explained in the follow subsections. The defines must be named
100as they are in the subsections.
101
102BL2 bootloader
103^^^^^^^^^^^^^^
104The 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 Vinczebb207982019-08-21 15:13:04 +0200110- ``FLASH_AREA_SCRATCH_OFFSET`` - Defines the offset from the flash base
Gyorgy Szingdb9783c2019-04-17 21:08:48 +0200111 address where the scratch area starts, which is used during image swapping.
David Vinczebb207982019-08-21 15:13:04 +0200112- ``FLASH_AREA_SCRATCH_SIZE`` - Defines the size of the scratch area. The
Gyorgy Szingdb9783c2019-04-17 21:08:48 +0200113 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 Vinczebb207982019-08-21 15:13:04 +0200116The BL2 requires further definitions depending on the number of images, the
117meaning 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
152The table below shows a fraction of the flash layout in case of 2 and 1
153updatable 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 Colesa4952592019-10-01 11:43:18 +0100175- ``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 Szingdb9783c2019-04-17 21:08:48 +0200183Assemble tool
184^^^^^^^^^^^^^
Sverteczky, Marcell79ae9152019-06-06 15:00:11 +0200185The ``assemble.py`` tool is used to concatenate secure and non-secure binary
Gyorgy Szingdb9783c2019-04-17 21:08:48 +0200186to 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, Marcell79ae9152019-06-06 15:00:11 +0200196Image tool
197^^^^^^^^^^^^^
198The ``imgtool.py`` tool is used to handle the tasks related to signing the
David Vinczed8fbe0e2019-08-12 15:58:57 +0200199binary. It requires the following definition:
Sverteczky, Marcell79ae9152019-06-06 15:00:11 +0200200
Raef Colesa4952592019-10-01 11:43:18 +0100201- ``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, Marcell79ae9152019-06-06 15:00:11 +0200204
Gyorgy Szingdb9783c2019-04-17 21:08:48 +0200205Secure Storage (SST) Service definitions
206^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
207The 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 Katariya7d74ddb2019-09-19 11:59:57 +0100211- ``SST_FLASH_AREA_SIZE`` - Defines the size of the dedicated flash area
212 for secure storage.
TudorCretuba8a3fa2019-07-22 10:05:12 +0100213- ``SST_SECTOR_SIZE`` - Defines the size of the external flash sectors.
Vikas Katariya7d74ddb2019-09-19 11:59:57 +0100214- ``SST_SECTORS_PER_BLOCK`` - Defines the number of contiguous SST_SECTOR_SIZE
215 to form an SST_BLOCK_SIZE.
Gyorgy Szingdb9783c2019-04-17 21:08:48 +0200216- ``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
TudorCretuba8a3fa2019-07-22 10:05:12 +0100229Internal Trusted Storage (ITS) Service definitions
230^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
231The 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 Hu74977d22019-10-22 10:26:03 +0800235- ``ITS_FLASH_AREA_SIZE`` - Defines the size of the dedicated flash area for the
236 internal trusted storage.
TudorCretuba8a3fa2019-07-22 10:05:12 +0100237- ``ITS_SECTOR_SIZE`` - Defines the size of the internal flash sectors.
David Hu74977d22019-10-22 10:26:03 +0800238- ``ITS_SECTORS_PER_BLOCK`` - Defines the number of contiguous ITS_SECTOR_SIZE
239 to form an ITS_BLOCK_SIZE.
TudorCretuba8a3fa2019-07-22 10:05:12 +0100240- ``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 Szingdb9783c2019-04-17 21:08:48 +0200253***************************************
254Expose target support for HW components
255***************************************
256Services may require HW components to be supported by the target to enable some
257features (e.g. SST service with rollback protection, etc). The following
258definitions need to be set in the .cmake file if the target has the following
259HW 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.*