本文轉載自:https://blog.csdn.net/radianceblau/article/details/73229005

對於嵌入式工程師瞭解晶片啟動過程是十分有必要的，在分析、除錯各種問題的時候都有可能涉及到這方面的知識。同時這部分知識也是比較複雜的，因為其中涉及到晶片內部架構，啟動各個階段軟體程式碼執行順序，啟動模式等等。下面以比較常用的Qualcomm MSM8953晶片的啟動過程為例，進行巨集觀分析（大部分翻譯了高通的手冊^-^），下一篇文章進行程式碼分析。

處理器核心

可以看到MSM8953中的處理器有5個，分別為：

1，  APPS           Cortex A53 core，執行android

2，  RPM(Resource Power Manager)      CortexM3 core，主要用於低功耗應用

3，  Modem(MSS_QDSP6)        高通自有指令集處理器，處理3G、4G通訊協議等

4，  Pronto(WCNSS) 處理wifi相關程式碼

5，  LPASS        音訊相關

對映下面晶片硬體結構圖中各個處理器的框圖來看就很清晰了。

啟動相關image介紹

1，PBL(Primary Boot Loader)   位於rom中，是晶片上電後執行的真正第一行程式碼，在正常啟動流程中會載入SBL1。如果啟動異常會虛擬出9008埠用於緊急下載（短接板子上的force_boot_from_usb引腳(MSM8953 為gpio37)到1.8v可以強制進入緊急下載模式）。

2，SBL1(Second BootLoader stage 1) 位於eMMC中，由PBL載入，初始化buses、DDR、clocks等，會虛擬出9006埠，用於不能開機時dump ram

3，QSEE/TrustZone  安全相關，如fuse

4，DEVCFG OEM配置資訊（如OEMLock）

6，  Debug Policy 除錯相關

7，  APPSBL      即為BootLoader，目前使用LK（littlekernel）

8，HLOS(High LevelOperating System) 即為Linux/Android

9，Modem PBL  即為Modem處理器的PBL

10，MBA(Modem BootAuthenticator) Modem處理器啟動鑑權

啟動流程

1，  系統上電，使MSM8953從上電覆位開始執行。

2，  在Cortex A53中執行的PBL會載入：

        a，  從啟動裝置（如eMMC）載入SBL1 segment1到L2（即為TCM）

        b，  載入SBL1 segment2到RPM處理器的RAM中。

3，  SBL1 segment1會初始化DDR，然後完成如下載入：

        a，  從啟動裝置載入QSEE image到DDR

        b，  從啟動裝置載入DEVCFG image到DDR

        c，  從啟動裝置載入Debug Policy image到DDR

        d，  從啟動裝置載入HLOS APPSBL image到DDR

        e，  從啟動裝置載入RPMfirmware image到RPM的RAM中。

4，  SBL1移交執行控制權給QSEE。QSEE建立安全執行環境，配置xPU，支援fuse。

        a，  SBL1執行在AArch32（譯者注：名詞相關知識見文末“附件介紹一”）模式，而QSEE執行在AArch64模式。為了切換到AArch64模式，SBL1會啟動重對映器，操作RMR暫存器，然後觸發warm-reset，QSEE就能夠執行在AArch64模式了。

5，  QSEE通知RPM啟動RPM 韌體的執行。

6，  QSEE移交執行控制權給HLOS APPSBL。

        a，  APPSBL只能在AArch32模式開始執行。

        b，  這時AArch32的執行模式切換是在EL3/Monitor模式（譯者注：名詞相關知識見文末“附件介紹二”）完成的。通過檢視APPSBL的ELF頭能夠得知其需要執行在32位指令集架構下。EL3/Monitor模式改變到32位模式，然後再啟動APPSBL。

7，  APPSBL載入、驗證kernel。APPSBL通過SCM呼叫改變到HLOS kernel需要的AArch64模式。這和之前LK直接跳轉到kernel執行是不同的。

8，  HLOS kernel通過PIL載入MBA到DDR

9，  HLOS kernel對Hexagon modem DSP進行解復位。

10，Modem PBL繼續它的啟動。

11，HLOS kernel 通過PIL載入AMSS modemimage到DDR

12，Modem PBL驗證MBA然後跳轉到MBA。

13，HLOS通過PIL載入WCNSS(Pronto)image到DDR

14，HLOS對WCNSS(Pronto)進行解復位以便Prontoimage開始執行。

15，HLOS通過PIL載入LPASS image到DDR

16，HLOS對LPSAA進行解復位以便LPASSimage開始執行。

下面是流程的簡化圖，其中區分了AArch32和AArch64位的QSEE/TrustZone

關於eMMC和DDR的初始化時間問題

從上面的描述中已經可以看清，為避免迷惑，在分離出來看看：

1，PBL中是含有eMMC驅動的，有訪問eMMC的能力，自身執行在MCU內部SRAM中。

2，除了PBL程式的img在MCU片內ROM外，其餘img均儲存在eMMC中。

3，PBL首先從eMMC載入SBL1到L2（內部快取並非DDR），SBL1同樣執行在片內SRAM。

4，有SBL1初始化DDR各種時序後，DDR自此可用（eMMC一直可用）

5，再由SBL1載入其餘各個img到DDR，然後按照linux的正常順序啟動^-^....

附加介紹一：AArch64、AArch32

AArch64是ARMv8架構的一種執行狀態。

為了更廣泛地向企業領域推進，需要引入 64位構架。同時也需要在 ARMv8架構中引入新的 AArch64執行狀態。AArch64不是一個單純的 32位 ARM構架擴充套件，而是 ARMv8內全新的構架，完全使用全新的 A64指令集。這些都源自於多年對現代構架設計的深入研究。更重要的是， AArch64作為一個分離出的執行狀態，意味著一些未來的處理器可能不支援舊的 AArch32執行狀態。雖然最初的 64位 ARM處理器將會完全向後相容，但我們大膽且前瞻性地將 AArch64作為在 ARMv8處理器中唯一的執行狀態。我們在這些系統中將不支援 32位執行狀態，這將使許多有益的實現得到權衡，如預設情況下，使用一個較大的 64K大小的頁面，並會使得純淨的 64位 ARM伺服器系統不受遺留程式碼的影響。立即進行這種劃分是很重要的，因為有可能在未來幾年內將出現僅支援 64位的伺服器系統。沒有必要在新的 64位架構中去實現一個完整的 32位流水線，這將會提高未來 ARM伺服器系統的能效。這樣回想起來， AArch64作為在 Fedora ARM專案中被支援的 ARM構架是一個很自然的過程： armv5tel、armv7hl、aarch64。新的架構被命名為：aarch64，這同 ARM 自己選擇的主線命名方式保持一致，同時也考慮到了 ARM架構名與 ARM商標分開的期望。

ARMv8-A 將 64位架構支援引入 ARM架構中，其中包括：

• 64 位通用暫存器、SP（堆疊指標）和 PC（程式計數器）
• 64 位資料處理和擴充套件的虛擬定址

兩種主要執行狀態：

• AArch64 - 64 位執行狀態，包括該狀態的異常模型、記憶體模型、程式設計師模型和指令集支援
• AArch32 — 32 位執行狀態，包括該狀態的異常模型、記憶體模型、程式設計師模型和指令集支援

這些執行狀態支援三個主要指令集

• A32（或 ARM）：32 位固定長度指令集，通過不同架構變體增強部分 32 位架構執行環境現在稱為 AArch32。
• T32 (Thumb) 是以 16 位固定長度指令集的形式引入的，隨後在引入 Thumb-2 技術時增強為 16 位和 32 位混合長度指令集。部分 32 位架構執行環境現在稱為 AArch32。
• A64：提供與 ARM 和 Thumb 指令集類似功能的 32 位固定長度指令集。隨 ARMv8-A 一起引入，它是一種 AArch64 指令集。 
  ARM ISA 不斷改進，以滿足前沿應用程式開發人員日益增長的要求，同時保留了必要的向後相容性，以保護軟體開發投資。在 ARMv8-A 中，對 A32 和 T32 進行了一些增補，以保持與 A64 指令集一致。

附件介紹二：Exception Level

• ARMv8定義EL0-EL3共 4個Exception Level來控制PE的行為.

 Exception Level 與Security

關於ARMv8架構的知識，推薦如下部落格：

http://blog.csdn.net/forever_2015/article/details/50285865