關于MTK啟動過程詳解是本文要介紹的內容，主要是來了解MTK在啟動過程中的一些原理。MT6305上電給基帶芯片供電，在一定時序條件后，給基帶芯片復位信號，開始了ARM核的啟動過程。要談啟動，我們必須熟悉Scatterfile、基帶資料的Memorymapping章節。Scatterfile定義了loadregion和excecuteregion，我們要關心系統運行時代碼、數據的地址分布。

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

1、配置PLL，配置基帶芯片的EMI參數，以讓系統能夠以最大的速度讀取外部存儲設備數據，讓CPU以最大速度運行，從而縮短啟動過程。

2、做好runtime代碼及數據的準備，確保excecuteregion的代碼及數據到位。

3、配置好ARM七種異常模式的堆棧，進入RTOSnucleus的初始化。

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

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中完成，然后taskschedule后執行comp_entry_func。comp_cfg_func、comp_reset_func、comp_end_func我認為無太多意義。

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

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

GUI機制

至于MMIframewok，我未做太多了解，但任何GUI系統面對的都是最終的LCDbufffer。但不同的是，MTK的基帶芯片搞了個LCD控制器，并加了layer的概念，從硬件上支持2Dfunction和加速LCD的刷屏。對于上層的GUI，要做的是選擇哪個layer是active。

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

需要說明的是，僅僅是這樣一張圖，我們應該有更多的聯想。Layerbuffer都是從外部RAM開辟的內存空間，LCD的訪問時序完全決定于如何配置LCD控制器。對Layerbuffer的讀寫，需要占用系統總線，即使再做總線上的區域規劃，外部RAM的數據總線是公共資源。對公共資源的訪問，就意味著并發，意味著仲裁ARBITER。為什么在以前的項目中，出現一些關于LCD的莫名其妙的問題，不能說這里是根本原因，但我們應該從系統的角度去注意到這點。我對資源的占有，就意味著別人的失去。以往被掩蓋的缺陷，可能會因為系統運行時的變化，暴露出來。這就是我認為，有些系統問題，不能從代碼表面去分析，而要從ARM核的角度，從同cache,BUS,controller等外圍設備之間的聯系來系統的分析問題。

關注一下開機LOGO的顯示，是在uem_poweron_timer_expiry_hdlr函數中，同時這里做了latchpower的動作。還有潛力，提前顯示出LOGO。

內存分配機制

在MTK的資料中，介紹了它的內存管理機制，有3種：ADM、Controlbuffer、SystemMemory。后兩個是系統使用的，與上層應用無關。但是我對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。系統的一些taskstack.等也都是通過kal_system_alloc來分配的。

也就是說，Controlbuffer、SystemMemory用的都是System_Mem_Pool的空間。而System_Mem_Pool可以查到，是在custom_configmem函數中配置。

ADM就完全沒有使用操作系統提供的內存管理算法，是平臺自創了一套。開發者，可以自己開辟一個POOL,自己在這個池用ADM提供的內存管理API完成內存的動態管理。具體的分配算法，就沒有再細看，跟一些通用的內存分配算法應該一致。但是在以前調試一個問題的時候，應該是可以斷定，ADM在每一個allocnode前后都加了GAP調試區，來判斷是否被overwrite。

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

文件系統

文件系統用的是FAT格式，最關鍵的是如何MOUNT存儲設備，如何匹配文件系統讀寫接口。MTK通過表格的形式來讓客戶選擇支持的flash，真的是很方便，考慮太周到。

編譯機制

MTK的makefile,寫的很復雜，有perl腳本，也有make腳本，但框架結構很好。雖然我對makefile結構通讀了一遍，但沒有仔細花時間對此形成文檔。

方案印象

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

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

基于MTK平臺的產品開發

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

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

小結：

關于MTK啟動過程詳解的內容介紹完了，希望通過本文的學習能對你有所幫助！