摘要：
本文試圖通過**來深入剖析
qualcomm
手機開機的整個過程，即從按下開機鍵一直到出現待機介面，
qualcomm
的手機軟體在整個流程中究竟完成了哪些工作。本文的主要目標是理清手機的初始化流程，並為今後
amoi
定做初始化工作提供乙個參考。
關鍵字：開機、
rex、
tmc、
ui_task、
一、開機的簡要流程分析
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（
）層軟體打交道，但請大家記住，手機上所有功能的實現最根本點就是由這些服務元件（
service task
）來完成的。將來大家跟蹤乙個具體的功能模組時，比如說通話模組，如果需要，可以再去深入研究它的具體實現。
好了，到現在為止，所有的
amss
核心軟體就全部跑起來了（手機的功能模組，在軟體方面就體現為
os層面的乙個任務）。但現在大家還根本看不到
brew
和aee
的影子。呵呵，各位不要急。到了這個層面之後，我想稍微多說幾句。最早的
qualcomm
平台，比如說
5***
系列，是根本沒有
brew
的，那個時候的al（
）層軟體開發，是直接呼叫底層
service task
所提供的
api來完成相應的工作的。從這種角度來看的話，顯然那時的開發是比較鬱悶和難度較高的。不過，到了
65xx
之後，qualcomm
平台引入了
brew
，手機開發商就沒必要去從這麼底層（
service api
）的層面進行手機開發了，他們完全可以基於
brew
來實現一台手機的所有功能（
qualcomm
給我們的參考**，就是全
brew
平台的）。
brew
的執行環境
aee是如何跑起來的呢？關鍵在於
ui_task()
，由於ui_task
和我們手機開發的關係非常密切，其地位也相當重要，所以，後文我將單獨對它進行乙個深入的研究與分析。到目前為止，大家只需要知道
ui_task
將aee
載入起來了，並且，它起到了乙個中間層的作用，即所有
amss
底層服務元件的訊息，都將經由
ui_task
而轉到aee
，並最終轉到具體的
（）的執行**裡面（
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商的操作流程；
是在brew
層面的乙個
al層的入口
，它其著管理整個上層
al層軟體的作用，根據產品需求，這個
需要定做；
4.aee
是整個上層
的執行環境，目前
qualcomm
沒有公開它的原始碼，但它的執行機制，
amoi
需要好好研究清楚，我將在另外一篇《
qualcomm
平台aee
執行機制深入分析與研究》中**它的執行機理和排程機制，大家有興趣可以參考此文；
高通平台 開機logo 替換
經過兩天的奮戰終於把開機logo給搞定了啊。首先修改開機logo要從 入手呢？先分析一下原始碼看看.1 void display image on screen 211 12if fbimg 2425 fbcon putimage fbimg,flag 26 粗略的看了一下原始碼，大概可以知道要修改...
高通平台開機logo的修改
方法一 準備一張和lcd解析度一樣大小的pnglogo.png，在高通原始碼目錄device qcom common display logo下面，有readme.txt檔案，裡面有說明生成映象檔案的方法 執行命令 python logo gen.py logo.png，在當前目錄下面會生成spla...
高通dul sim卡方案需求
忙活了一天，本來可以完成任務的的，這才發現自己的c語言的基礎有多差啊，就是個變數的問題啊！到現在還是沒有找到可行的方案？高通的雙卡方案，是在開機的時候就初始化兩個卡，如果兩個卡都有的話。然後呢可以切換成只有一張卡的狀態，但是呢，這個切換只是在上層應用做的處理就是使得一張卡斷網，驅動層兩個卡還是在不停...