doc: Fix case in titles
Unified case in titles. Fixed small grammar issues. Signed-off-by: Francesco Servidio <francesco.servidio@nordicsemi.no>
This commit is contained in:
Francesco Servidio
Andrzej Puzdrowski
parent
a6df132b68
commit
5bc983276f
|
|
@ -1,4 +1,4 @@
|
|||
### Blinking LED test application for MCUboot Bootloader
|
||||
### Blinking LED test application for MCUboot bootloader
|
||||
|
||||
### Description
|
||||
|
||||
|
|
@ -109,7 +109,7 @@ To obtain encrypted upgrade image of BlinkyApp extra flag `ENC_IMG=1` should be
|
|||
|
||||
This also suggests user already placed corresponing `*.pem` key in `\keys` folder. The key variables are defined in root `Makefile` as `SIGN_KEY_FILE` and `ENC_KEY_FILE`
|
||||
|
||||
### Post-Build
|
||||
### 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.
|
||||
|
||||
|
|
|
|||
|
|
@ -124,7 +124,7 @@ Since this application is created to demonstrate MCUboot library features and no
|
|||
2. `CY_SMIF_SLAVE_SELECT_0` is used as definition SMIF driver API. This configuration is used on evaluation kit for this example CY8CPROTO-062-4343W, CY8PROTO-062S3-4343W, CY8CKIT-062-4343W. If you try to use custom hardware with this application - change value of `smif_id` in `main.c` of MCUBootApp to value that corresponds to your design.
|
||||
|
||||
|
||||
### Downloading Solution's Assets
|
||||
### Downloading solution's assets
|
||||
|
||||
There is a set assets required:
|
||||
|
||||
|
|
@ -137,7 +137,7 @@ To get submodules - run the following command:
|
|||
|
||||
git submodule update --init --recursive
|
||||
|
||||
### Building Solution
|
||||
### Building solution
|
||||
|
||||
This folder contains make files infrastructure for building MCUBoot Bootloader. Same approach used in sample BlinkyLedApp application. Example command are provided below for couple different build configurations.
|
||||
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ Refer to **Cypress Semiconductors** [github](https://github.com/cypresssemicondu
|
|||
1. MCUboot-Based Basic Bootloader [mtb-example-psoc6-mcuboot-basic](https://github.com/cypresssemiconductorco/mtb-example-psoc6-mcuboot-basic)
|
||||
2. MCUboot-Based Bootloader with Rollback to Factory App in External Flash [mtb-example-anycloud-mcuboot-rollback](https://github.com/cypresssemiconductorco/mtb-example-anycloud-mcuboot-rollback)
|
||||
|
||||
### Solution Description
|
||||
### Solution description
|
||||
|
||||
There are two applications implemented:
|
||||
* MCUBootApp - PSoC6 MCUboot-based bootloading application;
|
||||
|
|
@ -31,7 +31,7 @@ For more details about External Memory usage, please refer to separate guiding d
|
|||
|
||||
MCUBootApp checks image integrity with SHA256, image authenticity with EC256 digital signature verification and uses either completely software implementation of cryptographic functions or accelerated by hardware - both based on Mbed TLS Library.
|
||||
|
||||
### Downloading Solution's Assets
|
||||
### Downloading solution's assets
|
||||
|
||||
There is a set assets required:
|
||||
|
||||
|
|
@ -52,7 +52,7 @@ Submodules can also be updated and initialized separately:
|
|||
|
||||
|
||||
|
||||
### Building Solution
|
||||
### Building solution
|
||||
|
||||
Root directory for build is **boot/cypress.**
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Porting How-To
|
||||
# Porting how-to
|
||||
|
||||
This document describes the requirements and necessary steps required to port
|
||||
`MCUboot` to a new target `OS`.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# MCUboot project security policy
|
||||
|
||||
## Reporting Security Issues
|
||||
## Reporting security issues
|
||||
|
||||
The MCUboot team takes security, vulnerabilities, and weaknesses
|
||||
seriously.
|
||||
|
|
@ -34,7 +34,7 @@ We will make our best effort to respond within a timely manner. Most
|
|||
vulnerabilities found within published code will undergo an embargo of
|
||||
90 days to allow time fixes to be developed and deployed.
|
||||
|
||||
## Vulnerability Advisories
|
||||
## Vulnerability advisories
|
||||
|
||||
Vulnerability reports and published fixes will be reported as follows:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Submitting Patches
|
||||
# Submitting patches
|
||||
|
||||
Development on MCUboot primarily takes place in github, at:
|
||||
https://github.com/mcu-tools/mcuboot
|
||||
|
|
@ -27,7 +27,7 @@ space. JIRA is quite flexible about where the indicators go, but
|
|||
putting them in a trailer with a common format will make them easier
|
||||
to find later.
|
||||
|
||||
# Developer Certificate of Origin
|
||||
# Developer certificate of origin
|
||||
|
||||
```
|
||||
Developer Certificate of Origin
|
||||
|
|
|
|||
|
|
@ -48,7 +48,7 @@ characteristics:
|
|||
* Built to run from flash.
|
||||
* Built to run from a fixed location (i.e., not position-independent).
|
||||
|
||||
## [Image Format](#image-format)
|
||||
## [Image format](#image-format)
|
||||
|
||||
The following definitions describe the image format.
|
||||
|
||||
|
|
@ -134,7 +134,7 @@ The `ih_hdr_size` field indicates the length of the header, and therefore the
|
|||
offset of the image itself. This field provides for backwards compatibility in
|
||||
case of changes to the format of the image header.
|
||||
|
||||
## [Flash Map](#flash-map)
|
||||
## [Flash map](#flash-map)
|
||||
|
||||
A device's flash is partitioned according to its _flash map_. At a high
|
||||
level, the flash map maps numeric IDs to _flash areas_. A flash area is a
|
||||
|
|
@ -165,7 +165,7 @@ images therefore the flash area IDs of primary and secondary areas are mapped
|
|||
based on the number of the active image (on which the bootloader is currently
|
||||
working).
|
||||
|
||||
## [Image Slots](#image-slots)
|
||||
## [Image slots](#image-slots)
|
||||
|
||||
A portion of the flash memory can be partitioned into multiple image areas, each
|
||||
contains two image slots: a primary slot and a secondary slot.
|
||||
|
|
@ -251,7 +251,7 @@ work properly even when it is reset during the middle of an image swap. For this
|
|||
reason, the rest of the document describes its behavior when configured to swap
|
||||
images during an upgrade.
|
||||
|
||||
### [RAM Loading](#ram-load)
|
||||
### [RAM loading](#ram-load)
|
||||
|
||||
In ram-load mode the slots are equal. Like the direct-xip mode, this mode
|
||||
also selects the newest image by reading the image version numbers in the image
|
||||
|
|
@ -293,7 +293,7 @@ happens as described above. If the image is encrypted, it is copied in RAM at
|
|||
the provided address and then decrypted. Finally, the decrypted image is
|
||||
authenticated in RAM and executed.
|
||||
|
||||
## [Boot Swap Types](#boot-swap-types)
|
||||
## [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
|
||||
|
|
@ -375,7 +375,7 @@ direct-xip mode's "revert" mechanism are the following:
|
|||
- Proceed to step 3.
|
||||
3. Proceed to image validation ...
|
||||
|
||||
## [Image Trailer](#image-trailer)
|
||||
## [Image trailer](#image-trailer)
|
||||
|
||||
For the bootloader to be able to determine the current state and what actions
|
||||
should be taken during the current boot operation, it uses metadata stored in
|
||||
|
|
@ -490,7 +490,7 @@ of 3 is explained below.
|
|||
};
|
||||
```
|
||||
|
||||
## [IMAGE TRAILERS](#image-trailers)
|
||||
## [Image trailers](#image-trailers)
|
||||
|
||||
At startup, the bootloader determines the boot swap type by inspecting the
|
||||
image trailers. When using the term "image trailers" what is meant is the
|
||||
|
|
@ -585,7 +585,7 @@ occurred mid-swap), it fully determines the operation to resume by reading the
|
|||
0-3. The set of tables in the previous section are not necessary in the resume
|
||||
case.
|
||||
|
||||
## [High-Level Operation](#high-level-operation)
|
||||
## [High-level operation](#high-level-operation)
|
||||
|
||||
With the terms defined, we can now explore the bootloader's operation. First,
|
||||
a high-level overview of the boot process is presented. Then, the following
|
||||
|
|
@ -613,7 +613,7 @@ Procedure:
|
|||
|
||||
3. Boot into image in primary slot.
|
||||
|
||||
### [Multiple Image Boot](#multiple-image-boot)
|
||||
### [Multiple image boot](#multiple-image-boot)
|
||||
|
||||
When the flash contains multiple executable images the bootloader's operation
|
||||
is a bit more complex but similar to the previously described procedure with
|
||||
|
|
@ -705,7 +705,7 @@ process is presented below.
|
|||
+ Boot into image in the primary slot of the 0th image position\
|
||||
(other image in the boot chain is started by another image).
|
||||
|
||||
### [Multiple Image Boot for RAM loading and direct-xip](#multiple-image-boot-for-ram-loading-and-direct-xip)
|
||||
### [Multiple image boot for RAM loading and direct-xip](#multiple-image-boot-for-ram-loading-and-direct-xip)
|
||||
|
||||
The operation of the bootloader is different when the ram-load or the
|
||||
direct-xip strategy is chosen. The flash map is very similar to the swap
|
||||
|
|
@ -740,7 +740,7 @@ strategy but there is no need for Scratch area.
|
|||
|
||||
+ Boot the loaded slot of image 0.
|
||||
|
||||
## [Image Swapping](#image-swapping)
|
||||
## [Image swapping](#image-swapping)
|
||||
|
||||
The bootloader swaps the contents of the two image slots for two reasons:
|
||||
|
||||
|
|
@ -836,7 +836,7 @@ happened when a swap was requested:
|
|||
After completing the operations as described above the image in the primary slot
|
||||
should be booted.
|
||||
|
||||
## [Swap Status](#swap-status)
|
||||
## [Swap status](#swap-status)
|
||||
|
||||
The swap status region allows the bootloader to recover in case it restarts in
|
||||
the middle of an image swap operation. The swap status region consists of a
|
||||
|
|
@ -917,7 +917,7 @@ point within the region.
|
|||
Note: since the scratch area only ever needs to record swapping of the last
|
||||
sector, it uses at most min-write-size * 3 bytes for its own status area.
|
||||
|
||||
## [Reset Recovery](#reset-recovery)
|
||||
## [Reset recovery](#reset-recovery)
|
||||
|
||||
If the bootloader resets in the middle of a swap operation, the two images may
|
||||
be discontiguous in flash. Bootutil recovers from this condition by using the
|
||||
|
|
@ -986,7 +986,7 @@ belongs to image 0 or image 1.
|
|||
After the swap operation has been completed, the bootloader proceeds as though
|
||||
it had just been started.
|
||||
|
||||
## [Integrity Check](#integrity-check)
|
||||
## [Integrity check](#integrity-check)
|
||||
|
||||
An image is checked for integrity immediately before it gets copied into the
|
||||
primary slot. If the bootloader doesn't perform an image swap, then it can
|
||||
|
|
@ -1027,7 +1027,7 @@ If you want to enable and use encrypted images, see:
|
|||
Note: Image encryption is not supported when the direct-xip upgrade strategy
|
||||
is selected.
|
||||
|
||||
### [Using Hardware Keys for Verification](#hw-key-support)
|
||||
### [Using hardware keys for verification](#hw-key-support)
|
||||
|
||||
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
|
||||
|
|
@ -1082,7 +1082,7 @@ D | +-----------------+ |
|
|||
+---------------------+
|
||||
```
|
||||
|
||||
## [Dependency Check](#dependency-check)
|
||||
## [Dependency check](#dependency-check)
|
||||
|
||||
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
|
||||
|
|
@ -1106,14 +1106,14 @@ state after dependency check.
|
|||
For more information on adding dependency entries to an image,
|
||||
see: [imgtool](imgtool.md).
|
||||
|
||||
## [Downgrade Prevention](#downgrade-prevention)
|
||||
## [Downgrade prevention](#downgrade-prevention)
|
||||
|
||||
Downgrade prevention is a feature which enforces that the new image must have a
|
||||
higher version/security counter number than the image it is replacing, thus
|
||||
preventing the malicious downgrading of the device to an older and possibly
|
||||
vulnerable version of its firmware.
|
||||
|
||||
### [SW Based Downgrade Prevention](#sw-downgrade-prevention)
|
||||
### [Software-based downgrade prevention](#sw-downgrade-prevention)
|
||||
|
||||
During the software based downgrade prevention the image version numbers are
|
||||
compared. This feature is enabled with the `MCUBOOT_DOWNGRADE_PREVENTION`
|
||||
|
|
@ -1121,7 +1121,7 @@ option. In this case downgrade prevention is only available when the
|
|||
overwrite-based image update strategy is used (i.e. `MCUBOOT_OVERWRITE_ONLY`
|
||||
is set).
|
||||
|
||||
### [HW Based Downgrade Prevention](#hw-downgrade-prevention)
|
||||
### [Hardware-based downgrade prevention](#hw-downgrade-prevention)
|
||||
|
||||
Each signed image can contain a security counter in its protected TLV area, which
|
||||
can be added to the image using the `-s` option of the [imgtool](imgtool.md) script.
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ The current port is available for use in the following SoCs within the OSes:
|
|||
- Zephyr RTOS - _WIP_
|
||||
- NuttX - _WIP_
|
||||
|
||||
## Installing Requirements and Dependencies
|
||||
## Installing requirements and dependencies
|
||||
|
||||
1. Install additional packages required for development with MCUboot:
|
||||
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ or Zephyr, following the provided instructions.
|
|||
In the next version, it is planned to compile MCUboot using RIOT,
|
||||
which should be able to boot any of the supported OS images.
|
||||
|
||||
## Building Applications for the bootloader
|
||||
## Building applications for the bootloader
|
||||
|
||||
A compatible MCUboot image can be compiled by typing: `make mcuboot`.
|
||||
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ flash partitions defined is the frdm_k64f's in
|
|||
`boards/arm/frdm_k64f/frdm_k64f.dts`. Make sure the labels in your board's
|
||||
`.dts` file match the ones used there.
|
||||
|
||||
## Installing Requirements and Dependencies
|
||||
## Installing requirements and dependencies
|
||||
|
||||
Install additional packages required for development with MCUboot:
|
||||
|
||||
|
|
@ -74,7 +74,7 @@ on the target and flash tool used, this might erase the whole of the flash
|
|||
memory (mass erase) or only the sectors where the bootloader resides prior to
|
||||
programming the bootloader image itself.
|
||||
|
||||
## Building Applications for the bootloader
|
||||
## Building applications for the bootloader
|
||||
|
||||
In addition to flash partitions in DTS, some additional configuration
|
||||
is required to build applications for MCUboot.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# MCUboot Release Notes
|
||||
# MCUboot release notes
|
||||
|
||||
- Table of Contents
|
||||
{:toc}
|
||||
|
|
@ -75,7 +75,7 @@ There are bug fixes, and associated imgtool updates as well.
|
|||
- imgtool: added possibility to set confirm flag for hex files as well.
|
||||
- imgtool: Print image digest during verify.
|
||||
|
||||
### Zephyr-RTOS Compatibility
|
||||
### Zephyr-RTOS compatibility
|
||||
|
||||
This release of MCUboot works with the Zephyr "main" at the time of the
|
||||
release. It was tested as of has 7a3b253ce. This version of MCUboot also
|
||||
|
|
@ -111,7 +111,7 @@ updates as well.
|
|||
2.9.10 has an infinite loop in a certain end-of-file situation." Fix
|
||||
by updating a dependency in documentation generation.
|
||||
|
||||
### Zephyr-RTOS Compatibility
|
||||
### Zephyr-RTOS compatibility
|
||||
|
||||
This release of MCUboot works the Zephyr "main" at the time of the
|
||||
release. It was tested as of has 1a89ca1238. When Zephyr v2.3.0 is
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Release Process
|
||||
# Release process
|
||||
|
||||
The following documents the release process used with MCUboot.
|
||||
|
||||
|
|
@ -18,13 +18,13 @@ We add pre-release tags of the format MAJOR.MINOR.PATCH-rc1.
|
|||
We mark in documentation an MCUboot development version using
|
||||
the format MAJOR.MINOR.PATCH-dev.
|
||||
|
||||
## Release Notes
|
||||
## Release notes
|
||||
|
||||
Before making a release, be sure to update the `docs/release-notes.md`
|
||||
to describe the release. This should be a high-level description of
|
||||
the changes, not a list of the git commits.
|
||||
|
||||
## Release Candidates
|
||||
## Release candidates
|
||||
|
||||
Prior to each release, tags are made (see below) for at least one
|
||||
release candidate (a.b.c-rc1, followed by a.b.c-rc2, etc, followed by
|
||||
|
|
@ -35,7 +35,7 @@ During the time between rc1 and the final release, the only changes
|
|||
that should be merged into main are those to fix bugs found in the
|
||||
rc and Mynewt metadata as described in the next section.
|
||||
|
||||
## imgtool release
|
||||
## Imgtool release
|
||||
|
||||
imgtool is released through pypi.org (The Python package index) and
|
||||
requires that its version to be updated by editing
|
||||
|
|
@ -57,7 +57,7 @@ the rc step is finished, the release needs to be exported by modifying
|
|||
new release version, including updates to the pseudo keys
|
||||
(`*-(latest|dev)`).
|
||||
|
||||
## Tagging and Release
|
||||
## Tagging and release
|
||||
|
||||
To make a release, make sure your local repo is on the tip version by
|
||||
fetching from origin. Typically, the releaser should create a branch
|
||||
|
|
@ -85,7 +85,7 @@ git push origin HEAD:refs/heads/main
|
|||
git push origin va.b.c-rcn
|
||||
```
|
||||
|
||||
## Branching after a Release
|
||||
## Branching after a release
|
||||
|
||||
After the final (non-`rc`) a.b.0 release is made, a new branch must
|
||||
be created and pushed:
|
||||
|
|
|
|||
|
|
@ -91,7 +91,7 @@ This exports the keys.
|
|||
|
||||
const int bootutil_key_cnt = sizeof(bootutil_keys) / sizeof(bootutil_keys[0]);
|
||||
|
||||
## Building bootloader
|
||||
## Building the bootloader
|
||||
|
||||
Enable the BOOTUTIL_SIGN_RSA syscfg setting in your app or target syscfg.yml
|
||||
file
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
## mcuboot test plan
|
||||
## MCUboot test plan
|
||||
|
||||
The current target for running the tests is the Freedom K64F board.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Zephyr Test Plan
|
||||
# Zephyr test plan
|
||||
|
||||
The following roughly describes how MCUboot is tested on Zephyr. The
|
||||
testing is done with the code in `samples/zephyr`. These examples
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Building MCUboot with nRF52840 CC310 enabled
|
||||
|
||||
## Pre-prerequisites
|
||||
## Prerequisites
|
||||
|
||||
Clone [nrfxlib](https://github.com/NordicPlayground/nrfxlib) next to the MCUboot root folder. So that it's located `../nrfxlib` from MCUboot root folder.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
MCUboot Simulator
|
||||
MCUboot simulator
|
||||
#################
|
||||
|
||||
This is a small simulator designed to exercise the mcuboot upgrade
|
||||
|
|
|
|||
Loading…
Reference in New Issue