摘 要:设计了一种Android手机系统框架下的基带NV数据保存方案。主要包括方案的总体框架、AP侧数据接收和保存流程、CP侧NV数据发送流程、扩展的IIC通信机制的设计，以及方案验证与结果分析等。在由Cortex A9核心的四核AP芯片和ARM9核心的单核CP芯片组成的手机硬件系统上实现和测试了该方案。验证结果表明，该基带NV数据导出方案具有良好的可靠性和可行性，可以应用于实际的商业产品中。

关键词：Android系统；基带NV数据；IIC通信；内部处理器通信；数据包

当前的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驱动组成。

在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数据的保存工作，这一步很重要，将在下节详细介绍。

(4)NVM Daemon将NV数据完整地保存到文件系统后，发送应答ACK包通知CP侧数据保存完成。如果在收包过程中出现异常，则发送ACK包通知CP侧重传。

1.2.2 AP侧数据保存机制

NV数据以包的形式发送，不同NV数据的数据包可能交错发送，NVM Daemon应能够正确组包，正确地将NV数据保存到文件系统中。NV数据包格式结构体的定义为：

typedef struct _pkginfo{

u8 head; //包头首部

u8 type；

//当前包的NV数据类型

u8 cur_id;

//当前传输的数据包id

u8 total_id； //总数据包个数id

u32 data_len；//当前包传输的有效数据字节长度

}pkginfo;

同时，为了响应AP和CP间的数据收发动作，需要发送ACK包，ACK包格式结构体定义为：

typedef struct _ackinfo{

u8 head; //包头首部字段

u8 type； //数据类型

u8 result；//当前包传输结果

u8 tail； //包尾字段

}ackinfo;

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读取数据包，否则继续。

(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所示。

硬件连接与通用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所示。

重复以上测试场景多次后，将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.