Commit 4ff0c186 authored by Francesco Servidio's avatar Francesco Servidio Committed by Fabio Utzig
Browse files

doc: Fixed consistency of MCUboot



Fixed the consistency of the case used in the term MCUboot.

Signed-off-by: default avatarFrancesco Servidio <francesco.servidio@nordicsemi.no>
parent 6138b4f7
# [mcuboot](http://mcuboot.com/)
# [MCUboot](http://mcuboot.com/)
[![Package on PyPI](https://img.shields.io/pypi/v/imgtool.svg)][pypi]
[![Coverity Scan Build Status](https://scan.coverity.com/projects/12307/badge.svg)][coverity]
......@@ -16,7 +16,7 @@
[travis]: https://travis-ci.org/mcu-tools/mcuboot
[license]: https://github.com/mcu-tools/mcuboot/blob/main/LICENSE
This is mcuboot version 1.8.0
This is MCUboot version 1.8.0
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
......@@ -24,7 +24,7 @@ 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
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.
......@@ -45,7 +45,7 @@ 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:
[MCUBoot GitHub Issues](https://github.com/mcu-tools/mcuboot/issues)
[MCUboot GitHub Issues](https://github.com/mcu-tools/mcuboot/issues)
~~Issues were previously tracked on [MCUboot JIRA](https://runtimeco.atlassian.net/projects/MCUB/summary)
, but it is now deprecated.~~
......@@ -55,7 +55,7 @@ participate please visit:
Information and documentation on the bootloader are stored within the source.
~~It was previously also documented on confluence:
[MCUBoot Confluence](https://runtimeco.atlassian.net/wiki/discover/all-updates)
[MCUboot Confluence](https://runtimeco.atlassian.net/wiki/discover/all-updates)
however, it is now deprecated and not currently maintained~~
For more information in the source, here are some pointers:
......@@ -66,7 +66,7 @@ For more information in the source, here are some pointers:
- [boot/mynewt](boot/mynewt): Mynewt bootloader app
- [boot/nuttx](boot/nuttx): Bootloader application and port of MCUboot interfaces for NuttX.
- [boot/espressif](boot/espressif): Bootloader application and MCUboot port for Espressif SoCs.
- [imgtool](scripts/imgtool.py): A tool to securely sign firmware images for booting by mcuboot.
- [imgtool](scripts/imgtool.py): A tool to securely sign firmware images for booting by MCUboot.
- [sim](sim): A bootloader simulator for testing and regression
## Joining
......
### Blinking LED test application for MCUBoot Bootloader
### Blinking LED test application for MCUboot Bootloader
### Description
Implements simple Blinky LED CM4 application to demonstrate MCUBoot Application operation in terms of BOOT and UPGRADE process.
Implements simple Blinky LED CM4 application to demonstrate MCUboot Application operation in terms of BOOT and UPGRADE process.
It is started by MCUBoot Application which is running on CM0p.
It is started by MCUboot Application which is running on CM0p.
Functionality:
......@@ -20,7 +20,7 @@ Currently supported platforms
### Hardware limitations
Since this application is created to demonstrate MCUBoot library features and not as reference examples some considerations are taken.
Since this application is created to demonstrate MCUboot library features and not as reference examples some considerations are taken.
1. Port/pin `P5_0` and `P5_1` used to configure serial port for debug prints. These pins are the most commonly used for serial port connection among available Cypress PSoC 6 kits. If you try to use custom hardware with this application - change definitions of `CY_DEBUG_UART_TX` and `CY_DEBUG_UART_RX` in `main.c` of BlinkyApp to port/pin pairs corresponding to your design.
2. Port `GPIO_PRT13` pin `7U` used to define user connection LED. This pin is the most commonly used for USER_LED connection among available Cypress PSoC 6 kits. If you try to use custom hardware with this application - change definitions of `LED_PORT` and `LED_PIN` in `main.c` of BlinkyApp to port/pin pairs corresponding to your design.
......@@ -111,7 +111,7 @@ This also suggests user already placed corresponing `*.pem` key in `\keys` folde
### Post-Build
Post build action is executed at compile time for `BlinkyApp`. In case of build for `PSOC_062_2M` platform it calls `imgtool` from `MCUBoot` scripts and adds signature to compiled image.
Post build action is executed at compile time for `BlinkyApp`. In case of build for `PSOC_062_2M` platform it calls `imgtool` from `MCUboot` scripts and adds signature to compiled image.
Flags passed to `imgtool` for signature are defined in `SIGN_ARGS` variable in BlinkyApp.mk.
......@@ -135,11 +135,11 @@ Files to use for programming are:
**Flags:**
- `BUILDCFG` - configuration **Release** or **Debug**
- `MAKEINFO` - 0 (default) - less build info, 1 - verbose output of compilation.
- `HEADER_OFFSET` - 0 (default) - no offset of output hex file, 0x%VALUE% - offset for output hex file. Value 0x10000 is slot size MCUBoot Bootloader in this example.
- `IMG_TYPE` - `BOOT` (default) - build image for BOOT slot of MCUBoot Bootloader, `UPGRADE` - build image for UPGRADE slot of MCUBoot Bootloader.
- `HEADER_OFFSET` - 0 (default) - no offset of output hex file, 0x%VALUE% - offset for output hex file. Value 0x10000 is slot size MCUboot Bootloader in this example.
- `IMG_TYPE` - `BOOT` (default) - build image for BOOT slot of MCUboot Bootloader, `UPGRADE` - build image for UPGRADE slot of MCUboot Bootloader.
- `ENC_IMG` - 0 (default) - build regular upgrade image, `1` - build encrypted upgrade image (MCUBootApp should also be built with this flash set 1)
**NOTE**: In case of `UPGRADE` image `HEADER_OFFSET` should be set to MCUBoot Bootloader slot size.
**NOTE**: In case of `UPGRADE` image `HEADER_OFFSET` should be set to MCUboot Bootloader slot size.
### Example terminal output
......
### Port of MCUBoot library to be used with Cypress targets
### Port of MCUboot library to be used with Cypress targets
**Solution Description**
Given solution demonstrates operation of MCUBoot on Cypress' PSoC6 device.
Given solution demonstrates operation of MCUboot on Cypress' PSoC6 device.
There are two applications implemented:
* MCUBootApp - PSoC6 MCUBoot-based bootloading application;
* MCUBootApp - PSoC6 MCUboot-based bootloading application;
* BlinkyApp - simple PSoC6 blinking LED application which is a target of BOOT/UPGRADE;
Cypress boards, that can be used with this evaluation example:
......@@ -86,7 +86,7 @@ To enable multi-image operation define `MCUBOOT_IMAGE_NUMBER` in `MCUBootApp/con
Default value of `MCUBOOT_IMAGE_NUMBER` is 1, which corresponds to single image configuratios.
In multi-image operation (two images are considered for simplicity) MCUBoot Bootloader application operates as following:
In multi-image operation (two images are considered for simplicity) MCUboot Bootloader application operates as following:
* Verifies Primary_1 and Primary_2 images;
* Verifies Secondary_1 and Secondary_2 images;
......@@ -98,7 +98,7 @@ This ensures two dependent applications can be accepted by device only in case b
**Default Flash map for Multi-Image operation:**
`0x10000000 - 0x10018000` - MCUBoot Bootloader
`0x10000000 - 0x10018000` - MCUboot Bootloader
`0x10018000 - 0x10028000` - Primary_1 (BOOT) slot of Bootloader
......@@ -117,7 +117,7 @@ For more details about External Memory usage, please refer to separate guiding d
### Hardware limitations
Since this application is created to demonstrate MCUBoot library features and not as reference examples some considerations are taken.
Since this application is created to demonstrate MCUboot library features and not as reference examples some considerations are taken.
1. `SCB5` used to configure serial port for debug prints. This is the most commonly used Serial Communication Block number among available Cypress PSoC 6 kits. If you try to use custom hardware with this application - change definition of `CYBSP_UART_HW` in `main.c` of MCUBootApp to SCB* that correspond to your design.
......
......@@ -2,9 +2,9 @@
### Disclaimer
Given solution is included in `mcuboot` repository with purpose to demonstrate basic consepts and features of MCUBoot library on Cypress PSoC 6 device. Applications are created per mcuboot library maintainers requirements. Implemetation differs from conventional and recomended by Cypress Semiconductors development flow for PSoC 6 devices. These applications are not recomended as a starting point for development and should not be considered as supported examples for PSoC 6 devices.
Given solution is included in `MCUboot` repository with purpose to demonstrate basic consepts and features of MCUboot library on Cypress PSoC 6 device. Applications are created per MCUboot library maintainers requirements. Implemetation differs from conventional and recomended by Cypress Semiconductors development flow for PSoC 6 devices. These applications are not recomended as a starting point for development and should not be considered as supported examples for PSoC 6 devices.
Examples provided to use with **ModusToolbox® Software Environment** are a recommended reference point to start development of MCUBoot based bootloaders for PSoC 6 devices.
Examples provided to use with **ModusToolbox® Software Environment** are a recommended reference point to start development of MCUboot based bootloaders for PSoC 6 devices.
Refer to **Cypress Semiconductors** [github](https://github.com/cypresssemiconductorco) page to find examples.
......@@ -14,7 +14,7 @@ Refer to **Cypress Semiconductors** [github](https://github.com/cypresssemicondu
### Solution Description
There are two applications implemented:
* MCUBootApp - PSoC6 MCUBoot-based bootloading application;
* MCUBootApp - PSoC6 MCUboot-based bootloading application;
* BlinkyApp - simple PSoC6 blinking LED application which is a target of BOOT/UPGRADE;
The default flash map for MCUBootApp implemented is next:
......@@ -56,11 +56,11 @@ Submodules can also be updated and initialized separately:
Root directory for build is **boot/cypress.**
This folder contains make files infrastructure for building both MCUBoot Bootloader and sample BlinkyApp application used for Bootloader demo functionality.
This folder contains make files infrastructure for building both MCUboot Bootloader and sample BlinkyApp application used for Bootloader demo functionality.
Instructions on how to build and upload MCUBootApp bootloader application and sample user applocation are located in `Readme.md` files in corresponding folders.
Supported platforms for `MCUBoot`, `BlinkyApp`:
Supported platforms for `MCUboot`, `BlinkyApp`:
* PSOC_062_2M
* PSOC_062_1M
......
# mcuboot - apps/boot
# MCUboot - apps/boot
This sample app implements a boot loader for the Mynewt OS (apache.mynewt.org).
This app requires the following Mynewt repositories:
......
# Porting How-To
This document describes the requirements and necessary steps required to port
`mcuboot` to a new target `OS`.
`MCUboot` to a new target `OS`.
# Requirements
* `mcuboot` requires a configuration file, which can be included as
* `MCUboot` requires a configuration file, which can be included as
mcuboot_config/mcuboot_config.h, which configures various options
(that begin with MCUBOOT_).
* `mcuboot` requires that the target provides a `flash` API with ability to
* `MCUboot` requires that the target provides a `flash` API with ability to
get the flash's minimum write size, and read/write/erase individual sectors.
* `mcuboot` doesn't bundle a cryptographic library, which means the target
* `MCUboot` doesn't bundle a cryptographic library, which means the target
OS must already have it bundled. The supported libraries at the moment are
either `mbed TLS` or the set `tinycrypt` + `mbed TLS` (where `mbed TLS` is
used to provide functionality not existing in `tinycrypt`).
......@@ -70,20 +70,20 @@ in the following files:
## Flash Map
The bootloader requires to be able to address flash regions where the code
for mcuboot and images of applications are stored, in system-agnostic way.
For that purpose the mcuboot uses ID, which is integer (uint8_t) number
for MCUboot and images of applications are stored, in system-agnostic way.
For that purpose the MCUboot uses ID, which is integer (uint8_t) number
that should uniquely identify each flash region.
Such flash regions are served by object of `const struct flash_area` type while
layout of these objects is gathered under `flash_map`.
The common code of mcuboot, that is non-system specific, does not directly
The common code of MCUboot, that is non-system specific, does not directly
access contents of that object and never modifies it, instead it calls
`flash_area_` API to perform any actions on that object.
This way systems are free to implement internal logic of flash map or define
`struct flash_area` as they wish; the only restriction is that ID should be
uniquely tied to region characterized by device, offset and size.
Changes to common mcuboot code should not affect system specific internals
of flash map, on the other side system specific code, within mcuboot, is
Changes to common MCUboot code should not affect system specific internals
of flash map, on the other side system specific code, within MCUboot, is
is not restricted from directly accessing `struct flash_area` elements.
......@@ -98,7 +98,7 @@ struct flash_area {
};
```
The above example of structure hold all information that is currently required
by mcuboot, although the mcuboot will not be trying to access them directly,
by MCUboot, although the MCUboot will not be trying to access them directly,
instead a system is required to provide following mandatory getter functions:
```c
......@@ -114,7 +114,7 @@ uint32_t flash_area_get_size(const struct flash_area *fa)
```
The mcuboot common code uses following defines that should be defined by system
The MCUboot common code uses following defines that should be defined by system
specific header files and are used to identify destination of flash area by ID:
```c
......@@ -168,7 +168,7 @@ int flash_area_id_from_multi_image_slot(int image_index, int slot);
int flash_area_id_to_multi_image_slot(int image_index, int area_id);
```
**Note:** As of writing, it is possible that mcuboot will open a flash area multiple times simultaneously (through nested calls to `flash_area_open`). As a result, mcuboot may call `flash_area_close` on a flash area that is still opened by another part of mcuboot. As a workaround when porting, it may be necessary to implement a counter of the number of times a given flash area has been opened by mcuboot. The `flash_area_close` implementation should only fully deinitialize the underlying flash area when the open counter is decremented to 0. See [this GitHub PR](https://github.com/mcu-tools/mcuboot/pull/894/) for a more detailed discussion.
**Note:** As of writing, it is possible that MCUboot will open a flash area multiple times simultaneously (through nested calls to `flash_area_open`). As a result, MCUboot may call `flash_area_close` on a flash area that is still opened by another part of MCUboot. As a workaround when porting, it may be necessary to implement a counter of the number of times a given flash area has been opened by MCUboot. The `flash_area_close` implementation should only fully deinitialize the underlying flash area when the open counter is decremented to 0. See [this GitHub PR](https://github.com/mcu-tools/mcuboot/pull/894/) for a more detailed discussion.
## Memory management for mbed TLS
......
# Submitting Patches
Development on mcuboot primarily takes place in github, at:
Development on MCUboot primarily takes place in github, at:
https://github.com/mcu-tools/mcuboot
Changes should be submitted via github pull requests. Each commit
......
......@@ -29,7 +29,7 @@
## [Summary](#summary)
mcuboot comprises two packages:
MCUboot comprises two packages:
* The bootutil library (boot/bootutil)
* The boot application (each port has its own at boot/<port>)
......@@ -296,31 +296,31 @@ authenticated in RAM and executed.
## [Boot Swap Types](#boot-swap-types)
When the device first boots under normal circumstances, there is an up-to-date
firmware image in each primary slot, which mcuboot can validate and then
firmware image in each primary slot, which MCUboot can validate and then
chain-load. In this case, no image swaps are necessary. During device upgrades,
however, new candidate image(s) is present in the secondary slot(s), which
mcuboot must swap into the primary slot(s) before booting as discussed above.
MCUboot must swap into the primary slot(s) before booting as discussed above.
Upgrading an old image with a new one by swapping can be a two-step process. In
this process, mcuboot performs a "test" swap of image data in flash and boots
this process, MCUboot performs a "test" swap of image data in flash and boots
the new image or it will be executed during operation. The new image can then
update the contents of flash at runtime to mark itself "OK", and mcuboot will
update the contents of flash at runtime to mark itself "OK", and MCUboot will
then still choose to run it during the next boot. When this happens, the swap is
made "permanent". If this doesn't happen, mcuboot will perform a "revert" swap
made "permanent". If this doesn't happen, MCUboot will perform a "revert" swap
during the next boot by swapping the image(s) back into its original location(s)
, and attempting to boot the old image(s).
Depending on the use case, the first swap can also be made permanent directly.
In this case, mcuboot will never attempt to revert the images on the next reset.
In this case, MCUboot will never attempt to revert the images on the next reset.
Test swaps are supported to provide a rollback mechanism to prevent devices
from becoming "bricked" by bad firmware. If the device crashes immediately
upon booting a new (bad) image, mcuboot will revert to the old (working) image
upon booting a new (bad) image, MCUboot will revert to the old (working) image
at the next device reset, rather than booting the bad image again. This allows
device firmware to make test swaps permanent only after performing a self-test
routine.
On startup, mcuboot inspects the contents of flash to decide for each images
On startup, MCUboot inspects the contents of flash to decide for each images
which of these "swap types" to perform; this decision determines how it
proceeds.
......@@ -345,7 +345,7 @@ The possible swap types, and their meanings, are:
- `BOOT_SWAP_TYPE_PANIC`: Swapping encountered an unrecoverable error.
The "swap type" is a high-level representation of the outcome of the
boot. Subsequent sections describe how mcuboot determines the swap type from
boot. Subsequent sections describe how MCUboot determines the swap type from
the bit-level contents of flash.
### [Revert mechanism in direct-xip mode](#direct-xip-revert)
......@@ -438,7 +438,7 @@ allows it to compute how far this swap operation has progressed for each
sector. The swap status field can thus used to resume a swap operation if the
bootloader is halted while a swap operation is ongoing and later reset. The
`BOOT_MAX_IMG_SECTORS` value is the configurable maximum number of sectors
mcuboot supports for each image; its value defaults to 128, but allows for
MCUboot supports for each image; its value defaults to 128, but allows for
either decreasing this size, to limit RAM usage, or to increase it in devices
that have massive amounts of Flash or very small sized sectors and thus require
a bigger configuration to allow for the handling of all slot's sectors.
......@@ -456,7 +456,7 @@ of 3 is explained below.
4. Swap info: A single byte which encodes the following information:
- Swap type: Stored in bits 0-3. Indicating the type of swap operation in
progress. When mcuboot resumes an interrupted swap, it uses this field to
progress. When MCUboot resumes an interrupted swap, it uses this field to
determine the type of operation to perform. This field contains one of the
following values in the table below.
- Image number: Stored in bits 4-7. It has always 0 value at single image
......@@ -498,7 +498,7 @@ aggregate information provided by both image slot's trailers.
### [New swaps (non-resumes)](#new-swaps-non-resumes)
For new swaps, mcuboot must inspect a collection of fields to determine which
For new swaps, MCUboot must inspect a collection of fields to determine which
swap operation to perform.
The image trailers records are structured around the limitations imposed by
......@@ -545,9 +545,9 @@ higher priority when testing the image trailers.
-------------------------------------------------'
```
Any of the above three states results in mcuboot attempting to swap images.
Any of the above three states results in MCUboot attempting to swap images.
Otherwise, mcuboot does not attempt to swap images, resulting in one of the
Otherwise, MCUboot does not attempt to swap images, resulting in one of the
other three swap types, as illustrated by State IV.
```
......@@ -564,11 +564,11 @@ other three swap types, as illustrated by State IV.
-------------------------------------------------'
```
In State IV, when no errors occur, mcuboot will attempt to boot the contents of
In State IV, when no errors occur, MCUboot will attempt to boot the contents of
the primary slot directly, and the result is `BOOT_SWAP_TYPE_NONE`. If the image
in the primary slot is not valid, the result is `BOOT_SWAP_TYPE_FAIL`. If a
fatal error occurs during boot, the result is `BOOT_SWAP_TYPE_PANIC`. If the
result is either `BOOT_SWAP_TYPE_FAIL` or `BOOT_SWAP_TYPE_PANIC`, mcuboot hangs
result is either `BOOT_SWAP_TYPE_FAIL` or `BOOT_SWAP_TYPE_PANIC`, MCUboot hangs
rather than booting an invalid or compromised image.
Note: An important caveat to the above is the result when a swap is requested
......@@ -579,7 +579,7 @@ Note: An important caveat to the above is the result when a swap is requested
### [Resumed swaps](#resumed-swaps)
If mcuboot determines that it is resuming an interrupted swap (i.e., a reset
If MCUboot determines that it is resuming an interrupted swap (i.e., a reset
occurred mid-swap), it fully determines the operation to resume by reading the
`swap info` field from the active trailer and extracting the swap type from bits
0-3. The set of tables in the previous section are not necessary in the resume
......@@ -621,7 +621,7 @@ one image. Every image can be updated independently therefore the flash is
partitioned further to arrange two slots for each image.
```
+--------------------+
| MCUBoot |
| MCUboot |
+--------------------+
~~~~~ <- memory might be not contiguous
+--------------------+
......@@ -642,7 +642,7 @@ partitioned further to arrange two slots for each image.
| Scratch |
+--------------------+
```
MCUBoot is also capable of handling dependencies between images. For example
MCUboot is also capable of handling dependencies between images. For example
if an image needs to be reverted it might be necessary to revert another one too
(e.g. due to API incompatibilities) or simply to prevent from being updated
because of an unsatisfied dependency. Therefore all aborted swaps have to be
......@@ -973,7 +973,7 @@ If it does not match then "source: none" is returned.
-----------------------------------------------------------------------'
```
If the swap status region indicates that the images are not contiguous, mcuboot
If the swap status region indicates that the images are not contiguous, MCUboot
determines the type of swap operation that was interrupted by reading the `swap
info` field in the active image trailer and extracting the swap type from bits
0-3 then resumes the operation. In other words, it applies the procedure defined
......@@ -1033,16 +1033,16 @@ By default, the whole public key is embedded in the bootloader code and its
hash is added to the image manifest as a KEYHASH TLV entry. As an alternative
the bootloader can be made independent of the keys by setting the
`MCUBOOT_HW_KEY` option. In this case the hash of the public key must be
provisioned to the target device and mcuboot must be able to retrieve the
provisioned to the target device and MCUboot must be able to retrieve the
key-hash from there. For this reason the target must provide a definition
for the `boot_retrieve_public_key_hash()` function which is declared in
`boot/bootutil/include/bootutil/sign_key.h`. It is also required to use
the `full` option for the `--public-key-format` imgtool argument in order to
add the whole public key (PUBKEY TLV) to the image manifest instead of its
hash (KEYHASH TLV). During boot the public key is validated before using it for
signature verification, mcuboot calculates the hash of the public key from the
signature verification, MCUboot calculates the hash of the public key from the
TLV area and compares it with the key-hash that was retrieved from the device.
This way mcuboot is independent from the public key(s). The key(s) can be
This way MCUboot is independent from the public key(s). The key(s) can be
provisioned any time and by different parties.
## [Protected TLVs](#protected-tlvs)
......@@ -1084,7 +1084,7 @@ D | +-----------------+ |
## [Dependency Check](#dependency-check)
MCUBoot can handle multiple firmware images. It is possible to update them
MCUboot can handle multiple firmware images. It is possible to update them
independently but in many cases it can be desired to be able to describe
dependencies between the images (e.g. to ensure API compliance and avoid
interoperability issues).
......@@ -1142,7 +1142,7 @@ provide an implementation of the security counter interface defined in
## [Measured boot and data sharing](#boot-data-sharing)
MCUBoot defines a mechanism for sharing boot status information (also known as
MCUboot defines a mechanism for sharing boot status information (also known as
measured boot) and an interface for sharing application specific information
with the runtime software. If any of these are enabled the target must provide
a shared data area between the bootloader and runtime firmware and define the
......@@ -1198,7 +1198,7 @@ The `sw_type` string that is passed as the `--boot_record` option's parameter
will be the value of the "Software type" attribute in the generated BOOT_RECORD
TLV. The target must also define the `MAX_BOOT_RECORD_SZ` macro which indicates
the maximum size of the CBOR encoded boot record in bytes.
During boot, MCUBoot will look for these TLVs (in case of multiple images) in
During boot, MCUboot will look for these TLVs (in case of multiple images) in
the manifests of the active images (the latest and validated) and copy the CBOR
encoded binary data to the shared data area. Preserving all these image
attributes from the boot stage for use by later runtime services (such as an
......
......@@ -15,7 +15,7 @@ There are a couple of ways to fix this:
1. Use a reversible padding scheme. This will work, but requires
at least one pad byte always be added (to set the length). This
padding would be somewhat incompatible across versions (older
EC256 would work, newer mcuboot code would reject old
EC256 would work, newer MCUboot code would reject old
signatures. EC code would only reliably work in the new
combination).
......@@ -60,7 +60,7 @@ default, but not specifying a specific version of imgtool.
The signature generation in the simulator can be changed at the same
time the boot code begins to accept unpadded signatures. The sim is
always run out of the same tree as the mcuboot code, so there should
always run out of the same tree as the MCUboot code, so there should
not be any compatibility issues.
## Background
......
......@@ -24,7 +24,7 @@
## [Rationale](#rationale)
To provide confidentiality of image data while in transport to the
device or while residing on an external flash, `MCUBoot` has support
device or while residing on an external flash, `MCUboot` has support
for encrypting/decrypting images on-the-fly while upgrading.
The image header needs to flag this image as `ENCRYPTED` (0x04) and
......@@ -84,7 +84,7 @@ are the results of applying the given operations over the AES-CTR key.
ECIES follows a well defined protocol to generate an encryption key. There are
multiple standards which differ only on which building blocks are used; for
MCUBoot we settled on some primitives that are easily found on our crypto
MCUboot we settled on some primitives that are easily found on our crypto
libraries. The whole key encryption can be summarized as:
* Generate a new private key and derive the public key; when using ECIES-P256
......@@ -112,7 +112,7 @@ artifacts while ECIES-X25519 is named ENC_X25519.
## [Upgrade process](#upgrade-process)
When starting a new upgrade process, `MCUBoot` checks that the image in the
When starting a new upgrade process, `MCUboot` checks that the image in the
`secondary slot` has the `ENCRYPTED` flag set and has the required TLV with the
encrypted key. It then uses its internal private/secret key to decrypt
the TLV containing the key. Given that no errors are found, it will then
......
......@@ -18,7 +18,7 @@ You can generate a keypair for one of these types using the 'keygen' command:
./scripts/imgtool.py keygen -k filename.pem -t rsa-2048
or use rsa-3072, ecdsa-p256, or ed25519 for the type. The key type used
should match what mcuboot is configured to verify.
should match what MCUboot is configured to verify.
This key file is what is used to sign images, this file should be
protected, and not widely distributed.
......@@ -29,7 +29,7 @@ time you use the private key.
## [Incorporating the public key into the code](#incorporating-the-public-key-into-the-code)
There is a development key distributed with mcuboot that can be used
There is a development key distributed with MCUboot that can be used
for testing. Since this private key is widely distributed, it should
never be used for production. Once you have generated a production
key, as described above, you should replace the public key in the
......@@ -68,7 +68,7 @@ primary slot and adds a header and trailer that the bootloader is expecting:
it from the image version.
-d, --dependencies TEXT
--pad-sig Add 0-2 bytes of padding to ECDSA signature
(for mcuboot <1.5)
(for MCUboot <1.5)
-H, --header-size INTEGER [required]
--pad-header Add --header-size zeroed bytes at the
beginning of the image
......
......@@ -33,7 +33,7 @@ for more details.
- [RIOT](readme-riot.md)
- [Mbed-OS](readme-mbed.md)
- [Patch submission](SubmittingPatches.md) - information
on how to contribute to mcuboot
on how to contribute to MCUboot
- Testing
- [Zephyr](testplan-zephyr.md) test plan
- [mynewt](testplan-mynewt.md) test plan
......
......@@ -19,7 +19,7 @@ The current port is available for use in the following SoCs within the OSes:
1. Install additional packages required for development with MCUboot:
```
cd ~/mcuboot # or to your directory where mcuboot is cloned
cd ~/mcuboot # or to your directory where MCUboot is cloned
pip3 install --user -r scripts/requirements.txt
```
......
......@@ -32,10 +32,10 @@ flash partitions defined is the frdm_k64f's in
## Installing Requirements and Dependencies
Install additional packages required for development with mcuboot:
Install additional packages required for development with MCUboot:
```
cd ~/mcuboot # or to your directory where mcuboot is cloned
cd ~/mcuboot # or to your directory where MCUboot is cloned
pip3 install --user -r scripts/requirements.txt
```
......
......@@ -21,7 +21,7 @@ for the NuttX RTOS, and the Espressif ESP32 SDK.
- Add simulator support for testing direct-XIP and ramload.
- Support Mbed TLS 3.0. Updates the submodule for Mbed TLS to 3.0.
- Enable direct-xip mode in mbed-os port.
- extract `bootutil_public` library, a common interface for mcuboot
- extract `bootutil_public` library, a common interface for MCUboot
and the application.
- Allow to boot primary image if secondary one is unreachable.
- Add AES256 image encryption support.
......@@ -43,7 +43,7 @@ for the NuttX RTOS, and the Espressif ESP32 SDK.
## Version 1.7.0
The 1.7.0 release of MCUBoot adds support for the Mbed-OS platform,
The 1.7.0 release of MCUboot adds support for the Mbed-OS platform,
Equal slots (direct-xip) upgrade mode, RAM loading upgrade mode,
hardening against hardware level fault injection and timing attacks
and single image mode.
......@@ -52,7 +52,7 @@ There are bug fixes, and associated imgtool updates as well.
### About this release
- Initial support for the Mbed-OS platform.
- Added possibility to enter deep sleep mode after mcuboot app execution
- Added possibility to enter deep sleep mode after MCUboot app execution
for cypress platform.
- Added hardening against hardware level fault injection and timing attacks.
- Introduced Abstract crypto primitives to simplify porting.
......@@ -62,7 +62,7 @@ There are bug fixes, and associated imgtool updates as well.
- Fixed boostrapping in swap-move mode.
- Fixed issue causing that interrupted swap-move operation might brick device
if the primary image was padded.
- Abstracting mcuboot crypto functions for cleaner porting
- Abstracting MCUboot crypto functions for cleaner porting
- Droped flash_area_read_is_empty() porting API.
- boot/zephyr: Added watchdog feed on nRF devices.
See `CONFIG_BOOT_WATCHDOG_FEED` option.
......@@ -236,7 +236,7 @@ docs](encrypted_images.md) for more information.
The 1.2.0 release of MCUboot brings a lot of fixes/updates, where much of the
changes were on the boot serial functionality and imgtool utility. There are
no breaking changes in MCUBoot functionality, but some of the CLI parameters
no breaking changes in MCUboot functionality, but some of the CLI parameters
in imgtool were changed (either removed or added or updated).
### About this release
......@@ -282,7 +282,7 @@ newt/imgtool support for password protected keys.
- imgtool: removed PKCS1.5 support, added support for password
protected keys
- tinycrypt 0.2.8 and the mbed-tls ASN1 parser are now bundled with
mcuboot (eg secp256r1 is now free of external dependencies!)
MCUboot (eg secp256r1 is now free of external dependencies!)
- Overwrite-only mode was updated to erase/copy only sectors that
actually store firmware
- A lot of small code and documentation fixes and updates.
......
# Release Process
The following documents the release process used with mcuboot.
The following documents the release process used with MCUboot.
## Version numbering
......@@ -15,7 +15,7 @@ incremeting the numbers:
We add pre-release tags of the format MAJOR.MINOR.PATCH-rc1.
We mark in documentation an MCUBoot development version using
We mark in documentation an MCUboot development version using
the format MAJOR.MINOR.PATCH-dev.
## Release Notes
......@@ -51,7 +51,7 @@ https://www.python.org/dev/peps/pep-0440/#pre-releases
## Mynewt release information
On Mynewt, `newt` always fetches a versioned MCUBoot release, so after
On Mynewt, `newt` always fetches a versioned MCUboot release, so after
the rc step is finished, the release needs to be exported by modifying
`repository.yml` in the root directory; it must be updated with the
new release version, including updates to the pseudo keys
......@@ -101,7 +101,7 @@ for bug fixes or required minor updates (eg, new `imgtool` features).
## Post release actions
Mark the MCUBoot version as a development version. The version number used
Mark the MCUboot version as a development version. The version number used
should be specified for the next expected release.
It should be larger than the last release version by incrementing the MAJOR or
the MINOR number. It is not necessary to define the next version precisely as
......
......@@ -12,7 +12,7 @@ For the 3 algorithms supported, rsa, ec and ec256, two files are provided:
key_<sign-algo>.pem, key_<sign-algo>_2.pem. And a keys file with the C public
key data for key_<sign-algo>.pem.
Build and load mcuboot:
Build and load MCUboot:
* `newt build k64f_boot_<sign-algo>`
* `newt load k64f_boot_<sign-algo>`
......@@ -41,7 +41,7 @@ key_<sign-algo>.pem. Both others should be erased.