doc: Fix case in titles

Unified case in titles.
Fixed small grammar issues.

Signed-off-by: Francesco Servidio <[email protected]>

Author: FrancescoSer

boot/cypress/BlinkyApp/Readme.md

@@ -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.
 

boot/cypress/MCUBootApp/README.md

@@ -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.
 

boot/cypress/README.md

@@ -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.**
 

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`.

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 @@ 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:
 

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 @@ 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

docs/design.md

@@ -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,22 +1106,22 @@ 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`
 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.

docs/readme-espressif.md

@@ -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:
 

docs/readme-riot.md

@@ -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`.
 

docs/readme-zephyr.md

@@ -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.

docs/release-notes.md

@@ -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

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 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:

docs/signed_images.md

@@ -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

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.
 

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