摘要：
    本文試圖通過程式碼來深入剖析Qualcomm手機開機的整個過程，即從按下開機鍵一直到出現待機介面，Qualcomm的手機軟體在整個流程中究竟完成了哪些工作。本文的主要目標是理清手機的初始化流程，併為今後Amoi定做初始化工作提供一個參考。
關鍵字：開機、Rex、TMC、ui_task、CoreApp

一、開機的簡要流程分析
    Qualcomm的平臺軟體支援兩種啟動方式：一種是Nor Flash啟動方式，另外一種就是Nand Flash啟動方式。Nor Flash啟動方式就相當於硬體直接找到一個入口點開始執行程式碼，相比較而言會 比較簡單，且Amoi沒有采用此種方式，所以本文對於這種方式不做詳細分析。另外一種就是Nand Flash啟動方式，這種方式和PC的啟動方式比較相像，也是Amoi採用的Boot方式，下面將詳細分析在此方式下面的開機過程。
    按下開機鍵之後，將產生一個時鐘中斷，從而通知AMSS主晶片的Boot Load硬體去將放置於Nand Flash上面的第一個Block（8K）裡面的Boot程式碼Copy到核心記憶體（RAM，這個記憶體應該是CPU自帶的記憶體，同後面提到的SDRAM有一定區別，可以把它當作CPU的Cache）的0xFFFF0000地址，並開始執行Boot程式碼。Boot的主要任務是完成整個系統的硬體初始化工作（類似於PC上面的BIOS所完成的硬體自檢工作，至於Boot的詳細工作機制，後文會有詳細描述）。Boot所完成的工作裡面，最重要的一件事就是會將整個手機軟體程式碼（AMSS軟體包）拷貝到SDRAM中，並最後將控制權交給AMSS軟體。說白了，就是Boot執行完成之後，程式碼的執行點將由Boot跳轉到AMSS軟體的的入口點函式main().（此函式在mobile.c裡實現）。
    程式碼執行到了Main()之後，在這個函式裡面將完成作業系統（rex）的初始化工作，其實現方法是呼叫    rex_init()。

Rex_init()完成的工作很簡單：
    1.完成作業系統必要的一些資料結構（timer連結串列、任務連結串列等）的初始化；
    2.接下來，它建立了三個任務，分別是：rex_idle_task、rex_dpc_task和tmc_task。
    Idle任務沒什麼好解釋的，目前這個任務為空，什麼也沒做，dpc_task目前不知道是做什麼的，暫時可以不用管。前面的這兩個任務都屬於作業系統層面的，由作業系統來維護，和手機軟體關係不大。哪一個和手機軟體關係大呢？答案是：tmc_task。大家可以把這個當作作業系統的入口(主)任務，也可以把它當作整個手機軟體的入口任務。即AMSS軟體裡的所有其它任務的建立和維護就是由這個tmc_task來完成的。
    到此為止，整個AMSS軟體還並沒有跑起來，只是跑到了tmc_task裡面了。在tmc_task裡面，會呼叫tmc_init()來完成整個AMSS軟體包的初始化工作，其中最重要的一項工作就是呼叫tmc_define_tasks()將AMSS軟體包所有需要的任務都建立起來了。比如說slee_task、dog_task、cm_task、wms_task、ui_task等。這些任務，一般不需要直接和AL（Application Layer）層軟體打交道，但請大家記住，手機上所有功能的實現最根本點就是由這些服務元件（Service Task）來完成的。將來大家跟蹤一個具體的功能模組時，比如說通話模組，如果需要，可以再去深入研究它的具體實現。
    好了，到現在為止，所有的AMSS核心軟體就全部跑起來了（手機的功能模組，在軟體方面就體現為OS層面的一個任務）。但現在大家還根本看不到Brew和AEE的影子。呵呵，各位不要急。到了這個層面之後，我想稍微多說幾句。最早的Qualcomm平臺，比如說5xxx系列，是根本沒有Brew的，那個時候的AL（Application Layer）層軟體開發，是直接呼叫底層Service task所提供的API來完成相應的工作的。從這種角度來看的話，顯然那時的開發是比較鬱悶和難度較高的。不過，到了65xx之後，Qualcomm平臺引入了Brew，手機開發商就沒必要去從這麼底層（Service API）的層面進行手機開發了，他們完全可以基於Brew來實現一臺手機的所有功能（Qualcomm給我們的參考程式碼，就是全Brew平臺的）。
    Brew的執行環境AEE是如何跑起來的呢？關鍵在於ui_task()，由於ui_task和我們手機開發的關係非常密切，其地位也相當重要，所以，後文我將單獨對它進行一個深入的研究與分析。到目前為止，大家只需要知道ui_task將AEE載入起來了，並且，它起到了一箇中間層的作用，即所有AMSS底層服務元件的訊息，都將經由ui_task而轉到AEE，並最終轉到具體的App（Applet）的執行程式碼裡面（HandleEvent()）。
    注意：

    1.上述的開機過程，在每一次按開機鍵都需要走一遍，即關機之後，整個系統的所有功能都將消失，而不像有些手機，看起來是關了機，但實際上底層還是有一些軟體模組在跑。為什麼可以肯定地說上述開機過程每次都必須走一遍，原因很簡單，因為我們的平臺軟體是基於Nand Flash啟動的，所有的程式碼都需要Copy到SDRAM才能執行，而關機斷電之後，SDRAM裡的東東會全部丟失，所以，毫無疑問，上述的過程必須每次開機都執行；
    2.關機的過程相對比較簡單，系統檢測到關機中斷之後，將呼叫tmc_powerdown_handler（）來完成關機動作，它將把所有AMSS的任務都Stop掉，並最後呼叫rex_exit()退出Rex，從而完成整個關機動作。
    3.顯然，關機動作前，如果有必要，每一個任務必須將它希望儲存的資訊儲存到Flash上面，以便下次開機時可以得到這些資訊；

 

    說明：
    1.Tmc是作業系統層面和AMSS軟體關係最密切的一個任務，不過需要OEM商在此處修改的地方應該不多；
    2.ui_task是在作業系統層面，OEM商需要重點研究清楚的一個任務，它是連線底層Task和上層AL的一箇中間層，有可能需要加入OEM商的操作流程；
    3.CoreApp是在Brew層面的一個AL層的入口Applet，它其著管理整個上層AL層軟體的作用，根據產品需求，這個App需要定做；
    4.AEE是整個上層App的執行環境，目前Qualcomm沒有公開它的原始碼，但它的執行機制，Amoi需要好好研究清楚，我將在另外一篇《Qualcomm平臺AEE執行機制深入分析與研究》中探討它的執行機理和排程機制，大家有興趣可以參考此文；