Android手机系统中基带NV数据保存方案*
2013-08-13黄一峰黄俊伟
黄一峰,黄俊伟,吴 恋
(重庆邮电大学 新一代宽带移动通信终端研究所,重庆 400065)
当前的Android手机设计中通常将应用子系统(AP)和通信子系统(CP)分离。比较典型的情况是应用子系统运行Android操作系统,通信子系统运行Nucleus操作系统,两者相对独立,通过一定的接口进行通信[1]。
在手机运行过程中,通信子系统(即基带子系统(CP))会产生一些需要动态更新的数据,譬如手机系统数据、TD参数、GSM参数、音频校准数据等[2-3]。每台手机的这些数据都不尽相同。一般这些数据通过非失忆性介质(即NV(NonVolatile)模块)来进行保存和管理。因此,需要设计一种机制将CP侧的NV数据保存下来,以供基带子系统启动或运行时使用。
本文设计了一种双硬件处理器环境下将基带NV数据保存到手机文件系统(Flash)中的方案。其中,基带系统运行在ARM9核心的单核CP芯片上,应用系统运行在Cortex A9核心的四核AP芯片上。两者通过IIC机制进行通信和数据共享。本文的设计主要包括AP侧软件模块设计、CP侧NV数据发送流程设计以及IIC通信机制设计。
在实际的手机产品中应用本文的设计,进行大数据量、长时间基带NV数据保存测试,并进行可靠性分析,得到了良好的实验结果,证明了本设计的可靠性和可行性。
1 系统方案设计
1.1 系统总体框架设计
基带NV数据保存方案包括AP侧软件模块、CP侧数据发送流程以及IIC通信机制三个方面,如图1所示。
其中,CP侧主要由NV数据产生模块(NVM Process)和CP侧IIC驱动组成;AP侧主要由数据接收模块(NVM Driver)、NV数据守护进程(NVM Daemon)和 AP侧 IIC驱动组成。
图1 基带NV数据保存方案框架图
在CP侧,Nucleus操作系统的NV数据进程(NVM Process)负责产生基带的NV数据,经过设备抽象层(DAI)转发后,基带NV数据被CP侧IIC驱动写入IIC缓存Buffer中。
在AP侧,对应的IIC驱动将从IIC缓存Buffer中读取到的NV数据上报给AP侧数据接收进程(NVM Driver)。最后,AP侧NVM守护进程收到数据接收进程上报的数据,进行数据包的解析,并将其保存在Flash设备中。
IIC通信机制包括物理上的IIC连接(IIC TX、RX、CTS、RTS)和公共的函数接口(API),AP侧和CP侧IIC驱动通过调用这些API即可完成相互通信和数据传输,从而达到两个系统命令和数据交互的目的。
1.2 AP侧软件模块设计
1.2.1 AP侧数据接收流程
NV数据采用包的形式,数据包的解析由守护进程NVM Daemon来完成。因此底层的驱动程序NVM Driver和IIC Driver不关心数据的具体格式,只关注数据的接收和传送过程[4]。如图2所示,AP侧数据接收流程如下:
(1)NVM Daemon程序启动成功之后,首先打开NVM驱动设备,若打开成功,则返回设备号,否则打印错误信息并退出。
(2)NVM Daemon通过read系统调用从NVM Driver获取更新后的NV数据。NVM Driver从IIC通道读取基带更新数据时,会首先判断通道中是否有可读数据,如果没有,则进程进入睡眠,等待唤醒条件到来,唤醒条件为通道中有可读数据;如通道中有可读数据,则直接读取,并将数据送往NVM Daemon。CP侧不定时更新数据,并将数据送往IIC通道。
(3)从内核空间得到的基带数据是以包的形式封装的,所以接下来NVM Daemon要做的工作就是解析包头,从包中取出有效数据,并且进行NV数据的保存工作,这一步很重要,将在下节详细介绍。
图2 AP侧和CP侧软件交互图
(4)NVM Daemon将NV数据完整地保存到文件系统后,发送应答ACK包通知CP侧数据保存完成。如果在收包过程中出现异常,则发送ACK包通知CP侧重传。
1.2.2 AP侧数据保存机制
NV数据以包的形式发送,不同NV数据的数据包可能交错发送,NVM Daemon应能够正确组包,正确地将NV数据保存到文件系统中。NV数据包格式结构体的定义为:
ackinfo结构体成员result表示当前包传输结果,返回0表示接收正确,返回1表示接收错误,要求CP侧重传。
NVM Daemon对NV数据的保存过程如图3所示,以动态NV数据(nv_dynamic)为例,简述如下:
(1)Daemon程序启动后首先初始化全局变量n,用来统计本次接收过程中总共接收了多少个nv_dynamic类型的NV数据包。
(2)进入read系统调用,收到数据后,首先解析包头数据,获取数据类型、总包数、当前包数、有效数据长度等,并将这些信息保存到包格式pkginfo结构体中。
(3)打开 nv_dynamic.bin文件,将变量 n的值加 1;判断是否 n>pkginfo->total_id,若大于,则表明接收到的包数已经超过了本次传输的总包数,为异常情况,打印相关的异常信息并且退出,重新调用read读取数据包,否则继续。
图3 NVM Daemon对NV数据包保存流程图
(4)判断是否 n=pkginfo->cur_id,如果不等,则说明此时得到的NV数据不是按正常顺序发送到AP端的,此时发送ACK包给CP,要求重传。
(5)若 n=pkginfo->cur_id,接着判断是否 n=pkginfo->total_id,如果不等,则直接将NV数据保存到 nv_dynamic.bin中,然后进行下一个数据包的接收。
(6)如果 n=pkginfo->total_id,则说明此次接收的是整个传输的最后一个包,将NV数据保存到nv_dynamic.bin文件。然后发送ACK包通知CP整个数据接收完成。将n清0,关闭nv_dynamic.bin文件后退出。
通过上述流程,可以有效解决NV数据发送过程中的包序错乱、发包重复等问题,保证NV数据的有效保存。
1.3 CP侧NV数据发送流程
CP侧负责NV数据的产生和发送工作。CP侧NV数据发送具体流程如下:
(1)内部定时器每20 ms判断基带NV数据是否有更新。
(2)若 NV数据有更新,且长度满足发送条件,则进行包头封装,完成组包工作,不满足则退出。
(3)NV数据组包完成后,平台无关化接口函数DAI_NV_SEND()调用CP侧IIC驱动发送长度为L的NV数据。
(4)DAI_NV_SEND()函数调用完成后返回数据发送结果 retVal。
(5)判断retVal是否等于应发送长度 L,若是则更新缓存Buffer数据索引后结束,不是则直接结束。
2 扩展的IIC通信机制设计
IIC通信机制建立在普通IIC通信机制之上,除了一般的IIC数据收发功能外,还扩展了通道注册、通道对象管理、通道中断处理等功能。
IIC通信机制为AP与CP间的NV数据驱动提供通信和数据传送功能,起到了一个桥梁的作用。其结构设计如图4所示。
图4 IIC通信机制结构图
图5 保存的基带NV二进制数据截图
硬件连接与通用IIC通信协议相同,在AP和CP侧有对等的IIC驱动模块。二者有相同的数据结构和循环数据缓冲区管理接口。
对于外部接口、内部接口,通道对象管理和中断ISR服务等,AP和CP侧需要分别实现。AP和CP外部API接口相同,但具体实现不同。
IIC通信机制提供给AP和CP的外部API包括:创建数据通道(iic_create_ch)、读通道数据(iic_read_ch)、写通道数据(iic_write_ch)、注册通道中断(iic_register_inthandle)、通道使能(iic_enable_inthandle)等。
3 系统功能测试与结果分析
系统功能的测试主要包括两个测试点:(1)数据通路是否畅通;(2)NVM Daemon保存的NV数据是否完整有效。
针对测试点(1)可以在各个数据通路之间采取假数据发送的方式进行测试,例如,在AP侧IIC Driver中用假数代替从基带获取的NV数据送往NVM Driver中,测试两者间通路是否畅通。
针对测试点(2)将假数据以包的形式发送,分多种类型,分开不按顺序发送,测试NVM Daemon的组包能力。
在进行数据通路测试的同时,使用一定压力的基带业务,以测试系统的抗压能力[5]。具体测试场景设计如表1所示。
表1 系统功能测试场景设计
重复以上测试场景多次后,将AP侧保存的NV数据导出到PC上观察可知,保存的NV数据正确,也没有出现数据包丢失和错乱的情况,符合系统设计的目标,如图5所示。
本文提出的基带NV数据保存功能模块已经在基于Linux 2.6.32内核的Android 4.1定制版本上实现。
在AP和CP侧通信机制设计中采用了扩展功能的IIC机制,使AP与CP两个独立系统的通信和数据交换十分方便。同时,在AP侧的NV驱动中使用了中断唤醒的技术,在没有数据传送时,整个数据通道处于睡眠状态,有效地节省了系统资源开销。最后,AP侧的NVM Daemon在组包过程中考虑到了数据包错乱、重复等异常情况,并设计了相应的容错机制。既可保证数据的完整有效性,也能满足实际项目的需求。
本方案已经被应用于国家重大专项“TD-SCDMA增强型多媒体手机终端的研发和产业化”中。
[1]王海霞.TD/GSM双模手机软件架构的研究与实现[D].南京:南京邮电大学,2010.
[2]朱亚洲.GSM手机软件开发[D].武汉:武汉科技大学,2007.
[3]周非,亓英杰,刘永康,等.TD-SCDMA终端探测设的DSP设计与实现[J].电子技术应用,2012,38(4):16-19.
[4]孟小华,黄宗轩.Android系统非标准设备驱动程序设计[J].微型机与应用,2011,30(14):7-9.
[5]李志丹.嵌入式软件调试方法研究[J].计算机与数字工程,2012(7):157-159.