doc: Fixed consistency of MCUboot
Fixed the consistency of the case used in the term MCUboot.
Signed-off-by: Francesco Servidio <francesco.servidio@nordicsemi.no>
diff --git a/docs/PORTING.md b/docs/PORTING.md
index 2df9b49..4abb1c4 100644
--- a/docs/PORTING.md
+++ b/docs/PORTING.md
@@ -1,18 +1,18 @@
# 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 @@
## 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 @@
};
```
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 @@
```
-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_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
diff --git a/docs/SubmittingPatches.md b/docs/SubmittingPatches.md
index 55b9230..5d19c51 100644
--- a/docs/SubmittingPatches.md
+++ b/docs/SubmittingPatches.md
@@ -1,6 +1,6 @@
# 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
diff --git a/docs/design.md b/docs/design.md
index e5e94b3..99d86a2 100755
--- a/docs/design.md
+++ b/docs/design.md
@@ -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 @@
## [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 @@
- `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 @@
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 @@
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 @@
### [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 @@
-------------------------------------------------'
```
-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 @@
-------------------------------------------------'
```
-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 @@
### [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 @@
partitioned further to arrange two slots for each image.
```
+--------------------+
-| MCUBoot |
+| MCUboot |
+--------------------+
~~~~~ <- memory might be not contiguous
+--------------------+
@@ -642,7 +642,7 @@
| 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 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 @@
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 @@
## [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 @@
## [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 @@
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
diff --git a/docs/ecdsa.md b/docs/ecdsa.md
index e60c7aa..18ba0cf 100644
--- a/docs/ecdsa.md
+++ b/docs/ecdsa.md
@@ -15,7 +15,7 @@
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 @@
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
diff --git a/docs/encrypted_images.md b/docs/encrypted_images.md
index 838f493..e78713a 100644
--- a/docs/encrypted_images.md
+++ b/docs/encrypted_images.md
@@ -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 @@
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 @@
## [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
diff --git a/docs/imgtool.md b/docs/imgtool.md
index 97f3272..9d50e67 100644
--- a/docs/imgtool.md
+++ b/docs/imgtool.md
@@ -18,7 +18,7 @@
./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 @@
## [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 @@
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
diff --git a/docs/index.md b/docs/index.md
index afb5565..4dae701 100644
--- a/docs/index.md
+++ b/docs/index.md
@@ -33,7 +33,7 @@
- [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
diff --git a/docs/readme-espressif.md b/docs/readme-espressif.md
index fa72fb3..0f6f5ac 100644
--- a/docs/readme-espressif.md
+++ b/docs/readme-espressif.md
@@ -19,7 +19,7 @@
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
```
diff --git a/docs/readme-zephyr.md b/docs/readme-zephyr.md
index 26bc519..53179b4 100644
--- a/docs/readme-zephyr.md
+++ b/docs/readme-zephyr.md
@@ -32,10 +32,10 @@
## 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
```
diff --git a/docs/release-notes.md b/docs/release-notes.md
index 885fe31..4c36236 100644
--- a/docs/release-notes.md
+++ b/docs/release-notes.md
@@ -21,7 +21,7 @@
- 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 @@
## 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 @@
### 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 @@
- 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 @@
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 @@
- 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.
diff --git a/docs/release.md b/docs/release.md
index 90c32b5..197bbad 100644
--- a/docs/release.md
+++ b/docs/release.md
@@ -1,6 +1,6 @@
# 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 @@
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 @@
## 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 @@
## 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
diff --git a/docs/testplan-mynewt.md b/docs/testplan-mynewt.md
index 5a227b9..59d7e74 100644
--- a/docs/testplan-mynewt.md
+++ b/docs/testplan-mynewt.md
@@ -12,7 +12,7 @@
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 @@
FIXME: this is currently not functional, skip this section!
-Build and load mcuboot:
+Build and load MCUboot:
* `newt build k64f_boot_rsa_ec`
* `newt load k64f_boot_rsa_ec`
@@ -68,7 +68,7 @@
### Overwrite only functionality
-Build/load mcuboot:
+Build/load MCUboot:
* `newt build k64f_boot_rsa_noswap`
* `newt load k64f_boot_rsa_noswap`
@@ -92,7 +92,7 @@
### Validate slot 0 option
-Build/load mcuboot:
+Build/load MCUboot:
* `newt build k64f_boot_rsa_validate0`
* `newt load k64f_boot_rsa_validate0`
@@ -120,7 +120,7 @@
DISCLAIMER: be careful with copy/paste of commands, this test uses another
target/app!
-Build/load mcuboot:
+Build/load MCUboot:
* `newt build k64f_boot_rsa`
* `newt load k64f_boot_rsa`
diff --git a/docs/testplan-zephyr.md b/docs/testplan-zephyr.md
index bd5b34b..63b57e6 100644
--- a/docs/testplan-zephyr.md
+++ b/docs/testplan-zephyr.md
@@ -1,6 +1,6 @@
# Zephyr Test Plan
-The following roughly describes how mcuboot is tested on Zephyr. The
+The following roughly describes how MCUboot is tested on Zephyr. The
testing is done with the code in `samples/zephyr`. These examples
were written using the FRDM-K64F, but other boards should be similar.
At this time, however, the partitions are hardcoded in the Makefile