转自：http://www.wowotech.net/u-boot/boot_flow_1.html
1. 前言
本文将结合u-boot的“board—>machine—>arch—>cpu”框架，介绍u-boot中平台相关部分的启动流程。并通过对启动流程的简单分析，掌握u-boot移植的基本方法。
注1：本文所使用的u-boot版本，是2016/4/23从u-boot官网（git://git.denx.de/u-boot.git）导入的一个快照，具体可参考“https://github.com/wowotechX/u-boot”。
注2：为了方便，本文将“平台相关部分的启动流程”，定义为从u-boot启动开始，到board有关的C代码被执行为止。后续的部分，会在下一篇文章中分析。
2. 多平台架构
嵌入式软件工程师，在设计某一个软件的时候，或多或少的都会思考“跨平台”的问题（驱动和系统工程师尤甚）：
这个“软件”是否可以运行于不同的软硬件环境中？
这个“软件”和其它“软件”是否有共同的地方可以抽象出来？
这些问题的本质，是软件工程中的抽象和封装，以最简洁、最高效的方式，实现尽可能多的功能。u-boot作为一个跨平台、跨设备的bootloader，同样会面临这些问题。它的解决方案，就是“board—>machine—>arch—>cpu”框架，如下：
图片1 u-boot多平台架构
几个路径：
- board/xxx/xxx-board
- arch/arm/mach-xxx
- arch/arm
- arch/arm/cpu/armv8/
该结构其实就是device tree普及之前，linux kernel所采用的结构，它基本上和硬件的拓扑结构保持一致：
一个嵌入式产品，无论是一款手机，还是一块开发板，首先呈现给用户的就是一个可满足产品功能的“硬件实体”，该“实体”包括一些必要的外部设备，如显示屏、按键、麦克风、扬声器等等，它就是图片1中最大的那个方块----board；
除了用户能感知到的外部设备，board上还有一个最重要设备----CPU，是产品的运算和控制中心。不过，众所周知，当今的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启动后，会先执行CPU（如armv8）的初始化代码。
2）CPU相关的代码，会调用ARCH的公共代码（如arch/arm）。
3）ARCH的公共代码，在适当的时候，调用board有关的接口。u-boot的功能逻辑，大多是由common代码实现，部分和平台有关的部分，则由公共代码声明，由board代码实现。
4）board代码在需要的时候，会调用machine（arch/arm/mach-xxx）提供的接口，实现特定的功能。因此machine的定位是提供一些基础的代码支持，不会直接参与到u-boot的功能逻辑中。
具体请参考后面的分析。
3. 平台相关部分的启动流程分析
本文先不涉及u-boot和平台相关的Kconfig/Makefile部分，以ARM64为例，假定u-boot首先从“arch/arm/cpu/armv8/start.S”的_start接口开始执行。因此我们从_start开始分析。
注3：后续u-boot的移植指南中，会介绍该假定的依据。
注4：启动流程分析的过程中，我们会重点解释、归纳出代码中以CONFIG_为前缀的配置项，后续u-boot的移植工作，大部分就是这些配置项的确定过程。
3.1 _start
_start是u-boot启动后的第一个执行地址，对armv8来说，它只是简单的跳转到reset处执行，如下：
/* 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函数，由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）根据当前的EL级别，配置中断向量、MMU、Endian、i/d Cache等。
3）配置ARM的勘误表
具体可参考apply_core_errata函数，由CONFIG_ARM_ERRATA_XXX控制，在项目的初期，可以不打开，后续根据实际情况打开）。
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
一般情况下，不需要实现。start.S中也有一个WEAK类型的定义，由CONFIG_GICV2 | CONFIG_GICV3控制，一般情况下，没有打开的必要。
5）如果是多CPU的场景，处理其它的CPU的boot
多CPU功能由CONFIG_ARMV8_MULTIENTRY控制，不需要打开。
6）跳转到arm公共的_main中执行
ARM64平台的_main位于arch/arm/lib/crt0_64.S文件中，具体请参考下面的描述。
3.3 _main
crt0是C-runtime Startup Code的简称，意思就是运行C代码之前的准备工作。关于_main函数，arch/arm/lib/crt0_64.S中有非常详细的注释（这一点要给u-boot点100个赞！），大家可以参考。该函数的定义如下：
/* 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代码的运行环境，为调用board_init_f接口做准备。包括：
a）设置堆栈（C代码的函数调用，堆栈是必须的）。如果当前的编译是SPL（由CONFIG_SPL_BUILD定义），可单独定义堆栈基址（CONFIG_SPL_STACK），否则，通过CONFIG_SYS_INIT_SP_ADDR定义堆栈基址。
b）调用board_init_f_alloc_reserve接口，从堆栈开始的地方，为u-boot中大名鼎鼎的GD ('global data') 数据结构，分配空间。
c）调用board_init_f_init_reserve接口，对GD进行初始化。
2）调用board_init_f函数，完成一些前期的初始化工作，例如：
a）点亮一个Debug用的LED灯，表示u-boot已经活了。
b）初始化DRAM、DDR等system范围的RAM等。
c）计算后续代码需要使用的一些参数，包括relocation destination、the future stack、the future GD location等。
注5：关于u-boot的relocation操作，后续会有专门的文章介绍。
3）如果当前是SPL（由CONFIG_SPL_BUILD控制），则_main函数结束，直接返回。如果是正常的u-boot，则继续执行后续的动作。
4）根据board_init_f指定的参数，执行u-boot的relocation操作。
5）清除BBS段。
6）调用board_init_r函数，执行后续的初始化操作（已经不再本文的讨论范围了，具体请参考后续的分析文章）。
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进行后续的操作。
因此，如果使用SPL功能，需要尽可能的减少SPL的代码量，以减小它的size。
4.2 配置项总结
经过第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功能来说，必须提供。
问题:
1. uboot的这些CONFIG宏在哪里打开，是否可以使用make menuconfig来控制？
在./configs/下有很多板载或者芯片的default config示例。另外是可以使用make menuconfig打开界面的，可以先cp configs/***_deconfig .config, 然后make menuconfig即可