Silabs bootloader fundamentals
Silabs bootloader fundamentals
1.简介
引导加载程序是存储在保留闪存中的程序，可以初始化设备，更新固件映像，并可能执行一些完整性检查。无论是通过串行通信还是通过无线方式，都可以根据需要进行固件映像更新。生产级编程通常在产品制造过程中完成，但希望能够在生产完成后重新编程系统。更重要的是，能够在部署后使用新功能和错误修复更新设备的固件是很有价值的。固件映像更新功能使这成为可能。
Silicon Labs支持不使用引导加载程序的设备，但这需要外部硬件，如调试适配器（Silicon Labs ISA3或无线入门工具包（WSTK））或第三方SerialWire / JTAG编程设备来更新固件。没有引导加载程序的设备在部署后无法通过无线方式更新固件，这就是Silicon Labs强烈主张实施引导加载程序的原因。
2017年3月，Silicon Labs推出了Gecko Bootloader，这是一个可通过Simplicity Studio IDE配置的代码库，用于生成可与各种Silicon Labs协议栈一起使用的引导加载程序。Gecko Bootloader可以与EFR32MG1 / EFR32BG1（EFR32xG1）和EFR32xG1 + Flash一起使用，但是，从EFR32MG12 / EFR32BG12 / EFR32FG12（EFR32xG12）平台开始，它和所有未来的Mighty Gecko，Flex Gecko和Blue Gecko版本将使用仅限Gecko Bootloader。与EmberZNet PRO等特定协议和包括EM3x在内的平台一起使用的传统Ember引导加载程序应用程序将继续用于这些平台。2017年12月，蓝牙SDK（软件开发套件）的2.7.0版本删除了对传统蓝牙启动加载程序的支持。
Gecko Bootloader和传统的Ember引导加载程序使用自定义的更新映像文件格式，将在本节中进一步介绍
5.引导加载文件格式小号。Gecko Bootloader生成的应用程序引导加载程序使用的更新映像文件是GBL（Gecko BootLoader）文件，旧版Ember引导加载程序使用的是EBL（Ember BootLoader）文件
可以通过两种方式完成引导加载固件更新映像。第一种是空中下载（OTA），即通过无线网络，如下图所示。
第二种是通过设备的硬连线链接。下图表示使用UART（通用异步接收器/发送器），SPI（串行协议接口）或USB（通用串行总线）接口以及NCP的SoC（片上系统）的串行引导加载程序用例（网络协处理器）使用UART或SPI。
Silicon Labs网络设备使用以两种不同模式执行固件更新的引导加载程序：独立（也称为独立引导加载程序）和应用程序（也称为应用程序引导加载程序）。应用程序引导加载程序进一步划分为使用外部存储空间用于下载更新映像的应用程序和使用本地存储的应用程序。这两个引导加载程序类型将在接下来的两节中讨论。
本文档中描述的固件更新情况假设源节点（通过串行或OTA链接将固件映像发送到目标的设备）通过其他方式获取新固件。例如，如果本地Zigbee网络上的设备连接了以太网网关，则该设备可以通过Internet获取或接收这些固件更新。固件更新过程的这一必要部分取决于系统，超出了本文档的范围。
1) 独立引导加载
独立引导加载程序是使用外部通信接口（如UART或SPI）获取应用程序映像的程序。独立固件更新是一个单阶段过程，允许将应用程序映像放入闪存，覆盖现有的应用程序映像，而无需应用程序本身的参与。独立引导加载程序和在闪存中运行的应用程序之间几乎没有交互。通常，应用程序与引导加载程序交互的唯一时间是它请求重新引导到引导加载程序。一旦引导加载程序运行，它就会通过物理连接（如UART或SPI）或无线电（无线）接收包含（新）固件映像的引导加载数据包。
启动固件更新过程后，新代码将覆盖现有堆栈和应用程序代码。如果在此过程中发生任何错误，则无法恢复代码并且必须重新开始该过程。有关旧版独立引导加载程序的更多信息，请参阅AN760：使用Ember独立引导加载程序。有关将Gecko Bootloader配置为独立引导加载程序的信息，请参阅UG266：Silicon Labs Gecko Bootloader用户指南。
2) 应用程序启动加载
应用程序引导加载程序在运行的应用程序完全下载更新映像文件后开始固件更新过程。应用程序引导加载程序期望映像存在于引导加载程序可访问的外部存储器中或主闪存的一部分中（如果芯片具有足够的内存来支持此本地存储模型）。
应用程序引导加载程序依赖于应用程序来获取新的固件映像。应用程序可以通过任何方便的方式（UART，无线等）下载该映像，但必须将其存储在称为下载空间的区域中。下载空间通常是外部存储器设备，例如EEPROM或dataflash，但在使用应用程序引导加载程序的本地存储变体时，它也可以是芯片内部闪存的一部分。存储新映像后，将调用应用程序引导加载程序以验证新映像并将其从下载空间复制到闪存。
由于应用程序引导加载程序不参与获取图像，并且在固件更新过程开始之前下载整个图像，因此下载错误不会对运行图像产生负面影响。可以重新启动或暂停下载过程以随时间获取图像。在启动固件更新过程之前，可以验证下载的更新映像的完整性，以防止应用损坏或无功能的映像。
传统的Ember应用程序引导加载程序提供UART独立引导加载功能，作为恢复机制，以防正在运行的应用程序映像和升级映像损坏。可以将Gecko Bootloader配置为接受多个升级图像的列表，以尝试验证和应用。这允许Gecko Bootloader存储实际上是更新映像的备份副本，如果第一个映像损坏，它可以访问该副本。
请注意，EmberZNet和Silicon Labs Thread NCP平台不使用应用程序引导加载程序，因为应用程序代码驻留在主机上而不是直接驻留在NCP上。相反，充当串行协处理器的设备将使用独立的引导加载程序，该引导加载程序设计为通过与预期的NCP固件使用的相同串行接口接受代码。但是，主机应用程序（驻留在NCP的单独MCU上）可以使用适当的任何引导加载方案。Silicon Labs蓝牙NCP可以使用传统的OTA DFU引导加载程序。
有关应用程序引导加载程序的更多信息，请参阅UG266：Silicon Labs Gecko Bootloader用户指南和AN772：使用软件应用程序引导加载程序。
2.关于 gecko Bootloader
Silicon Labs Gecko Bootloader是一个可配置的代码库，可以与所有较新的Silicon Labs Gecko MCU和无线MCU一起使用。它使用称为GBL文件的特殊格式的更新映像文件。Gecko Bootloader采用两级设计，其中最小的第一级引导加载程序用于更新主引导加载程序。这允许主引导加载程序的现场更新，包括添加新功能，更改通信协议，添加新的安全功能和修复程序等。Gecko Bootloader由三个组成部分组成：
核心：引导加载程序核心包含两个引导加载程序阶段的主要功能。它还包含写入内部主闪存，执行引导加载程序更新以及重置应用程序以标记适用的重置原因的功能。
驱动程序：不同的引导加载应用程序需要不同的硬件驱动程序以供引导加载程序的其他组件使用。
插件：主引导加载程序的所有部分都是可选的或可选择用于不同的配置实现为插件。每个插件都有一个通用头文件和一个或多个实现。当前版本包含用于UART和SPI通信协议，SPI闪存，内部闪存和不同加密操作等功能的插件。
1)特征
Gecko Bootloader功能包括：
现场更新
安全启动
签署GBL固件更新映像文件
加密的GBL固件更新映像文件
这些功能在以下部分进行了总结，并在UG266：Silicon Labs Gecko Bootloader用户指南中有更详细的描述。有关使用Gecko Bootloader的特定于协议的信息可在以下文档中找到：
AN1084：将Gecko Bootloader与EmberZNet和Silicon Labs Thread一起使用
AN1085：在Silicon Labs Connect中使用Gecko Bootloader
AN1086：将Gecko Bootloader与Silicon Labs蓝牙应用程序配合使用
a.现场可更新
Bootloader固件字段更新功能由两阶段设计，第一阶段和主阶段提供。引导加载程序的最小第一阶段（不可现场更新）只能通过读取和写入内部闪存中的固定地址来更新主引导加载程序。要执行主引导加载程序更新，运行的主引导加载程序将验证引导加载程序更新映像的完整性和真实性，将引导加载程序更新映像写入内部闪存中的固定位置，并向第一阶段引导加载程序发出重新引导。在将更新映像复制到主引导加载程序位置之前，第一阶段引导加载程序会验证主引导加载程序更新映像的完整性。
b.安全启动
安全启动旨在防止不受信任的映像在设备上运行。启用安全启动后，引导加载程序会使用非对称加密技术在每次启动时强制执行应用程序映像的加密签名验证。使用的签名算法是ECDSA-P256-SHA256。在制造期间将公钥写入设备，而私钥保密。这可确保应用程序由受信任方创建和签名。
c.签署GBL更新图像文件
除了安全启动之外，Gecko Bootloader还支持强制执行更新映像文件的加密签名验证。这允许引导加载程序和应用程序在开始更新过程之前验证应用程序或引导加载程序更新是否来自受信任的源。使用的签名算法是ECDSA-P256-SHA256。公钥与安全引导的密钥相同，在制造期间写入设备，而私钥从不分发。这可确保GBL文件由受信任方创建和签名。
d.加密的GBL更新文件
GBL更新文件也可以加密，以防止窃听者获取明文固件映像。使用的加密算法是AES-CTR-128，加密密钥在制造期间写入设备。
2)使用性
下表显示了可以与不同平台一起使用的引导加载程序。
| 平台 |
Gecko Bootloader |
Legacy Ember Bootloaders |
Legacy Bluetooth Bootloaders |
| EM3X |
NO |
YES |
* |
| EFR32MG1/+FLASH |
YES |
NO** |
* |
| EFR32BG1 |
YES |
NO |
* |
| EFR32BG1+FLASH |
YES |
NO |
* |
| EFR32FG1 |
YES |
NO** |
* |
| EFR32MG12/BG12/FG12 |
YES |
NO |
* |
| Future products |
YES |
NO |
* |
* Bluetooth SDK 2.7.0版本中删除了对旧版蓝牙Bootloader的支持。
**在EmberZNet SDK版本6.1.0和Silicon Labs Thread版本2.5.0中不推荐支持这些平台。
3.用于引导加载的内存空间
1)Gecko BootLoader
引导加载程序的第一个阶段占用一个闪存页面。在具有2 kB闪存页的设备上，如EFR32MG1，这意味着第一阶段需要2 kB。
主引导加载程序的大小取决于所需的功能。使用典型的引导加载程序配置，主引导加载程序占用14 kB闪存，使总引导加载程序大小达到16 kB。
Silicon Labs建议为引导加载程序保留至少16 kB。
在EFR32xG1设备（Mighty Gecko，Flex Gecko和Blue Gecko系列）上，引导加载程序位于主闪存中。
第一阶段bootloader @ 0x0
主引导程序@ 0x800
应用程序@ 0x4000
在较新的设备（EFR32xG12和更高版本）上，引导加载程序位于信息块的引导加载程序区域中
应用程序@ 0x0
第一阶段bootloader @ 0x0FE10000
主引导程序@ 0x0FE10800
2)传统的Ember BootLoader
下图显示了典型Silicon Labs网状网络SOC或NCP的存储器映射。
对于每个Silicon Labs网状网络平台（在SOC或NCP使用情况下），在主闪存的起始处保留一块闪存（通常为8 kB或16 kB，具体取决于所使用的IC变体）以保存引导加载程序和一块闪存（在4 kB和36 kB之间，具体取决于实现）保留在闪存的末尾，用于模拟EEPROM。在除本地存储应用程序引导加载程序之外的所有情况下，内存空间的余额都是未保留的，可用于保存网络堆栈和应用程序代码。
4.设计决策
决定部署引导加载程序类型取决于许多因素。请注意，平台类型和可用闪存可能会限制引导加载程序选择。
与此相关的一些问题是：
设备在哪里获得新的更新图像？这是通过网络协议进行的无线传输吗？使用连接到Internet的独立接口？
设备是否有外部存储器芯片来存储新的更新映像？如果没有，是否有足够的内部闪存来存储最大预期应用程序映像的当前和新下载的副本？
如果设备通过空中接收新图像，它是否会与保存下载图像的服务器相距多跳？
需要什么样的图像安全性？
将使用什么通信驱动程序（在单一协议的情况下）？
用例是否需要多个协议？
1)Gecko BootLoader
Gecko Bootloader平台的可配置设计意味着开发人员可以创建引导加载程序以适应几乎任何设计选择。有关详细信息，请参阅UG266：Silicon Labs Gecko Bootloader用户指南。
2)传统的Ember BootLoader
下表显示了旧版Ember引导加载程序，不同类型以及引导加载程序支持的功能。
| 特征 |
应用程序引导程序 |
安全应用程序启动加载程序 |
本地存储引导程序 |
安全本地存储启动加载程序 |
独立引导程序 |
Standalone-OTA- bootloader |
| 串行链接下载 |
YES |
YES |
YES |
YES |
YES |
YES |
| 无应用程序运行的无线图像传输 |
|
|
|
|
|
YES |
| 应用程序在下载新图像时运行 |
YES |
YES |
YES |
YES |
|
|
| 可用于多跳部署 |
YES |
YES |
YES |
YES |
|
|
| 支持加密的Ember Bootloader文件（EBL） |
|
YES |
|
YES |
|
|
| 通过加载存储的映像可以恢复Bootload Failures |
YES |
YES |
YES |
YES |
|
|
| 需要外部存储 |
YES |
YES |
|
|
|
|
| 片上闪存要求 |
EM34x/5x: 8 kB EM358x/9x: 16 kB EFR32: not supported |
EM34x/5x: 8 kB EM358x/9x: 16 kB EFR32: not supported 2 |
EM34x/5x: not supported EM358x/9x: 16 kB + 246 kB 1 EFR32: not sup- ported |
EM34x/5x: not supported EM358x/9x: 16 kB + 246 kB 1 EFR32: not sup- ported |
EM34x/5x: not supported EM358x/9x: 16 kB + 246 kB 1 EFR32: not sup- ported |
EM34x/5x: 8 kB EM358x/9x: 16 kB EFR32: not sup- ported |
| EM34x，EM351 |
YES |
YES |
|
|
YES |
YES |
| EM357，EM3581，EM3582 （192 kB和256 kB部分） |
YES |
YES |
|
|
YES |
YES |
| EM3585，EM3586，EM3587，EM3588 （512 kB部分） |
YES |
YES |
YES |
YES |
YES |
YES |
| EFR32（128 kB和256 kB部分） |
Not suppor- ted |
Not suppor- ted |
|
|
Not suppor- ted |
|
| 1 可以将本地存储配置为使用或多或少的片上空间进行存储。246 kB是基于保留在512 kB部分上的单个平均大小的图像的推荐量。个别申请需求可能有所不同 实际的引导加载程序是16 kB。 2 使用Gecko Bootloader为这些平台创建类似的配置。 |
||||||
5.引导加载文件格式
A、Gecko BootLoader 文件
GBL文件格式由Gecko Bootloader使用。
1)文件格式
a.文件结构
GBL文件格式由许多标签组成，这些标签指示后续数据的格式和整个标签的长度。标签的格式如下：
| 标签ID |
标签长度 |
标记有效负载 |
| 4字节 |
4字节 |
变量（根据标签长度） |
b.明文标签说明
| 标签名 |
ID |
描述 |
| GBL标题标记 |
0x03A617EB |
这必须是文件中的第一个标记。标头标签包含GBL文件规范的版本号，以及指示GBL文件类型的标志 - 无论是签名还是加密。 |
| GBL应用信息标签 |
0xF40A0AF4 |
此标记包含有关此GBL文件中包含的应用程序更新映像的信息 |
| GBL Bootloader标签 |
0xF50909F5 |
此标记包含完整的引导加载程序更新映像。 |
| GBL程序数据标签 |
0xFE0101FE或0xFD0303FD |
此标记包含有关要在特定地址编程到主闪存中的应用程序数据的信息。 |
| GBL元数据标签 |
0xF60808F6 |
此标记包含引导加载程序不解析的元数据，但可以通过回调返回给应用程序。 |
| GBL签名标签 |
0xF70A0AF7 |
此标记包含文件中所有先前数据的ECDSA-P256签名。 |
| GBL结束标记 |
0xFC0404FC |
此标记表示GBL文件的结尾。它包含整个文件的32位CRC作为完整性检查。CRC是一种非密码检查。这必须是最后一个标签。 |
GBL文件中允许的GBL标记序列如下图所示。
c.加密标签说明
加密的GBL文件格式类似于未加密的版本。它引入了许多新标签。
| 标签名 |
ID |
描述 |
| GBL标题标记 |
0x03A617EB |
GBL标头与纯文本GBL文件相同，但必须设置指示GBL文件已加密的标志。 |
| GBL加密初始标头 |
0xFA0606FA |
其中包含有关图像加密的信息，如Nonce和加密数据量。 |
| GBL加密程序数据 |
0xF90707F9 |
它包含一个加密的有效负载，其中包含明文GBL标记，应用信息，Bootoader，元数据或程序数据之一。使用AES-CTR-128加密数据。 |
加密的GBL文件中允许的GBL标记序列如下图所示。
2)映像验证文件
可选的GBL签名标记可用于确保GBL文件的真实性。Silicon Labs强烈建议将引导加载程序配置为仅接受签名的GBL文件。
B、Ember BootLoader 文件
1)基本文件格式
所有Ember引导加载程序都要求它们正在处理的图像采用EBL（Ember Bootload）文件格式。
EBL文件格式由许多标签组成，这些标签指示后续数据的格式和整个标签的长度。标签的格式如下：
| 标签ID |
标签长度 |
标记有效负载 |
| 2个字节 |
2个字节 |
变量（根据标签长度） |
标记格式的详细信息可以在这些头文件中找到：
| 平台 头文件名 |
|
| EM3x系列 |
|
| EFR32系列 |
不支持。 |
a.未加密的标签说明
| 名 |
ID |
描述 |
| EBL标题标记 |
为0x0000 |
其中包含有关图像所针对的芯片，AAT（应用程序地址表），堆栈版本，客户应用程序版本，构建日期和构建时间戳的信息。这必须是第一个标签。 |
| EBL计划数据 |
0xFE01 |
其中包含有关在特定地址编程到主闪存中的数据的信息。 |
| EBL程序制造数据 |
0x02FE |
其中包含有关在芯片的客户信息块（CIB）部分（针对EM35x器件）或UserData部分（针对EFR32™器件）的特定地址处编程的数据的信息。 |
| EBL结束 |
0xFC04 |
此标记指示EBL文件的结尾。它包含整个文件的32位CRC作为完整性检查。CRC是非加密检查。这必须是最后一个标签。 |
b.数据验证
EBL文件格式包括三个32位CRC值，用于验证文件的完整性。这些值是使用halCommonCrc32（）函数计算的，该函数可以在hal / micro / generic / crc.c中找到。计算中使用的CRC的初始值是0xFFFFFFFF。
下表描述了.EBL下载格式中内置的数据完整性检查。
| 完整性检查 |
描述 |
| 标题CRC |
标题数据包含headerCrc字段（在其他代码区域中也称为aatCrc），仅为头字节的4字节，1的补码，LSB优先CRC。这用于验证标头的完整性。该CRC假定AAT中的类型字段的值被设置为0xFFFF。 |
| EBLTAG_END CRC |
结束标记值是数据下载流的一个补码，LSB优先CRC，包括结束标记的头部和CRC值本身。这用作下载流的运行CRC，并验证下载文件是否已正确接收。标签中的CRC是运行中的一个补码CRC并且当该值被添加到CRC算法的运行计算时，它导致预定义的0xDEBB20E3的存储器。 |
| 图像CRC |
标头的imageCrc字段是要写入的所有闪存页面的一个补码，MSB优先CRC，包括页面中任何未使用的空间（初始化为0xFF）。它不包括EBL标记数据，并假定AAT的前128个字节。这在图像下载完成后使用，除了标题之外的所有内容都已写入闪存以验证下载。下载程序通过读取在头部的pageRanges []数组中定义的每个写入的flash页面并计算正在运行的CRC来完成此操作。 |
2)加密的Ember BootLoader 文件格式
Ember加密的引导加载程序文件格式类似于未加密的版本。它引入了许多新标签。如果引导加载程序仅接受加密的EBL映像，则称其为“安全”引导加载程序。
a.加密标签说明
| 名 |
ID |
描述 |
| EBL加密标头 |
0xFB05 |
其中包含有关图像的基本信息。标头未经过身份验证或加密。 |
| EBL加密初始标头 |
0xFA06 |
其中包含有关图像加密的信息，例如Nonce，加密数据量以及可选的已验证但未加密的数据块。标签已通过身份验证。 |
| EBL加密程序数据 |
0xF907 |
其中包含有关编程到闪存中的内容的数据。内容已加密。使用AES-CCM加密数据。 |
| EBL加密MAC |
0xF709 |
它包含用于验证图像的经过身份验证和加密的部分内容的消息验证代码。 |
加密图像将在EBL加密程序数据标记内包装正常的，不安全的EBL标记。每个标记的内容都是加密的，但加密的数据标记ID和标记长度字段不是。对于未加密的EBL中存在的每个标记，将创建相应的加密程序数据标记。
加密文件格式如下图所示：
b.Nonce generation
加密图像的随机数是EBL加密Init标记中包含的12字节值。em3xx_convert或Simplicity Commander工具将在加密期间生成随机nonce值，并将其存储在EBL Encryption Init标记中。
重要的是，nonce值不会被使用两次来使用相同的加密密钥加密两个不同的图像。这是因为CCM依赖于使用带有伪随机噪声块的XOR来加密文件的内容。然而，随着一个12字节的随机数的这个机会是在2大致1 96。
c.映像验证
加密的EBL图像受到消息认证码（MAC）的保护，该消息认证码是通过每个标签的未加密内容计算的。MAC存储在EBL MAC标记中，安全引导加载程序将在加载图像中的任何数据之前计算并验证存储的MAC。