doc: Fix case in titles
Unified case in titles.
Fixed small grammar issues.
Signed-off-by: Francesco Servidio <francesco.servidio@nordicsemi.no>
diff --git a/docs/PORTING.md b/docs/PORTING.md
index 5feb7ac..dd67ffb 100644
--- a/docs/PORTING.md
+++ b/docs/PORTING.md
@@ -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`.
diff --git a/docs/SECURITY.md b/docs/SECURITY.md
index aa50858..ac2bb4a 100644
--- a/docs/SECURITY.md
+++ b/docs/SECURITY.md
@@ -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 @@
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:
diff --git a/docs/SubmittingPatches.md b/docs/SubmittingPatches.md
index 5d19c51..37f908c 100644
--- a/docs/SubmittingPatches.md
+++ b/docs/SubmittingPatches.md
@@ -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 @@
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
diff --git a/docs/design.md b/docs/design.md
index 2a09d6f..8d8e0fe 100755
--- a/docs/design.md
+++ b/docs/design.md
@@ -48,7 +48,7 @@
* 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 @@
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 @@
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 @@
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 @@
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 @@
- 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 @@
};
```
-## [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 @@
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 @@
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 @@
+ 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 @@
+ 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 @@
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 @@
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 @@
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 @@
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 @@
+---------------------+
```
-## [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 @@
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 @@
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.
diff --git a/docs/readme-espressif.md b/docs/readme-espressif.md
index bd95178..e391627 100644
--- a/docs/readme-espressif.md
+++ b/docs/readme-espressif.md
@@ -14,7 +14,7 @@
- Zephyr RTOS - _WIP_
- NuttX - _WIP_
-## Installing Requirements and Dependencies
+## Installing requirements and dependencies
1. Install additional packages required for development with MCUboot:
diff --git a/docs/readme-riot.md b/docs/readme-riot.md
index 9bb1b9b..3aba53b 100644
--- a/docs/readme-riot.md
+++ b/docs/readme-riot.md
@@ -15,7 +15,7 @@
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`.
diff --git a/docs/readme-zephyr.md b/docs/readme-zephyr.md
index 159c9c4..ea18fe9 100644
--- a/docs/readme-zephyr.md
+++ b/docs/readme-zephyr.md
@@ -30,7 +30,7 @@
`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 @@
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.
diff --git a/docs/release-notes.md b/docs/release-notes.md
index ad55718..d08900a 100644
--- a/docs/release-notes.md
+++ b/docs/release-notes.md
@@ -1,4 +1,4 @@
-# MCUboot Release Notes
+# MCUboot release notes
- Table of Contents
{:toc}
@@ -75,7 +75,7 @@
- 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 @@
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
diff --git a/docs/release.md b/docs/release.md
index 197bbad..151943e 100644
--- a/docs/release.md
+++ b/docs/release.md
@@ -1,4 +1,4 @@
-# Release Process
+# Release process
The following documents the release process used with MCUboot.
@@ -18,13 +18,13 @@
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 @@
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 @@
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 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:
diff --git a/docs/signed_images.md b/docs/signed_images.md
index 22a6836..c1edcfb 100644
--- a/docs/signed_images.md
+++ b/docs/signed_images.md
@@ -91,7 +91,7 @@
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
diff --git a/docs/testplan-mynewt.md b/docs/testplan-mynewt.md
index 59d7e74..0e5e94f 100644
--- a/docs/testplan-mynewt.md
+++ b/docs/testplan-mynewt.md
@@ -1,4 +1,4 @@
-## mcuboot test plan
+## MCUboot test plan
The current target for running the tests is the Freedom K64F board.
diff --git a/docs/testplan-zephyr.md b/docs/testplan-zephyr.md
index 63b57e6..9b70151 100644
--- a/docs/testplan-zephyr.md
+++ b/docs/testplan-zephyr.md
@@ -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