Minor improvements to README (ARMmbed#130)

Author: LiyouZhou

README.md

@@ -16,7 +16,7 @@ Generic bootloader to be used in conjunction with [mbed-cloud-client](https://gi
 
 The metadata header is the bootloader update interface. Each stage of the boot sequence leading up to and including the application (except the root bootloader) is paired with a metadata header (containing version, size, hash etc.). Information contained in the metadata header allows validation and ordering of available firmwares.
 
-The firmware metadata header structure can be found [here](https://github.com/ARMmbed/mbed-cloud-client/blob/master/update-client-hub/modules/common/update-client-common/arm_uc_metadata_header_v2.h). There are two header formats, internal and external. The external header format is meant to be used when storing firmware on external storage which is assumed to be insecure. Hence the external header format contains extra security information prevent external tampering of the header data.
+The firmware metadata header structure can be found [here](https://github.com/ARMmbed/mbed-cloud-client/blob/master/update-client-hub/modules/common/update-client-common/arm_uc_metadata_header_v2.h). There are two header formats, internal and external. The external header format is used for storing firmware on external storage which is assumed to be insecure. Hence the external header format contains extra security information to prevent external tampering of the header data.
 
 ## Configurations
 
@@ -46,10 +46,10 @@ NOTE: See the [mbed cloud client documentation](https://cloud.mbed.com/docs/curr
 
 The bootloader uses device secret key to authenticate anything that is stored on external storage. The update client must be able to obtain the same key as the bootlaoder. The key is derived from a device root of trust using the algorithm [here](https://github.com/ARMmbed/mbed-cloud-client/blob/master/update-client-hub/modules/common/source/arm_uc_crypto.c#L401).
 
-You may choose to use SOTP to generate and store device RoT. During first boot the mbed cloud client will generate a random number from an available entropy source and storge it in SOTP on internal flash. On subsequent boots, the RoT will be read from SOTP. To enable SOTP RoT, you must set the following:
-1. Macro `PAL_USE_INTERNAL_FLASH=1` and `PAL_INT_FLASH_NUM_SECTIONS=2` to indicate that 2 sectors are used for SOTP.
-1. Macro `ARM_UC_USE_SOTP=1` to tell bootloader to retrive RoT from SOTP.
-1. "sotp-section-1-address", "sotp-section-1-size", "sotp-section-2-address", "sotp-section-2-size". The addresses **Must align to flash erase boundary**. The sizes must be full sector sized and at least 1k large.
+You may choose to use NVSTORE to store the device RoT. During first boot mbed cloud client will generate a random number from an available entropy source and storge it in NVSTORE on internal flash. On subsequent boots, the RoT will be read from NVSTORE. To enable NVSTORE RoT, you must set the following:
+1. Macro `ARM_BOOTLOADER_USE_NVSTORE_ROT=1` to enable the RoT implementation [here](https://github.com/ARMmbed/mbed-bootloader/blob/master/source/nvstore_rot.cpp).
+1. "nvstore.area_1_address", "nvstore.area_1_size", "nvstore.area_2_address", "nvstore.area_2_size". The addresses **Must align to flash erase boundary**. The sizes must be full sector sized and at least 1k.
+1. NVSTORE and SOTP are binary compatible hence the bootloader works with any software that uses SOTP as long as the offsets are set the same.
 
 Alternatively you can choose to use a custom device specific RoT by implementing the function `mbed_cloud_client_get_rot_128bit`. An example can be found [here](https://github.com/ARMmbed/mbed-bootloader-internal/blob/master/source/example_insecure_rot.c#L40).
 
@@ -62,7 +62,9 @@ User **may** set in `mbed_app.json`:
 1. `SHOW_PROGRESS_BAR`, Set to 1 to print a progress bar for various processes.
 
 ## Flash Layout
+
 ### The flash layout for K64F with SOTP and firmware storage on internal flash
+
 ```
     +--------------------------+
     |         LittleFS         |
@@ -89,24 +91,25 @@ User **may** set in `mbed_app.json`:
     |Active App Metadata Header|
     |                          |
     +--------------------------+ <-+ update-client.application-details
-    |          SOTP_2          |
-    +--------------------------+ <-+ sotp-section-2-address
-    |          SOTP_1          |
-    +--------------------------+ <-+ sotp-section-1-address
+    |        NVSTORE_2         |
+    +--------------------------+ <-+ nvstore.area_2_address
+    |        NVSTORE_1         |
+    +--------------------------+ <-+ nvstore.area_1_address
     |                          |
     |        Bootloader        |
     |                          |
-    |                          |
     +--------------------------+ <-+ 0
 ```
 
 ### Notes on Flash Layout
+
 - Internal Flash Only layout can be enabled by compiling the bootloader with the internal_flash_sotp.json configuration file `--app-config configs/internal_flash_sotp.json`. By default the firmware storage region and filesystem is on [external sd card](#external-storage).
 - The default flash layout is tested with GCC_ARM compiler and tiny.json compiler profile only. If a different compiler is used, the bootloader binary size will be larger and the offsets needs to be adjusted.
-- The SOTP regions require 1 flash erase sector each with at least 1k of space.
+- The NVSTORE regions require 1 flash erase sector each with at least 1k of space.
 - The LittleFS requires 2 flash sectors per folder and 1 sector per file as well as 2 sectors for the filesystem itself.
 
 ### Alignment
+
 **Flash Erase Boundary**: Flash can usually only be erased in blocks of specific sizes, this is platform specific and hence many regions need to align to this boundary.
 
 **Flash Page Boundary**: Flash can usually only be written in blocks of specific sizes, this is platform specific and hence many regions need to align to this boundary.