Android手機系統(tǒng)中基帶NV數(shù)據(jù)保存方案*

黃一峰，黃俊偉，吳 戀

(重慶郵電大學 新一代寬帶移動通信終端研究所，重慶 400065)

當前的Android手機設(shè)計中通常將應(yīng)用子系統(tǒng)(AP)和通信子系統(tǒng)(CP)分離。比較典型的情況是應(yīng)用子系統(tǒng)運行Android操作系統(tǒng)，通信子系統(tǒng)運行Nucleus操作系統(tǒng)，兩者相對獨立，通過一定的接口進行通信[1]。

在手機運行過程中，通信子系統(tǒng)(即基帶子系統(tǒng)(CP))會產(chǎn)生一些需要動態(tài)更新的數(shù)據(jù)，譬如手機系統(tǒng)數(shù)據(jù)、TD參數(shù)、GSM參數(shù)、音頻校準數(shù)據(jù)等[2-3]。每臺手機的這些數(shù)據(jù)都不盡相同。一般這些數(shù)據(jù)通過非失憶性介質(zhì)(即NV(NonVolatile)模塊)來進行保存和管理。因此，需要設(shè)計一種機制將CP側(cè)的NV數(shù)據(jù)保存下來，以供基帶子系統(tǒng)啟動或運行時使用。

本文設(shè)計了一種雙硬件處理器環(huán)境下將基帶NV數(shù)據(jù)保存到手機文件系統(tǒng)（Flash）中的方案。其中，基帶系統(tǒng)運行在ARM9核心的單核CP芯片上，應(yīng)用系統(tǒng)運行在Cortex A9核心的四核AP芯片上。兩者通過IIC機制進行通信和數(shù)據(jù)共享。本文的設(shè)計主要包括AP側(cè)軟件模塊設(shè)計、CP側(cè)NV數(shù)據(jù)發(fā)送流程設(shè)計以及IIC通信機制設(shè)計。

在實際的手機產(chǎn)品中應(yīng)用本文的設(shè)計，進行大數(shù)據(jù)量、長時間基帶NV數(shù)據(jù)保存測試，并進行可靠性分析，得到了良好的實驗結(jié)果，證明了本設(shè)計的可靠性和可行性。

1 系統(tǒng)方案設(shè)計

1.1 系統(tǒng)總體框架設(shè)計

基帶NV數(shù)據(jù)保存方案包括AP側(cè)軟件模塊、CP側(cè)數(shù)據(jù)發(fā)送流程以及IIC通信機制三個方面，如圖1所示。

其中，CP側(cè)主要由NV數(shù)據(jù)產(chǎn)生模塊(NVM Process)和CP側(cè)IIC驅(qū)動組成；AP側(cè)主要由數(shù)據(jù)接收模塊(NVM Driver)、NV數(shù)據(jù)守護進程(NVM Daemon)和 AP側(cè) IIC驅(qū)動組成。

圖1 基帶NV數(shù)據(jù)保存方案框架圖

在CP側(cè)，Nucleus操作系統(tǒng)的NV數(shù)據(jù)進程(NVM Process)負責產(chǎn)生基帶的NV數(shù)據(jù)，經(jīng)過設(shè)備抽象層(DAI)轉(zhuǎn)發(fā)后，基帶NV數(shù)據(jù)被CP側(cè)IIC驅(qū)動寫入IIC緩存Buffer中。

在AP側(cè)，對應(yīng)的IIC驅(qū)動將從IIC緩存Buffer中讀取到的NV數(shù)據(jù)上報給AP側(cè)數(shù)據(jù)接收進程(NVM Driver)。最后，AP側(cè)NVM守護進程收到數(shù)據(jù)接收進程上報的數(shù)據(jù)，進行數(shù)據(jù)包的解析，并將其保存在Flash設(shè)備中。

IIC通信機制包括物理上的IIC連接(IIC TX、RX、CTS、RTS)和公共的函數(shù)接口(API)，AP側(cè)和CP側(cè)IIC驅(qū)動通過調(diào)用這些API即可完成相互通信和數(shù)據(jù)傳輸，從而達到兩個系統(tǒng)命令和數(shù)據(jù)交互的目的。

1.2 AP側(cè)軟件模塊設(shè)計

1.2.1 AP側(cè)數(shù)據(jù)接收流程

NV數(shù)據(jù)采用包的形式，數(shù)據(jù)包的解析由守護進程NVM Daemon來完成。因此底層的驅(qū)動程序NVM Driver和IIC Driver不關(guān)心數(shù)據(jù)的具體格式，只關(guān)注數(shù)據(jù)的接收和傳送過程[4]。如圖2所示，AP側(cè)數(shù)據(jù)接收流程如下：

(1)NVM Daemon程序啟動成功之后，首先打開NVM驅(qū)動設(shè)備，若打開成功，則返回設(shè)備號，否則打印錯誤信息并退出。

(2)NVM Daemon通過read系統(tǒng)調(diào)用從NVM Driver獲取更新后的NV數(shù)據(jù)。NVM Driver從IIC通道讀取基帶更新數(shù)據(jù)時，會首先判斷通道中是否有可讀數(shù)據(jù)，如果沒有，則進程進入睡眠，等待喚醒條件到來，喚醒條件為通道中有可讀數(shù)據(jù)；如通道中有可讀數(shù)據(jù)，則直接讀取，并將數(shù)據(jù)送往NVM Daemon。CP側(cè)不定時更新數(shù)據(jù)，并將數(shù)據(jù)送往IIC通道。

(3)從內(nèi)核空間得到的基帶數(shù)據(jù)是以包的形式封裝的，所以接下來NVM Daemon要做的工作就是解析包頭，從包中取出有效數(shù)據(jù)，并且進行NV數(shù)據(jù)的保存工作，這一步很重要，將在下節(jié)詳細介紹。

圖2 AP側(cè)和CP側(cè)軟件交互圖

(4)NVM Daemon將NV數(shù)據(jù)完整地保存到文件系統(tǒng)后，發(fā)送應(yīng)答ACK包通知CP側(cè)數(shù)據(jù)保存完成。如果在收包過程中出現(xiàn)異常，則發(fā)送ACK包通知CP側(cè)重傳。

1.2.2 AP側(cè)數(shù)據(jù)保存機制

NV數(shù)據(jù)以包的形式發(fā)送，不同NV數(shù)據(jù)的數(shù)據(jù)包可能交錯發(fā)送，NVM Daemon應(yīng)能夠正確組包，正確地將NV數(shù)據(jù)保存到文件系統(tǒng)中。NV數(shù)據(jù)包格式結(jié)構(gòu)體的定義為：

ackinfo結(jié)構(gòu)體成員result表示當前包傳輸結(jié)果，返回0表示接收正確，返回1表示接收錯誤，要求CP側(cè)重傳。

NVM Daemon對NV數(shù)據(jù)的保存過程如圖3所示，以動態(tài)NV數(shù)據(jù)(nv_dynamic)為例，簡述如下：

(1)Daemon程序啟動后首先初始化全局變量n，用來統(tǒng)計本次接收過程中總共接收了多少個nv_dynamic類型的NV數(shù)據(jù)包。

(2)進入read系統(tǒng)調(diào)用，收到數(shù)據(jù)后，首先解析包頭數(shù)據(jù)，獲取數(shù)據(jù)類型、總包數(shù)、當前包數(shù)、有效數(shù)據(jù)長度等，并將這些信息保存到包格式pkginfo結(jié)構(gòu)體中。

(3)打開 nv_dynamic.bin文件，將變量 n的值加 1；判斷是否 n＞pkginfo-＞total_id，若大于，則表明接收到的包數(shù)已經(jīng)超過了本次傳輸?shù)目偘鼣?shù)，為異常情況，打印相關(guān)的異常信息并且退出，重新調(diào)用read讀取數(shù)據(jù)包，否則繼續(xù)。

圖3 NVM Daemon對NV數(shù)據(jù)包保存流程圖

(4)判斷是否 n=pkginfo-＞cur_id，如果不等，則說明此時得到的NV數(shù)據(jù)不是按正常順序發(fā)送到AP端的，此時發(fā)送ACK包給CP，要求重傳。

(5)若 n=pkginfo-＞cur_id，接著判斷是否 n=pkginfo-＞total_id，如果不等，則直接將NV數(shù)據(jù)保存到 nv_dynamic.bin中，然后進行下一個數(shù)據(jù)包的接收。

(6)如果 n=pkginfo-＞total_id，則說明此次接收的是整個傳輸?shù)淖詈笠粋€包，將NV數(shù)據(jù)保存到nv_dynamic.bin文件。然后發(fā)送ACK包通知CP整個數(shù)據(jù)接收完成。將n清0，關(guān)閉nv_dynamic.bin文件后退出。

通過上述流程，可以有效解決NV數(shù)據(jù)發(fā)送過程中的包序錯亂、發(fā)包重復(fù)等問題，保證NV數(shù)據(jù)的有效保存。

1.3 CP側(cè)NV數(shù)據(jù)發(fā)送流程

CP側(cè)負責NV數(shù)據(jù)的產(chǎn)生和發(fā)送工作。CP側(cè)NV數(shù)據(jù)發(fā)送具體流程如下：

(1)內(nèi)部定時器每20 ms判斷基帶NV數(shù)據(jù)是否有更新。

(2)若 NV數(shù)據(jù)有更新，且長度滿足發(fā)送條件，則進行包頭封裝，完成組包工作，不滿足則退出。

(3)NV數(shù)據(jù)組包完成后，平臺無關(guān)化接口函數(shù)DAI_NV_SEND()調(diào)用CP側(cè)IIC驅(qū)動發(fā)送長度為L的NV數(shù)據(jù)。

(4)DAI_NV_SEND()函數(shù)調(diào)用完成后返回數(shù)據(jù)發(fā)送結(jié)果 retVal。

(5)判斷retVal是否等于應(yīng)發(fā)送長度 L，若是則更新緩存Buffer數(shù)據(jù)索引后結(jié)束，不是則直接結(jié)束。

2 擴展的IIC通信機制設(shè)計

IIC通信機制建立在普通IIC通信機制之上，除了一般的IIC數(shù)據(jù)收發(fā)功能外，還擴展了通道注冊、通道對象管理、通道中斷處理等功能。

IIC通信機制為AP與CP間的NV數(shù)據(jù)驅(qū)動提供通信和數(shù)據(jù)傳送功能，起到了一個橋梁的作用。其結(jié)構(gòu)設(shè)計如圖4所示。

圖4 IIC通信機制結(jié)構(gòu)圖

圖5 保存的基帶NV二進制數(shù)據(jù)截圖

硬件連接與通用IIC通信協(xié)議相同，在AP和CP側(cè)有對等的IIC驅(qū)動模塊。二者有相同的數(shù)據(jù)結(jié)構(gòu)和循環(huán)數(shù)據(jù)緩沖區(qū)管理接口。

對于外部接口、內(nèi)部接口，通道對象管理和中斷ISR服務(wù)等，AP和CP側(cè)需要分別實現(xiàn)。AP和CP外部API接口相同，但具體實現(xiàn)不同。

IIC通信機制提供給AP和CP的外部API包括：創(chuàng)建數(shù)據(jù)通道(iic_create_ch)、讀通道數(shù)據(jù)(iic_read_ch)、寫通道數(shù)據(jù)(iic_write_ch)、注冊通道中斷(iic_register_inthandle)、通道使能(iic_enable_inthandle)等。

3 系統(tǒng)功能測試與結(jié)果分析

系統(tǒng)功能的測試主要包括兩個測試點：(1)數(shù)據(jù)通路是否暢通；(2)NVM Daemon保存的NV數(shù)據(jù)是否完整有效。

針對測試點(1)可以在各個數(shù)據(jù)通路之間采取假數(shù)據(jù)發(fā)送的方式進行測試，例如，在AP側(cè)IIC Driver中用假數(shù)代替從基帶獲取的NV數(shù)據(jù)送往NVM Driver中，測試兩者間通路是否暢通。

針對測試點(2)將假數(shù)據(jù)以包的形式發(fā)送，分多種類型，分開不按順序發(fā)送，測試NVM Daemon的組包能力。

在進行數(shù)據(jù)通路測試的同時，使用一定壓力的基帶業(yè)務(wù)，以測試系統(tǒng)的抗壓能力[5]。具體測試場景設(shè)計如表1所示。

表1 系統(tǒng)功能測試場景設(shè)計

重復(fù)以上測試場景多次后，將AP側(cè)保存的NV數(shù)據(jù)導(dǎo)出到PC上觀察可知，保存的NV數(shù)據(jù)正確，也沒有出現(xiàn)數(shù)據(jù)包丟失和錯亂的情況，符合系統(tǒng)設(shè)計的目標，如圖5所示。

本文提出的基帶NV數(shù)據(jù)保存功能模塊已經(jīng)在基于Linux 2.6.32內(nèi)核的Android 4.1定制版本上實現(xiàn)。

在AP和CP側(cè)通信機制設(shè)計中采用了擴展功能的IIC機制，使AP與CP兩個獨立系統(tǒng)的通信和數(shù)據(jù)交換十分方便。同時，在AP側(cè)的NV驅(qū)動中使用了中斷喚醒的技術(shù)，在沒有數(shù)據(jù)傳送時，整個數(shù)據(jù)通道處于睡眠狀態(tài)，有效地節(jié)省了系統(tǒng)資源開銷。最后，AP側(cè)的NVM Daemon在組包過程中考慮到了數(shù)據(jù)包錯亂、重復(fù)等異常情況，并設(shè)計了相應(yīng)的容錯機制。既可保證數(shù)據(jù)的完整有效性，也能滿足實際項目的需求。

本方案已經(jīng)被應(yīng)用于國家重大專項“TD-SCDMA增強型多媒體手機終端的研發(fā)和產(chǎn)業(yè)化”中。

[1]王海霞.TD/GSM雙模手機軟件架構(gòu)的研究與實現(xiàn)[D].南京：南京郵電大學，2010.

[2]朱亞洲.GSM手機軟件開發(fā)[D].武漢：武漢科技大學，2007.

[3]周非，亓英杰，劉永康，等.TD-SCDMA終端探測設(shè)的DSP設(shè)計與實現(xiàn)[J].電子技術(shù)應(yīng)用，2012，38(4)：16-19.

[4]孟小華，黃宗軒.Android系統(tǒng)非標準設(shè)備驅(qū)動程序設(shè)計[J].微型機與應(yīng)用，2011，30(14)：7-9.

[5]李志丹.嵌入式軟件調(diào)試方法研究[J].計算機與數(shù)字工程，2012(7)：157-159.