??在之前的博文 Linux 之八 完整嵌入式 Linux 環境介紹及搭建過程詳解 中我們說了要一步步搭建整個嵌入式 Linux 運行環境，今天繼續介紹 U-Boot 相關的內容。我所使用的硬件平臺及整個要搭建的嵌入式 Linux 環境見博文 Linux 之八 完整嵌入式 Linux 環境介紹及搭建過程詳解，沒有特殊說明都是在以上環境中進行驗證的，就不過多說明了。

??這篇博文我們僅僅關注啟動過程本身，想要吃透 U-Boot，有太多東西需要學習！最開始我想放到一篇文章中，寫著寫著內容越來越多，最終超過了 CSDN 編輯器的限制。。。最終決定把內容拆分成多篇文章。你可能需要：

U-Boot 之一 零基礎編譯 U-Boot 過程詳解 及 編譯后的使用說明

U-Boot 之二 詳解使用 eclipse + J-Link 進行編譯及在線調試

U-Boot 之三 U-Boot 源碼文件解析及移植過程詳解

U-Boot 之四 U-Boot 之四 U-Boot 之四 構建過程（Kconfig 配置 + Kbuild 編譯）詳解

SPL

??SPL 即 Secondary Program Loader 的縮寫，中文就是第二段程序加載器。這里的第二段程序其實就是指的 U-Boot，也就是，SPL 是第一段程序，優先執行，然后他再去加載 U-Boot。

??這里有一點需要注意，一般 MCU 內部還有個固化的引導程序，這個固化的 BootLoader 我在博文 STM32 之十四 System Memory、Bootloader 中有過詳細的介紹。這段程序的會初始化部分外設以與外部通信，具體可以參考官方手冊。在引入了 SPL 之后，整個啟動過程就是如下所示：

??在 U-Boot 源碼中，啟動過程沒有完全單獨出 SPL 的代碼，而是復用了大量 U-Boot 里面的代碼。在代碼中，通過宏 CONFIG_SPL_XXX 來進行區分。因此，SPL 的啟動 與 U-Boot 的啟動流程是一樣的（但是所具體實現的功能是不一樣的），下面我們來介紹一下 U-Boot 啟動過程。

啟動流程

??我們可以將 U-Boot 的啟動過程劃分為兩個階段：芯片初始化 和 板級初始化。芯片初始化階段的代碼主要是位于 ./arch/架構/cpu 目錄下，其中再根據架構的不同來區分，主要以匯編語言為主，下圖展示了 ./arch 目錄的基本介紹；

板級初始化階段的代碼主要位于 ./arch/lib、 ./arch/mach-xxx、./board 目錄下，代碼也逐漸由匯編語言過度到 C 語言了。當然這兩個階段都可能引用一些公共的代碼（例如平臺無關的頭文件）。./board 目錄基本就是按照廠商來組織（例如 ST），同一廠家的開發板放在同一個目錄下。

??U-Boot 源碼文件眾多，我們如何知道最開始的啟動文件（程序入口）是哪個呢？這就需要查看 .\arch\arm\cpu 目錄下的 u-boot.lds 文件了（對于 SPL/TPL 對應的就是 .\arch\arm\cpu\u-boot-spl.lds 文件）。.lds 是連接腳本文件，它描述了如何生成最終的二進制文件，其中就包含程序入口。例如，在 u-boot.lds 文件中我們可以看到如下代碼：

OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm") OUTPUT_ARCH(arm) ENTRY(_start) SECTIONS { #ifndef CONFIG_CMDLINE/DISCARD/ : { *(.u_boot_list_2_cmd_*) } #endif// 省略一部分. = 0x00000000;. = ALIGN(4);.text :{*(.__image_copy_start)*(.vectors)CPUDIR/start.o (.text*)}

在部分 .\arch\arm\mach-xxx 目錄下面也有 u-boot-spl.lds，這個一般就是針對那些比較特殊的架構單獨實現的連接腳本。在編譯過程中，會通過 CONFIG_SYS_LDSCRIPT=xxxx 來執行這個特殊的腳本文件，如果不指定默認采用.\arch\arm\cpu\u-boot-spl.lds 文件。

u-boot.lds 文件也同上的說明可能有多個。

??從上面的代碼可以看到，ENTRY(_start) 表示最終可執行程序的入口是 _start。第一個節的開始定義了一個名為 __image_copy_start 的符號，它的定義位于 ./arch/arm/lib/sections.c 中：char __image_copy_start[0] __section(".__image_copy_start"); 它僅僅就是個符號，不包含任何內容；接下來就是 vectors，它的定義位于 ./arch/arm/lib/vectors_m.S 中（針對我使用的 STM32F7 這個 ARM 核），這個其實就是 ARM 核中斷向量表。

.section .vectors ENTRY(_start).long CONFIG_SYS_INIT_SP_ADDR @ 0 - Reset stack pointer.long reset @ 1 - Reset.long __invalid_entry @ 2 - NMI.long __hard_fault_entry @ 3 - HardFault.long __mm_fault_entry @ 4 - MemManage.long __bus_fault_entry @ 5 - BusFault.long __usage_fault_entry @ 6 - UsageFault.long __invalid_entry @ 7 - Reserved.long __invalid_entry @ 8 - Reserved.long __invalid_entry @ 9 - Reserved.long __invalid_entry @ 10 - Reserved.long __invalid_entry @ 11 - SVCall.long __invalid_entry @ 12 - Debug Monitor.long __invalid_entry @ 13 - Reserved.long __invalid_entry @ 14 - PendSV.long __invalid_entry @ 15 - SysTick.rept 255 - 16.long __invalid_entry @ 16..255 - External Interrupts.endr

熟悉 ARM 平臺的應該知道，它的入口就是中斷向量表。因此，_start 也是定義在這里的。接下來我們以比較簡單的 u-boot-spl.lds 為例，來完整解析一下連接腳本：

/* SPDX-License-Identifier: GPL-2.0+ */ /** Copyright (c) 2004-2008 Texas Instruments** (C) Copyright 2002* Gary Jennejohn, DENX Software Engineering, <garyj@denx.de>*//* 指定輸出可執行文件: "elf32 位小端格式" */ OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm") /* 指定輸出可執行文件的目標架構:"arm" */ OUTPUT_ARCH(arm) /* 指定輸出可執行文件的入口地址(起始代碼段):"_start" */ ENTRY(_start) SECTIONS {/* * 設置 0 的原因是 arm 內核的處理器,上電后默認是從 0x00000000 處啟動* 1. stm32 片內的 nor-flash 起始地址是0x08000000,上電后,系統會自動將該地址(0x08000000) 映射到 0x00000000(硬件設計實現)*/. = 0x00000000;/* * 代碼以 4 字節對齊 .text為代碼段* 各個段按先后順序依次排列 * ARM規定在 cortex-m 的內核中,鏡像入口處首地址存放的是主堆棧的地址,其次是復位中斷地址，再其后依次存放其他中斷地址* 更詳細的啟動過程可以參見我之前的博文：ARM 之九 Cortex-M/R 內核啟動過程 / 程序啟動流程（基于ARMCC、Keil）*/. = ALIGN(4);.text :{__image_copy_start = .; /* u-boot 的設計中需要將 u-boot 的鏡像拷貝到ram(sdram,ddr....)中執行，這里表示復制的開始地址 */*(.vectors) /* 中斷向量表 */CPUDIR/start.o (.text*) /* CPUDIR/start.o中的所有.text段 */*(.text*) /* 其他.o中的所有.text 段 */*(.glue*) /* 其他.o中的所有.glue 段 */}/* * .rodata 段,確保是以4字節對齊 */. = ALIGN(4); .rodata : {*(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) } /* 按名稱依次存放其他 .o 文件中的.rodata *//* * data段,確保是以4字節對齊*/. = ALIGN(4); .data : {*(.data*) }/* * u_boot_list 段,確保是以4字節對齊 * 這里存放的都是 u_boot_list 中的函數* 例如:base/bdinfo/blkcache/cmp....* 具體的可參看./u-boot.map .u_boot_list* tips:要想優化編譯出來的 u-boot.bin 大小,可以參看此文件進行對照裁剪*/. = ALIGN(4);.u_boot_list : {KEEP(*(SORT(.u_boot_list*)));}/* * binman_sym_table 段,確保是以 4 字節對齊* binman 實現的功能是讓 c 代碼通過 binman_* 的函數接口字節調用鏡像中的個別函數* 具體可參看 binman_sym.h 中的接口*/. = ALIGN(4);.binman_sym_table : {__binman_sym_start = .;KEEP(*(SORT(.binman_sym*)));__binman_sym_end = .;}/* * __image_copy_end 也是個符號表示一個結束地址,確保是以4字節對齊 */. = ALIGN(4);__image_copy_end = .; /* u-boot 的設計中需要將 u-boot 的鏡像拷貝到ram(sdram,ddr....)中執行，這里表示復制的結束地址 */.rel.dyn : {__rel_dyn_start = .;*(.rel*)__rel_dyn_end = .;}.end :{*(.__end)}_image_binary_end = .; /* bin文件結束 */.bss __rel_dyn_start (OVERLAY) : {__bss_start = .;*(.bss*). = ALIGN(4);__bss_end = .;}__bss_size = __bss_end - __bss_start;.dynsym _image_binary_end : {*(.dynsym) }.dynbss : {*(.dynbss) }.dynstr : {*(.dynstr*) }.dynamic : {*(.dynamic*) }.hash : {*(.hash*) }.plt : {*(.plt*) }.interp : {*(.interp*) }.gnu : {*(.gnu*) }.ARM.exidx : {*(.ARM.exidx*) } } /* 下面就是檢查一些限制 */ #if defined(CONFIG_SPL_MAX_SIZE) ASSERT(__image_copy_end - __image_copy_start < (CONFIG_SPL_MAX_SIZE), \"SPL image too big"); #endif#if defined(CONFIG_SPL_BSS_MAX_SIZE) ASSERT(__bss_end - __bss_start < (CONFIG_SPL_BSS_MAX_SIZE), \"SPL image BSS too big"); #endif#if defined(CONFIG_SPL_MAX_FOOTPRINT) ASSERT(__bss_end - _start < (CONFIG_SPL_MAX_FOOTPRINT), \"SPL image plus BSS too big"); #endif

??這里有一點需要注意，SPL/TPL 與 U-Boot 采用的部分接口是一樣的，但是具體實現并不在同一文件中。也就是說，對于同一函數，SPL/TPL 與 U-Boot 在不同的文件中有不同的實現（下面啟動過程章節分別說明）。SPL/TPL 的代碼是分散在源碼目錄的各個文件夾下的，那么我們如何知道 SPL/TPL 具體使用了哪些源代碼文件呢？

??一個比較簡單的方法是：SPL 的編譯過程產生的文件會單獨放到 SPL 目錄下，TPL 的編譯過程產生的文件會單獨放到 TPL 目錄下，我們可以直接查看編譯后的 SPL 或者 TPL 文件夾，其中的內容也是按照源碼目錄組織的。SPL 編譯產生的文件（剔除了部分文件）如下所示：

SPL ├── arch │ └── arm │ ├── cpu │ │ ├── armv7m │ │ │ ├── built-in.o │ │ │ ├── cache.o │ │ │ ├── cpu.o │ │ │ ├── mpu.o │ │ │ └── start.o │ │ └── built-in.o │ ├── lib │ │ ├── ashldi3.o │ │ ├── ashrdi3.o │ │ ├── asm-offsets.s │ │ ├── bdinfo.o │ │ ├── bootm-fdt.o │ │ ├── built-in.o │ │ ├── cache.o │ │ ├── crt0.o │ │ ├── div0.o │ │ ├── div64.o │ │ ├── eabi_compat.o │ │ ├── interrupts_m.o │ │ ├── lib1funcs.o │ │ ├── lib.a │ │ ├── lshrdi3.o │ │ ├── memcpy.o │ │ ├── memset.o │ │ ├── muldi3.o │ │ ├── psci-dt.o │ │ ├── reset.o │ │ ├── sections.o │ │ ├── setjmp.o │ │ ├── spl.o │ │ ├── stack.o │ │ ├── uldivmod.o │ │ ├── vectors_m.o │ │ ├── zimage.o │ └── mach-stm32 │ ├── built-in.o │ ├── soc.o ├── board │ └── st │ ├── common │ │ └── built-in.o │ └── stm32f746-disco │ ├── built-in.o │ ├── stm32f746-disco.o ├── boot │ ├── built-in.o │ ├── image-board.o │ ├── image-fdt.o │ ├── image.o ├── cmd │ ├── built-in.o │ ├── nvedit.o ├── common │ ├── built-in.o │ ├── cli.o │ ├── command.o │ ├── console.o │ ├── dlmalloc.o │ ├── fdt_support.o │ ├── init │ │ ├── board_init.o │ │ └── built-in.o │ ├── malloc_simple.o │ ├── memsize.o │ ├── spl │ │ ├── built-in.o │ │ ├── spl_legacy.o │ │ ├── spl.o │ │ ├── spl_xip.o │ ├── s_record.o │ ├── stdio.o │ ├── xyzModem.o ├── disk │ ├── built-in.o │ ├── part.o ├── drivers │ ├── block │ │ ├── blk_legacy.o │ │ └── built-in.o │ ├── built-in.o │ ├── clk │ │ ├── analogbits │ │ │ └── built-in.o │ │ ├── built-in.o │ │ ├── clk_fixed_factor.o │ │ ├── clk_fixed_rate.o │ │ ├── clk_stm32f.o │ │ ├── clk-uclass.o │ │ ├── imx │ │ │ └── built-in.o │ │ ├── tegra │ │ │ └── built-in.o │ │ └── ti │ │ └── built-in.o │ ├── core │ │ ├── built-in.o │ │ ├── device.o │ │ ├── dump.o │ │ ├── fdtaddr.o │ │ ├── lists.o │ │ ├── of_extra.o │ │ ├── ofnode.o │ │ ├── read_extra.o │ │ ├── root.o │ │ ├── simple-bus.o │ │ ├── uclass.o │ │ ├── util.o │ ├── gpio │ │ ├── built-in.o │ │ ├── gpio-uclass.o │ │ ├── stm32_gpio.o │ ├── misc │ │ ├── built-in.o │ │ ├── misc-uclass.o │ │ ├── stm32_rcc.o │ ├── mtd │ │ ├── built-in.o │ │ ├── mtdcore.o │ │ ├── mtd.o │ │ ├── mtd_uboot.o │ │ ├── mtd-uclass.o │ │ ├── stm32_flash.o │ ├── pinctrl │ │ ├── broadcom │ │ │ └── built-in.o │ │ ├── built-in.o │ │ ├── nxp │ │ │ └── built-in.o │ │ ├── pinctrl_stm32.o │ │ ├── pinctrl-uclass.o │ ├── ram │ │ ├── built-in.o │ │ ├── ram-uclass.o │ │ ├── stm32_sdram.o │ ├── reset │ │ ├── built-in.o │ │ ├── reset-uclass.o │ │ ├── stm32-reset.o │ ├── serial │ │ ├── built-in.o │ │ ├── serial_stm32.o │ │ ├── serial-uclass.o │ ├── soc │ │ └── built-in.o │ └── timer │ ├── built-in.o │ ├── stm32_timer.o │ ├── timer-uclass.o ├── dts │ ├── built-in.o │ └── dt-spl.dtb ├── env │ └── built-in.o ├── fs │ ├── built-in.o │ ├── fs_internal.o ├── include │ ├── autoconf.mk │ └── generated │ ├── asm-offsets.h │ └── generic-asm-offsets.h ├── lib │ ├── abuf.o │ ├── asm-offsets.s │ ├── built-in.o │ ├── crc32.o │ ├── ctype.o │ ├── date.o │ ├── display_options.o │ ├── div64.o │ ├── elf.o │ ├── errno.o │ ├── fdtdec_common.o │ ├── fdtdec.o │ ├── hang.o │ ├── hash-checksum.o │ ├── hashtable.o │ ├── hexdump.o │ ├── libfdt │ │ ├── built-in.o │ │ ├── fdt_addresses.o │ │ ├── fdt_empty_tree.o │ │ ├── fdt.o │ │ ├── fdt_overlay.o │ │ ├── fdt_ro.o │ │ ├── fdt_rw.o │ │ ├── fdt_strerror.o │ │ ├── fdt_sw.o │ │ ├── fdt_wip.o │ ├── linux_compat.o │ ├── linux_string.o │ ├── lmb.o │ ├── membuff.o │ ├── net_utils.o │ ├── panic.o │ ├── qsort.o │ ├── rand.o │ ├── rtc-lib.o │ ├── slre.o │ ├── string.o │ ├── strto.o │ ├── tables_csum.o │ ├── time.o │ ├── tiny-printf.o │ ├── uuid.o ├── u-boot.cfg ├── u-boot-spl ├── u-boot-spl.bin ├── u-boot-spl.dtb ├── u-boot-spl-dtb.bin ├── u-boot-spl.lds ├── u-boot-spl.map ├── u-boot-spl-nodtb.bin ├── u-boot-spl-pad.bin └── u-boot-spl.sym

從中的 .o 文件我們就可以清除的知道 SPL 使用了那些源代碼文件了。U-Boot 本身的編譯默認并沒有一個統一的目錄，產生的中間文件都是直接放到與源文件統一目錄下的。

??當然我們可以在使用 make 命令時指定 O=xxx （例如，make O=/tmp/build canyonlands_config，每個命令都需要指定）參數來指定配置及編譯輸出的位置。例如 make O=build stm32f769-disco_defconfig 就會把配置生成的文件放到 ./build 目錄下，再例如最終編譯命令：CROSS_COMPILE=arm=none=eabi- ARC=arm make O=build -j8。關于構建及配置我們后面單獨說明。

芯片初始化階段

??這里就以我使用的 STM32F769 這個 MCU 為例來說明一下，該 MCU 是 ARM 核心，指令集架構是 armv7m，因此，我的開發板使用的芯片初始化使用的具體代碼就是 ./arch/arm/cpu/armv7m 下的各代碼。那么具體是哪個文件呢？

??前面說過，ARM 架構要求，中斷向量表，開頭依次是 SP 地址，復位中斷地址，其他中斷地址。獲取 SP 后，從復位中斷開始執行。看中斷向量表，給出了 reset 這個符號，那么我們就需要找到 reset 這個符號。再看看目錄中，正好有個 start.S 的文件里就定義了 reset 符號，那么毫無疑問就是它了。

?? 然而，當我自信滿滿的打開 start.S 時卻發現，其中的代碼極其少，對比了一下 armv7 以及 armv8 目錄下的 start.S ，完全就不是一個級別！具體如下圖對比所示：

??首先，我們可以確認的是，U-Boot 是支持 armv7m 指令集架構的 CPU 的（根據后面對于源代碼的研究，好多功能是不可用的）。至于為什么代碼這么少，我也不是很清楚。我們就通過對比的方法并結合 U-Boot 的手冊來重點關注一下他們的共同點：

他們的開頭都是直接從 reset 符號下的代碼開始執行的（Cortex-M 內核規定）。啟動過程中的函數調用如下（忽略在某些宏定義成立時的調用）所示：

armv8： reset -> save_boot_params -> save_boot_params_ret -> apply_core_errata -> lowlevel_init -> _main

armv7： reset -> save_boot_params -> save_boot_params_ret -> cpu_init_crit -> lowlevel_init -> _main

armv7m： reset -> _main

其中，save_boot_params 是個弱函數，意味著如果需要，我們可以通過自定義同名函數來替代該函數。lowlevel_init() 這個函數定義在 lowlevel_init.S 這個文件中，官方手冊中有詳細說明具體用途：

• 來做一些基本的初始化，以使 MCU可以運行到 board_init_f()
• 沒有全局數據或 BSS
• 沒有堆棧（ARMv7 可能有一個，但很快會被移除）
• 不能設置 SDRAM 或使用控制臺
• 必須僅做最少的事，只要能運行到 board_init_f() 即可
• 可以不需要它

他們都定義了一個名為 c_runtime_cpu_setup 符號，并導出為了全局符號，只是該符號內部代碼有所不同。但是，該符號均沒有在本文件中調用。

他們經過一些列執行后，最終都會跳轉到 _main，下文我們單獨詳細來介紹 _main。

至于目錄下的其他 .s 和 .c 文件，其中都是定義一些供外部使用的接口。

_main

??_main 這個符號定義在 ./arch/arm/lib/crt0.S 文件中。crt0 是 C-runtime Startup Code 的簡稱，主要就是用來準備 C 運行環境。下圖是 _main 的函數調用關系（忽略部分宏值條件，順序先后為從上到下）：

接下來我們在分析一下 _main 的具體功能：

為調用 board_init_f() 初始化基本環境。這個環境只提供一個棧和一個存儲 GD（Global Data，全局數據）數據結構的地方，兩者都位于一些現成的 RAM (SRAM，鎖定的緩存……)中。在這種情況下，全局變量無論是否初始化，都是不可用的，只有初始化的常量數據可用。在調用 board_init_f() 之前，全局數據應該清零。

??代碼一開始就是設置棧指針的位置，宏 CONFIG_SPL_STACK / CONFIG_TPL_STACK / CONFIG_SYS_INIT_SP_ADDR 會在 .\include\configs\使用的開發板.h 中定義（例如，我這里對應的是 stm32f746-disco.h）。
??注意，GD 的數據結構定義在 include\asm-generic\global_data.h 中的 global_data，然后又使用 typedef struct global_data gd_t 進行了重定義。而 gd 這個符號定義在 arch\x86\include\asm\global_data.h 中，如下所示：

由此可見，gd 就是一個 gd_t 類型的地址（指針）。經過上面的一番操作之后，內存數據就如下所示了：

r9 存放的就是 gd 的地址。

調用 board_init_f()。對于 SPL，board_init_f() 是定義在 .\common\spl\spl.c 中；對于 U-Boot，board_init_f() 是定義在 .\common\board_f.c 中。該函數為從系統 RAM (DRAM, DDR…)執行硬件做準備。由于系統 RAM 可能還不可用，因此 board_init_f() 必須使用當前 GD 來存儲必須傳遞到以后階段的任何數據。這些數據包括重定位目的地地址、未來棧和未來的 GD 位置。

設置中間環境，其中棧和 GD 是由 board_init_f() 在系統 RAM 中分配的，但 BSS 和初始化的非 const 數據仍然不可用。對于 U-Boot（非 SPL），調用 relocate_code()。這個函數將 U-Boot 從當前位置重定位到由 board_init_f() 計算的重定位位置； 對于 SPL，board_init_f() 直接返回（到 crt0）。在 SPL中沒有代碼重定位，因此不需要調用 relocate_code()。

??relocate_code() 定義在 .\arch\arm\lib\relocate.S 中。函數原型：void relocate_code(addr_moni)在進行了代碼重定位之后，中斷向量表也是需要重定位的。這里需要注意的是，在代碼重定位完成之后，后續執行就開始執行重定位之后的代碼了。因此，這部分代碼中有計算重定位之后的 here 位置。
??對于 U-Boot（非 SPL），一些 cpu 在內存方面還有一些工作要做，所以調用 c_runtime_cpu_setup。c_runtime_cpu_setup 就定義在我們的起始文件 start.S 中，很多芯片的實現就是空的，沒啥內容。

為調用 board_init_r() 設置最終環境。這個環境有 BSS（初始化為 0），初始化為非 const 數據（初始化為預期值），以及系統 RAM 中的棧(對于 SPL 來說，將棧和 GD 移動到 RAM 是可選的)。GD 保留了 board_init_f() 設置的值。最終的內存如下所示：

調用 board_init_r()。對于 SPL，board_init_r() 是定義在 .\common\spl\spl.c 中；對于 U-Boot，board_init_r() 是定義在 .\common\board_r.c 中。

板級初始化階段

??在上面對于 _main 的分析中，我們可以看到，其中調用了很多 board_ 開頭的函數。這部分函數主要位于 ./common 目錄下。同時需要注意的是，這里指的是 U-Boot 本身，SPL/TPL 的代碼主要位于 .\common\spl\ 目錄下。

• ./common/init/board_init.c 其中的接口 U-Boot 與 SPL/TPL 共用。
  • ulong board_init_f_alloc_reserve(ulong top)：從“top”地址分配預留的空間作為“globals”使用，并返回已分配空間的“bottom”地址。
    
  • void board_init_f_init_reserve(ulong base)：初始化保留的空間（已從 C 運行時環境處理代碼安全地在 C 堆棧上分配）。
    
• void board_init_f(ulong boot_flags)：為執行 board_init_r 準備環境。在這里，GD 可用、棧在 RAM 中，BSS 不可用（全局變量、靜態變量均不可用）。
  • ./common/board_f.c：U-Boot 使用的接口位于此文件中，調用關系如下圖：
    
    void board_init_f(ulong boot_flags) 通過遍歷執行 static const init_fnc_t init_sequence_f[] 中定義的各個接口實現各種功能。
  • .\common\spl\spl.c：SPL/TPL 使用的接口位于此文件中，調用關系如下圖：
    
• void board_init_r(gd_t *new_gd, ulong dest_addr)：開始執行通用代碼。從這里開始，GD 可用、SDRAM 可用、棧在 RAM 中，BSS 可用（全局變量、靜態變量均可用），并最終執行位于 .\common\main.c 中的 void main_loop(void)。
  • ./common/board_r.c
    
    void board_init_r(gd_t *new_gd, ulong dest_addr) 通過遍歷執行 static init_fnc_t init_sequence_r[] 中定義的各個接口實現各種功能。
  • .\common\spl\spl.c：SPL/TPL 使用的接口位于此文件中，調用關系如下圖：
    
    load 完鏡像后，默認會去調用 spl_board_prepare_for_boot() 和 jump_to_image_no_args() 跳轉到 U-Boot。至此，u-boot-spl 的流程就走完了，接下來就是走 u-boot 的流程。

對比其他架構

??這里有必要來對比其他架構來一個說明（就以 armv7 架構 ARM CPU 作為對比 ）。如果大家去看網上的一些文章，會發現他們的啟動流程和這里的有很大區別，一個典型的啟動流程圖如下所示：

至于 armv7m 為啥與上面差別這么大，我也還沒搞清楚！

參考

https://askubuntu.com/questions/1243252/how-to-install-arm-none-eabi-gdb-on-ubuntu-20-04-lts-focal-fossa

https://james-hui.com/2021/07/02/building-a-small-uboot-linux-and-rootfs-for-arm-cortex-m7/

https://www.cnblogs.com/dylancao/p/8621789.html

https://wowothink.com/1e031f74/

https://blog.csdn.net/linuxweiyh/article/details/99331659

https://loee.xyz/2021/04/27/uboot-%E6%B5%81%E7%A8%8B%E5%88%86%E6%9E%90/

https://www.twblogs.net/t/5d26d62ebd9eee1ede06f20d

https://mrchen.love/Article/ID/57

https://blog.csdn.net/weixin_39890452/article/details/114470827

https://www.cnblogs.com/cslunatic/archive/2013/03/28/2986146.html

https://wowothink.com/146db8db/

https://www.pianshen.com/article/70672050376/

https://my.oschina.net/u/4232364/blog/3134261

https://adrianalin.gitlab.io/popsblog.me/posts/build-linux-for-stm32f769i-disco-using-buildroot/

總結

以上是生活随笔為你收集整理的U-Boot 之五 详解 U-Boot 及 SPL 的启动流程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。