You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
FEATURE
* Do not assume active header contiguous with app
Modify the README
* Info re hdr loc & storage choices
* Add info re RoT
* and link to docs re firmware stoarge
API porting
* restore build badge and clean up
IOTUC-70
1. Use this [script](https://github.com/ARMmbed/mbed-cloud-client-example/blob/master/tools/combine_bootloader_with_app.py) to combine the bootloader with application `python tools/combine_bootloader_with_app.py -a {application.bin} -b {bootloader.bin} --app-offset {firmware_metadata_header_address+firmware_metadata_header_size} --header-offset {firmware_metadata_header_address} -o {combined.bin}`.
12
+
1. Use this [script](https://github.com/ARMmbed/mbed-cloud-client-example/blob/master/tools/combine_bootloader_with_app.py) to combine the bootloader with application `python tools/combine_bootloader_with_app.py -a {application.bin} -b {bootloader.bin} --app-offset {application-start-address} --header-offset {firmware_metadata_header_address} -o {combined.bin}`.
11
13
1. Flash `{combined.bin}` to device by drag and drop.
12
14
13
15
## Metadata Header
@@ -18,19 +20,37 @@ The firmware metadata header structure can be found [here](https://github.com/AR
18
20
19
21
## Configurations
20
22
21
-
User **must** set in `mbed_app.json`:
23
+
NOTE: All these configurations must be set the same in the mbed cloud client when compiling the corresponding application for successful update operation.
24
+
25
+
### Active Application and Header
26
+
22
27
1.`update-client.application-details`, Address at which the metadata header of the active firmware is written. **Must align to flash erase boundary**
23
28
1.`application-start-address`, Address at which The application starts **Must align to vector table size boundary and flash write page boundary**. It is assumed the region between `update-client.application-details` and `application-start-address` contains only the header. MUST be the same as "target.mbed_app_start" in the application.
29
+
30
+
If the `application-start-address` is set less than one erase sector after the `update-client.application-details`, the two regions will be erased together. Otherwise the two regions will be erased separately in which case `application-start-address` must also align to **flash erase boundary**.
31
+
32
+
### Firmware Candidate Storage
33
+
34
+
1.`MBED_CLOUD_CLIENT_UPDATE_STORAGE`, This need to be set in the "macros" section of `mbed_app.json`. Choices are ARM_UCP_FLASHIAP_BLOCKDEVICE and ARM_UCP_FLASHIAP. This determines whether the firmware is stored on a blockdevice or internal flash. If blockdevice is used `ARM_UC_USE_PAL_BLOCKDEVICE=1` must also be set.
24
35
1.`update-client.storage-address`, The address in sd block device or internal flash where the firmware candidates are stored. **Must align to flash erase boundary**
25
36
1.`update-client.storage-size`, total size on the block device or internal flash reserved for firmware storage. It will be rounded up to align with flash erase sector size automatically.
26
37
1.`update-client.storage-locations`, The number of slots in the firmware storage.
27
38
1.`update-client.storage-page`, The write page size of the underlying storage.
28
39
29
-
If you are using SOTP to provide the RoT, you must set the following:
The addresses **Must align to flash erase boundary**. The sizes must be full sector sized and at least 1k large.
40
+
NOTE: See the [mbed cloud client documentation](https://cloud.mbed.com/docs/current/porting/update-k64f-port.html) for more information about storage options avaiable and porting to new platforms.
41
+
42
+
### Device Secret Key
43
+
44
+
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).
45
+
46
+
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:
47
+
1. Macro `PAL_USE_INTERNAL_FLASH=1` and `PAL_INT_FLASH_NUM_SECTIONS=2` to indicate that 2 sectors are used for SOTP.
48
+
1. Macro `ARM_UC_USE_SOTP=1` to tell bootloader to retrive RoT from SOTP.
49
+
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.
50
+
51
+
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).
32
52
33
-
All these configurations must be set the same in the mbed cloud client when compiling the corresponding application for successful update operation.
53
+
### MISC
34
54
35
55
User **may** set in `mbed_app.json`:
36
56
1.`MAX_COPY_RETRIES`, The number of retries after a failed copy attempt.
0 commit comments