U-Boot

　　U-Boot，全稱 Universal Boot Loader，是遵循GPL條款的開放源碼項目。U-Boot的作用是系統引導。U-Boot從FADSROM、8xxROM、PPCBOOT逐步發展演化而來。其源碼目錄、編譯形式與Linux內核很相似，事實上，不少U-Boot源碼就是根據相應的Linux內核源程序進行簡化而形成的，尤其是一些設備的驅動程序，這從U-Boot源碼的注釋中能體現這一點。

　　U-Boot不僅僅支持嵌入式Linux系統的引導，它還支持NetBSD， VxWorks， QNX， RTEMS， ARTOS， LynxOS， android嵌入式操作系統。其目前要支持的目標操作系統是OpenBSD， NetBSD， FreeBSD，4.4BSD， Linux， SVR4， Esix， Solaris， Irix， SCO， Dell， NCR， VxWorks， LynxOS， pSOS， QNX， RTEMS， ARTOS， android。這是U-Boot中Universal的一層含義，另外一層含義則是U-Boot除了支持PowerPC系列的處理器外，還能支持MIPS、 x86、ARM、NIOS、XScale等諸多常用系列的處理器。

　　這兩個特點正是U-Boot項目的開發目標，即支持盡可能多的嵌入式處理器和嵌入式操作系統。就目前來看，U-Boot對PowerPC系列處理器支持最為豐富，對Linux的支持最完善。其它系列的處理器和操作系統基本是在2002年11 月PPCBOOT改名為U-Boot后逐步擴充的。從PPCBOOT向U-Boot的順利過渡，很大程度上歸功于U-Boot的維護人德國DENX軟件工程中心Wolfgang Denk［以下簡稱W.D］本人精湛專業水平和執著不懈的努力。當前，U-Boot項目正在他的領軍之下，眾多有志于開放源碼BOOT LOADER移植工作的嵌入式開發人員正如火如荼地將各個不同系列嵌入式處理器的移植工作不斷展開和深入，以支持更多的嵌入式操作系統的裝載與引導。

　　uboot啟動流程分析

　　可知程序的入口在_start，在SourceInsight中查找可發現程序的入口_start在u-boot-2016.05\arch\arm\lib\vectors.S中。

　　。。。

　　ENTRY（_start）

　　SECTIONS

　　{

　　。。。

　　。 = 0x00000000;

　　。 = ALIGN（4）;

　　.text ：

　　{

　　*（.__image_copy_start）

　　*（.vectors）

　　CPUDIR/start.o （.text*）

　　*（.text*）

　　}

　　。。。

　　。 = ALIGN（4）;

　　.rodata ： { *（SORT_BY_ALIGNMENT（SORT_BY_NAME（.rodata*））） }

　　。 = ALIGN（4）;

　　.data ： {

　　*（.data*）

　　}

　　。 = ALIGN（4）;

　　。 = 。;

　　。。。

　　.bss_start __rel_dyn_start （OVERLAY） ： {

　　KEEP（*（.__bss_start））;

　　__bss_base = 。;

　　}

　　.bss __bss_base （OVERLAY） ： {

　　*（.bss*）

　　。 = ALIGN（4）;

　　__bss_limit = 。;

　　}

　　.bss_end __bss_limit （OVERLAY） ： {

　　KEEP（*（.__bss_end））;

　　}

　　。。。

　　}

　　12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152

　　進入boot-2016.05\arch\arm\lib\vectors.S中，可以看到從_start開始后就跳轉到reset去執行：

　　。。。

　　.globl _start

　　。。。

　　_start：

　　#ifdef CONFIG_SYS_DV_NOR_BOOT_CFG

　　.word CONFIG_SYS_DV_NOR_BOOT_CFG

　　#endif

　　b reset

　　ldr pc， _undefined_instruction

　　ldr pc， _software_interrupt

　　ldr pc， _prefetch_abort

　　ldr pc， _data_abort

　　ldr pc， _not_used

　　ldr pc， _irq

　　ldr pc， _fiq

　　。。.12345678910111213141516171819202122

　　1、從u-boot-2016.05\arch\arm\cpu\arm920t\start.S中reset執行

　　主要執行流程：reset -》 cpu_init_crit -》 lowlevel_init -》 _main

　　reset：

　　。。。

　　#ifndef CONFIG_SKIP_LOWLEVEL_INIT

　　bl cpu_init_crit

　　#endif

　　bl _main

　　。。。

　　#ifndef CONFIG_SKIP_LOWLEVEL_INIT

　　cpu_init_crit：

　　。。。

　　bl lowlevel_init

　　。。。

　　#endif /* CONFIG_SKIP_LOWLEVEL_INIT */

　　1234567891011121314151617181920212223

　　2、由bl _main跳轉到u-boot-2016.05\arch\arm\lib\crt0.S中從入口_main開始執行

　　主要執行流程：board_init_f -》 relocate_code -》 board_init_r

　　ENTRY（_main）

　　。。。

　　bl board_init_f_alloc_reserve

　　。。。

　　bl board_init_f_init_reserve

　　。。。

　　bl board_init_f

　　#if ！ defined（CONFIG_SPL_BUILD）

　　。。。

　　b relocate_code

　　。。。

　　#endif

　　#if ！defined（CONFIG_SPL_BUILD） || defined（CONFIG_SPL_FRAMEWORK）

　　。。。

　　#if defined（CONFIG_SYS_THUMB_BUILD）

　　。。。

　　#else

　　ldr pc， =board_init_r

　　#endif

　　#endif

　　ENDPROC（_main）123456789101112131415161718192021222324252627282930313233

　　這部分有三點說明：

　?、拧-boot-2016.05\common\board_f.c：board_init_f通過initcall_run_list（init_sequence_f）函數執行一系列初始化函數以實現前半部分板級初始化。全局結構體gd在u-boot-2016.05\arch\arm\include\asm\global_data.h中聲明：

　　#define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm （“r9”）1

　?、?、u-boot-2016.05\arch\arm\lib\relocate.S：relocate_code實現uboot代碼的重定位，此部分如果覺得源代碼不是簡單明了可自己改寫。

　?、?、去重定位uboot有兩種路徑：

　　一種是將gd-》flags設為0，在初始化函數序列init_sequence_f中的jump_to_copy函數中去跳轉到relocate_code：

　　static int jump_to_copy（void）

　　{

　　if （gd-》flags & GD_FLG_SKIP_RELOC）

　　return 0;

　　。。。

　　#if defined（CONFIG_X86） || defined（CONFIG_ARC）

　　。。。

　　#else

　　relocate_code（gd-》start_addr_sp， gd-》new_gd， gd-》relocaddr）;

　　#endif

　　return 0;

　　}1234567891011121314

　　另一種就是不宏定義CONFIG_SPL_BUILD，然后在u-boot-2016.05\arch\arm\lib\crt0.S中通過

　　#if ！ defined（CONFIG_SPL_BUILD）

　　。。。

　　b relocate_code

　　。。。

　　#endif123456789

　　來跳轉到relocate_code。以上兩種方法選其一，另一種就得去掉。

　　3、在上一步通過ldr pc， =board_init_r指令進入u-boot-2016.05\common\board_r.c：board_init_r函數，進而調用initcall_run_list（init_sequence_r）函數執行一系列初始化函數以實現后半部分板級初始化，并在initcall_run_list函數里進入run_main_loop不再返回。

　　void board_init_r（gd_t *new_gd， ulong dest_addr）

　　{

　　。。。

　　if （initcall_run_list（init_sequence_r））

　　hang（）;

　　/* NOTREACHED - run_main_loop（） does not return */

　　hang（）;

　　}

　　1234567891011

　　init_sequence_r是一個函數指針數組，里面存放了很多初始化函數指針，里面有兩個重要的函數指針initr_announce和run_main_loop：

　　init_fnc_t init_sequence_r［］ = {

　　。。。

　　initr_announce，

　　。。。

　　run_main_loop，

　　};12345678910

　　initr_announce函數聲明從此處開始程序就將跳轉到RAM中運行：

　　static int initr_announce（void）

　　{

　　debug（“Now running in RAM - U-Boot at： %08lx\n”， gd-》relocaddr）;

　　return 0;

　　}12345

　　最后一項是run_main_loop ，進入run_main_loop 后便不再返回。

　　4、在run_main_loop 里會進入u-boot-2016.05\common\main.c：main_loop函數

　　static int run_main_loop（void）

　　{

　　。。。

　　for （;;）

　　main_loop（）;

　　return 0;

　　}12345678

　　進入main_loop之前就已經完成初始化，接下來準備去處理命令

　　/* We come here after U-Boot is initialised and ready to process commands */

　　void main_loop（void）

　　{

　　const char *s;

　　bootstage_mark_name（BOOTSTAGE_ID_MAIN_LOOP， “main_loop”）;

　　。。。

　　/* get environment_variable： s = getenv（“bootcmd”）; -》 bootcmd */

　　s = bootdelay_process（）;

　　。。。

　　autoboot_command（s）;

　　。。。

　　}123456789101112131415161718

　　main_loop函數里有兩個重要的過程：

　?、?、首先在bootdelay_process函數里通過s = getenv（“bootcmd”）得到bootcmd參數并返回bootcmd參數，

　　const char *bootdelay_process（void）

　　{

　　char *s;

　　int bootdelay;

　　。。。

　　s = getenv（“bootdelay”）;

　　。。。

　　debug（“### main_loop entered： bootdelay=%d\n\n”， bootdelay）;

　　。。。

　　s = getenv（“bootcmd”）;

　　。。。

　　stored_bootdelay = bootdelay;

　　return s;

　　}1234567891011121314151617181920212223

　　其中，bootcmd參數通過以下方式指定：

　　先在u-boot-2016.05\include\env_default.h中

　　#ifdef CONFIG_BOOTCOMMAND

　　“bootcmd=” CONFIG_BOOTCOMMAND “\0”

　　#endif123

　　再在u-boot-2016.05\include\configs\smdk2440.h中指定

　　#define CONFIG_BOOTCOMMAND “nand read 30000000 kernel;bootm 30000000”1

　　⑵、然后進入autoboot_command函數，并將bootcmd參數傳入，繼而進入run_command_list函數，繼續將bootcmd參數傳入

　　void autoboot_command（const char *s）

　　{

　　。。。

　　if （stored_bootdelay ！= -1 && s && ！abortboot（stored_bootdelay）） {

　　。。。

　　run_command_list（s， -1， 0）;

　　。。。

　　}

　　。。。

　　}

　　123456789101112

　　5、從autoboot_command函數進入u-boot-2016.05\common\cli.c：run_command_list函數后，接著會調用board_run_command函數去執行命令

　　int run_command_list（const char *cmd， int len， int flag）

　　{

　　int need_buff = 1;

　　char *buff = （char *）cmd; /* cast away const */

　　int rcode = 0;

　　if （len == -1） {

　　len = strlen（cmd）;

　　#ifdef CONFIG_SYS_HUSH_PARSER

　　。。。

　　#else

　　/* the built-in parser will change our string if it sees \n */

　　need_buff = strchr（cmd， ‘\n’） ！= NULL;

　　#endif

　　}

　　if （need_buff） {

　　buff = malloc（len + 1）;

　　if （！buff）

　　return 1;

　　memcpy（buff， cmd， len）;

　　buff［len］ = ‘\0’;

　　}

　　#ifdef CONFIG_SYS_HUSH_PARSER

　　。。。

　　#ifdef CONFIG_CMDLINE

　　。。。

　　#else

　　rcode = board_run_command（buff）;

　　#endif

　　#endif

　　。。。

　　}1234567891011121314151617181920212223242526272829303132

　　那么，board_run_command如何去執行命令？

　　首先，board_run_command函數通過bootcmd參數中的bootm命令找到u-boot-2016.05\cmd\bootm.c中的

　　U_BOOT_CMD（

　　bootm， CONFIG_SYS_MAXARGS， 1， do_bootm，

　　“boot application image from memory”， bootm_help_text

　?。?1234

　　然后，根據這個信息找到執行bootm命令的處理函數指針do_bootm，并進入do_bootm函數執行相關代碼，而U_BOOT_CMD在u-boot-2016.05\include\command.h中定義：

　　#define U_BOOT_CMD（_name， _maxargs， _rep， _cmd， _usage， _help） \

　　U_BOOT_CMD_COMPLETE（_name， _maxargs， _rep， _cmd， _usage， _help， NULL）12

　　#define U_BOOT_CMD_COMPLETE（_name， _maxargs， _rep， _cmd， _usage， _help， \

　　_comp） \

　　_CMD_REMOVE（sub_ ## _name， _cmd）123

　　#define _CMD_REMOVE（_name， _cmd） \

　　int __remove_ ## _name（void） \

　　{ \

　　if （0） \

　　_cmd（NULL， 0， 0， NULL）; \

　　return 0; \

　　}1234567

　　在此，board_run_command函數還會將bootm命令中的參數（內核映像所在地址）30000000賦給bootm_headers_t結構體變量images，則images首地址就是30000000，images在u-boot-2016.05\cmd\bootm.c中定義：

　　bootm_headers_t images; 1