高通OTA升级非常规分区方法
- 1. 高通LE OTA背景
- 2. 高通LE OTA升级方案
- 2.1 SDX12 OTA方案
- 2.2 OTA升级TZ/RPM/Aboot
OTA是一个通用述语,常见的解释为over the air。通过这一解释,OTA最开始的概念,是空中升级。后来,又衍生出了FOTA,FOAT的概念。
FOTA可以理解为Firmware Over The Air,即在线升级,是指通过模块的数据通道完成升级包的下载和安装。此外,FOAT,是模块项目实践运用中,发展出来的另一种升级方式,可描述为通过本地升级工具对模块进行软件更新的过程。FOAT与FOTA的不同是,升级包的导入方式上的不同。FOAT是通过串口传输导入,没有无线部分的介入。所以两者只是升级包导入的方式上的不同。在升级包导入到设备后,升级包的安装更新,都归为模块自身的基本升级功能,由Recovery系统来完成。
综上,在模块项目中OTA调试,可分为三大块,即:
1. 高通LE OTA背景
高通MDM、MSM平台提供了基本的升级功能,大概都以开源的Android升级设计实现作为基础,对其代码进行移植,适配到自身平台上。从差分包制作工具,升级过程,都有一套完整的方案,并且所涉及到的工具和代码均完全开放,因此该方案的可塑性也更大。其中包括统一的用于安装升级包的Recovery系统,编译OTA底包专属框架,和处理底包制作升级包的脚本和工具等。
由于该方案中各个文件的PATCH 基于文件系统而来,因此很难在bootloader 阶段实现(无法挂载文件系统),所以在分区设计上,除了预留存放差分包,备份文件的空间外,还需要添加专门的分区(kernel, bootloader,filesystem)以供FOTA 使用,而该分区必须独立于正常运行时的分区。这也就导致了该方案在硬件(FLASH,DDR)要求比较高。
在LE 的FOTA 方案中,升级程序作为一个应用程序运行,升级包则是一个标准的zip 文件(命名为ota 文件),升级过程则是解析升级包中指定的脚本文件,并根据解析到的内容引用对应的功能模块,从而完成整个升级过程。
2. 高通LE OTA升级方案
下面主要介绍基于高通LE OTA方案,SDX12做的一些改进,以及如何在SDX12上完成 tz、rpm、appsboot等非常规镜像或分区的OTA升级。
2.1 SDX12 OTA方案
X12 OTA升级使用的是高通平台通用的FOTA方案,基本可以总结以下几个步骤:
- 本地制作差分包,并上传到远端OTA服务器
- x12启动OTA client线程去在固定间隔时间访问OTA服务器
- 当OTA服务器上有可用OTA 包,则校验包是否完整、版本号是否符合预期
- 若(3)中校验OK,则下载OTA包到本地
- 下载完成后重启进入recovery模式
- recovery模式启动后会先检测是否存在OTA包,存在则解压包并使用包中的工具打patch
- 升级完成后设置成功标记并重启进入boot模式
- 升级完成
流程图如下:
高通LE平台是多个子系统构成,其中boot、system这两个子系统属于HLOS镜像,其他如tz、rpm、appsboot、modem等均为non-HLOS镜像。
虽然NAND设备 (例如SDX12) 支持non-hlos镜像的OTA升级,但电源中断安全升级机制仅适用于system、boot和modem镜像。启动关键映像 (如tz、rpm、appsboot等) 可以升级,但如果在升级的很短时间内发生电源中断 (通常为毫秒),设备将处于砖砌状态。
因此默认OTA方案通常仅建议升级boot、system和modem镜像,其中boot镜像是以全包的方式、system镜像以文件patch方式、modem以压缩拆分后的patch方式:
但由于boot镜像占用较大的空间,对于硬件(FLASH,DDR)要求比较高。很多时候无法满足,因此我们在高通LE OTA升级方案上做出如下优化:将boot镜像也以patch的方式进行升级,这样就可以减少对于硬件(FLASH,DDR)要求,满足低存储空间的场景。
2.2 OTA升级TZ/RPM/Aboot
但是还存在客户想OTA升级启动关键映像 (如tz、rpm、appsboot等),如客户有屏幕的场景,想更新开机动画,而开机动画在sbl阶段就已经开始,因此就需要去升级appsboot镜像。虽然启动关键映像 (如tz、rpm、appsboot等) 可以升级,但如果在升级的很短时间内发生电源中断 (通常为毫秒),设备将处于砖砌状态。但高通针对这种情况,也是提供了对应的升级方案,但不建议使用,下面我们将简单介绍如何去OTA升级这些非常规的分区。
根据高通文档80-16206-49 AA,我们可以看到如我们想升级non-hlos镜像,只需将这些镜像打包在OTA目标版本底包的RADIO目录下即可。
按照上述方法,我们手动将appsboot镜像打包到RADIO目录下:
然后使用OTA差分制作工具制作差分包,就可以在OTA差分包firmware目录下看到appsboot镜像,当升级时就会按照patch脚本去打patch升级appsboot镜像:
在差分包的patch脚本META-INF\com\google\android\updater-script中也确实可以看到appsboot镜像将以raw镜像的方式升级:
但上面这种方式需要手动打包tz、rpm、appsboot等镜像到OTA目标版本底包中,这样是非常不便利的,因此修改ota底包制作流程,将tz、rpm、appsboot等镜像按需打包进OTA底包中:
但如果我们在目标和当前版本OTA底包中都放上tz、rpm、appsboot等镜像,又会导致他们会以patch的方式升级,而tz、rpm、appsboot等镜像本身就只有不到1M的空间,因此完全无需patch方式,因此修改差分包制作工具,判断当文件为tz、rpm、appsboot等镜像时,无需制作patch,直接拷贝目标镜像即可。
通过上述这些修改,就可以完成OTA升级tz、rpm、appsboot等非常规分区。