commit | d82afbfaa839f2d4b86b883fc570f4955a9bec0e | [log] [tgz] |
---|---|---|
author | George Beckstein <becksteing@embeddedplanet.com> | Thu Oct 29 17:32:11 2020 -0400 |
committer | Fabio Utzig <utzig@utzig.org> | Tue Nov 03 19:16:46 2020 -0300 |
tree | 23996ffee54e2463760cc713a87171db6f3dbb61 | |
parent | ea30ef3ca7f6e96cc8c99bfa83a012323003cee5 [diff] |
Mbed-OS porting layer implementation for mcuboot This PR provides a porting layer implementation and framework for building an mcuboot-based bootloader with Mbed-OS. Some symbols are not provided by the Mbed-OS port within mcuboot, namely: - The secondary storage device (see below) - The signing keys - The encryption keys, if used Use of this port is demonstrated by the following projects: - https://github.com/AGlass0fMilk/mbed-mcuboot-demo (a complete mcuboot/Mbed-OS-based bootloader) - https://github.com/AGlass0fMilk/mbed-mcuboot-blinky (example showing how to make an Mbed-OS application that is bootable by mcuboot) Memory porting implementation: The underlying implemenation uses Mbed's BlockDevice API as the storage backend for mcuboot's memory operations. This provides a very flexible way of configuring the location and layout of the secondary flash storage area. To build an mcuboot-based bootloader with Mbed-OS, the user must implement a hook function, mbed::BlockDevice* get_secondary_bd(), to provide the secondary BlockDevice that mcuboot will use. The signing and encryption keys must also be provided by the user. They can be generated using the existing imgtool utility in the same manner used by Zephyr. There are no automated build steps currently provided by Mbed-OS to sign/encrypt build artifacts. Known limitations: The update candidate encryption features have not yet been fully tested. A truly secure implementation will require integration with Mbed's TRNG API in the future to inhibit side-channel attacks on the decryption process. The TinyCrypt backend is currently only supported for Mbed-OS builds when building with the GCC toolchain. The new cmake-based Mbed-OS build system will fix the underlying issue (file name uniqueness). Signed-off-by: George Beckstein <becksteing@embeddedplanet.com> Signed-off-by: Evelyne Donnaes <evelyne.donnaes@arm.com> Signed-off-by: Lingkai Dong <lingkai.dong@arm.com> Co-authored-by: Lingkai Dong <lingkai.dong@arm.com> Co-authored-by: Fabio Utzig <fabio.utzig@nordicsemi.no>
This is mcuboot version 1.7.0-rc1
MCUboot is a secure bootloader for 32-bit MCUs. The goal of MCUboot is to define a common infrastructure for the bootloader, system flash layout on microcontroller systems, and to provide a secure bootloader that enables simple software upgrades.
MCUboot is operating system and hardware independent and relies on hardware porting layers from the operating. Currently, mcuboot works with both the Apache Mynewt and Zephyr operating systems, but more ports are planned in the future. RIOT is currently supported as a boot target with a complete port planned.
Instructions for different operating systems can be found here:
The issues being planned and worked on are tracked using GitHub issues. To participate please visit:
Issues were previously tracked on MCUboot JIRA , but it is now deprecated.
Information and documentation on the bootloader are stored within the source.
It was previously also documented on confluence: MCUBoot Confluence however, it is now deprecated and not currently maintained
For more information in the source, here are some pointers:
Developers welcome!