Fabio Utzig | 01ccb19 | 2017-05-08 09:17:50 -0300 | [diff] [blame] | 1 | # Porting How-To |
| 2 | |
| 3 | This document describes the requirements and necessary steps required to port |
| 4 | `mcuboot` to a new target `OS`. |
| 5 | |
| 6 | # Requirements |
| 7 | |
Marti Bolivar | f91bca5 | 2018-04-12 12:40:46 -0400 | [diff] [blame] | 8 | * `mcuboot` requires a configuration file, which can be included as |
| 9 | mcuboot_config/mcuboot_config.h, which configures various options |
| 10 | (that begin with MCUBOOT_). |
| 11 | |
Fabio Utzig | 01ccb19 | 2017-05-08 09:17:50 -0300 | [diff] [blame] | 12 | * `mcuboot` requires that the target provides a `flash` API with ability to |
Fabio Utzig | e2d99f8 | 2017-06-28 19:33:33 -0300 | [diff] [blame] | 13 | get the flash's minimum write size, and read/write/erase individual sectors. |
Fabio Utzig | 01ccb19 | 2017-05-08 09:17:50 -0300 | [diff] [blame] | 14 | |
| 15 | * `mcuboot` doesn't bundle a cryptographic library, which means the target |
| 16 | OS must already have it bundled. The supported libraries at the moment are |
Fabio Utzig | e2d99f8 | 2017-06-28 19:33:33 -0300 | [diff] [blame] | 17 | either `mbed TLS` or the set `tinycrypt` + `mbed TLS` (where `mbed TLS` is |
| 18 | used to provide functionality not existing in `tinycrypt`). |
Fabio Utzig | 01ccb19 | 2017-05-08 09:17:50 -0300 | [diff] [blame] | 19 | |
Fabio Utzig | 01ccb19 | 2017-05-08 09:17:50 -0300 | [diff] [blame] | 20 | # Steps to port |
| 21 | |
Fabio Utzig | 01ccb19 | 2017-05-08 09:17:50 -0300 | [diff] [blame] | 22 | ## Main app and calling the bootloader |
| 23 | |
| 24 | From the perspective of the target OS, the bootloader can be seen as a library, |
| 25 | so an entry point must be provided. This is likely a typical `app` for the |
| 26 | target OS, and it must call the following function to run the bootloader: |
| 27 | |
| 28 | ```c |
| 29 | int boot_go(struct boot_rsp *rsp); |
| 30 | ``` |
| 31 | |
| 32 | This function is located at `boot/bootutil/loader.c` and receives a `struct |
| 33 | boot_rsp` pointer. The `struct boot_rsp` is defined as: |
| 34 | |
| 35 | ```c |
| 36 | struct boot_rsp { |
| 37 | /** A pointer to the header of the image to be executed. */ |
| 38 | const struct image_header *br_hdr; |
| 39 | |
| 40 | /** |
| 41 | * The flash offset of the image to execute. Indicates the position of |
| 42 | * the image header. |
| 43 | */ |
| 44 | uint8_t br_flash_id; |
| 45 | uint32_t br_image_addr; |
| 46 | }; |
| 47 | ``` |
| 48 | |
| 49 | After running the management functions of the bootloader, `boot_go` returns |
| 50 | an initialized `boot_rsp` which has pointers to the location of the image |
| 51 | where the target firmware is located which can be used to jump to. |
| 52 | |
Marti Bolivar | f91bca5 | 2018-04-12 12:40:46 -0400 | [diff] [blame] | 53 | ## Configuration file |
| 54 | |
| 55 | You must provide a file, mcuboot_config/mcuboot_config.h. This is |
| 56 | included by several files in the "library" portion of MCUboot; it |
| 57 | provides preprocessor definitions that configure the library's |
| 58 | build. |
| 59 | |
| 60 | See the file samples/mcuboot_config/mcuboot_config.template.h for a |
| 61 | starting point and more information. This is a good place to convert |
| 62 | settings in your environment's configuration system to those required |
| 63 | by MCUboot. For example, Mynewt uses MYNEWT_VAL() and Zephyr uses |
| 64 | Kconfig; these configuration systems are converted to MCUBOOT_ options |
| 65 | in the following files: |
| 66 | |
| 67 | - boot/zephyr/include/mcuboot_config/mcuboot_config.h |
| 68 | - boot/mynewt/mcuboot_config/include/mcuboot_config/mcuboot_config.h |
| 69 | |
Fabio Utzig | 6f9c795 | 2018-07-19 07:53:20 -0300 | [diff] [blame^] | 70 | ## Flash Map |
Fabio Utzig | 01ccb19 | 2017-05-08 09:17:50 -0300 | [diff] [blame] | 71 | |
| 72 | The bootloader requires a `flash_map` to be able to know how the flash is |
Fabio Utzig | e2d99f8 | 2017-06-28 19:33:33 -0300 | [diff] [blame] | 73 | partitioned. A `flash_map` consists of `struct flash_area` entries |
| 74 | specifying the partitions, where a `flash_area` defined as follows: |
Fabio Utzig | 01ccb19 | 2017-05-08 09:17:50 -0300 | [diff] [blame] | 75 | |
| 76 | ```c |
| 77 | struct flash_area { |
| 78 | uint8_t fa_id; /** The slot/scratch identification */ |
| 79 | uint8_t fa_device_id; /** The device id (usually there's only one) */ |
| 80 | uint16_t pad16; |
| 81 | uint32_t fa_off; /** The flash offset from the beginning */ |
| 82 | uint32_t fa_size; /** The size of this sector */ |
| 83 | }; |
| 84 | ``` |
| 85 | |
| 86 | `fa_id` is can be one of the following options: |
| 87 | |
| 88 | ```c |
| 89 | #define FLASH_AREA_IMAGE_0 1 |
| 90 | #define FLASH_AREA_IMAGE_1 2 |
| 91 | #define FLASH_AREA_IMAGE_SCRATCH 3 |
| 92 | ``` |
| 93 | |
| 94 | The functions that must be defined for working with the `flash_area`s are: |
| 95 | |
| 96 | ```c |
| 97 | /*< Opens the area for use. id is one of the `fa_id`s */ |
| 98 | int flash_area_open(uint8_t id, const struct flash_area **); |
| 99 | void flash_area_close(const struct flash_area *); |
| 100 | /*< Reads `len` bytes of flash memory at `off` to the buffer at `dst` */ |
| 101 | int flash_area_read(const struct flash_area *, uint32_t off, void *dst, |
| 102 | uint32_t len); |
| 103 | /*< Writes `len` bytes of flash memory at `off` from the buffer at `src` */ |
| 104 | int flash_area_write(const struct flash_area *, uint32_t off, |
| 105 | const void *src, uint32_t len); |
| 106 | /*< Erases `len` bytes of flash memory at `off` */ |
| 107 | int flash_area_erase(const struct flash_area *, uint32_t off, uint32_t len); |
| 108 | /*< Returns this `flash_area`s alignment */ |
| 109 | uint8_t flash_area_align(const struct flash_area *); |
Fabio Utzig | 41d1885 | 2017-07-10 15:27:00 -0300 | [diff] [blame] | 110 | /*< Initializes an array of flash_area elements for the slot's sectors */ |
Fabio Utzig | 01ccb19 | 2017-05-08 09:17:50 -0300 | [diff] [blame] | 111 | int flash_area_to_sectors(int idx, int *cnt, struct flash_area *ret); |
| 112 | /*< Returns the `fa_id` for slot, where slot is 0 or 1 */ |
| 113 | int flash_area_id_from_image_slot(int slot); |
| 114 | /*< Returns the slot, for the `fa_id` supplied */ |
| 115 | int flash_area_id_to_image_slot(int area_id); |
| 116 | ``` |
| 117 | |
| 118 | ## Memory management for mbed TLS |
| 119 | |
| 120 | `mbed TLS` employs dynamic allocation of memory, making use of the pair |
| 121 | `calloc/free`. If `mbed TLS` is to be used for crypto, your target RTOS |
| 122 | needs to provide this pair of function. |
| 123 | |
| 124 | To configure the what functions are called when allocating/deallocating |
| 125 | memory `mbed TLS` uses the following call [^cite1]: |
| 126 | |
| 127 | ``` |
| 128 | int mbedtls_platform_set_calloc_free (void *(*calloc_func)(size_t, size_t), |
| 129 | void (*free_func)(void *)); |
| 130 | ``` |
| 131 | |
| 132 | If your system already provides functions with compatible signatures, those |
| 133 | can be used directly here, otherwise create new functions that glue to |
| 134 | your `calloc/free` implementations. |
| 135 | |
| 136 | [^cite1]```https://tls.mbed.org/api/platform_8h.html``` |