Zephyr RTOS架构下的固件升级
目录
概述
1 固件升级的方式
1.1 估计升级的模式
1.2 固件升级方式
2 双区（2 Slot）DFU和单区（1 Slot）DFU
2.1 双区DFU
2.1.1 后台式DFU设升级方式
2.1.2 非后台式DFU的升级方式
2.2 单区DFU
2.3 两种模式的比较
3 nRF Connect SDK中的Bootloader
3.1 Bootloader的作用
3.2 nRF Connect SDK支持Boot类型
3.3 SMP DFU协议
4 nodic 平台下MCU Boot 的Flash分配
5 Image structure
概述
本文简要介绍了Zephyr OS架构下固件升级的一些内容，其中包括固件升级的模式，实现原理，nordic平台下固件升级的方法，image分配的方式等内容。
1 固件升级的方式
1.1 估计升级的模式
1） DFU模式
DFU（Device Firmware Update）的中文翻译设备固件升级。DFU的升级方式有很多，除了可以通过无线方式（OTA）进行升级，也可以通过有线方式进行升级，比如通过UART，USB或者SPI通信接口来升级设备固件。
2）OTA模式
OTA（Over The Air）是实现DFU的一种方式而已，准确说，OTA的全称应该是OTA DFU，即通过空中无线方式实现设备固件升级。只不过为了方便起见，直接用OTA来指代固件空中升级（有时候也将OTA称为FOTA，即Firmware OTA，这种称呼意思更明了一些）。只要是通过无线通信方式实现DFU的，都可以叫OTA，比如4G/WiFi/蓝牙/NFC/Zigbee/NB-IoT，都支持OTA。
1.2 固件升级方式
OTA方式还是有线通信方式，DFU包括后台式（background）和非后台式两种模式。
1） 后台式DFU
后台式DFU又称静默式DFU（Silent DFU），在升级的时候，新固件在后台悄悄下载，即新固件下载属于应用程序功能的一部分，在新固件下载过程中，应用可以正常使用，也就是说整个下载过程对用户来说是无感的，下载完成后，系统再跳到BootLoader程序，由BootLoader完成新老固件拷贝操作，至此整个升级过程结束。
2) 前台式DFU
前台式DFU，在升级的时候，系统需要先从应用程序跳到BootLoader程序，由BootLoader进行新固件下载工作，下载完成后BootLoader继续完成新老固件拷贝操作，至此升级结束。
2 双区（2 Slot）DFU和单区（1 Slot）DFU
双区或者单区DFU是新固件覆盖老固件的两种方式。
2.1 双区DFU
2.1.1 后台式DFU设升级方式
后台式DFU必须采用双区模式进行升级，即老系统（老固件）和新系统（新固件）各占一块Slot（存储区）。假设老固件放在Slot0中，新固件放在Slot1中，升级的时候，应用程序先把新固件下载到Slot1中，只有当新固件下载完成并校验成功后，系统才会跳入BootLoader程序，然后擦除老固件所在的Slot0区，并把新固件拷贝到Slot0中，或者把Slot0和Slot1两者的image进行交换。
2.1.2 非后台式DFU的升级方式
非后台式DFU可以采用双区也可以采用单区模式，与后台式DFU相似，双区模式下新老固件各占一块Slot（老固件为Slot0，新固件为Slot1），升级时，系统先跳入BootLoader程序，然后BootLoader程序把新固件下载到Slot1中，只有新固件下载完成并校验成功后，才会去擦除老固件所在的Slot0区，并把新固件拷贝到Slot0区。
2.2 单区DFU
单区模式的非后台式DFU只有一个Slot0，老固件和新固件分享这一个Slot0，升级的时候，进入bootloader程序DFU模式后立马擦除老固件，然后直接把新固件下载到同一个Slot中，下载完成后校验新固件的有效性，新固件有效升级完成，否则要求重来。
2.3 两种模式的比较
1） 单区模式的特点
跟非后台式DFU双区模式相比，单区模式节省了一个Slot的Flash空间，在系统资源比较紧张的时候，单区模式是一个不错的选择。不管是双区模式还是单区模式，升级过程出现问题后，都可以进行二次升级，都不会出现“变砖”情况。
2）双区模式的特点
双区模式的特点是，如果升级过程中出现问题或者新固件有问题，它还可以选择之前的老固件老系统继续执行而不受其影响。而单区模式碰到这种情况就只能一直待在bootloader中，然后等待二次或者多次升级尝试，此时设备的正常功能已无法使用。双区模式牺牲了很多存储空间，但是换来了更好的升级体验。
3 nRF Connect SDK中的Bootloader
3.1 Bootloader的作用
Bootloader在其中起到的作用包括：
1）判断正常启动还是DFU升级流程，
2）启动并校验应用image，
3) 升级的时候完成新image和老image的交换或者拷贝工作。
3.2 nRF Connect SDK支持Boot类型
nRF Connect SDK支持MCUboot，B0和nRF5 Bootloader三种Bootloader，一般推荐使用MCUboot。MCUboot位于如下目录：
D:\ncs\v2.9.0\bootloader\mcuboot\boot\zephyr在nRF Connect SDK中的MCUboot功能强大，兼容的芯片平台多，而且是一个久经考验的第三方开源Bootloader。MCUboot把存储区划分：Primary slot和Secondary slot，而且primary slot跟secondary slot两者大小是一样的，程序默认在Primary slot中执行。
需要注意的是，nRF Connect SDK对MCUboot进行了定制，在nRF Connect SDK中，程序只能在Primary slot中执行，Secondary slot只是用来存储新image，而且Secondary slot可以放在内部Flash，也可以放在外部Flash。
nRF Connect SDK中，存储器分区有如下两种典型情况：
1） MCU 内部Flash方式
2） MCU 内部Flash + Extent Flash方式
3.3 SMP DFU协议
smp 全称simple management protocol（简单管理协议），它是设备管理协议的一种，在nRF Connect SDK中，mcumgr模块实现了smp协议，或者说，smp协议按照mcumgr的要求对相应的传输数据进行编码，这样mcumgr里面注册的命令组（command group）可以直接对传输数据进行解析。
4 nodic 平台下MCU Boot 的Flash分配
笔者使用nRF52840芯片，其MCU的Flash的分配情况如下：
5 Image structure
/*** End-of-image slot structure.** 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) [*] |* | |* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+* | 0xff padding as needed |* | (BOOT_MAX_ALIGN minus 16 octets from Encryption key 0) [*] |* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+* | Encryption key 1 (16 octets) [*] |* | |* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+* | 0xff padding as needed |* | (BOOT_MAX_ALIGN minus 16 octets from Encryption key 1) [*] |* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+* | Swap size (4 octets) |* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+* | 0xff padding as needed |* | (BOOT_MAX_ALIGN minus 4 octets from Swap size) |* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+* | Swap info | 0xff padding (BOOT_MAX_ALIGN minus 1 octet) |* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+* | Copy done | 0xff padding (BOOT_MAX_ALIGN minus 1 octet) |* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+* | Image OK | 0xff padding (BOOT_MAX_ALIGN minus 1 octet) |* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+* | 0xff padding as needed |* | (BOOT_MAX_ALIGN minus 16 octets from MAGIC) |* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+* | MAGIC (16 octets) |* | |* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+** [*]: Only present if the encryption option is enabled* (`MCUBOOT_ENC_IMAGES`).*/