Lines Matching refs:to
1 # Porting how-to
3 This document describes the requirements and necessary steps required to port
4 `MCUboot` to a new target `OS`.
12 * `MCUboot` requires that the target provides a `flash` API with ability to
18 used to provide functionality not existing in `tinycrypt`).
20 # Steps to port
26 target OS, and it must call the following function to run the bootloader:
37 /** A pointer to the header of the image to be executed. */
41 * The flash offset of the image to execute. Indicates the position of
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.
61 starting point and more information. This is a good place to convert
62 settings in your environment's configuration system to those required
64 Kconfig; these configuration systems are converted to MCUBOOT_ options
72 The bootloader requires to be able to address flash regions where the code
80 `flash_area_` API to perform any actions on that object.
81 This way systems are free to implement internal logic of flash map or define
83 uniquely tied to region characterized by device, offset and size.
85 Changes to common MCUboot code should not affect system specific internals
101 by MCUboot, although the MCUboot will not be trying to access them directly,
102 instead a system is required to provide following mandatory getter functions:
118 specific header files and are used to identify destination of flash area by ID:
146 /*< Reads `len` bytes of flash memory at `off` to the buffer at `dst` */
174 …to `flash_area_open`). As a result, MCUboot may call `flash_area_close` on a flash area that is st…
181 `calloc/free`. If `Mbed TLS` is to be used for crypto, your target RTOS
182 needs to provide this pair of function.
194 be used directly here, otherwise create new functions that glue to your