blob: 52a8217b659e55cd907ba1bae046e7ea73b2adf7 [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.
David Vincze8bdfc2d2019-03-18 15:49:23 +010061- ``FLASH_AREA_IMAGE_PRIMARY_OFFSET`` - Defines the offset from the flash base
62 address where the primary image area starts, which hosts the active firmware
63 image.
64- ``FLASH_AREA_IMAGE_PRIMARY_SIZE`` - Defines the size of the primary image
65 area.
66- ``FLASH_AREA_IMAGE_SECONDARY_OFFSET`` - Defines the offset from the flash base
67 address where the secondary image area starts, which is a placeholder for new
68 firmware images.
69- ``FLASH_AREA_IMAGE_SECONDARY_SIZE`` - Defines the size of the secondary image
70 area.
Gyorgy Szingdb9783c2019-04-17 21:08:48 +020071- ``FLASH_AREA_IMAGE_SCRATCH_OFFSET`` - Defines the offset from the flash base
72 address where the scratch area starts, which is used during image swapping.
73- ``FLASH_AREA_IMAGE_SCRATCH_SIZE`` - Defines the size of the scratch area. The
74 minimal size must be as the biggest sector size in the flash.
75- ``FLASH_DEV_NAME`` - Specifies the flash device used by BL2.
76
77Assemble tool
78^^^^^^^^^^^^^
Sverteczky, Marcell79ae9152019-06-06 15:00:11 +020079The ``assemble.py`` tool is used to concatenate secure and non-secure binary
Gyorgy Szingdb9783c2019-04-17 21:08:48 +020080to a single binary blob. It requires the following definitions:
81
82- ``SECURE_IMAGE_OFFSET`` - Defines the offset from the single binary blob base
83 address, where the secure image starts.
84- ``SECURE_IMAGE_MAX_SIZE`` - Defines the maximum size of the secure image area.
85- ``NON_SECURE_IMAGE_OFFSET`` - Defines the offset from the single binary blob
86 base address, where the non-secure image starts.
87- ``NON_SECURE_IMAGE_MAX_SIZE`` - Defines the maximum size of the non-secure
88 image area.
89
Sverteczky, Marcell79ae9152019-06-06 15:00:11 +020090Image tool
91^^^^^^^^^^^^^
92The ``imgtool.py`` tool is used to handle the tasks related to signing the
93binary. It requires the following definitions:
94
95- ``SIGN_BIN_SIZE`` - Defines the size of the concatenated binary that is to
96 be signed.
97- ``IMAGE_LOAD_ADDRESS`` - Defines the address to where the image is loaded
98 and is executed from. Only used in case the ``MCUBOOT_UPGRADE_STRATEGY``
99 is configured to be ``RAM_LOADING``.
100
Gyorgy Szingdb9783c2019-04-17 21:08:48 +0200101Secure Storage (SST) Service definitions
102^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
103The SST service requires the following definitions:
104
105- ``SST_FLASH_AREA_ADDR`` - Defines the flash area address where the secure
106 store area starts.
107- ``SST_SECTOR_SIZE`` - Defines the size of the flash sectors.
108- ``SST_NBR_OF_SECTORS`` - Defines the number of sectors available for the
109 secure area.
110- ``SST_FLASH_DEV_NAME`` - Specifies the flash device used by SST to store the
111 data.
112- ``SST_FLASH_PROGRAM_UNIT`` - Defines the smallest flash programmable unit in
113 bytes.
114- ``SST_MAX_ASSET_SIZE`` - Defines the maximum asset size to be stored in the
115 SST area.
116- ``SST_NUM_ASSETS`` - Defines the maximum number of assets to be stored in the
117 SST area.
118
119.. Note::
120
121 The sectors must be consecutive.
122
123***************************************
124Expose target support for HW components
125***************************************
126Services may require HW components to be supported by the target to enable some
127features (e.g. SST service with rollback protection, etc). The following
128definitions need to be set in the .cmake file if the target has the following
129HW components:
130
131- ``TARGET_NV_COUNTERS_ENABLE`` - Specifies that the target has non-volatile
132 (NV) counters.
133
134--------------
135
136*Copyright (c) 2017-2019, Arm Limited. All rights reserved.*