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

　　引言

　　随着嵌入式系统的发展和广泛应用,必不可少的维护工作变得日益繁重。如移动电话在用户使用过程中，部分未能在软件研发阶段发现的缺陷会逐渐暴露,不可避免地增加了维护成本。又如在设备运行期间,用户往往会基于原有软硬件对产品提出新功能或更高的性能要求，这对软件重用性提出了挑战。在移动设备数量较多, 而且使用地点无法预知的情况下, 采用传统的人工更新方式会耗费大量的人力物力。自更新技术在嵌入式系统中分为两个相互联系又相互独立的阶段：首先是将更新包下载至本地移动设备中，然后在本地移动设备中实现自更新。

　　将自更新技术嵌入RTOS中的关键在于自更新后系统启动的稳定性。嵌入式移动系统一般都有独立的bootloader对系统进行初始化并引导加载内核。这种启动基于bootloader，该自更新机制决定了bootloader不仅仅起到加载内核镜像这一基本功能，而是被看作是一个虚拟系统。

　　1 自更新机制的架构

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

　　图1 自更新机制架构图

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

　　2 更新系统的设计

　　2.1 Flash 存储器的布局

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