blob: f6816c8a5476b8d529d93894abc22648e83bbe38 [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======
23This folder contains stdout redirection to UART, a temporary memory mapped flash
24implementation for the bootloader and tfm\_mbedtls\_config.h for all the
25targets.
26
27drivers
28=======
29This folder contains the headers with CMSIS compliant driver definitions that
30that TF-M project expects a target to provide.
31
32target_cfg.h
33------------
34This file is expected to define the following macros respectively.
35
36- ``TFM_DRIVER_STDIO`` - This macro should expand to a structure of type
37 ``ARM_DRIVER_USART``. TFM redirects its standard input and output to this
38 instance of USART.
39- ``NS_DRIVER_STDIO`` - This macro should expand to a structure of type
40 ``ARM_DRIVER_USART``. Non-Secure application redirects its standard input and
41 output to this instance of USART.
42
43target
44======
45This folder contains the files for individual target.
46
47Flash layout header file
48------------------------
49Target must provide a header file, called ``flash_layout.h``, which defines the
50information explained in the follow subsections. The defines must be named
51as they are in the subsections.
52
53BL2 bootloader
54^^^^^^^^^^^^^^
55The BL2 bootloader requires the following definitions:
56
57- ``FLASH_BASE_ADDRESS`` - Defines the first valid address in the flash.
58- ``FLASH_AREA_BL2_OFFSET`` - Defines the offset from the flash base address
59 where the BL2 - MCUBOOT area starts.
60- ``FLASH_AREA_BL2_SIZE`` - Defines the size of the BL2 area.
61- ``FLASH_AREA_IMAGE_0_OFFSET`` - Defines the offset from the flash base address
62 where the image 0 area starts, which hosts the active firmware image.
63- ``FLASH_AREA_IMAGE_0_SIZE`` - Defines the size of the image 0 area.
64- ``FLASH_AREA_IMAGE_1_OFFSET`` - Defines the offset from the flash base address
65 where the image 1 area starts, which is a placeholder for new firmware images.
66- ``FLASH_AREA_IMAGE_1_SIZE`` - Defines the size of the image 1 area.
67- ``FLASH_AREA_IMAGE_SCRATCH_OFFSET`` - Defines the offset from the flash base
68 address where the scratch area starts, which is used during image swapping.
69- ``FLASH_AREA_IMAGE_SCRATCH_SIZE`` - Defines the size of the scratch area. The
70 minimal size must be as the biggest sector size in the flash.
71- ``FLASH_DEV_NAME`` - Specifies the flash device used by BL2.
72
73Assemble tool
74^^^^^^^^^^^^^
Sverteczky, Marcell79ae9152019-06-06 15:00:11 +020075The ``assemble.py`` tool is used to concatenate secure and non-secure binary
Gyorgy Szingdb9783c2019-04-17 21:08:48 +020076to a single binary blob. It requires the following definitions:
77
78- ``SECURE_IMAGE_OFFSET`` - Defines the offset from the single binary blob base
79 address, where the secure image starts.
80- ``SECURE_IMAGE_MAX_SIZE`` - Defines the maximum size of the secure image area.
81- ``NON_SECURE_IMAGE_OFFSET`` - Defines the offset from the single binary blob
82 base address, where the non-secure image starts.
83- ``NON_SECURE_IMAGE_MAX_SIZE`` - Defines the maximum size of the non-secure
84 image area.
85
Sverteczky, Marcell79ae9152019-06-06 15:00:11 +020086Image tool
87^^^^^^^^^^^^^
88The ``imgtool.py`` tool is used to handle the tasks related to signing the
89binary. It requires the following definitions:
90
91- ``SIGN_BIN_SIZE`` - Defines the size of the concatenated binary that is to
92 be signed.
93- ``IMAGE_LOAD_ADDRESS`` - Defines the address to where the image is loaded
94 and is executed from. Only used in case the ``MCUBOOT_UPGRADE_STRATEGY``
95 is configured to be ``RAM_LOADING``.
96
Gyorgy Szingdb9783c2019-04-17 21:08:48 +020097Secure Storage (SST) Service definitions
98^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
99The SST service requires the following definitions:
100
101- ``SST_FLASH_AREA_ADDR`` - Defines the flash area address where the secure
102 store area starts.
103- ``SST_SECTOR_SIZE`` - Defines the size of the flash sectors.
104- ``SST_NBR_OF_SECTORS`` - Defines the number of sectors available for the
105 secure area.
106- ``SST_FLASH_DEV_NAME`` - Specifies the flash device used by SST to store the
107 data.
108- ``SST_FLASH_PROGRAM_UNIT`` - Defines the smallest flash programmable unit in
109 bytes.
110- ``SST_MAX_ASSET_SIZE`` - Defines the maximum asset size to be stored in the
111 SST area.
112- ``SST_NUM_ASSETS`` - Defines the maximum number of assets to be stored in the
113 SST area.
114
115.. Note::
116
117 The sectors must be consecutive.
118
119***************************************
120Expose target support for HW components
121***************************************
122Services may require HW components to be supported by the target to enable some
123features (e.g. SST service with rollback protection, etc). The following
124definitions need to be set in the .cmake file if the target has the following
125HW components:
126
127- ``TARGET_NV_COUNTERS_ENABLE`` - Specifies that the target has non-volatile
128 (NV) counters.
129
130--------------
131
132*Copyright (c) 2017-2019, Arm Limited. All rights reserved.*