NO IMAGE

微博搜尋 bindingfly 歡迎關注

一、 目的
      來到這裡近兩月,更近距離的接近了MTK。身處基於MTK平臺的產品開發浪潮之中,讓我對MTK有更多的瞭解,不光是在平臺技術本身。就技術上,從軟體 角度、系統角度,對MTK我應該能給出深度而全面的評價或看法。就產品上,我也有自己的一些見解和思考。總之,對於MTK我所產生的思考及結論,希望能在 這裡同大家分享。如果能拋磚引玉,引發大家更有意義及價值的思考,是我此文最大的願望。
二、 適用範圍
     全體
三、 定義
     無
四、 前言
       MTK是一個偉大的公司。在輿論批評山寨,並間接批評MTK的時候,我們只能認為這是產業成功而引起的喧鬧中的一種形式。 MTK在手機市場快速發展的時候,我投身所謂在振興民族通訊產業的TD領域。那時我經常提及MTK,MTK在01年起步,在04年面向市場,花了3年時 間。在一個已經成熟的GSM網路,完成一個終端平臺的商用,花了3年時間。而對於一個還處於實驗室階段的TD平臺,它的成熟花個3年時間是起碼的。這是我 經常向別人解釋為什麼TD終端還不成熟的理由或者藉口。在努力促使TD終端商用化的過程中,經受了3年各種各樣的煎熬,有網路、平臺、應用、專案、市場等
方方面面,讓我更感覺MTK方案設計有很多可取之處。下面,我就將我所瞭解到的與MTK平臺有關的任何細節的東西,都一一列舉出來,重點還是在軟體部分。
五、 MTK方案
       04年,多媒體手機開始興起。MTK方案的技術核心就是基帶晶片支援多媒體功能,降低了成本,加速了多媒體手機產品的上市時間。MTK方案的服務核心就是 turnkey模式,一改ADI、infineon等方案那種“能在我的方案上做什麼賣給使用者”的思維方式,而是“我的方案能直接賣給什麼使用者”。
MTK 在基帶晶片中整合LCD控制器、CAMERA控制器、多媒體CODEC。這種方式,自然是外帶多媒體協處理器從成本及開發週期上無法比擬的。ADI、 infineon、agere、TI等方案的出局就成必然。但為什麼這些歐美公司在方案上不做調整呢?可能的原因是,在失去技術核心競爭力以及領跑優勢 後,和中國公司站在同一起跑線競爭太難。中國人能吃苦,老外要渡假。
MTK將能做的功能,基本上都給客戶做好。這大大縮短了客戶的研發週期,也就 是所謂的降低了技術門檻。從節約社會勞動力,提高社會整體效益的角度講,MTK的方式是合理的。它避免了N個客戶的重複勞動,重複的走彎路。從這個角度 講,TI方案最次,連BASIC MMI都沒有,還停留在早期做GSM手機的模式。
MTK這種直面客戶的模式,也最大力度的支援著手機終端生產者,花最大的精力在如何降低成本及創新去迎合消費者需求,提升他們本來就缺乏的核心競爭力。山寨機的存在,說明有這樣一群消費者需要成本低廉、多樣性的手機產品,並容忍產品的細節性缺陷。

六、            MTK軟體平臺
       做過的手機平臺有好幾個,但都是Feature phone。目前做手機,可以說是在高科技產品光環下的系統整合,需要一定的技術實力,但更多的是平臺積累的經驗。特別是軟體,平臺之間的切換很麻煩。越 是更多的依賴積累於某一平臺的經驗,切換到其他平臺就更麻煩。越是做過多的平臺具體工作,切換到其他平臺就越麻煩。因此,我非常看好智慧手機的前景,儘管 現在市場存在問題,未來幾年的市場仍然存在問題。在未來,支撐智慧作業系統的硬體配置成本不再可怕的時候,智慧手機必然是首選,是MTK turnkey模式發展方向的終極模式。

我瞭解MTK軟體平臺,主要是先看支撐軟體平臺的硬體方案。方案之間的差異化 競爭,核心還是在硬體方案的差異化。但是所有的方案,從框架上來講,都是大同小異。最大的同,都是基於同一個ARM核,可能有基於基帶應用的不同,在 PLL、CACHE、協處理器以及外圍控制器上的小異。即使使用C166的infineon方案,效能雖然有差異,但從使用角度講,原理是一樣的。

      針對MTK軟體平臺,我看過它的啟動過程、記憶體分配機制、編譯機制、GUI機制、RTOS、檔案系統以及非常重要的基帶晶片資料(主要是6225)。在閱讀MTK方案的過程中,關鍵之處我都做了記錄,一直就想找個機會對這些做一整理。

6.1              啟動過程
       MT6305上電給基帶晶片供電,在一定時序條件後,給基帶晶片復位訊號,開始了ARM核的啟動過程。要談啟動,我們必須熟悉Scatter file、基帶資料的Memory mapping章節。Scatter file定義了load region和excecute region,我們要關心繫統執行時程式碼、資料的地址分佈。

       Bootarm.s是一個重要的檔案,與啟動過程有關,其中的INT_Initialize函式是ARM啟動開始執行的程式碼。BSP所做的事情主要包括:

       1、配置PLL,配置基帶晶片的EMI引數,以讓系統能夠以最大的速度讀取外部儲存裝置資料,讓CPU以最大速度執行,從而縮短啟動過程。

       2、做好runtime程式碼及資料的準備,確保excecute region的程式碼及資料到位。

       3、配置好ARM七種異常模式的堆疊,進入RTOS nucleus的初始化。

       4、nucleus留給客戶的初始化函式Application_Initialize,做了平臺該做的初始化工作,比如外部控制器的初始化等等。

6.2              RTOS
      在分析系統問題,開發跨執行緒應用時,必須熟悉RTOS。目前使用的RTOS是nucleus,儘管在BSP中看到了它對ThreadX的支援。不同的 RTOS,實際上也是大同小異,但是具體的API或者引數會有不同,因此我們需要下載nucleus的API文件,在需要了解細節時,可以翻閱此文件。同 時,TRACE32支援基於RTOS級別的除錯,因此對RTOS的瞭解,有助於提高除錯能力。

      有點特殊的是,nucleus有 LISR,HISR的概念,實際上它是一種給開發者的印象。它告訴開發者,中斷處理函式LISR要儘量的耗時短,以確保其它中斷能有機會及時響應。 HISR再處理略為次要些的工作,但耗時也不能太長,因為HISR比任何TASK的優先順序都高,我們應該讓真正需要實時的工作獲取CPU的機會。

Application_Initialize中的mainp函式,負責任務 的建立。我們在程式碼中見不到任務建立的函式,只需要維護任務初始化引數資料結構。對於系統的那些task資訊,都儲存在 sys_comp_config_tbl變數中,我們看不到。但是MTK提供給客戶的custom_comp_config_tbl,客戶是可以修改的, 在這裡使用者可以定義自己的task。

關於任務,需要關心資料結構 comptask_handler_struct。關於comptask_handler_struct成員的執行順序,應該 是:comp_init_func 在系統還未 schedule 即在Application_Initialize中完成,然後task schedule後執行comp_entry_func。comp_cfg_func、comp_reset_func、comp_end_func我認
為無太多意義。

        task和module有什麼區別?可以肯定的是,task 是作業系統層面的概念,module是軟體平臺設計者因為某種需要而設計的,可能大家比我更清楚,但這種概念在具體工作中可能還是需要弄清楚。

到此,基於RTOS的各個TASK應該都已經排程起來。首先毫無疑問,idle task必須是優先順序最低的task。按照常理,系統會從最高優先順序的任務開始排程,至於如何跑到MMI顯示LOGO介面,在必要時,我們可以去研究。

6.3              GUI機制
        至於MMI framewok,我未做太多瞭解,但任何GUI系統面對的都是最終的LCD bufffer。但不同的是,MTK的基帶晶片搞了個LCD控制器,並加了layer的概念,從硬體上支援2D function和加速LCD的刷屏。對於上層的GUI,要做的是選擇哪個layer是active。

LCD控制器的刷屏機制。以6225為例,支援4 layer。MTK資料對LCD控制器未做詳細的描述,如圖1是其對LCD介面塊圖的描述。但通過LCD控制器驅動,我們可以對LCD控制器內部結構做更 多的假設。圖1中的Overlay,我們可以設想為一個專有的DMA控制器通道,目標地址為LCD,源地址是layer buffer。系統通過配置要刷哪幾層,配置alpha值來控制2D效果。這一目的的達到,硬體上有它的考慮,我們也沒有必要做太多確定性的假想。


圖1  LCD介面塊圖

       需要說明的是,僅僅是這樣一張圖,我們應該有更多的聯想。Layer buffer都是從外部RAM開闢的記憶體空間,LCD的訪問時序完全決定於如何配置LCD控制器。對Layer buffer的讀寫,需要佔用系統匯流排,即使再做匯流排上的區域規劃,外部RAM的資料匯流排是公共資源。對公共資源的訪問,就意味著併發,意味著仲裁 ARBITER。為什麼在以前的專案中,出現一些關於LCD的莫名其妙的問題,不能說這裡是根本原因,但我們應該從系統的角度去注意到這點。我對資源的佔
有,就意味著別人的失去。以往被掩蓋的缺陷,可能會因為系統執行時的變化,暴露出來。這就是我認為,有些系統問題,不能從程式碼表面去分析,而要從ARM核 的角度,從同cache,BUS,controller等外圍裝置之間的聯絡來系統的分析問題。

關注一下開機LOGO的顯示,是在uem_poweron_timer_expiry_hdlr函式中,同時這裡做了latch power的動作。還有潛力,提前顯示出LOGO。

6.4              記憶體分配機制
      在MTK的資料中,介紹了它的記憶體管理機制,有3種:ADM、Control buffer、System Memory。後兩個是系統使用的,與上層應用無關。但是我對kal_system_alloc也做了初步分析。

       sys_mem_ptr,其估計應該指向的是 System_Mem_Pool,       debug_mem_ptr,其估計應該指向的是 debug_Mem_Pool。       經過初步分析,kal_system_alloc就是從System_Mem_Pool做簡單的加法操作,sys_mem_left_size就是 System_Mem_Pool還剩下多少。kal_system_alloc從sys_mem_ptr開始來計算要取的記憶體。ctrl_buf是通過
kal_system_alloc的記憶體,然後再通過NU_Create_Partition_Pool建立POOL。系統的一些task stack.等也都是通過kal_system_alloc來分配的。

         也就是說,Control buffer、System Memory用的都是System_Mem_Pool的空間。而System_Mem_Pool可以查到,是在custom_configmem函式中配置。

ADM就完全沒有使用作業系統提供的記憶體管理演算法,是平臺自創了一套。開發 者,可以自己開闢一個POOL,自己在這個池用ADM提供的記憶體管理API完成記憶體的動態管理。具體的分配演算法,就沒有再細看,跟一些通用的記憶體分配演算法 應該一致。但是在以前除錯一個問題的時候,應該是可以斷定,ADM在每一個alloc node前後都加了GAP除錯區,來判斷是否被overwrite。

         至於系統中,到底是用了多少塊記憶體用於ADM,各塊記憶體又是讓哪些應用在共享,開發者可能更清楚。在系統中是否建立了對記憶體動態分配的監控機制,比如查詢記憶體洩漏、動態記憶體使用效率等等。

6.5              檔案系統
       檔案系統用的是FAT格式,最關鍵的是如何MOUNT儲存裝置,如何匹配檔案系統讀寫介面。MTK通過表格的形式來讓客戶選擇支援的flash,真的是很方便,考慮太周到。

6.6              編譯機制
       MTK的makefile,寫的很複雜,有perl指令碼,也有make指令碼,但框架結構很好。雖然我對makefile結構通讀了一遍,但沒有仔細花時間對此形成文件。

6.7              方案印象
      MTK軟體平臺,接觸了一年,總體感覺其底層程式碼寫的很工整,結構很清晰。越到上層,程式碼就顯的龐大凌亂,結構性和可讀性都不強。如果把晶片設計也說 上,我覺得MTK的基帶晶片設計很智慧,針對特定的多媒體手機應用,設計出專門的控制器嵌入晶片內部。像uart控制virtrual fifo 和camera的resizer以及lcd controller,用低成本控制器來快速完成邏輯,從而減輕CPU的負擔,提高晶片的整體效能。在其他多媒體處理器中,都是不多見的。

與業界認為從事MTK平臺開發的技術含量低恰恰相反,我認為MTK方案技術含 量非常高。MTK軟體平臺的程式碼開放程度也不低,MTK的技術支援也非常有力而迅速,以MTK平臺為基礎的終端承載了最豐富多樣的應用。MTK方案給希望 對手機平臺有深入而全面瞭解的同事提供了機會。

七、            基於MTK平臺的產品開發
       有那麼多的公司在做基於MTK平臺的產品,競爭那麼激烈,研發上如何在競爭中體現優勢?硬體上,大家都一樣。軟體上,也是一樣。你可以有,別人也可以有或 者偷,別人可以有,我們也可以有或者偷。最多是差個把月,怎麼辦。一箇中心兩個基本點。以服務好客戶為中心,保證兩個基本點,一是要快,二是差異。

拉不到客戶什麼就不要做了。在大家都差不多的情況下,我們以客戶為中心,快速 的滿足客戶需求,提供產品。這樣能拉住客戶,讓客戶找不到離開的理由。第二是產品差異,是創新。如果有產品創新最好,要麼降低了成本,要麼吸引了消費者。 但這兩點中,還是快字最重要,這是可以通過團隊專業實力和激情來保證的。但是創新,有運氣的成分,需要研發同市場碰撞出火花。鼓勵和激勵創新,但不能只靠 產品創新一定會出現。

       總結起來,又回到管理二字上。依靠內部專案和質量管理保證產品研發速度、保證客戶服務質量。