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