UG103.6: Bootloader Fundamentals (Rev. 1.6)

• 1. 引言
  • 1.1 Standalone Bootloader
  • 1.2 Application Bootloader
• 2. 关于 Gecko Bootloader
  • 2.1 特性
    • 2.1.1 可现场更新
      • Series 1
      • Series 2
    • 2.1.2 安全启动
    • 2.1.3 签名的 GBL 固件更新映像文件
    • 2.1.4 加密的 GBL 固件更新映像文件
  • 2.2 适用性
• 3. 用于引导加载的存储空间
  • 3.1 Gecko Bootloader
  • 3.2 Legacy Ember Bootloaders
• 4. 设计决策
  • 4.1 Gecko Bootloader
  • 4.2 Legacy Ember Bootloaders
• 5. Ember 引导加载文件格式
  • 5.1 基本文件格式
    • 5.1.1 未加密的 Tag 说明
    • 5.1.2 数据验证
  • 5.2 加密的 Ember 引导加载文件格式
    • 5.2.1 加密的 Tag 说明
    • 5.2.2 Nonce 生成
    • 5.2.3 映像校验
  • 5.3 Ember 引导加载（EBL）文件

本文档介绍了 Silicon Labs 网络设备的引导加载（Bootloading）。总结了 Silicon Labs Gecko Bootloader 与 legacy Ember Bootloader 之间的差异，并讨论了它们对平台的适用性。描述了 standalone bootloader 和 application bootloader 的概念，并讨论了它们的相对优势和劣势。此外，还介绍了每种方法的设计和实现细节。最后，描述了 bootloader 的文件格式。

1. 引言

Bootloader 是一个存储在预留 flash 中的程序，它可以初始化设备、更新固件映像，并可能执行一些完整性检查。无论是通过串行通信还是无线方式，都可以根据需要进行固件映像更新。Production-level 编程通常在产品制造过程中完成，但有时会希望能够在生产完成后进行重新编程。更重要的是，这能够在设备部署后更新具有新特性和错误修复的固件。这使得更新固件映像成为可能。

Silicon Labs 支持不使用 bootloader 的设备，但这需要外部硬件（如 Debug Adapter（Silicon Labs ISA3 或 Wireless Starter Kit (WSTK)）或第三方的 SerialWire/JTAG 编程设备）来更新固件。没有 bootloader 的设备在部署后无法使用受支持的方式更新固件，因此 Silicon Labs 强烈推荐使用 bootloader。

在 2017 年 3 月，Silicon Labs 推出了 Gecko Bootloader，这是一个可通过 Simplicity Studio IDE 配置的代码库，用于生成可与各种 Silicon Labs 协议栈一起使用的 bootloader。Gecko Bootloader 可以与 EFM32 和 EFR32 Series 1 及之后的设备一起使用。Legacy Ember bootloader 将继续提供与 EM3xx 平台一起使用。2018 年，Gecko SDK 套件的 2x 版中删除了对 EFR32 上的 legacy Ember Bootloader 支持。2017 年 12 月，Bluetooth SDK 的 2.7.0 版本中删除了对 legacy Bluetooth Bootloader 的支持。

Gecko Bootloader 和 legacy Ember Bootloader 使用自定义的更新映像文件格式。由 Gecko Bootloader 生成的 application Bootloader 的更新映像文件是 GBL（Gecko BootLoader）文件，其在 UG266: Silicon Labs Gecko Bootloader User’s Guide 中进行了描述。legacy Ember Bootloader 使用的更新映像文件是 EBL（Ember BootLoader）文件，其将在 5. Ember 引导加载文件格式 中进一步介绍。

引导加载一个固件更新映像有两种方式。第一种是无线方式（OTA，Over-The-Air），即通过无线网络，如下图所示。

第二种是通过设备的硬连线链路。下图展示 SoC（使用 UART、SPI 或 USB）和 NCP（使用 UART 或 SPI）的串行引导加载用例。

Silicon Labs 网络设备以两种不同的模式使用 bootloader 来执行固件更新：standalone bootloader 和 application bootloader。Application bootloader 又进一步地划分为使用外部存储和使用本地存储（用于下载更新映像）。这两种 bootloader 类型将在接下来的两节中讨论。

本文档中描述的固件更新情况假定为源节点（通过 serial 或 OTA 链路将固件映像发送到目标的设备）通过其他方式获取新固件。例如，如果本地 ZigBee 网络上的设备已连接到以太网网关，则该设备可以通过 Internet 获取或接收这些固件更新。固件更新过程的这一必要部分取决于系统，这超出了本文档的范围。

1.1 Standalone Bootloader

Standalone bootloader 是使用外部通信接口（如 UART 或 SPI）来获取 application 映像的程序。Standalone 固件更新是一个 single-stage 过程，这允许将 application 映像放入 flash 来覆盖现有的 application 映像，而无需 application 本身的参与。Standalone bootloader 与在 flash 中正在运行的 application 之间几乎没有交互。通常，application 与 bootloader 交互的唯一时间是它请求重新引导到 bootloader。一旦 bootloader 运行，它就会通过物理连接（如 UART 或 SPI）或无线方式接收包含（新）固件映像的固件更新包。

启动固件更新过程后，新代码将覆盖现有的协议栈和 application 代码。如果在此过程中发生任何错误，则无法恢复代码并且必须重新开始该过程。有关 legacy standalone bootloader 的更多信息，请参阅 AN760: Using the Ember Standalone Bootloader 。有关将 Gecko Bootloader 配置为 standalone bootloader 的信息，请参阅 UG266: Silicon Labs Gecko Bootloader User’s Guide。

1.2 Application Bootloader

Application bootloader 在正在运行的 application 下载完更新映像文件后开始固件更新过程。Application bootloader 期望映像存放在可访问的外部存储器中或 main flash 中（如果芯片具有足够的存储空间来支持此本地存储模型）。

Application bootloader 依赖 application 来获取新的固件映像。Application 可以以任何便捷的方式（UART、OTA 等）下载映像，但必须将其存储在称为下载空间（download space）的区域中。下载空间通常是外部存储器设备（如 EEPROM 或 dataflash），但在使用 application bootloader 的本地存储变体时，它也可以是芯片内部 flash 的一部分。存储新映像后，将调用 application bootloader 来验证新映像并将其从下载空间复制到 flash 中。

由于 application bootloader 不参与映像的获取，并且映像在固件更新过程开始之前下载，因此下载错误不会对正在运行的映像产生负面影响。下载过程可以随时重新开始或暂停。可以在开始固件更新过程之前验证所下载映像的完整性，以防止损坏或无功能的映像被应用。

Legacy Ember application bootloader 提供 UART standalone bootloader 能力来作为恢复机制，以防止正在运行的 application 映像和升级映像被损坏。可以将 Gecko Bootloader 配置为接受一个多升级映像的列表，以尝试验证和应用。这允许 Gecko Bootloader 存储更新映像的备份副本，如果第一个映像损坏，它可以访问该副本。

注意，EmberZNet NCP 平台不使用 application bootloader，因为 application 代码驻留在 host 上而不是直接驻留在 NCP 上。取而代之的是，充当串行协处理器的设备将使用 standalone bootloader，该 bootloader 旨在通过与预期的 NCP 固件使用的相同串行接口接受代码。但是，host application（与 NCP 位于不同的 MCU）可以使用任何合适的引导加载方案。Silicon Labs Bluetooth NCP 可以使用 legacy OTA DFU bootloader。

有关 application bootloader 的详情，可以参阅 UG266: Silicon Labs Gecko Bootloader User’s Guide 和 AN772: Using the Ember Application Bootloader 。

2. 关于 Gecko Bootloader

Silicon Labs Gecko Bootloader 是一个可配置的代码库，可以与所有 newer Silicon Labs Gecko MCU 和 wireless MCU 一起使用。它使用 GBL 格式的更新映像文件。Gecko Bootloader 在 Series 1 设备上采用一个 two-stage 设计，其中 first stage bootloader 用于更新 main bootloader。在 Series 2 设备上，first stage bootloader 被 SE（Secure Element，安全元素）或 VSE（Virtual Secure Element，虚拟安全元素）代替，而 Gecko Bootloader 由 main bootloader 构成。具有 first stage bootloader 或 SE/VSE 可以对 main bootloader 进行现场更新（包括添加新功能、更改通信协议、添加新安全特性和修复程序等）。Gecko Bootloader 由三个组件组成：

• Core ：包含 bootloader 的主要功能。它还包含写入内部 main flash、执行 bootloader 更新和重置到 application 中（标记合适的重置原因）的功能。
• Driver ：不同的引导加载应用需要不同的硬件驱动程序以供 bootloader 的其他组件使用。
• Plugin ：main bootloader 的所有可选项或用于不同配置的选择被实现为 plugin。每个 plugin 都有一个通用的头文件和一个或多个实现。当前版本包含 UART 和 SPI 通信协议、SPI flash 存储、内部 flash 存储和不同的加密操作等功能的 plugin。

2.1 特性

Gecko Bootloader 特性包括：

• 可现场更新（Field-updateable）
• 安全启动（Secure boot）
• 签名的 GBL 固件更新映像文件（Signed GBL firmware update image file）
• 加密的 GBL 固件更新映像文件（Encrypted GBL firmware update image file）

这些特性在随后的小节中进行了总结，并在 UG266: Silicon Labs Gecko Bootloader User Guide 中详细地描述。有关使用 Gecko Bootloader 的特定于协议的信息可在以下文档中找到：

• AN1084: Using the Gecko Bootloader with EmberZNet
• UG235.06: Bootloading and OTA with Silicon Labs Connect
• AN1086: Using the Gecko Bootloader with Silicon Labs Bluetooth Applications

2.1.1 可现场更新

Series 1

在 EFM32 和 EFR32 Series 1 设备上，Gecko bootloader 的现场更新功能由一个 two-stage 设计提供，该 bootloader 具有 first stage 和 main stage。Bootloader 的 first stage 是不可现场更新的，并且只能通过读写内部 flash 中的固定地址来更新 main bootloader。要执行 main bootloader 更新，正在运行的 main bootloader 将验证 bootloader 更新映像的完整性和真实性，然后将其写入内部 flash，并发出一个 reboot 以重新引导到 first stage bootloader 中。First stage bootloader 会先验证 main bootloader 更新映像的完整性，然后再将其复制到 main bootloader 的位置上，从而完成更新。

Series 2

在 Series 2 设备上，SE/VSE 提供了 Gecko bootloader 的现场更新功能。要执行 main bootloader 更新，正在运行的 main bootloader 将验证 bootloader 更新映像的完整性和真实性，然后将其写入内部 flash，并请求 SE/VSE 安装更新。SE/VSE 可选地先验证 main bootloader 更新映像的真实性，然后再将其复制到 main bootloader 的位置上，以完成更新。可以使用相同的机制来更新 SE/VSE 自身。

2.1.2 安全启动

安全启动（Secure boot）旨在防止不受信任的映像在设备上运行。启用安全启动后，Bootloader 会使用非对称加密技术在每次启动时强制执行 application 映像的加密签名验证。使用的签名算法是 ECDSA-P256-SHA256。公钥在制造期间写入设备，而私钥保密。这确保了 application 是由可信方创建和签名的。

2.1.3 签名的 GBL 固件更新映像文件

除了安全启动之外，Gecko Bootloader 还支持强制执行更新映像文件的加密签名验证。这允许 bootloader 和 application 在开始更新过程之前验证 application 或 bootloader 的更新是否来自受信任的源。使用的签名算法是 ECDSA-P256-SHA256。公钥与安全引导的密钥相同，在制造期间写入设备，而私钥不分发。这可确保 GBL 文件由受信任方创建和签名。

2.1.4 加密的 GBL 固件更新映像文件

GBL 更新文件也可以加密，以防止窃听者获取明文固件映像。使用的加密算法是 AES-CTR-128，加密密钥在制造期间写入设备。

2.2 适用性

下表展示了可以与不同平台一起使用的 bootloader。

3. 用于引导加载的存储空间

3.1 Gecko Bootloader

Series 1 设备上的 first stage bootloader 占用单个 flash page。在使用 2 kB flash page 的设备上（如 EFR32MG1），意味着 first stage 需要 2 kB。

Main bootloader 的大小取决于所需的功能。典型的 bootloader 配置为：Series 1 设备的 main bootloader 占用 14 kB flash，使两个 bootloader 的大小合计达到 16 kB。

Silicon Labs 建议为 Series 1 和 EFR32xG21 的 bootloader 保留至少 16 kB；为 EFR32xG22 的 bootloader 保留至少 24 kB。

在 EFR32xG1 设备上（Mighty Gecko、Flex Gecko 和 Blue Gecko 系列），bootloader 位于 main flash 中：

• First stage bootloader @ 0x0
• Main bootloader @ 0x800
• Application @ 0x4000

在 EFR32xG12 及更高版本的 Series 1 设备上，bootloader 位于信息块（Information Block）的 bootloader 区域中：

• Application @ 0x0
• First stage bootloader @ 0x0FE10000
• Main bootloader @ 0x0FE10800

在 EFR32xG21 上，main bootloader bootloader 位于 main flash 中：

• Main bootloader @ 0x0
• Application @ 0x4000

在 EFR32xG22 上，main bootloader bootloader 位于 main flash 中：

• Main bootloader @ 0x0
• Application @ 0x6000

3.2 Legacy Ember Bootloaders

下图展示了典型 Silicon Labs mesh 网络 SOC 或 NCP 的存储器映射。

对于每个 Silicon Labs mesh 网络平台（在 SOC 或 NCP 使用情况下），在 main flash 的起始处保留一个 flash 块（通常为 8 kB 或 16 kB，具体取决于所使用的 IC）来保存 bootloader，并且在 flash 的末尾保留一个 flash 块（在 4 kB 和 36 kB 之间，具体取决于实现），用于 simulated EEPROM。除了 Local Storage Application Bootloader 外，其他所有情况下剩余的存储空间都是非保留的，可用于保存网络协议栈和 application 代码。

4. 设计决策

部署哪种类型的 bootloader 取决于许多因素。注意，平台类型和可用的 flash 可能会限制 bootloader 的选择。

与此相关的一些问题是：

• 设备从何处获得新的更新映像？是否通过网络协议进行的无线传输？是否使用单独的接口连接到 Internet？
• 设备是否有外部存储器芯片来存储新的更新映像？如果没有，是否有足够的内部 flash 来存储最大的预期 application 映像（当前的和新下载的副本）？
• 如果设备通过无线方式接收新的映像，它是否会多次跳转到持有下载映像的服务器？
• 需要什么样的映像安全性？
• 将使用哪种通信驱动程序（在单协议的情况下）？
• 用例是否需要多个协议？

4.1 Gecko Bootloader

Gecko Bootloader 平台的可配置设计意味着开发人员可以创建 bootloader 以适应几乎全部的设计选择。有关详细信息，请参阅 UG266: Silicon Labs Gecko Bootloader User’s Guide 。

4.2 Legacy Ember Bootloaders

下表展示了 legacy Ember bootloaders 的不同类型及支持的特性。

5. Ember 引导加载文件格式

本节中描述的引导加载文件格式由 Simplicity Commander 命令生成。有关更多信息，请参阅 UG162: Simplicity Commander Reference Guide 。

注意：有关 Gecko 引导加载文件格式的类似信息，请参见 UG266: Silicon Labs Gecko Bootloader User’s Guide 。

5.1 基本文件格式

所有 Ember Bootloader 均要求其处理的映像为 EBL（Ember Bootload）文件格式。EBL 文件格式由许多 tag 组成，这些 tag 指示后续数据的格式和整个 tag 的长度。Tag 的格式如下：

Tag 格式的详细信息可以在以下头文件中找到：

5.1.1 未加密的 Tag 说明

下表列出了未加密的 EBL 映像的 tag。

下图展示了完整的 EBL 映像：

5.1.2 数据验证

EBL 文件格式包括三个 32-bit CRC 值，用于验证文件的完整性。这些值是使用 halCommonCrc32() 函数计算的，该函数可以在 hal/micro/generic/crc.c 中找到。计算中使用的 CRC 的初始值为 0xFFFFFFFF。

下表描述了 .EBL 下载格式中内置的数据完整性检查。

5.2 加密的 Ember 引导加载文件格式

Ember 加密的 bootloader 文件格式类似于未加密的版本。它引入了许多新 tag。如果 bootloader 仅接受加密的 EBL 映像，则称其为“secure”bootloader。

5.2.1 加密的 Tag 说明

下表列出了加密的 tag 及其说明。

加密的映像会将普通的、不安全的 EBL tag 包装在 EBL Encrypted Program Data tag 中。每个 tag 的内容均已加密，但加密的数据 tag ID 和 tag 长度字段未加密。对于未加密的 EBL 中存在的每个 tag，将创建一个对应的 Encrypted Program Data tag。

下图展示了加密的文件格式：

5.2.2 Nonce 生成

加密映像的随机数是 EBL Encryption Init tag 中包含的 12-byte 值。em3xx_convert 或 Simplicity Commander 工具将在加密期间生成随机 nonce 值，并将其存储在 EBL Encryption Init tag 中。

重要的是，一个 nonce 值不会被使用两次来（使用相同的加密密钥）加密两个不同的映像。这是因为 CCM 依赖于使用带有伪随机噪声块的 XOR 来加密文件的内容。然而，对于 12-byte 的随机数，这个机会大约是 1/2⁹⁶。

5.2.3 映像校验

加密的 EBL 映像受到 MAC（message authentication code，消息认证码）的保护，该消息认证码是通过每个 tag 的未加密内容计算的。MAC 存储在 EBL MAC tag 中，安全 bootloader 将在加载映像中的任何数据之前计算并验证存储的 MAC。

5.3 Ember 引导加载（EBL）文件

所有 Ember bootloader 均要求其处理的映像为 EBL 文件格式。