Silicon labs Gecko bootloader 的主要特性【二】
在前面一篇文章大致介绍了Gecko bootloader（下称bootloader）的基础知识，比如两种Bootloader的特点，本文继续说明bootloader的代码结构和功能。
如果对于bootloader的基本功能不太清楚，可以先阅读文章[一]。
一、代码与构成
Bootloader总是由第一阶段引导（或者等效的硬件）和第二阶段主引导组合而成，第一阶段在EFR32 Series 1和EFM32上需要使用，但这部分也是SDK直接集成的，所以这里先不关注。
总体而言， Bootloader包括三大部分的代码。
|
Core |
包含bootloader第一阶段和第二阶段主引导的全部主要功能。比如写内部FLASH，执行bootloader更新，设置复位原因且可保留到application当中。 |
|
Driver |
驱动，不同的产品会需要不同的硬件，这一部分用来适配硬件 |
|
Plugin |
插件，Silicon Labs把多个可选择或者可配置的功能封装为插件，某此功能可能会有多个实现，由用户选用哪一个，或者作一个功能选项，由用户选择要不要这个功能。比如是选择SPI/UART通信协议 ，是否使用外部存储(external SPI flash storage), 使用内部存储，加密校验方式等。 |
二、重要的功能
Boootloader主要特性如下：
l Boot本身也支持现场升级
l 安全启动引导(secure boot)
l 验证签名GBL升级固件映像文件(Signed GBL firmware update image file)
l 加密GBL升级固件映像文件(Encrypted GBL firmware update image file)
2.1 现场升级
在Series 1 平台上（含EFM32,EFR32），bootloader的第一阶段引导（minimal first stage）是不可以进行现场升级的。第二阶段的主引导可以升级，这是通过将片上固定地址段的内容读出并写到另一个固定的地址段完成。升级过程大致如下，由第二阶段主引导在正常运行时，对新的主引导程序进行完整性和合法性进行确认，并写入内部的FLASH当中。通过重启，让第一阶段的boot得到运行，第一阶段的boot再次确定本次升级引导程序固件的完整性，通过后将新的主引导复制到指定地址（覆盖了原来的主引导程序），完成升级。
在Series 2平台（EFR32MG21），通过使用hardware Secure Element对第二阶段主引导程序进行升级，流程依然是由第二阶段主引导对新的主引导程序进行完整性和合法性进行确认，并写入内部的FLASH当中。接下来请求Secure Element 来验证新固件是否合法，确认合法后，将新的主引导复制到指定地址（覆盖了原来的主引导程序），完成升级。所文档说明 Secure Element本身也可以升级，这一点尚没有找到完整资料。
2.2 安全启动引导
这一机制可以防止一个不受信任的应用程序在设备上运行。这一功能被激活时，bootloader会对应用程序进行一次加密签名验证，验证基于非对称的加密算法。 签名算法是ECDSA-P256-SHA256，公钥在设备生产过程中写入设备，私钥则由制造商保留。这样的做法可以保证应用程序是由受信任的研发人员创建并签名的。
2.3 验证签名
这个功能与安全启动这个功能不同，Bootloader还支持强制对即将用于升级的映像进行加密签名验证。让bootloader和应用程序可以先校验并确认即将升级的bootloader或者应用程序是来自于可信任的源节点，确认之后才会开始升级进程。应用的签名算法是ECDSA-P256-SHA256，公钥与安全启动引导所使用的一样，也是在生产时由制造商写入的那个密钥。私钥永远可能保密。这一机制可以确保GBL文件由被信任的第三方创建并签名。
2.4 加密升级固件
接收到一个可以被信任的升级文件，包括新版的bootloader和应用程序，都可以先加密再保存到存储器当中，这对于片外存储犹为重要，避免了明文保存固件，防止设备固件被窃取。加密算法是AES-CTR-128, 密钥是在生产阶段由制造商写入。
三 适用bootloader的芯片
目前主要有 ：
EFR32MG1 / (EFR32MG1+FLASH)
EFR32BG1
EFR32FG1
EFR32MG12/BG12/FG12
EFR32xG21
关于Bootloader，未完待续。。。
