Infineon: Switch to 1.9.0 code base, add xmc7000 family support, refactor memory layer
diff --git a/docs/encrypted_images.md b/docs/encrypted_images.md
index 838f493..6ce52f1 100644
--- a/docs/encrypted_images.md
+++ b/docs/encrypted_images.md
@@ -24,7 +24,7 @@
## [Rationale](#rationale)
To provide confidentiality of image data while in transport to the
-device or while residing on an external flash, `MCUBoot` has support
+device or while residing on an external flash, `MCUboot` has support
for encrypting/decrypting images on-the-fly while upgrading.
The image header needs to flag this image as `ENCRYPTED` (0x04) and
@@ -84,7 +84,7 @@
ECIES follows a well defined protocol to generate an encryption key. There are
multiple standards which differ only on which building blocks are used; for
-MCUBoot we settled on some primitives that are easily found on our crypto
+MCUboot we settled on some primitives that are easily found on our crypto
libraries. The whole key encryption can be summarized as:
* Generate a new private key and derive the public key; when using ECIES-P256
@@ -112,7 +112,7 @@
## [Upgrade process](#upgrade-process)
-When starting a new upgrade process, `MCUBoot` checks that the image in the
+When starting a new upgrade process, `MCUboot` checks that the image in the
`secondary slot` has the `ENCRYPTED` flag set and has the required TLV with the
encrypted key. It then uses its internal private/secret key to decrypt
the TLV containing the key. Given that no errors are found, it will then
@@ -132,8 +132,13 @@
sectors are re-encrypted when copying from the `primary slot` to
the `secondary slot`.
-PS: Each encrypted image must have its own key TLV that should be unique
-and used only for this particular image.
+---
+***Note***
+
+*Each encrypted image must have its own key TLV that should be unique*
+*and used only for this particular image.*
+
+---
Also when swap method is employed, the sizes of both images are saved to
the status area just before starting the upgrade process, because it