嵌入式系统自更新机制的设计与应用

引 言

随着嵌入式系统的发展和广泛应用，必不可少的维护工作变得日益繁重。如移动电话在用户使用过程中，部分未能在软件研发阶段发现的缺陷会逐渐暴露，不可避免地增加了维护成本。又如在设备运行期间，用户往往会基于原有软硬件对产品提出新功能或更高的性能要求，这对软件重用性提出了挑战。在移动设备数量较多，而且使用地点无法预知的情况下，采用传统的人工更新方式会耗费大量的人力物力。自更新技术在嵌入式系统中分为两个相互联系又相互独立的阶段：首先是将更新包下载至本地移动设备中，然后在本地移动设备中实现自更新。
将自更新技术嵌入RTOS中的关键在于自更新后系统启动的稳定性。嵌入式移动系统一般都有独立的boot―loader对系统进行初始化并引导加载内核。这种启动基于bootloader，该自更新机制决定了bootloader不仅仅起到加载内核镜像这一基本功能，而是被看作是一个虚拟系统。

1 自更新机制的架构
支持自更新功能的嵌入式系统由服务器端和客户端两部分组成。服务器端通过OMA协议，与客户端建立无线连接。客户端采用基于ARM9的微处理器，配有8 MB的RAM和32 MB的NOR F1ash存储器，及其他相关外围设备，具有相对可见的bootloader程序。自更新机制架构如图1所示。

自更新机制总体流程如下：a．设备厂商根据需求，生成包括升级到新版本或返回到旧版本的多个更新包。b．这些更新包将被送至无线服务提供商处进行统一管理，并最终将更新包提供给用户。c．在更新包提供给用户前，每个单独的移动设备将会选择最优方案(即网络提供商)。d．服务器端通过传输机制(如OMA―DL 1．O协议标准或网络提供商标准)与客户端建立会话连接，客户端将下载并存储更新包。e．更新应用程序将与用户交互以获得更新权限并进入更新进程。整个更新过程由bootloader完全控制，直到更新成功。f．更新后的目标设备重启，并将更新结果发送至服务器端。

2 更新系统的设计
2．1 Flash存储器的布局
原有嵌入式系统Flash存储器的布局如图2(a)所示。系统启动时从Flash的首地址开始执行，而bootloader和RTOS都位于code区，也就是bootloader并不独立于内核。将原本与代码区相邻的文件系统区后移，用于存储更新包。这种布局也是很多嵌入式系统所采用的，尤其是许多商业系统。系统在更新过程中根据自更新算法与原有代码区进行比对，烧写到Flash中。这种Flash部署方法有一个致命的缺点，就是没有考虑到更新过程中可能遇到的突发事件。比如，在更新过程中因为不可预料的掉电使得烧写错误，完全可能导致软件更新后系统无法启动，出现这种情况后必须人工重新烧写原有软件。

为了在原有基础上使系统具有高稳定性与扩展性，需要对Flash进行重新布局，如图2(b)所示。将代码区划分为两个区域：bootloader区，这个区域不可被擦写更新；RTOS区域，存放内核及应用程序。将更新包存储区设计为4部分。其中一个用来存储系统启动和更新过程的标识参数，这些数据极为重要，掉电后仍需保存于Flash中。另一个存储区用于存放更新时用到的更新包，称为更新包区。第三个区域存储下载的更新包，称为更新包备份区。最后一个区域存放设备出厂时的软件版本。bootloader固定在第一个分区，这样的设计具有很强的可扩展性，涵盖了更新算法。为了使人机接口更人性化，此区域包括LCD及其控制器的驱动和应用程序，使更新过程对用户可见。系统启动时设置异常向量表，初始化内存、堆栈指针寄存器、I／O器件、系统需求的RAM变量，使能中断，然后根据启动地址和更新标识这两个参数跳转执行相应代码，每次更新都不改变bootloader区域的内容。其中，启动地址指向bootloader要执行的代码，更新标识用于记录更新阶段。
2．2 更新进程的设计
系统每次启动后，服务器端主动报告当前有无可更新的软件包。如果客户端响应并发起会话，则随后检查Flash上的更新包备份区，存储下载的更新包，并更新标识。为了增强传输过程的安全性，在应用层设计一套具有校验、确认和断点续传功能的收发协议，以保证数据能够准确地通过移动通信系统传输到客户端。
当更新包下载完毕后，先将更新包由备份区拷贝至更新包区，更新进程根据已经设定的代码区在Flash中的地址，调用Flash的读写函数通过比对算法将更新包写入代码区。更新结束后设置标识，如果由于某种原因没有更新成功则标识位不变，系统复位后继续更新直到更新成功。可参考如下代构：