代码拉取完成，页面将自动刷新
Generic bootloader to be used in conjunction with mbed-cloud-client.
mbed-cli https://github.com/ARMmbed/mbed-climbed deploy to pull in dependenciesmbed compile -t GCC_ARM -m (K64F|NUCLEO_F429ZI|UBLOX_EVK_ODIN_W2) --profile=tiny.jsonpython 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}.{combined.bin} to device by drag and drop.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. 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.
NOTE: All these configurations must be set the same in the mbed cloud client when compiling the corresponding application for successful update operation.
update-client.application-details, Address at which the metadata header of the active firmware is written. Must align to flash erase boundaryapplication-start-address, Address at which the application starts Must align to vector table size boundary and flash write page boundary.application-jump-address, Optional address for the application's entry point (vector table) if this is different from application-start-address.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.
If application-jump-address is not set, the application-start-address will be used as the application's entry point. The entry point MUST be the same as "target.mbed_app_start" in the application.
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.update-client.storage-address, The address in sd block device or internal flash where the firmware candidates are stored. Must align to flash erase boundaryupdate-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.update-client.storage-locations, The number of slots in the firmware storage.update-client.storage-page, The write page size of the underlying storage.NOTE: See the mbed cloud client documentation for more information about storage options avaiable and porting to new platforms.
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.
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:
ARM_BOOTLOADER_USE_NVSTORE_ROT=1 to enable the RoT implementation here.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.
User may set in mbed_app.json:
MAX_COPY_RETRIES, The number of retries after a failed copy attempt.MAX_FIRMWARE_LOCATIONS, The maximum number of stored firmware candidates.MAX_BOOT_RETRIES, The number of retries after a failed forward to application.SHOW_PROGRESS_BAR, Set to 1 to print a progress bar for various processes. +--------------------------+
| LittleFS |
| (Does not concern |
| Bootloader) | update-client.storage-address
+--------------------------+ <-+ +
| | update-client.storage-size
| |
| |
|Firmware Candidate Storage|
| |
| |
| |
+--------------------------+ <-+ update-client.storage-address
| |
| |
| |
| Active App |
| |
| |
| |
+--------------------------+ <-+ application-start-address
| |
|Active App Metadata Header|
| |
+--------------------------+ <-+ update-client.application-details
| NVSTORE_2 |
+--------------------------+ <-+ nvstore.area_2_address
| NVSTORE_1 |
+--------------------------+ <-+ nvstore.area_1_address
| |
| Bootloader |
| |
+--------------------------+ <-+ 0
--app-config configs/internal_flash_sotp.json. By default the firmware storage region and filesystem is on external sd card.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.
Vector Table Size Boundary: The ARM architecture dictates that the Vector table of the application must be placed at an address that aligns to the next power of 2 of the size of the vector table.
The firmware update candidates can be stored on an external sd card. The firmware is stored sequentially on the block device. The expected layout is as follows:
+--------------------------+<-+ End of SD card block device
| |
+--------------------------+<-+ update-client.storage-size + update-client.storage-address
| |
+--------------------------+
| |
| Firmware Candidate 1 |
| |
+--------------------------+
| Firmware Candidate 1 |
| Metadata Header |
+--------------------------+
| |
+--------------------------+
| |
| Firmware Candidate 0 |
| |
+--------------------------+
| Firmware Candidate 0 |
| Metadata Header |
+--------------------------+ <-+ update-client.storage-address
| |
+--------------------------+ <-+ Start of SD card block device (ie 0x0)
Debug prints can be turned on by enabling the define #define tr_debug(fmt, ...) printf("[DBG ] " fmt "\r\n", ##__VA_ARGS__) in source/bootloader_common.h and setting the ARM_UC_ALL_TRACE_ENABLE=1 macro on command line mbed compile -DARM_UC_ALL_TRACE_ENABLE=1.
此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。
马建仓 AI 助手