1. 前言
本文將結合u-boot的“board—>machine—>arch—>cpu”框架咨跌，介紹u-boot中平臺相關部分的啟動流程昙篙。并通過對啟動流程的簡單分析惯殊，掌握u-boot移植的基本方法骤肛。
注1：本文所使用的u-boot版本，是2016/4/23從u-boot官網(wǎng)（git://git.denx.de/u-boot.git）導入的一個快照窍蓝，具體可參考“https://github.com/wowotechX/u-boot”腋颠。
注2：為了方便，本文將“平臺相關部分的啟動流程”吓笙，定義為從u-boot啟動開始淑玫，到board有關的C代碼被執(zhí)行為止。后續(xù)的部分观蓄，會在下一篇文章中分析混移。
2. 多平臺架構
嵌入式軟件工程師，在設計某一個軟件的時候侮穿，或多或少的都會思考“跨平臺”的問題（驅動和系統(tǒng)工程師尤甚）：
這個“軟件”是否可以運行于不同的軟硬件環(huán)境中歌径？
這個“軟件”和其它“軟件”是否有共同的地方可以抽象出來？
這些問題的本質亲茅，是軟件工程中的抽象和封裝回铛，以最簡潔、最高效的方式克锣，實現(xiàn)盡可能多的功能茵肃。u-boot作為一個跨平臺、跨設備的bootloader袭祟，同樣會面臨這些問題验残。它的解決方案，就是“board—>machine—>arch—>cpu”框架巾乳，如下：
該結構其實就是device tree普及之前您没，linux kernel所采用的結構，它基本上和硬件的拓撲結構保持一致：
一個嵌入式產(chǎn)品胆绊，無論是一款手機氨鹏，還是一塊開發(fā)板，首先呈現(xiàn)給用戶的就是一個可滿足產(chǎn)品功能的“硬件實體”压状，該“實體”包括一些必要的外部設備仆抵，如顯示屏、按鍵种冬、麥克風镣丑、揚聲器等等，它就是圖片1中最大的那個方塊----board娱两；
除了用戶能感知到的外部設備传轰，board上還有一個最重要設備----CPU，是產(chǎn)品的運算和控制中心谷婆。不過慨蛙，眾所周知，當今的CPU非常不單純纪挎，它在一個芯片上期贫，盡可能多的集成了和外部設備有關的功能，例如各種各樣的設備控制器异袄。這就是傳說中的SOC通砍，對應圖片1中的“machine”；
SOC里面烤蜕，涉及到ARCH和CPU的概念封孙，需要注意的是，u-boot的抽象讽营，和ARM等標準抽象（可參考“ARM概念梳理：Architecture, Core, CPU虎忌，SOC”中的描述）不一致。如圖片1所示橱鹏，u-boot把arm（包括arm32和arm64）歸為一個ARCH大類膜蠢，而把armv8等抽象為CPU。有點奇葩莉兰，大家記著就是了挑围。
基于圖片1的架構，u-boot和平臺有關的初始化流程糖荒，顯得比較直觀杉辙、清晰：
1）u-boot啟動后，會先執(zhí)行CPU（如armv8）的初始化代碼捶朵。
2）CPU相關的代碼蜘矢，會調用ARCH的公共代碼（如arch/arm）。
3）ARCH的公共代碼泉孩，在適當?shù)臅r候硼端，調用board有關的接口。u-boot的功能邏輯寓搬，大多是由common代碼實現(xiàn)珍昨，部分和平臺有關的部分，則由公共代碼聲明句喷，由board代碼實現(xiàn)镣典。
4）board代碼在需要的時候，會調用machine（arch/arm/mach-xxx）提供的接口唾琼，實現(xiàn)特定的功能兄春。因此machine的定位是提供一些基礎的代碼支持，不會直接參與到u-boot的功能邏輯中锡溯。
具體請參考后面的分析赶舆。
3. 平臺相關部分的啟動流程分析
本文先不涉及u-boot和平臺相關的Kconfig/Makefile部分哑姚，以ARM64為例，假定u-boot首先從“arch/arm/cpu/armv8/start.S”的_start接口開始執(zhí)行芜茵。因此我們從_start開始分析叙量。
注3：后續(xù)u-boot的移植指南中，會介紹該假定的依據(jù)九串。
注4：啟動流程分析的過程中绞佩，我們會重點解釋、歸納出代碼中以CONFIG_為前綴的配置項猪钮，后續(xù)u-boot的移植工作品山，大部分就是這些配置項的確定過程。
3.1 _start
_start是u-boot啟動后的第一個執(zhí)行地址烤低，對armv8來說肘交，它只是簡單的跳轉到reset處執(zhí)行，如下：
/*https://github.com/wowotechX/u-boot/blob/x_integration/arch/arm/cpu/armv8/start.S*/
.globl _start
_start:
b reset
3.2 reset
reset的代碼如下：
/*https://github.com/wowotechX/u-boot/blob/x_integration/arch/arm/cpu/armv8/start.S*/
reset:
#ifdef CONFIG_SYS_RESET_SCTRL
bl reset_sctrl
#endif
/*
* Could be EL3/EL2/EL1, Initial State:
* Little Endian, MMU Disabled, i/dCache Disabled
*/
adr x0, vectors
switch_el x1, 3f, 2f, 1f
3: msr vbar_el3, x0
mrs x0, scr_el3
orr x0, x0, #0xf /* SCR_EL3.NS|IRQ|FIQ|EA */
msr scr_el3, x0
msr cptr_el3, xzr /* Enable FP/SIMD */
#ifdef COUNTER_FREQUENCY
ldr x0, =COUNTER_FREQUENCY
msr cntfrq_el0, x0 /* Initialize CNTFRQ */
#endif
b 0f
2: msr vbar_el2, x0
mov x0, #0x33ff
msr cptr_el2, x0 /* Enable FP/SIMD */
b 0f
1: msr vbar_el1, x0
mov x0, #3 << 20
msr cpacr_el1, x0 /* Enable FP/SIMD */
0:
/* Apply ARM core specific erratas */
bl apply_core_errata
/*
* Cache/BPB/TLB Invalidate
* i-cache is invalidated before enabled in icache_enable()
* tlb is invalidated before mmu is enabled in dcache_enable()
* d-cache is invalidated before enabled in dcache_enable()
*/
/* Processor specific initialization */
bl lowlevel_init
#ifdef CONFIG_ARMV8_MULTIENTRY
branch_if_master x0, x1, master_cpu
/*
* Slave CPUs
*/
slave_cpu:
wfe
ldr x1, =CPU_RELEASE_ADDR
ldr x0, [x1]
cbz x0, slave_cpu
br x0 /* branch to the given address */
master_cpu:
/* On the master CPU */
#endif /* CONFIG_ARMV8_MULTIENTRY */
bl _main
主要做如下事情：
1）reset SCTRL寄存器
具體可參考reset_sctrl函數(shù)拂玻，由CONFIG_SYS_RESET_SCTRL控制酸些，一般不需要打開。該配置項的解釋如下：
Reset the SCTRL register at the very beginning of execution to avoid interference from stale mappings set up by early firmware/loaders/etc.
http://lists.denx.de/pipermail/u-boot/2015-April/211147.html
2）根據(jù)當前的EL級別檐蚜，配置中斷向量魄懂、MMU、Endian闯第、i/d Cache等市栗。
3）配置ARM的勘誤表
具體可參考apply_core_errata函數(shù)，由CONFIG_ARM_ERRATA_XXX控制咳短，在項目的初期填帽，可以不打開，后續(xù)根據(jù)實際情況打開）咙好。
4）調用lowlevel_init
的功能解釋如下（具體可參考u-boot的readme文檔）：
- purpose: essential init to permit execution to reach board_init_f()
- no global_data or BSS
- there is no stack (ARMv7 may have one but it will soon be removed)
- must not set up SDRAM or use console
- must only do the bare minimum to allow execution to continue to
board_init_f()
- this is almost never needed
- return normally from this function
一般情況下篡腌，不需要實現(xiàn)。start.S中也有一個WEAK類型的定義勾效，由CONFIG_GICV2 | CONFIG_GICV3控制嘹悼，一般情況下，沒有打開的必要层宫。
5）如果是多CPU的場景杨伙，處理其它的CPU的boot
多CPU功能由CONFIG_ARMV8_MULTIENTRY控制，不需要打開萌腿。
6）跳轉到arm公共的_main中執(zhí)行
ARM64平臺的_main位于crt0_64.S文件中限匣，具體請參考下面的描述。
3.3 _main
crt0是C-runtime Startup Code的簡稱毁菱，意思就是運行C代碼之前的準備工作米死。關于_main函數(shù)锌历，crt0_64.S中有非常詳細的注釋（這一點要給u-boot點100個贊！）峦筒，大家可以參考辩涝。該函數(shù)的定義如下：
/*https://github.com/wowotechX/u-boot/blob/x_integration/arch/arm/lib/crt0_64.S*/
ENTRY(_main)
/*
* Set up initial C runtime environment and call board_init_f(0).
*/
#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_STACK)
ldr x0, =(CONFIG_SPL_STACK)
#else
ldr x0, =(CONFIG_SYS_INIT_SP_ADDR)
#endif
bic sp, x0, #0xf/* 16-byte alignment for ABI compliance */
mov x0, sp
bl board_init_f_alloc_reserve
mov sp, x0
/* set up gd here, outside any C code */
mov x18, x0
bl board_init_f_init_reserve
mov x0, #0
bl board_init_f
#if !defined(CONFIG_SPL_BUILD)
/*
* Set up intermediate environment (new sp and gd) and call
* relocate_code(addr_moni). Trick here is that we'll return
* 'here' but relocated.
*/
ldr x0, [x18, #GD_START_ADDR_SP]/* x0 <- gd-="">start_addr_sp */
bic sp, x0, #0xf/* 16-byte alignment for ABI compliance */
ldr x18, [x18, #GD_BD] /* x18 <- gd-="">bd */
sub x18, x18, #GD_SIZE /* new GD is below bd */
adr lr, relocation_return
ldr x9, [x18, #GD_RELOC_OFF] /* x9 <- gd-="">reloc_off */
add lr, lr, x9/* new return address after relocation */
ldr x0, [x18, #GD_RELOCADDR] /* x0 <- gd-="">relocaddr */
b relocate_code
relocation_return:
/*
* Set up final (full) environment
*/
bl c_runtime_cpu_setup /* still call old routine */
/* TODO: For SPL, call spl_relocate_stack_gd() to alloc stack relocation */
/*
* Clear BSS section
*/
ldr x0, =__bss_start /* this is auto-relocated! */
ldr x1, =__bss_end /* this is auto-relocated! */
mov x2, #0
clear_loop:
str x2, [x0]
add x0, x0, #8
cmp x0, x1
b.lo clear_loop
/* call board_init_r(gd_t *id, ulong dest_addr) */
mov x0, x18 /* gd_t */
ldr x1, [x18, #GD_RELOCADDR] /* dest_addr */
b board_init_r /* PC relative jump */
/* NOTREACHED - board_init_r() does not return */
#endif /* !CONFIG_SPL_BUILD */
ENDPROC(_main)
功能可總結為（大部分翻譯自crt0_64.S中的注釋）：
1）設置C代碼的運行環(huán)境，為調用board_init_f接口做準備勘天。包括：
a）設置堆棧（C代碼的函數(shù)調用，堆棧是必須的）捉邢。如果當前的編譯是SPL（由CONFIG_SPL_BUILD定義）脯丝，可單獨定義堆棧基址（CONFIG_SPL_STACK）伏伐，否則宠进，通過CONFIG_SYS_INIT_SP_ADDR定義堆棧基址藐翎。
b）調用board_init_f_alloc_reserve接口材蹬，從堆棧開始的地方，為u-boot中大名鼎鼎的GD ('global data') 數(shù)據(jù)結構吝镣，分配空間堤器。
c）調用board_init_f_init_reserve接口，對GD進行初始化末贾。
2）調用board_init_f函數(shù)闸溃，完成一些前期的初始化工作，例如：
a）點亮一個Debug用的LED燈拱撵，表示u-boot已經(jīng)活了辉川。
b）初始化DRAM、DDR等system范圍的RAM等拴测。
c）計算后續(xù)代碼需要使用的一些參數(shù)乓旗，包括relocation destination、the future stack集索、the future GD location等屿愚。
注5：關于u-boot的relocation操作，后續(xù)會有專門的文章介紹抄谐。
3）如果當前是SPL（由CONFIG_SPL_BUILD控制）渺鹦，則_main函數(shù)結束，直接返回蛹含。如果是正常的u-boot毅厚，則繼續(xù)執(zhí)行后續(xù)的動作。
4）根據(jù)board_init_f指定的參數(shù)浦箱，執(zhí)行u-boot的relocation操作吸耿。
5）清除BBS段祠锣。
6）調用board_init_r函數(shù)，執(zhí)行后續(xù)的初始化操作（已經(jīng)不再本文的討論范圍了咽安，具體請參考后續(xù)的分析文章）伴网。
4. 總結
4.1 SPL功能
SPL是Secondary Program Loader的簡稱，之所以稱作secondary妆棒，是相對于ROM code來說的澡腾。SPL是u-boot中獨立的一個代碼分支，由CONFIG_SPL_BUILD配置項控制糕珊，是為了在正常的u-boot image之外动分，提供一個獨立的、小size的SPL image红选，通常用于那些SRAM比較欣焦（或者其它限制）、無法直接裝載并運行整個u-boot的平臺喇肋。
如果使用了SPL功能坟乾，u-boot的啟動流程通常是：
ROM code加載SPL并運行；
SPL進行必要的初始化之后蝶防，加載u-boot并運行甚侣；
u-boot進行后續(xù)的操作。
因此慧脱，如果使用SPL功能渺绒，需要盡可能的減少SPL的代碼量，以減小它的size菱鸥。
4.2 配置項總結
經(jīng)過第3章的流程分析宗兼，我們可以總結出和“平臺相關部分的啟動流程”有關的配置項，記錄如下：
CONFIG_SYS_RESET_SCTRL氮采，控制是否在啟動的時候reset SCTRL寄存器殷绍，一般不需要打開；
CONFIG_ARM_ERRATA_XXX鹊漠，控制ARM core的勘誤信息主到，一般不需要打開；
CONFIG_GICV2躯概、CONFIG_GICV3登钥，控制GIC的版本，用到的時候再說明娶靡；
CONFIG_ARMV8_MULTIENTRY牧牢，控制是否在u-boot中使用多CPU，一般不需要；
CONFIG_SPL_BUILD塔鳍，是否是能SPL的編譯伯铣，需要的話可以打開；
CONFIG_SPL_STACK轮纫，如果配置了CONFIG_SPL_BUILD腔寡，是否為SPL image配置單獨的stack（SP基址），如果需要掌唾，通過該配置項配置放前，如果不需要，則使用CONFIG_SYS_INIT_SP_ADDR糯彬；
CONFIG_SYS_INIT_SP_ADDR犀斋，配置u-boot的stack（SP基址），對于u-boot功能來說情连，必須提供。
