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 | ====== |
| 23 | This folder contains stdout redirection to UART, a temporary memory mapped flash |
| 24 | implementation for the bootloader and tfm\_mbedtls\_config.h for all the |
| 25 | targets. |
| 26 | |
| 27 | drivers |
| 28 | ======= |
| 29 | This folder contains the headers with CMSIS compliant driver definitions that |
| 30 | that TF-M project expects a target to provide. |
| 31 | |
| 32 | target_cfg.h |
| 33 | ------------ |
| 34 | This 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 | |
| 43 | target |
| 44 | ====== |
| 45 | This folder contains the files for individual target. |
| 46 | |
| 47 | Flash layout header file |
| 48 | ------------------------ |
| 49 | Target must provide a header file, called ``flash_layout.h``, which defines the |
| 50 | information explained in the follow subsections. The defines must be named |
| 51 | as they are in the subsections. |
| 52 | |
| 53 | BL2 bootloader |
| 54 | ^^^^^^^^^^^^^^ |
| 55 | The 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 | |
| 73 | Assemble tool |
| 74 | ^^^^^^^^^^^^^ |
Sverteczky, Marcell | 79ae915 | 2019-06-06 15:00:11 +0200 | [diff] [blame^] | 75 | 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] | 76 | to 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, Marcell | 79ae915 | 2019-06-06 15:00:11 +0200 | [diff] [blame^] | 86 | Image tool |
| 87 | ^^^^^^^^^^^^^ |
| 88 | The ``imgtool.py`` tool is used to handle the tasks related to signing the |
| 89 | binary. 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 Szing | db9783c | 2019-04-17 21:08:48 +0200 | [diff] [blame] | 97 | Secure Storage (SST) Service definitions |
| 98 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 99 | The 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 | *************************************** |
| 120 | Expose target support for HW components |
| 121 | *************************************** |
| 122 | Services may require HW components to be supported by the target to enable some |
| 123 | features (e.g. SST service with rollback protection, etc). The following |
| 124 | definitions need to be set in the .cmake file if the target has the following |
| 125 | HW 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.* |