doc: Fixed consistency of Mbed term
Fixed the consistency of the case used for the Mbed term.
Signed-off-by: Francesco Servidio <francesco.servidio@nordicsemi.no>
diff --git a/docs/PORTING.md b/docs/PORTING.md
index 4abb1c4..5feb7ac 100644
--- a/docs/PORTING.md
+++ b/docs/PORTING.md
@@ -14,7 +14,7 @@
* `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
+ either `Mbed TLS` or the set `tinycrypt` + `Mbed TLS` (where `Mbed TLS` is
used to provide functionality not existing in `tinycrypt`).
# Steps to port
@@ -170,21 +170,21 @@
**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
+## Memory management for Mbed TLS
-`mbed TLS` employs dynamic allocation of memory, making use of the pair
-`calloc/free`. If `mbed TLS` is to be used for crypto, your target RTOS
+`Mbed TLS` employs dynamic allocation of memory, making use of the pair
+`calloc/free`. If `Mbed TLS` is to be used for crypto, your target RTOS
needs to provide this pair of function.
To configure the what functions are called when allocating/deallocating
-memory `mbed TLS` uses the following call:
+memory `Mbed TLS` uses the following call:
```
int mbedtls_platform_set_calloc_free (void *(*calloc_func)(size_t, size_t),
void (*free_func)(void *));
```
-For reference see [mbed TLS platform.h](https://tls.mbed.org/api/platform_8h.html).
+For reference see [Mbed TLS platform.h](https://tls.mbed.org/api/platform_8h.html).
If your system already provides functions with compatible signatures, those can
be used directly here, otherwise create new functions that glue to your
`calloc/free` implementations.
diff --git a/docs/ecdsa.md b/docs/ecdsa.md
index 18ba0cf..bb2e376 100644
--- a/docs/ecdsa.md
+++ b/docs/ecdsa.md
@@ -4,7 +4,7 @@
shortcut was taken, and these signatures were padded to make them
always a fixed length. Unfortunately, this padding was done in a way
that is not easily reversible. Some crypto libraries are fairly
-strict about the formatting of the ECDSA signature (specifically, mbed
+strict about the formatting of the ECDSA signature (specifically, Mbed
TLS). This currently means that the ECDSA SECP224R1 (EC) signature
checking code will fail to boot about 1 out of every 256 images,
because the signature itself will end in a 0x00 byte, and the code
@@ -43,7 +43,7 @@
without padding), and the existing EC implementation will begin
accepting padded and unpadded signatures.
- - An mbed TLS implementation of EC256 can be added, but will require
+ - An Mbed TLS implementation of EC256 can be added, but will require
the `--no-pad-sig` signature to be able to boot all generated
images (without the argument 3 of out 4 images generated will have
padding, and be considered invalid).
diff --git a/docs/readme-espressif.md b/docs/readme-espressif.md
index 0f6f5ac..bd95178 100644
--- a/docs/readme-espressif.md
+++ b/docs/readme-espressif.md
@@ -29,7 +29,7 @@
git submodule update --init --recursive --checkout boot/espressif/hal/esp-idf
```
-3. Next, get the mbedtls submodule required by MCUboot.
+3. Next, get the Mbed TLS submodule required by MCUboot.
```
git submodule update --init --recursive ext/mbedtls
```
diff --git a/docs/release-notes.md b/docs/release-notes.md
index 4c36236..ad55718 100644
--- a/docs/release-notes.md
+++ b/docs/release-notes.md
@@ -20,7 +20,7 @@
brought in for another reason.
- 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.
+- Enable direct-xip mode in Mbed-OS port.
- extract `bootutil_public` library, a common interface for MCUboot
and the application.
- Allow to boot primary image if secondary one is unreachable.
@@ -134,7 +134,7 @@
should work with no changes for little-endian targets, but will
break compatibility with big-endian targets.
- A benchmark framework was added to Zephyr
-- ed25519 signature validation can now build without using mbedTLS
+- ed25519 signature validation can now build without using Mbed TLS
by relying on a bundled tinycrypt based sha-512 implementation.
- imgtool was updated to correctly detect trailer overruns by image.
- Encrypted image TLVs can be saved in swap metadata during a swap
@@ -169,8 +169,8 @@
- Numerous code cleanups and refactorings
- Documentation updates for multi-image features
- Update imgtool.py to support the new features
-- Updated the mbed TLS submodule to current stable version 2.16.3
-- Moved the mbed TLS submodule from within sim/mcuboot-sys to ext.
+- Updated the Mbed TLS submodule to current stable version 2.16.3
+- Moved the Mbed TLS submodule from within sim/mcuboot-sys to ext.
This will make it easier for other board supports to use this code.
- Added some additional overflow and bound checks to data in the image
header, and TLV data.
@@ -281,7 +281,7 @@
of ecdsa (secp256r1) was added
- 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
+- tinycrypt 0.2.8 and the Mbed TLS ASN1 parser are now bundled with
MCUboot (eg secp256r1 is now free of external dependencies!)
- Overwrite-only mode was updated to erase/copy only sectors that
actually store firmware
@@ -358,12 +358,12 @@
- An overwrite only which upgrades slot 0 with the image in slot 1.
- A swapping upgrade which enables image test, allowing for rollback to a
previous known good image.
-- Supports both mbed-TLS and tinycrypt as backend crypto libraries. One of them
+- Supports both Mbed TLS and tinycrypt as backend crypto libraries. One of them
must be defined and the chosen signing algorithm will require a particular
library according to this list:
- - RSA 2048 needs mbed TLS
- - ECDSA secp224r1 needs mbed TLS
- - ECDSA secp256r1 needs tinycrypt as well as the ASN.1 code from mbed TLS
+ - RSA 2048 needs Mbed TLS
+ - ECDSA secp224r1 needs Mbed TLS
+ - ECDSA secp256r1 needs tinycrypt as well as the ASN.1 code from Mbed TLS
(so still needs that present).
### Known issues