OrgZephyr/mcuboot
OrgZephyr
/
mcuboot
mirror of https://github.com/zephyrproject-rtos/mcuboot.git
1
0
Fork 0
Code Issues Releases Wiki Activity

Fix review issues

This commit is contained in:
Fabio Utzig 2017-06-28 19:33:33 -03:00 committed by David Brown
parent 01ccb1997e
commit e2d99f8630
1 changed files with 7 additions and 20 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
doc/PORTING.md
View File

@ -6,30 +6,17 @@ This document describes the requirements and necessary steps required to port
# Requirements
* `mcuboot` requires that the target provides a `flash` API with ability to
get flash alignment and read/write/erase individual sectors.
get the flash's minimum write size, and read/write/erase individual sectors.
* `mcuboot` doesn't bundle a cryptographic library, which means the target
OS must already have it bundled. The supported libraries at the moment are
`tinycrypt` and `mbed TLS`.
either `mbed TLS` or the set `tinycrypt` + `mbed TLS` (where `mbed TLS` is
used to provide functionality not existing in `tinycrypt`).
* TODO: what more?
# Steps to port
## Configuration options macro
Configuration options are checked with the macro `MYNEWT_VAL(x)` where `x`
is the configuration to get the value for. This enables support for OSes with
configuration systems that don't take the `#define ...` format. If the target
OS uses `#define ...` one can simply use the following definition:
```c
#define MYNEWT_VAL(x) (x)
```
If your system uses another method, like build config files, a proper façade
must be defined.
## Main app and calling the bootloader
From the perspective of the target OS, the bootloader can be seen as a library,
@ -67,16 +54,16 @@ where the target firmware is located which can be used to jump to.
### hal_flash_align
`mcuboot` needs to know the alignment of the flash. To get this information it
calls `hal_flash_align`.
`mcuboot` needs to know the write size (and alignment) of the flash. To get
this information it calls `hal_flash_align`.
TODO: this needs to die and move to flash_map...
### flash_map
The bootloader requires a `flash_map` to be able to know how the flash is
"partitioned". A `flash_map` consists of `struct flash_area` entries
specifying the "partitions", where a `flash_area` defined as follows:
partitioned. A `flash_map` consists of `struct flash_area` entries
specifying the partitions, where a `flash_area` defined as follows:
```c
struct flash_area {