Android手机系统中基带NV数据保存方案

Android手机系统中基带NV数据保存方案

摘要: 设计了一种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通信机制三个方面，。

其中，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]。，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数据的保存过程，以动态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数据驱动提供通信和数据传送功能，起到了一个桥梁的作用。其结构设计。

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