mcuboot学习笔记

已于 2023-09-15 13:48:33 修改
阅读量1.6k 收藏 7
点赞数 3
文章标签： 学习 蓝牙 arm 嵌入式 stm32
于 2023-03-27 14:06:06 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_38177846/article/details/129794224
版权

mcuboot简介

MCUboot 的目标是为引导加载程序，为微控制器系统上的系统闪存布局定义一个通用基础设施，并提供一个安全的引导加载程序，使软件升级变得容易。

–摘自mcuboot官网 mcuboot.

mcuboot一些基本概念

image header：

#define IMAGE_MAGIC                 0x96f3b83d
#define IMAGE_HEADER_SIZE           32
struct image_version {
    uint8_t iv_major;
    uint8_t iv_minor;
    uint16_t iv_revision;
    uint32_t iv_build_num;
};
/** Image 头部.  所有栏位使用小端模式. */
struct image_header {
    uint32_t ih_magic;
    uint32_t ih_load_addr;
    uint16_t ih_hdr_size;           /* image头部的大小 (bytes). */
    uint16_t ih_protect_tlv_size;   /* 受保护的TLV大小 (bytes). */
    uint32_t ih_img_size;           /* image大小，不包括头部. */
    uint32_t ih_flags;              /* IMAGE_F_[...]. */
    struct image_version ih_ver;
    uint32_t _pad1;
};

ih_load_addr的作用：在使用mcuboot image tool打包image package时，可以加入–load-addr选项，指定此image slot的加载地址。如果ih_load_addr与image slot的实际存储地址（RAM或者flash中）相同，那么当前代码运行模式为XIP模式。

以STM32F407 discovery开发板为例，它是XIP模式（代码直接可以从internal flash上运行）： flash_base_addr = 0x08000000; image_header_size = 0x200; image_primary_slot_offset = 0x20000; ih_load_addr = 0x08020200 ih_load_addr与image slot在flash中存储的地址相同，则可以判定当前为XIP模式，可以直接从ih_load_addr处启动image，不需要做代码搬运动作。 如果ih_load_addr与image slot在flash中存储的地址不相同，则需要将image slot从flash中拷贝到ih_load_addr指定的地址上，再启动image。

image slot:

image slot是mcuboot管理image的最小单位，每一个slot都表示一个内容完整的，可以运行的image bin。flash的一部分可以划分为多个镜像区，每个镜像区包含两个image slot：一个primary slot和一个secondary slot。通常情况下，mcuboot bootloader只会运行primary slot中的image，因此必须配置image，以便它们可以从flash中的固定位置运行（例外情况是 direct-xip 和 ram-load 升级模式）。 如果mcuboot bootloader需要运行驻留在secondary slot中的image，则必须先将其内容复制到primary slot中，方法是交换两个镜像或覆盖主插槽的内容。 mcuboot bootloader支持基于交换或覆盖的镜像升级，但必须在构建时进行配置以选择这两种策略之一。 除了镜像区域的slot外，bootloader还需要一个scratch(暂存区)以允许可靠的镜像交换。

image trailer:

image trailer位于image的最后，在启动时，bootloader通过检查镜像尾部来确定引导交换类型，其结构如下：

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                                                               ~
~    Swap status (BOOT_MAX_IMG_SECTORS * min-write-size * 3)    ~
~                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Encryption key 0 (16 octets) [*]              |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Encryption key 1 (16 octets) [*]              |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Swap size (4 octets)                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Swap info   |           0xff padding (7 octets)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Copy done   |           0xff padding (7 octets)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Image OK    |           0xff padding (7 octets)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       MAGIC (16 octets)                       |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1. *：星标表示，仅当加密选项启用时才显示(MCUBOOT_ENC_IMAGES)。
  2. 加密密钥：密钥加密密钥 (KEY)。 镜像加密和解密需要这些密钥。
  3. 交换大小：当开始新的交换操作时，需要交换的总大小（基于具有最大镜像的插槽 + TLV）被写入此位置，以便在执行交换时重置的情况下更容易恢复。
  4. Swap info：占用一个字节，包含如下信息：
    1. 交换类型：存储在bit 0-3 中。 指示正在进行的交换操作的类型。 当 mcuboot 恢复中断的交换时，它使用此字段来确定要执行的操作类型。 该字段包含下表中的以下值之一。
    2. 镜像编号：存储在bit 4-7 中。 它在单镜像启动时始终为 0 值。 在多镜像引导的情况下，它指示中断发生时交换了哪个镜像（在所有镜像交换操作的情况下，使用相同的scratch区域。因此，如果在恢复交换操作时在scratch区发现启动状态，则该字段用于确定尾部属于哪个镜像）。
  5. 拷贝完成标志（copy done）:一个字节的信息，用来指示这个插槽中的镜像是否拷贝完成（0x01:完成，0xff:没有完成）。
  6. 镜像有效标志（image ok）:一个字节的信息，用来指示这个插槽中的镜像是否被用户确认完整有效（0x01:确认过，0xff:没有确认）。
  7. 魔数（magic）:以下的16字节，以主机字节序列(host-byte-order HBO)写入：
const uint32_t boot_img_magic[4] = {
    0xf395c277,
    0x7fefd260,
    0x0f505235,
    0x8079b62c,
};

mcuboot flash map:

mcuboot使用结构体struct flash_area来管理flash分区，每一个flash area都被赋予一个唯一的ID，通过检索flash area id就可以查询到该flash area的offset和size。

/**
 * @brief Structure describing an area on a flash device.
 *
 * Multiple flash devices may be available in the system, each of
 * which may have its own areas. For this reason, flash areas track
 * which flash device they are part of.
 */
struct flash_area {
	uint8_t fa_id;       /**This flash area's ID; unique in the system.*/
	uint8_t fa_device_id;/*** ID of the flash device this area is a part of.*/
	uint16_t pad16;
	uint32_t fa_off;     /*** This area's offset, relative to the beginning of its flash device's storage.*/
	uint32_t fa_size;    /*** This area's size, in bytes.*/
};

#define BOOTLOADER_ID   0
#define PRIMARY_ID      1
#define SECONDARY_ID    2
#define SCRATCH_ID      3

/*MCUBOOT_IMAGE_NUMBER = 1的情况*/
#define FLASH_AREA_BOOTLOADER          BOOTLOADER_ID
#define FLASH_AREA_IMAGE_PRIMARY(x)    PRIMARY_ID
#define FLASH_AREA_IMAGE_SECONDARY(x)  SECONDARY_ID
#define FLASH_AREA_IMAGE_SCRATCH       SCRATCH_ID

mcuboot image layout：

A +---------------------+
  | Header              | <- struct image_header
  +---------------------+
  | Payload             |
  +---------------------+
  | TLV area            |
  | +-----------------+ |    struct image_tlv_info with
  | | TLV area header | | <- IMAGE_TLV_PROT_INFO_MAGIC (optional)
  | +-----------------+ |
  | | Protected TLVs  | | <- Protected TLVs (struct image_tlv)
B | +-----------------+ |
  | | TLV area header | | <- struct image_tlv_info with IMAGE_TLV_INFO_MAGIC
C | +-----------------+ |
  | | SHA256 hash     | | <- hash from A - B (struct image_tlv)
D | +-----------------+ |
  | | Keyhash         | | <- indicates which pub. key for sig (struct image_tlv)
  | +-----------------+ |
  | | Signature       | | <- signature from C - D (struct image_tlv), only hash
  | +-----------------+ |
  +---------------------+
  | Padding         	| <- padding behind tlvs area
  +---------------------+ 
  | Trailer         	| <- image trailer
  +---------------------+
  • SHA256 hash:A–B之间内容的SHA256信息摘要，如果TLV area包含protected tlvs，则SHA256信息摘要包含image header + image payload + protected tlvs，如果TLV area不包含protected tlvs，则SHA256信息摘要仅包含image header + image payload.
  • Keyhash:public key hash（使用3rd-party/mcuboot/scripts/imgtool.py getpub -k your-key.pem命令生成数组格式的public key）
  • Signature:签名（使用private key对SHA256 hash做加密）
  • Padding:填充
  • Trailer:image trailer

image upgrade mode:

固件升级包含以下三种模式：

  • direct-xip mode: eXecute In Place(芯片内执行)，是指CPU直接从存储器中读取程序代码执行，而不用再读到内存中。应用程序可以直接在flash闪存内运行，不必再把代码读到系统RAM中。在此模式下，bootloader可以直接从primary slot或secondary slot运行镜像（没有必须将其移动/复制到primary slot中）。在启动时，bootloader首先在插槽中查找镜像，然后检查镜像标头中的版本号。 它选择最新的镜像（具有最高版本号）和然后检查其有效性（完整性检查、签名验证等）

  • ram loading mode：primary slot & secondary slot的地位是相同的，与 direct-xip 模式一样，此模式也通过读取镜像头中的镜像版本号来选择最新的镜像。 但是不是就地执行它，而是将最新的镜像复制到用于执行的 RAM。

  • normal mode：mcuboot bootloader只会运行primary slot，如果需要运行secondary slot，则需要将其复制到primary slot中，根据primary slot & secondary slot中image的交换/移动策略，有下面三种方式：

    • overwrite ：secondary slot直接覆盖掉primary slot

    • swap

      • use scratch : 增加一个额外的临时区(scratch)，用来作为交换primary slot & secondary slot的过渡区域
      • use move ：不使用临时区，而是在构建primary slot的存储区域时，比secondary slot多使用一个sector，然后完成image的交换

mcuboot image升级策略

  • fih_int boot_go(struct boot_rsp *rsp)

    • fih_int context_boot_go(struct boot_loader_state *state, struct boot_rsp *rsp)

      • 三次遍历所有image的primary slot & secondary slot

        • 第一次遍历：完成之前所有没中断的swap operation（如果有的话），确定此次启动的swap type。比较重要的函数：void boot_prepare_image_for_update(struct boot_loader_state *state, struct boot_status *bs)。

        • 第二次遍历：根据上一次遍历返回的swap type，如果需要swap的话，执行int boot_perform_update(struct boot_loader_state *state, struct boot_status *bs)，完成primary slot & secondary slot的交换。在primary slot image trailer中设置image ok & copy done标志。

          #ifndef MCUBOOT_OVERWRITE_ONLY
    /* The following state needs image_ok be explicitly set after the
     * swap was finished to avoid a new revert.
     */
    swap_type = BOOT_SWAP_TYPE(state);
    if (swap_type == BOOT_SWAP_TYPE_REVERT ||
            swap_type == BOOT_SWAP_TYPE_PERM) {
        rc = swap_set_image_ok(BOOT_CURR_IMG(state));
        if (rc != 0) {
            BOOT_SWAP_TYPE(state) = swap_type = BOOT_SWAP_TYPE_PANIC;
        }
    }
    if (BOOT_IS_UPGRADE(swap_type)) {
        rc = swap_set_copy_done(BOOT_CURR_IMG(state));
        if (rc != 0) {
            BOOT_SWAP_TYPE(state) = BOOT_SWAP_TYPE_PANIC;
        }
    }
#endif /* !MCUBOOT_OVERWRITE_ONLY */

        • 第三次遍历：此时所有的image swap都已经完成，在启动primary slot之前，需要先验证下primary slot是否有效 (fih_int boot_validate_slot(struct boot_loader_state *state, int slot, struct boot_status *bs))。验证的大致步骤是：

          • 1）计算image header + image payload ( + protected tlv)内容的sha256 hash，将sha256 hash计算结果同tlv area中的sha256 hash做比较，验证image的完整性。
          • 2）从tlv area中读取出IMAGE_TLV_KEYHASH（public key hash），然后在用户的public key（bootutil_keys[]）中搜索是否有相同的public key，这一步是验证public key的有效性。
          • 3）从tlv area中读取出EXPECTED_SIG_TLV（签名，即对sha256 hash摘要使用private key加密），然后使用步骤2）中的public key解密EXPECTED_SIG_TLV，将解密结果同步骤1）中计算出的sha256 hash作比较，相同的话表示验签成功，否则验签失败。

      • 最后返回primary slot的位置和image header信息，交由用户的代码启动primary slot

新的升级

MCUBOOT_OVERWRITE_ONLY

这种模式是直接用secondary slot覆盖primary slot，因为没有备份区域，所以覆盖之后无法恢复primary slot。

MCUBOOT_SWAP_USING_SCRATCH

增加一个额外的临时区(scratch)，用来作为交换primary slot & secondary slot的过渡区域，交换之后如果secondary slot无法运行，还可以执行revert操作，恢复primary slot到交换之前的状态。此方式的优点是可以对原版本做保护，缺点也显而易见，flash的使用会增大，同时scratch区域会被频繁擦写，增加了flash损耗。

关于scratch，还有些补充说明，不论primary slot & secondary slot占用几个sector，假设scratch的大小设置为只占用一个sector的大小，此时primary slot & secondary slot交换的最小单位是一个flash sector。所以当primary slot & secondary slot较大时（占用多个sector size），那么scratch将会被频繁的擦写，这时scratch size的大小就需要重新慎重考虑，因为flash的擦写是有次数限制的。

MCUBOOT_SWAP_USING_MOVE

不使用临时区，而是在构建primary slot的存储区域时，比secondary slot多使用一个sector，然后完成image的交换：

1）将主插槽的所有扇区向上移动一个扇区。 从 N=0 开始：
2）将第 N 个扇区从次插槽复制到主插槽的第 N 个扇区。
3）将第 (N+1) 个扇区从主槽复制到辅助槽的第 N 个扇区。
4）重复第 2 步和第 3 步，直到交换所有插槽的扇区。

假设primary slot & secondary slot image内容都占用5个sector大小，假如使用not use scratch swap这种交换方式：
primary slot
+-----------+-----------+-----------+-----------+-----------+-----------+
| sector0   | sector1	|  sector2  | sector3	| sector4	|			|
+-----------+-----------+-----------+-----------+-----------+-----------+
整体向右移动一个sector
+-----------+-----------+-----------+-----------+-----------+-----------+
|     	    | sector0   | sector1	|  sector2  | sector3	| sector4	|
+-----------+-----------+-----------+-----------+-----------+-----------+
secondary slot
+-----------+-----------+-----------+-----------+-----------+
| sector0   | sector1	|  sector2  | sector3	| sector4	|
+-----------+-----------+-----------+-----------+-----------+
然后以插空的方式完成primary slot & secondary slot的交换

#define BOOTLOADER_SIZE                     (64 * 1024 )
#define APPLICATION_SIZE                    (128 * 1024)
#define BOOTLOADER_START_ADDRESS            (ADDR_FLASH_SECTOR_0)
#define APPLICATION_PRIMARY_START_ADDRESS   (ADDR_FLASH_SECTOR_5)
#define APPLICATION_SECONDARY_START_ADDRESS (ADDR_FLASH_SECTOR_7)
#define BOOTLOADER_SECTOR_SIZE              (16 * 1024)
#define APPLICATION_SECTOR_SIZE             (128 * 1024)
static const struct flash_area bootloader = {
    .fa_id = FLASH_AREA_BOOTLOADER,
    .fa_device_id = FLASH_DEVICE_INTERNAL_FLASH,
    .fa_off = BOOTLOADER_START_ADDRESS,
    .fa_size = BOOTLOADER_SIZE,
};
static const struct flash_area primary_img0 = {
    .fa_id = FLASH_AREA_IMAGE_PRIMARY(0),
    .fa_device_id = FLASH_DEVICE_INTERNAL_FLASH,
    .fa_off = APPLICATION_PRIMARY_START_ADDRESS,
    .fa_size = APPLICATION_SIZE * 2,
};
static const struct flash_area secondary_img0 = {
    .fa_id = FLASH_AREA_IMAGE_SECONDARY(0),
    .fa_device_id = FLASH_DEVICE_INTERNAL_FLASH,
    .fa_off = APPLICATION_SECONDARY_START_ADDRESS,
    .fa_size = APPLICATION_SIZE,
};
void swap_run(struct boot_loader_state *state, struct boot_status *bs, uint32_t copy_size)
{
    uint32_t sz;
    uint32_t sector_sz;
    uint32_t idx;
    uint32_t trailer_sz;
    uint32_t first_trailer_idx;
    uint8_t image_index;
    const struct flash_area *fap_pri;
    const struct flash_area *fap_sec;
    int rc;
    sz = 0;
    g_last_idx = 0;
    sector_sz = boot_img_sector_size(state, BOOT_PRIMARY_SLOT, 0);
    while (1) {
        sz += sector_sz;
        /* Skip to next sector because all sectors will be moved up. */
        g_last_idx++;
        if (sz >= copy_size) {
            break;
        }
    }
    /*
     * When starting a new swap upgrade, check that there is enough space.
     */
    if (boot_status_is_reset(bs)) {
        sz = 0;
        trailer_sz = boot_trailer_sz(BOOT_WRITE_SZ(state));
        first_trailer_idx = boot_img_num_sectors(state, BOOT_PRIMARY_SLOT) - 1;
        while (1) {
            sz += sector_sz;
            if  (sz >= trailer_sz) {
                break;
            }
            first_trailer_idx--;
        }
        if (g_last_idx >= first_trailer_idx) {
            BOOT_LOG_WRN("Not enough free space to run swap upgrade");
            bs->swap_type = BOOT_SWAP_TYPE_NONE;
            return;
        }
    }
	...省略部分代码
}
在mcuboot_config.h中打开MCUBOOT_SWAP_USING_MOVE，primary slot size配置为secondary slot size的两倍，且两个slot sector size相同，swap_run()会遇到"Not enough free space to run swap upgrade"错误，这里的逻辑无法理解。
swap use move的所有条件都已满足，且image payload size + image trailer size没有超过一个sector size.

恢复被中断的升级

MCUBOOT_OVERWRITE_ONLY

MCUBOOT_SWAP_USING_SCRATCH

MCUBOOT_SWAP_USING_MOVE

to do…

如何选择合适的升级方法呢？

升级方式优点缺点
MCUBOOT_OVERWRITE_ONLY不会使用额外的flash区域，算法简单，维护简单不能保护源版本，升级失败后设备可能变砖
MCUBOOT_SWAP_USING_SCRATCH可以保护源版本，升级失败后可以恢复到原来的版本，容错率高flash的使用量增加，scratch区域flash擦写次数成倍增加，损坏风险大大增加，算法复杂，维护困难
MCUBOOT_SWAP_USING_MOVE可以保护源版本，升级失败后可以恢复到原来的版本，容错率高，相对MCUBOOT_SWAP_USING_SCRATCH方式，flash擦写更加均匀此算法仅限于拥有相同布局的flash， 所有插槽的扇区应具有相同的大小

根据flash容量、flash擦写损耗、升级算法的复杂程度几方面来选择最适合你的方案。

mcuboot安全

mcuboot没有实现自己的加密算法库，可以通过开启Mbed-TLS or Tinycrypt来启用第三方加密算法库：

/* Uncomment to use ARM's mbedTLS cryptographic primitives */
#define MCUBOOT_USE_MBED_TLS

/* Uncomment to use Tinycrypt's. */
#define MCUBOOT_USE_TINYCRYPT

mcuboot image tool脚本的使用

python3 ./3rd-party/mcuboot/scripts/imgtool.py -h

Usage: imgtool.py [OPTIONS] COMMAND [ARGS]...

Options:
  -h, --help  Show this message and exit.

Commands:
  create   Create a signed or unsigned image INFILE and OUTFILE are parsed...
  getpriv  Dump private key from keypair
  getpub   Dump public key from keypair
  keygen   Generate pub/private keypair
  sign     Create a signed or unsigned image INFILE and OUTFILE are parsed...
  verify   Check that signed image can be verified by given key
  version  Print imgtool version information

mcuboot移植

mcuboot在stm32f407上的移植例程

熟能生巧啊
关注
  • 3
    点赞
  • 踩
  • 7
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
mtb-example-psoc6-mcuboot-basic:该示例演示了如何使用MCUboot（用于32位MCU的开源安全引导加载程序）为PSoC 6构建bootlaoder应用程序。 该引导程序在CM0 +上运行
04-09
PSoC 6 MCU：基于MCUboot的基本Bootloader 是一个开放源代码库，可为32位MCU开发安全的引导加载程序应用程序。 MCUboot是流行的IoT操作系统（例如Zephyr和Apache Mynewt）中的主要引导程序。 本示例演示了将MCUboot与PSoC 6 MCU配合使用，特别是PSoC:trade_mark:62/63 MCU系列。 本示例捆绑了两个应用程序： Bootloader应用程序：实现由CM0 +运行的基于MCUboot的基本Bootloader应用程序。 引导加载程序处理映像身份验证和升级。 当映像有效时，引导程序通过将映像的起始地址传递给CM4 CPU来启动/运行映像。 眨眼应用程序：实现由CM4运行的简单LED眨眼应用程序。 您可以通过以下方式之一来构建此应用程序。 该应用程序根据是以引导模式还是升级模式构建的，以不同的速率切换用户LED。 引导模式：将应用
实战：瑞萨Renesas RA2L1 MCUboot
沙子的专栏
09-20 322
瑞萨灵活软件包(FSP)集成了整个RA MCU的MCUboot端口，本文介绍了再RA2L1开发板使用MCUboot，稍作修改可以应用于物联网下的远程升级固件。
Zephyr应用笔记：mcuboot引导程序简单介绍
u010018991的博客
03-08 4212
本文对mcuboot（version 1.1.0）做一个简单介绍供参考，Github地址：https://github.com/runtimeco/mcuboot以下内容都是针对（version 1.1.0）做介绍：目前支持三种操作系统：ZephyrMynewtRIOT镜像跳转方式支持两种：1、两块镜像区域image_0和image_1；2、三块镜像区域image_0、image_1和scratc...
通用MCU BOOT接口基础指令使用指引
leo_zwliao的博客
10-26 1123
MCU 的 BOOT 接口基础指令，便于使用国民技术 BOOT Loader 进行下载开 发。本使用指南主要描述 N32G45x 系列、N32G4FR 系列、N32WB452 系列。这里介绍下文阐述中的一些约定，其中，“”代表必须包含的字段，“()”代表根据参数。详细SDK tel：14706656775。3. 逻辑层指令数据结构。1.1.2 数据结构。
mcuboot bootloader官方设计文档
weixin_38177846的博客
02-15 1532
mcuboot官方设计文档
Zephyr MCUBoot
qq_36115224的博客
03-21 577
MCUBoot 是可配置的安全引导加载程序，由多个行业领导者维护。ECDSA-P256RSA-2048RSA-3072默认情况下，它支持映像回滚，下载的固件会被试验性地启动一次。初次升级引导时，如果升级映像将自身标记为已确认，则其将被保留为主映像文件。如果升级映像未被确认，则后续引导将回退至 上一个被确认的映像。如果没有可用的有效映像，作为一种安全 预防措施，设备会将自己变砖。
java学习笔记总结
04-02
自己几个月的学习总结，一些解决问题的办法，很实用，希望对大家有所帮助！
java学习笔记markdown
03-12
狂神说java学习笔记，markdown版
MAKE 学习 笔记make
最新发布
04-22
MAKE学习笔记
学习笔记学习笔记学习笔记
01-29
学习笔记学习笔记学习笔记
Boot_Loader 详解，非常详细
01-11
Boot_Loader 详解，非常详细 Boot_Loader 详解，非常详细 Boot_Loader 详解，非常详细
JavaScript基础学习笔记
10-25
黑马视频记录下来的学习笔记
mcu 启动流程
weixin_42734533的博客
07-19 5679
2、复位中断服务程序执行的最终结果是跳转至C程序的main函数，如上图中标号2️⃣所示，而main函数应该是一个死循环，是一个永不返回的函数。stm32内部闪存的起始地址为0x8000000，程序从此处写入，中断向量表位于该位置，首先从0x8000000取出MSP的栈顶指针（设置堆栈），然后从中断向量表中取出复位中断向量，并执行复位中断程序来完成启动。建立中断向量表：中断向量表作为中断源的识别标志，可以形成相应的中断入口地址，或者中断服务程序的入口地址的偏移量和段基值。
痞子衡嵌入式：恩智浦i.MX RTxxx系列MCU启动那些事（1）- Boot简介
痞子衡嵌入式
12-04 875
　　大家好，我是痞子衡，是正经搞技术的痞子。今天痞子衡给大家介绍的是恩智浦i.MX RTxxx系列MCU的BootROM功能简介。 　　截止目前为止i.MX RTxxx系列已公布的芯片仅有一款i.MXRT600（还有几款正在研发测试之中），所以本文的研究对象主要是i.MXRT600，i.MXRT600是i.MXRTxxx系列的开山之作，功能模块非常全面，其BootROM特性基本可以涵盖...
zephyr 的MCUBOOT 使用笔记---基于Nordic 52840
supperThomas的专栏
08-08 7010
MCUBOOT 什么是MCUBOOT mcuboot 和常用的BootLoader有一些区别，实际上mcuboot相当于一个安全的引导程序，（注意这里的mcuboot只关注于安全引导，像我们常用的BootLoader的传输啊什么之类的，并不在mcuboot定义范围内） mcuboot有以下功能 固件更新的安全性检查，固件签名 标准的FLASH MAP分配规则 移植起来比较方便 还可以通过添加config的方式添加如下功能： 加解密固件二进制 容错升级（意外重启之后恢复） 恢复系统 参考链接 MCUB
MCU端 Boot+App设计方案
酒无忧的博客
11-28 3299
本文结合当前主流主机厂的升级规范来介绍不用MCU升级方案及其优缺点，除了本文提及的方案外还有很多其他的升级方案，升级方案的设定要考虑到客户需求以及硬件资源等因素。目前主流的客户需求，要求存储区划分要有Boot段、Config段、App A分区和App B分区。其中Boot端需要满足客户的Bootloader升级要求，Config端用于存储Boot和App版本以及一些刷写后需要保存的一些系统状态和flags。App A/B分区主要用于升级切换、回滚等操作。
痞子衡嵌入式：MCUBootUtility v3.5发布，支持串行NOR的ECC及双程序启动
痞子衡嵌入式
03-20 534
-- 　　痞子衡维护的 NXP-MCUBootUtility 工具距离上一个大版本(v3.4.0)发布过去半年了，这一次痞子衡为大家带来了版本升级 v3.5.0，这个版本主要有几个非常重要的更新需要跟大家特别说明一下。 一、v3.5更新记录 二、几个不可忽视的更新 2.1 支持串行NOR双程序启动下载 　　部分 i.MXRT 型号 BootROM 支持串行 NOR Flash 的双程序启动，这...
Zephyr应用笔记：mcuboot引导zephyr镜像
u010018991的博客
03-08 2127
第一次写博客且本人文字组织水平一直很low，所以大家将就看吧。博客的宗旨：看过这篇文章的人都能够顺利开发zephyr的boot。boot采用mcuboot（version 1.1.0），Github地址：https://github.com/runtimeco/mcubootzephyr（version 1.10.0），Github地址：https://github.com/zephyrproje...
btstack ble ota开发笔记(2)-mcuboot移植
weixin_38177846的博客
07-20 657
紧接上一篇文章，要实现一个完整的ota demo，除了实现ota image的传输通道外，还需要“bootloader”这个角色来帮我们实现ota image的校验、安全、引导以及启动，这里我选择开源的组件mcuboot，下面开始介绍mcuboot在stm32f4-discovery上的移植。首先估算下bootloader & application image的大小，确定好flash的分布情况，因为后续会涉及到flash的操作（读、写、擦除），为了方便程序的编写，各个image area在flash中的起
CAN 总线学习笔记
01-18
CAN总线学习笔记主要包括CAN总线的相关概念和CAN自收发程序的解读。这些学习笔记可以帮助初学者了解CAN总线的基本原理和应用。 在CAN总线学习笔记一中，作者提到了学习新知识时网络的重要性，尤其是IT技术的学习。作者指出，虽然关于CAN总线的介绍很多，但大多雷同，可能是因为不断转贴的结果。这篇学习笔记可能会介绍CAN总线的基本概念，如CAN总线的工作原理、通信方式、帧格式等。 在CAN总线学习笔记二中，作者提到了解读别人的程序是一项费时费力的任务，但对于初学者来说，参考别人的程序是必不可少的。这篇学习笔记可能会解读一个CAN自收发程序，帮助初学者理解CAN总线的数据收发过程和相关编程技巧。 总的来说，CAN总线学习笔记可以帮助初学者快速入门CAN总线技术，并了解如何使用CAN总线进行数据通信和编程。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值