Gecko Bootloader的介绍(Silicon Labs)【一】
Gecko Bootloader的介绍(Silicon Labs)
关键字： ZigBee,Thread, Bluetooth, EFR32, EFM32，EmberZnet, Bootloader, Gecko， Silicon labs, ARM , Cortex-M4, Cortex-M33
摘要：
在使用Silicon labs的MCU和无线芯片进行开发时，都会使用Bootloader, 包括zigbee, thread, Bluetooth, efm32，还有其他私有协议。Boot+应用的设计是目前主流平台都采用的固件组合方式，即能够快速完成启动，可以进行固件的直接替换或者更新，即使产品已经布署或者销售，在使用过程仍然可以实现维护，比如功能升级或者bug修复等。
正文：
---------------------------
产品中bootloader存在的前提下，可以通过UART, SPI,USB,或者空中无线传输，将新的应用固件传输到设备中，重启后由Bootloader进行固件的完整性检查，切换或者擦除旧固件再更新等操作，这是完成设备更新的基本原理。
在silicon的产品中，由于历史原因，存在gecko bootloader和 ember bootloader两种，后者仅在EM35X等芯片上还有使用，逐步停止使用，因此我们在这里只介绍Gecko bootloader。Gecko Bootloader本身也有多种类型, 这里就简称为boot，在设计产品时可以根据维护设备的需要，选择适合的类型。
两大类不同工作原理的Bootloader
|
独立引导 Standalone Bootloader |
设备开始升级后，运行Boot，通过UART, SPI或者空中传输等方式将新的固件直接写到原有固件所存在的区域。 过程不可逆，升级一旦开始，必须要完成升级，如果出错，可能要从新开始。Boot和app之间很少交互。 |
|
应用交互型引导 Application Bootloader |
设备的应用程序工作状态下，运行app, 将新的固件通过UART,SPI,USB或者空中传输等方式将新版固件完整地传输的设备上。并存储于外部存储器（如EEPROM,DATAFLASH）中，然后交boot来验证新版app，通过后再将新固件复制到Flash之中，升级完成。 升级过程可以中断或者取消。升级过程中出错可以继点续传输或者重来。Boot要在app完成新版固件传输之后才会被调用。 |
|
设备的应用程序工作状态下，运行app, 将新的固件通过UART,SPI,USB或者空中传输等方式将新版固件完整地传输的设备上。并存储于片上存储器，即事先分配好的一段FLASH，然后交boot来验证新版app，通过后由boot切换启动固件或者将用新固件覆盖旧固件，升级完成。 升级过程可以中断或者取消。升级过程中出错可以继点续传输或者重来。Boot要在app完成新版固件传输之后才会被调用。 |
在应用中有一个特例， 使用Silicon labs提供的ZigBee/Thread NCP固件，只能使用独立引导（Standalone Bootloader）。
有关Silicon Labs bootloader更多的细节，可以阅读官方文档 ug103.6, ug266, an772。
Bootloader自身的架构
Gecko bootloader是可以配置的代码库，用gbl文件作为升级镜像，也就是升级的文件通常以gbl后辍名提供给网关或者云端。适用于EFM32 或者 EFR32系列的芯片。但在EFR32 Series 1和Series 2上是不同的。前者分为两个阶段,第一段加载引导用于更新第二段（也称为主引导程序）。在Series2芯片上第一阶段的引导程序被等效的硬件代替（Secure Element）, 所以整个引导程序仅有主引导程序部分。第一阶段的引导程序或者Secure Element允许对第二阶段的引导程序进行现场更新，这样就可能对bootloader的整体功能进行修改，比如新增功能，更改通信协议，添加新的安全功能，修复程序等。
后面补充一些其他信息。
https://www.cnblogs.com/newbit/p/boot2.html
https://www.cnblogs.com/newbit/p/boot3.html
https://www.cnblogs.com/newbit/p/boot4.html
