1、前言
1.1編寫背景
最近在解決MIFI關機狀態下充電去logo的問題時跟蹤了一下開機流程也查閱了一些資料，決定做下記錄，鞏固MDM9x35平臺知識的學習，加深對高通9635平臺的瞭解，也爲同樣在學習高通該平臺啓動流程的人做參考。起初硬着頭皮分析代碼，看了些天發現還是一頭霧水，被9x35的架構給套住了，總是以之前高通其它平臺的原理去想9x35平臺的問題，最後一點點分析高通文檔，再結合代碼才勉強搞清楚了9635平臺軟件的大致架構。
1.2概述
本文檔簡要的介紹了高通MDM9x35的啓動流程，通過閱讀讀者可以大致的瞭解9x35平臺是如何正常啓動起來的。由於能力有限，加上寫作功底欠佳，其中難免會有錯誤之處，懇請指正，如有誤導大家之處，懇請諒解。
1.3定義與縮寫
本文檔中使用的術語如表1-1術語表所示，大多爲高通的縮略詞
|
解釋、含義 |
|
|
RPM |
Resource Power Manager(資源電源管理子系統) |
|
APPS |
Applications(應用子系統) |
|
Modem |
調製解調(基帶)處理子系統 |
|
ADSP |
Advanced Digital Signal Processor(數字信號處理器) |
|
PBL |
Primary Bootloader(主引導加載程序) |
|
SBL |
Second Bootloader(二級引導加載程序) |
|
SDI |
System Debug Image(系統debug鏡像) |
|
TZ |
TrustZone(信任區) |
|
MBA |
Modem Boot Authenticator(調制解調器引導認證) |
|
AMSS |
Advanced Mobile Subscriber Software(高通自己的操作系統) |
|
LPASS |
Low Power Audio SubSystem(低功耗音頻子系統) |
|
SMEM |
shared memory(共享內存) |
|
L2 TCM |
Tightly-Coupled Memory(緊耦合內存) |
|
HLOS |
High-level Operation System(高級操作系統) |
|
QRD |
Qualcomm Reference Design(高通參考設計) |
|
LK |
Little Kernel |
|
FW |
Firmware(固件) |
|
PIL |
Peripheral image loader(外圍鏡像加載) |
1.4參考資料
查閱、參考資料如表1-2所示。
|
序號 |
文檔名稱 |
作者或資料來源 |
|
1 |
80-NH740-7_D_MDM9x35_Boot_Architecture_BSP_Overview |
QRD |
|
2 |
80-NH740-43_A_Enable_Secure_Boot_MDM9x35_ASICs |
QRD |
|
3 |
《高通msm8994啓動流程簡介》 |
Web |
|
4 |
《8926平臺boot過程分析》 |
Web |
|
5 |
|
|
2、啓動流程
2.1子系統、處理器及啓動地址
MDM9X35正常運行一共包含四個子系統：資源功耗管理子系統（RPMR）、應用子系統（APSS）、低功耗音頻子系統（LPASS）和調制解調器（基帶）處理子系統（MPSS）；不同的系統運行在不同的處理器上，Hexagon爲高通驍龍的高級DSP，他們的處理器及啓動地址如表2-1所示。
|
子系統 |
處理器 |
啓動地址 |
|
RPM |
Cortex-M3 |
0x0 |
|
APSS |
Cortex-A7 |
Configurable |
|
LPASS |
Configurable |
|
|
MPSS |
Configurable |
2.2啓動流程框圖
如圖2-2爲MDM9x35的啓動流程框圖摘自高通文檔，注意圖中帶顏色的箭頭有助於我們理解。
2.3啓動流程詳情
通過圖2-2能明朗的看出啓動流程：
1、系統Power On MDM9x35芯片復位，第一個執行的CPU爲Cortex-M3，其運行的是RPM鏡像的PBL軟件。這個PPM的PBL程序和後面的APPS PBL、Modem PBL（圖2-2的灰色部分）應該是固化在ROM中的，高通不對我們開源，至少我沒有在軟件代碼中找到這三個PBL對應的代碼
2、在Cortex-M3中運行RPM PBL執行基本的電量和功率檢測，然後復位APP處理器Cortex-A7（不開源）
3、APPS處理器 Cortex-A7執行APPS PBL，他從啓動設備中加載並鑑定SBL1鏡像到L2（as TCM），然後跳轉到SBL1執行
4、SBL1開始執行，他首先初始化DDR，然後從啓動設備中加載並鑑定TZBSP鏡像到DDR, TZBSP執行完冷啓動的初始化（cold_boot_init）執行權交回SBL1
5、SBL1從啓動設備中加載並鑑定SDI鏡像到DDR,，SDI建立安全環境執行權交回SBL1
6、SBL1從啓動設備中加載並鑑定RPM固件到PPMcode RAM
7、RPM（Cortex-M3）開始執行RPM固件，此處RPM的執行可能由APPS的SBL1通知執行
8、SBL1從啓動設備中加載並鑑定HLOS APPSBL（此處就是我們熟悉lk，它是用來啓動linux的bootload）到DDR
9、、SBL1通過系統調用（TZ trap syscall）通知TZ boot loader啓動完成，然後TZ跳轉到APPSBL執行
10、APPSBL(lk)初始化系統，然後加載HLOS kernel（linux）
11、HLOS kernel起來之後根據需要通過PIL加載MBA和modem鏡像到DDR
12、HLOS kernel復位Modem處理器，ModemPBL開始運行
13、Modem PBL從DDR中將MBA拷貝到modem TCM中,然後在modemTCM中鑑定MBA
14、MBA鑑定DDR中的AMSS鏡像,然後運行amss系統
15、HLOS kernel根據需要通過PIL加載LPASS鏡像到DDR，TZ鑑定它，然後HLOS復位LPASS
Note：
A、執行SBL1鏡像文件，代碼位於“MDM9x35-LE3.0/boot_images/core/boot/secboot3/hw/mdm9x35/sbl1/sbl1.s”,這裏是一個啓動過程非常重要的地方，分析代碼你會發現它的主要功能便是啓動TZBSP、SDI、RPM、APPSBL四個模塊
B、4.5.6.這三步是通過SBL1來啓動TZBSP,SDI,RPM三個模塊，他們的代碼分別位於“/trustzone_images,/debug_image,/rpm_proc”中
C、RPM PBL也可以調用RPM功能，RPM模塊相關的代碼位於＂/rpm_proc＂目錄中
結合圖2-2附一張串口啓動流程實時打印圖2-3：
2.4流程功能表
表2-4爲啓動流程的組成和相應的功能圖
|
組成 |
處理器 |
加載 |
執行 |
功能 |
|
RPM PBL |
M3 |
NA |
PRM ROM and CodeRAM |
復位APPS處理器 |
|
APPS PBL |
Cotex-A7 |
NA |
APPS ROM and L2 as TCM(stack) |
啓動設備，接口檢測，緊急下載模式支持，加載並鑑定SBL1 |
|
SBL1 |
Cotex-A7 |
NAND |
L2 as TCM |
配置DDR，加載鑑定TZ,RPM_FW,加載鑑定SDI，APPSBL,提供memory dump支持 |
|
TZ |
Cotex-A7 |
NAND |
LPDDR2 |
更具安全需求和啓動模式配置XPU,NAND MPU |
|
RPM_FW |
M3 |
NAND |
RPM CodeRAM |
資源功耗管理 |
|
SDI |
Cotex-A7 |
NAND |
OCIMEM |
配置DDR,dump cache，flush cache和其他軟件支持debug配置 |
|
APPSBL |
Cotex-A7 |
NAND |
LPDDR2 |
開機第一幅圖，加載鑑定kernel，提供bl特別功能 |
|
HLOS |
Cotex-A7 |
NAND |
LPDDR2 |
啓動高級操作系統，復位外圍設備並加載相應的鏡像 |
|
Modem PBL |
Q6 |
NA |
Modem ROM and Q6 TCM (stack) |
初始化Q6 TCM，從LPDDR2拷貝MBA到TCM，鑑定MBA |
|
MBA |
Q6 |
NAND |
Q6 TCM(loaded from LPDDR2) |
鑑定modem鏡像， xPU protects the DDR regions for modem, memory dump |
3、軟件代碼結構
3.1代碼結構圖
如圖3-1爲代碼結構圖：
3.2文件目錄說明
圖3-1中除了（askey_proc、binaries）差不多每個目錄都會編譯成一個鏡像文件，所以每個目錄基本都是獨立的一套程序，互相之間沒有函數調用。
下面逐個對上面的文檔進行簡要介紹．（PS : 這些軟件代碼基本不需要進行深入分析，因爲這些代碼基本都是成熟的功能塊，不需要修改，有時間有興趣可以深入研究下）
adsp_proc : 這個目錄保存的是adsp處理器的軟件，adsp是與audio相關的dsp,audio的音頻數據就是通過這個處理器處理的． 裏面基本是高通定製的efs無源代碼。
apps_proc:這個目錄主要是APPS部分代碼，包括lk，kernel和應用層代碼等，應用層的修改主要在這個地方。
askey_proc：這個目錄主要存放編譯生成的版本、鏡像、配置及編譯信息等相關，客戶自己定製不做詳細介紹。
Binaries：這個目錄主要存編譯生成的鏡像、bin文件相關與askey_proc差不多，自己定製不做詳細介紹。
boot_image : 顧名思義，這裏存放的是與啓動相關的代碼，前文中提到的SBL1的代碼就位於這個目錄下，具體位置爲：/boot_images/core/boot/secboot3/hw/mdm9x35/sbl1/sbl1.s,分析啓動過程時，這是一個很重要的文件，很多功能是通過它來開啓的，比如trustzone,rpm,sdi，最後也是通過它來加載lk,由lk加載linux．需要注意的是，這個代碼已經不屬於modem端代碼了，它是運行在ap處理器上的．所以說9x35平臺是先啓動ap端後由ap端啓動modem端。
cnss_proc : CNSS是高通的wifi模塊，這個目錄裏主要存放了與wifi相關的固件．
common : 這個目錄裏面存放了主要的編譯工具和一些trace32調試工具的腳本文件．
debug_image : 這個文件夾下的文件最終會編譯成一個簡稱爲SDI的鏡像文件，該鏡像文件的主要功能是在系統崩潰後會通過安全看門狗主動把當時的程序執行環境dump到存儲器中，這樣有利於解決死機問題，這項功能可以不打開．詳細介紹可參考高通文檔 : 80-NH740-27_A_MDM9x30_MDM9x35_LE_Software_System_Debug_Manual.pdf
modem _proc : 這個目錄下的文件都是與通信相關的代碼，即真正的modem端代碼．與8x25平臺的modem端代碼概念已經不一樣了，9x35平臺的modem端是包括了很多功能，比如audio,但是9x35平臺的modem端只與通信模塊相關，有關射頻的代碼我也沒有分析過．
rpm_proc : RPM是一個單獨的處理器,其目標是降低MDM的平均功耗.其有三種工作模式 :power-efficient flexible extensible．其主要功能是動態的進行電源管理．具體的管理電源的幾種方式可參考高通文檔或直接分析源碼．解決電源管理方面的問題或許要看這裏的代碼．
trustzone_images : TZ是一個基於硬件的安全環境, 是Krait處理器(ARM7系列)的安全模式,類似於Supervisor模式. TZ軟件層由兩個主要部分組成 : TZBSP 和 TZOS/QSEE
TZOS/QSEE提供兩個主要功能:
1. 系統軟件和硬件在從下電狀態到啓動和喚醒期間初始化系統安全環境.
2. 在系統運行期間爲存儲空間和其它子系統提供保護和服務.(這裏可能翻譯不太準確,英文原文見高通文檔)
TZ是在SBL啓動階段被加載,用戶可以自定義和編譯TZ鏡像文件,包括TZBSP和TZ/QSEE(tz.mbn\tzbsp_no_xpu)
3.3編譯方法
整個工程是由OpenEmbedded（oe bitbake）自動構建系統進行自動化編譯的，這部分原理本人未研究過，僅限於會編譯，具體編譯原理及方法可參見高通文檔：80-N5576-44_E_9x15_9x25_9x35_LE_SW_Build_Process
4、總結
本文僅限於框架流程式的概要介紹MDM9x35的正常啓動流程，其過程相對比較複雜，PBL、SBL、LK、Kernel、Modem等任一流程展開都可以大篇幅介紹，以後有機會學習再詳述。希望讀者通過閱讀本文檔能對MDM9x35平臺的啓動過程有個大致的瞭解。