[uboot] （第四章）uboot流程——uboot編譯流程

阿新 • • 發佈：2018-12-11

以下例子都以project X專案tiny210（s5pv210平臺,armv7架構）為例

建議先看《[project X] tiny210(s5pv210)上電啟動流程（BL0-BL2）》，根據例子瞭解一下上電之後的BL0\BL1\BL2階段，以及各個階段的執行位置，功能。 建議先看《[uboot] （第二章）uboot流程——uboot-spl編譯流程》，其編譯流程基本上是類似的。最大區別在於dtb的編譯。

=================================================================================

一、uboot編譯和生成檔案

0、說明

現在的uboot已經做得和kernel很像，最主要的一點是，uboot也使用了dtb的方法，將裝置樹和程式碼分離開來（當然可以通過巨集來控制）。 project-x/u-boot/configs/tiny210_defconfig

CONFIG_OF_CONTROL=y
// 用於表示是否使用了dtb的方式

CONFIG_OF_SEPARATE=y
// 是否將dtb和uboot分離表一

所以在uboot的編譯中，和spl的最大區別是還要編譯dtb。 （前面我們將的spl是沒有使用dtb的，當然好像也可以使用dtb，只是我沒有試過）。

1、編譯方法

在project X專案中，所有映象，包括uboot、kernel、rootfs都是放在build目錄下進行編譯的。具體去參考該專案build的Makefile的實現。假設config已經配置完成，在build編譯命令如下：

make uboot

Makefile中對應的命令如下： project-x/build/Makefile

BUILD_DIR=$(shell pwd)
OUT_DIR=$(BUILD_DIR)/out
UBOOT_OUT_DIR=$(OUT_DIR)/u-boot
UBOOT_DIR=$(BUILD_DIR)/../u-boot
uboot:
        mkdir -p $(UBOOT_OUT_DIR)
        make -C $(UBOOT_DIR) CROSS_COMPILE=$(CROSS_COMPILE) KBUILD_OUTPUT=$(UBOOT_OUT_DIR) $(BOARD_NAME)_defconfig
        make -C $(UBOOT_DIR) CROSS_COMPILE=$(CROSS_COMPILE) KBUILD_OUTPUT=$(UBOOT_OUT_DIR)
## -C $(UBOOT_DIR) 指定了要在../uboot，也就是uboot的程式碼根目錄下執行make
## CROSS_COMPILE=$(CROSS_COMPILE) 指定了交叉編譯器
## KBUILD_OUTPUT=$(UBOOT_OUT_DIR) 指定了最終編譯的輸出目錄是build/out/u-boot.

最終，相當於進入了uboot目錄執行了make動作。

2、生成檔案

最終編譯完成之後，會在project-x/build/out/u-boot下生成如下檔案：

arch   common   dts       include   net         tools       u-boot.cfg      u-boot.lds        u-boot.srec
board  disk     examples  lib       scripts  System.map  u-boot      u-boot.dtb      u-boot.map        u-boot.sym
cmd    drivers  fs        Makefile  source   test        u-boot.bin  u-boot-dtb.bin  u-boot-nodtb.bin

其中，arch、common、dts、include、board、drivers、fs等等目錄是對應程式碼的編譯目錄，各個目錄下都會生成相應的built.o，是由同目錄下的目標檔案連線而成。 重點說一下以下幾個檔案：

檔案	說明
u-boot	初步連結後得到的uboot檔案
u-boot-nodtb.bin	在u-boot的基礎上，經過objcopy去除符號表資訊之後的可執行程式
u-boot.dtb	dtb檔案
u-boot-dtb.bin	將u-boot-nodtb.bin和u-boot.dtb打包在一起的檔案
u-boot.bin	在需要dtb的情況下，直接由u-boot-dtb.bin複製而來，也就是編譯u-boot的最終目標
u-boot.lds	uboot的連線指令碼
System.map	連線之後的符號表檔案
u-boot.cfg	由uboot配置生成的檔案

二、uboot編譯流程

1、編譯整體流程

根據一、2生成的檔案說明可知簡單流程如下： （1）各目錄下built-in.o的生成

原始檔、程式碼檔案編譯、彙編目標檔案同目錄目標檔案連線built-in目標檔案

（2）由所有built-in.o以u-boot.lds為連線指令碼通過連線來生成u-boot

built-in目標檔案以u-boot.lds為連線指令碼進行統一連線u-boot

（3）由u-boot生成u-boot-nodtb.bin

u-bootobjcopy動作去掉符號資訊表u-boot-nodtb.bin

（4）由生成uboot的dtb檔案

dts檔案dtc編譯、打包dtb檔案u-boot.dtb

（5）由u-boot-nodtb.bin和u-boot.dtb生成u-boot-dtb.bin

u-boot-nodtb.bin和u-boot.dtb追加整合兩個檔案u-boot-dtb.bin

（6）由u-boot-dtb.bin複製生成u-boot.bin

u-boot-dtb.bin複製u-boot.bin

2、具體編譯流程分析

我們直接從make uboot命令分析，也就是從uboot下的Makefile的依賴關係來分析整個編譯流程。注意，這個分析順序和上述的整體編譯流程的順序是反著的。

（1）入口分析 在project-x/u-boot/Makefile中

all:            $(ALL-y)
ALL-y += u-boot.srec u-boot.bin u-boot.sym System.map u-boot.cfg binary_size_check

u-boot.bin就是我們的目標，所以後需要主要研究u-boot.bin的依賴關係。

（2）u-boot.bin的依賴關係 在project-x/u-boot/Makefile中

ifeq ($(CONFIG_OF_SEPARATE),y)
## CONFIG_OF_SEPARATE用於定義是否有DTB並且是否是和uboot分開編譯的。
## tiny210是有定義這個巨集的，所以走的是上面這路

u-boot-dtb.bin: u-boot-nodtb.bin dts/dt.dtb FORCE
        $(call if_changed,cat)
## 由u-boot-nodtb.bin和dts/dt.dtb連線在一起，先生成u-boot-dtb.bin
## $(call if_changed,cat)會呼叫到cmd_cat函式，具體實現我們不分析了

u-boot.bin: u-boot-dtb.bin FORCE
        $(call if_changed,copy)
## 直接將u-boot-dtb.bin複製為u-boot.bin
## $(call if_changed,copy)會呼叫到cmd_copy函式，具體實現我們不分析了

else
u-boot.bin: u-boot-nodtb.bin FORCE
        $(call if_changed,copy)
endif

對應於上述二、1（5）流程和上述二、1（6）流程。後續有兩個依賴關係要分析，分別是u-boot-nodtb.bin和dts/dt.dtb。 u-boot-nodtb.bin依賴關係參考下述二、2（3）-2（6）. dts/dt.dtb依賴關係參考下述二、2（7）其中u-boot-nodtb.bin的依賴關係和SPL的相當類似，可以先參考一下《[uboot] （第二章）uboot流程——uboot-spl編譯流程》。

（3）u-boot-nodtb.bin的依賴關係 在project-x/u-boot/Makefile中

u-boot-nodtb.bin: u-boot FORCE
        $(call if_changed,objcopy)
        $(call DO_STATIC_RELA,$<,[email protected],$(CONFIG_SYS_TEXT_BASE))
        $(BOARD_SIZE_CHECK)
## $(call if_changed,objcopy)表示當依賴檔案發生變化時，將依賴檔案經過objcopy處理之後得到目標檔案。
## 也就是通過objcopy把u-boot的符號資訊以及一些無用資訊去掉之後，得到了u-boot-nodtb.bin。

如上述Makefile程式碼u-boot-nodtb.bin依賴於u-boot，並且由u-boot經過objcopy操作之後得到。對應於上述二、1（3）流程.

（4）u-boot的依賴關係 在project-x/u-boot/Makefile中

u-boot: $(u-boot-init) $(u-boot-main) u-boot.lds FORCE
        $(call if_changed,u-boot__)
## $(call if_changed,u-boot__)來生成目標
## $(call if_changed,u-boot__)對應cmd_u-boot__命令

如上，u-boot依賴於$(u-boot-init) 、$(u-boot-main)和u-boot.lds，並且最終會呼叫cmd_u-boot__來生成u-boot。 cmd_u-boot__實現如下 project-x/u-boot/Makefile

      cmd_u-boot__ ?= $(LD) $(LDFLAGS) $(LDFLAGS_u-boot) -o [email protected] \ 
      -T u-boot.lds $(u-boot-init)                             \    
      --start-group $(u-boot-main) --end-group                 \    
      $(PLATFORM_LIBS) -Map u-boot.map

將cmd_u-boot__通過echo命令打印出來之後得到如下（拆分出來看的）： project-x/u-boot/Makefile

/project-x/build/arm-none-linux-gnueabi-4.8/bin/arm-none-linux-gnueabi-ld
 -pie --gc-sections -Bstatic -Ttext 0x23E00000 
 -o u-boot 
-T u-boot.lds 
arch/arm/cpu/armv7/start.o 
--start-group 
arch/arm/cpu/built-in.o arch/arm/cpu/armv7/built-in.o arch/arm/lib/built-in.o arch/arm/mach-s5pc1xx/built-in.o board/samsung/common/built-in.o board/samsung/tiny210/built-in.o cmd/built-in.o common/built-in.o disk/built-in.o drivers/built-in.o drivers/dma/built-in.o drivers/gpio/built-in.o drivers/i2c/built-in.o drivers/mmc/built-in.o drivers/mtd/built-in.o drivers/mtd/onenand/built-in.o drivers/mtd/spi/built-in.o drivers/net/built-in.o drivers/net/phy/built-in.o drivers/pci/built-in.o drivers/power/built-in.o drivers/power/battery/built-in.o drivers/power/fuel_gauge/built-in.o drivers/power/mfd/built-in.o drivers/power/pmic/built-in.o drivers/power/regulator/built-in.o drivers/serial/built-in.o drivers/spi/built-in.o drivers/usb/common/built-in.o drivers/usb/dwc3/built-in.o drivers/usb/emul/built-in.o drivers/usb/eth/built-in.o drivers/usb/gadget/built-in.o drivers/usb/gadget/udc/built-in.o drivers/usb/host/built-in.o drivers/usb/musb-new/built-in.o drivers/usb/musb/built-in.o drivers/usb/phy/built-in.o drivers/usb/ulpi/built-in.o fs/built-in.o lib/built-in.o net/built-in.o test/built-in.o test/dm/built-in.o 
--end-group 
arch/arm/lib/eabi_compat.o 
-L /project-x/build/arm-none-linux-gnueabi-4.8/bin/../lib/gcc/arm-none-linux-gnueabi/4.8.3 -lgcc 
-Map u-boot.map

可以看出上述是一條連線命令，以u-boot.lds為連結指令碼，把$(u-boot-init) 、$(u-boot-main)的指定的目標檔案連線到u-boot中。 並且已經指定輸出檔案為u-boot，連線指令碼為u-boot.lds。 連線很重要的東西就是連線標識，也就是 $(LD) $(LDFLAGS) $(LDFLAGS_u-boot)的定義。嘗試把$(LD) \$(LDFLAGS) \$(LDFLAGS_u-boot)) 打印出來，結果如下：

LD=~/project-x/build/arm-none-linux-gnueabi-4.8/bin/arm-none-linux-gnueabi-ld
LDFLAGS=
LDFLAGS_u-boot=-pie --gc-sections -Bstatic -Ttext 0x23E00000

LDFLAGS_u-boot定義如下

LDFLAGS_u-boot += -pie
LDFLAGS_u-boot += $(LDFLAGS_FINAL)
ifneq ($(CONFIG_SYS_TEXT_BASE),)
LDFLAGS_u-boot += -Ttext $(CONFIG_SYS_TEXT_BASE)
endif

## 當指定CONFIG_SYS_TEXT_BASE時，會配置連線地址。在tiny210專案中，定義如下：
## ./include/configs/tiny210.h:52:#define CONFIG_SYS_TEXT_BASE            0x23E00000

## $(LDFLAGS_FINAL)在如下幾個地方定義了
## ./config.mk:19:LDFLAGS_FINAL :=
## ./config.mk:80:LDFLAGS_FINAL += -Bstatic
## ./arch/arm/config.mk:16:LDFLAGS_FINAL += --gc-sections
## 通過上述LDFLAGS_u-boot=-pie --gc-sections -Bstatic -Ttext 0x23E00000也就可以理解了
## 對應於上述二、1（2）流程。

對應於上述二、1（2）流程。關於u-boot依賴的說明在（5）、（6）中繼續介紹

（5）u-boot-init & u-boot-main依賴關係（程式碼是如何被編譯的） 先看一下這兩個值打印出來的

u-boot-init=arch/arm/cpu/armv7/start.o
u-boot-main= arch/arm/cpu/built-in.o arch/arm/cpu/armv7/built-in.o arch/arm/lib/built-in.o arch/arm/mach-s5pc1xx/built-in.o board/samsung/common/built-in.o board/samsung/tiny210/built-in.o cmd/built-in.o common/built-in.o disk/built-in.o drivers/built-in.o drivers/dma/built-in.o drivers/gpio/built-in.o drivers/i2c/built-in.o drivers/mmc/built-in.o drivers/mtd/built-in.o drivers/mtd/onenand/built-in.o drivers/mtd/spi/built-in.o drivers/net/built-in.o drivers/net/phy/built-in.o drivers/pci/built-in.o drivers/power/built-in.o drivers/power/battery/built-in.o drivers/power/fuel_gauge/built-in.o drivers/power/mfd/built-in.o drivers/power/pmic/built-in.o drivers/power/regulator/built-in.o drivers/serial/built-in.o drivers/spi/built-in.o drivers/usb/common/built-in.o drivers/usb/dwc3/built-in.o drivers/usb/emul/built-in.o drivers/usb/eth/built-in.o drivers/usb/gadget/built-in.o drivers/usb/gadget/udc/built-in.o drivers/usb/host/built-in.o drivers/usb/musb-new/built-in.o drivers/usb/musb/built-in.o drivers/usb/phy/built-in.o drivers/usb/ulpi/built-in.o fs/built-in.o lib/built-in.o net/built-in.o test/built-in.o test/dm/built-in.o

可以觀察到是一堆目標檔案的路徑。這些目標檔案最終都要被連線到u-boot中。 u-boot-init & u-boot-main的定義如下程式碼： project-x/u-boot/Makefile

u-boot-init := $(head-y)
## head-y定義在如下位置
## ./arch/arm/Makefile:73:head-y := arch/arm/cpu/$(CPU)/start.o

libs-y += lib/
libs-y += fs/
libs-y += net/
libs-y += disk/
libs-y += drivers/
libs-y += drivers/dma/
libs-y += drivers/gpio/
libs-y += drivers/i2c/
...
u-boot-dirs     := $(patsubst %/,%,$(filter %/, $(libs-y))) tools examples
## 過濾出路徑之後，加上tools目錄和example目錄

libs-y          := $(patsubst %/, %/built-in.o, $(libs-y)) 
## 先加上字尾built-in.o

u-boot-main := $(libs-y)

那麼u-boot-init & u-boot-main是如何生成的呢？需要看一下對應的依賴如下：

$(sort $(u-boot-init) $(u-boot-main)): $(u-boot-dirs) ;
## 也就是說$(u-boot-init) $(u-boot--main)依賴於$(u-boot-dirs) 
## sort函式根據首字母進行排序並去除掉重複的。
##u-boot-dirs     := $(patsubst %/,%,$(filter %/, $(libs-y))) tools examples
## $(filter %/, $(libs-y)過濾出'/'結尾的字串，注意，此時$(libs-y)的內容還沒有加上built-in.o檔案字尾
## patsubst去掉字串中最後的'/'的字元。
## 最後u-boot-dirs打印出來如下：
## u-boot-dirs=arch/arm/cpu arch/arm/cpu/armv7 arch/arm/lib arch/arm/mach-s5pc1xx board/samsung/common board/samsung/tiny210 cmd common disk drivers drivers/dma drivers/gpio drivers/i2c drivers/mmc drivers/mtd drivers/mtd/onenand drivers/mtd/spi drivers/net drivers/net/phy drivers/pci drivers/power drivers/power/battery drivers/power/fuel_gauge drivers/power/mfd drivers/power/pmic drivers/power/regulator drivers/serial drivers/spi drivers/usb/common drivers/usb/dwc3 drivers/usb/emul drivers/usb/eth drivers/usb/gadget drivers/usb/gadget/udc drivers/usb/host drivers/usb/musb-new drivers/usb/musb drivers/usb/phy drivers/usb/ulpi fs lib net test test/dm tools examples

u-boot-dirs依賴規則如下：

PHONY += $(u-boot-dirs)
$(u-boot-dirs): prepare scripts
        $(Q)$(MAKE) $(build)[email protected]
## 依賴於prepare scripts
## prepare會導致prepare0、prepare1、prepare2、prepare3目標被執行，最終編譯了tools目錄下的東西，生成了一些工具
## 然後執行$(Q)$(MAKE) $(build)[email protected]
## 也就是會對每一個目標檔案依次執行make \$(build)=目標檔案

對每一個目標檔案依次執行make $(build)=目標檔案 $(build)定義如下： project-x/u-boot/scripts/Kbuild.include

build := -f $(srctree)/scripts/Makefile.build obj

以arch/arm/mach-s5pc1xx為例 “$(MAKE) $(build)[email protected]”展開後格式如下 make -f project-x/u-boot/scripts/Makefile.build obj=arch/arm/mach-s5pc1xx。

Makefile.build定義built-in.o、.lib以及目標檔案.o的生成規則。這個Makefile檔案生成了子目錄的.lib、built-in.o以及目標檔案.o。 Makefile.build第一個編譯目標是__build，如下

PHONY := __build
__build:
## 所以會直接編譯執行__build這個目標，其依賴如下
__build: $(if $(KBUILD_BUILTIN),$(builtin-target) $(lib-target) $(extra-y)) \
         $(if $(KBUILD_MODULES),$(obj-m) $(modorder-target)) \
         $(subdir-ym) $(always)
        @:
## 和built-in.o相關的是依賴builtin-target。下面來看這個依賴。
builtin-target := $(obj)/built-in.o
## 以obj=arch/arm/mach-s5pc1xx為例，那麼builtin-target就是arch/arm/mach-s5pc1xx/built-in.o.

## 依賴關係如下：
$(builtin-target): $(obj-y) FORCE
        $(call if_changed,link_o_target)
## $(call if_changed,link_o_target)將所有依賴連線到$(builtin-target)，也就是相應的built-in.o中了。
## 具體實現可以檢視cmd_link_o_target的實現，這裡不詳細說明了。

## 那麼$(obj-y)是從哪裡來的呢？是從相應目錄下的Makefile中include得到的。
# The filename Kbuild has precedence over Makefile
kbuild-dir := $(if $(filter /%,$(src)),$(src),$(srctree)/$(src))
kbuild-file := $(if $(wildcard $(kbuild-dir)/Kbuild),$(kbuild-dir)/Kbuild,$(kbuild-dir)/Makefile)
include $(kbuild-file)
## 當obj=arch/arm/mach-s5pc1xx時,得到對應的kbuild-file=u-boot/arch/arm/mach-s5pc1xx/Makefile
## 而在u-boot/arch/arm/mach-s5pc1xx/Makefile中定義了obj-y如下：
## obj-y   = cache.o
## obj-y   += reset.o
## obj-y   += clock.o
## 對應obj-y對應一些目標檔案，由C檔案編譯而來，這裡就不說明了。

後面來看目標檔案的編譯流程 ./scripts/Makefile.build/scripts/Makefile.build

# Built-in and composite module parts
$(obj)/%.o: $(src)/%.c $(recordmcount_source) FORCE
        $(call cmd,force_checksrc)
        $(call if_changed_rule,cc_o_c)
## 呼叫cmd_cc_o_c對.c檔案進行編譯

## cmd_cc_o_c格式如下：
cmd_cc_o_c = $(CC) $(c_flags) -c -o [email protected] $<
## $(CC) $(c_flags)打印出來如下：
## CC=/home/disk3/xys/temp/project-x/build/arm-none-linux-gnueabi-4.8/bin/arm-none-linux-gnueabi-gcc
## c_flags=-Wp,-MD,arch/arm/mach-s5pc1xx/.clock.o.d -nostdinc -isystem /home/disk3/xys/temp/project-x/build/arm-none-linux-gnueabi-4.8/bin/../lib/gcc/arm-none-linux-gnueabi/4.8.3/include -Iinclude -I/home/disk3/xys/temp/project-x/u-boot/include -I/home/disk3/xys/temp/project-x/u-boot/arch/arm/include -include /home/disk3/xys/temp/project-x/u-boot/include/linux/kconfig.h -I/home/disk3/xys/temp/project-x/u-boot/arch/arm/mach-s5pc1xx -Iarch/arm/mach-s5pc1xx -D__KERNEL__ -D__UBOOT__ -Wall -Wstrict-prototypes -Wno-format-security -fno-builtin -ffreestanding -Os -fno-stack-protector -fno-delete-null-pointer-checks -g -fstack-usage -Wno-format-nonliteral -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -fno-pic -mno-unaligned-access -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -pipe -march=armv7-a -I/home/disk3/xys/temp/project-x/u-boot/arch/arm/mach-s5pc1xx/include -DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(clock) -DKBUILD_MODNAME=KBUILD_STR(clock)

對應於上述二、1（1）流程。

（6）u-boot.lds依賴關係 這裡主要是為了找到一個匹配的連線檔案。

u-boot.lds: $(LDSCRIPT) prepare FORCE
        $(call if_changed_dep,cpp_lds)
ifndef LDSCRIPT
        ifeq ($(wildcard $(LDSCRIPT)),)
                LDSCRIPT := $(srctree)/board/$(BOARDDIR)/u-boot.lds
        endif
        ifeq ($(wildcard $(LDSCRIPT)),)
                LDSCRIPT := $(srctree)/$(CPUDIR)/u-boot.lds
        endif
        ifeq ($(wildcard $(LDSCRIPT)),)
                LDSCRIPT := $(srctree)/arch/$(ARCH)/cpu/u-boot.lds
        endif
endif
## 也就是說依次從board/板級目錄、cpudir目錄、arch/架構/cpu/目錄下去搜索u-boot.lds檔案。
## 例如，tiny210(s5vp210 armv7)最終會在./arch/arm/cpu/下搜尋到u-boot.lds

綜上，最終指定了project-X/u-boot/arch/arm/cpu/u-boot.lds作為連線指令碼。

（7）dts/dt.dtb依賴關係 該依賴關係的主要目的是生成dtb檔案。首先了解dts檔案被放在了arch/arm/dts裡面，並通過dts下的Makefile進行選擇。 Makefile如下（剪切出一部分） project-X/u-boot/arch/arm/dts/Makefile

dtb-$(CONFIG_S5PC110) += s5pc1xx-goni.dtb
dtb-$(CONFIG_EXYNOS5) += exynos5250-arndale.dtb \
        exynos5250-snow.dtb \
        exynos5250-spring.dtb \
        exynos5250-smdk5250.dtb \
        exynos5420-smdk5420.dtb \
        exynos5420-peach-pit.dtb \
        exynos5800-peach-pi.dtb \
        exynos5422-odroidxu3.dtb
dtb-$(CONFIG_TARGET_TINY210) += \
        s5pv210-tiny210.dtb
## 填充選擇dtb-y

targets += $(dtb-y)

# Add any required device tree compiler flags here
DTC_FLAGS +=
## 用於新增DTC編譯選項

PHONY += dtbs
dtbs: $(addprefix $(obj)/, $(dtb-y))
        @:
## 偽目標，其依賴為$(dtb-y)加上了源路徑，如下
## arch/arm/dts/s5pc1xx-goni.dtb
## arch/arm/dts/s5pv210-tiny210.dtb
## 後續會使用到這個偽目標

接下來看一下dts/dt.dtb的依賴關係

dtbs dts/dt.dtb: checkdtc u-boot
        $(Q)$(MAKE) $(build)=dts dtbs
## checkdtc依賴用於檢查dtc的版本
## u-boot一旦發生變化那麼就重新編譯一遍dtb
## 重點關注命令 $(Q)$(MAKE) $(build)=dts dtbs
## 展開來就是make -f ~/project-x/u-boot/scripts/Makefile.build obj=dts dtbs
## 我們相當於值在/scripts/Makefile.build下執行了目標dtbs

在scripts/Makefile.build中dtbs的目標定義在哪裡呢 project-X/u-boot/scripts/Makefile.build

kbuild-file := $(if $(wildcard $(kbuild-dir)/Kbuild),$(kbuild-dir)/Kbuild,$(kbuild-dir)/Makefile)
include $(kbuild-file)
## 把對應的Makefile路徑包含了進去，也就是arch/arm/dts/Makefile
## 如前面所說，arch/arm/dts/Makefile中定義了dtbs的目標
## dtbs: $(addprefix $(obj)/, $(dtb-y))
##        @:
## 這裡我們就找到對應的依賴關係了，依賴就是$(obj)/, $(dtb-y)，舉個例子就是arch/arm/dts/s5pv210-tiny210.dtb

include scripts/Makefile.lib
## 包含了scripts/Makefile.lib，在編譯dts的時候會用到

接下來就是$(obj)/, $(dtb-y)的依賴關係了 project-X/u-boot/scripts/Makefile.lib

$(obj)/%.dtb: $(src)/%.dts FORCE
        $(call if_changed_dep,dtc)
## 使用了萬用字元的方式
## 這樣就通過dtc對dts編譯生成了dtb檔案

對應於上述二、1（4）流程。

三、一些重點定義

1、連線標誌 在二、2（4）中說明。連線命令在cmd_u-boot__中，如下

      cmd_u-boot__ ?= $(LD) $(LDFLAGS) $(LDFLAGS_u-boot) -o [email protected] \ 
      -T u-boot.lds $(u-boot-init)                             \    
      --start-group $(u-boot-main) --end-group                 \    
      $(PLATFORM_LIBS) -Map u-boot.map

連線標識如下：

LD=~/project-x/build/arm-none-linux-gnueabi-4.8/bin/arm-none-linux-gnueabi-ld
LDFLAGS=
LDFLAGS_u-boot=-pie --gc-sections -Bstatic -Ttext 0x23E00000

LDFLAGS_u-boot定義如下

LDFLAGS_u-boot += -pie
LDFLAGS_u-boot += $(LDFLAGS_FINAL)
ifneq ($(CONFIG_SYS_TEXT_BASE),)
LDFLAGS_u-boot += -Ttext $(CONFIG_SYS_TEXT_BASE)
endif

‘-o’指定了輸出檔案是u-boot，’-T’是指定了連線指令碼是當前目錄下的u-boot.lds, -Ttext指定了連線地址是CONFIG_SYS_TEXT_BASE。

2、連線地址 在二、2（4）中說明。 CONFIG_SYS_TEXT_BASE指定了u-boot.bin的連線地址。這個地址也就是uboot的起始執行地址。對於tiny210，其定義如下（可以進行修改） /include/configs/tiny210.h

#define CONFIG_SYS_TEXT_BASE            0x23E00000

3、連線指令碼 在二、2（6）中說明。 u-boot/arch/arm/cpu/u-boot.lds

u-boot.lds: $(LDSCRIPT) prepare FORCE
        $(call if_changed_dep,cpp_lds)
ifndef LDSCRIPT
        ifeq ($(wildcard $(LDSCRIPT)),)
                LDSCRIPT := $(srctree)/board/$(BOARDDIR)/u-boot.lds
        endif
        ifeq ($(wildcard $(LDSCRIPT)),)
                LDSCRIPT := $(srctree)/$(CPUDIR)/u-boot.lds
        endif
        ifeq ($(wildcard $(LDSCRIPT)),)
                LDSCRIPT := $(srctree)/arch/$(ARCH)/cpu/u-boot.lds
        endif
endif

綜上，最終指定了project-X/u-boot/arch/arm/cpu/u-boot.lds作為連線指令碼。

四、uboot連結指令碼說明

1、連線指令碼整體分析

相對比較簡單，直接看連線指令碼的內容project-x/u-boot/arch/arm/cpu/u-boot.lds 前面有一篇分析連線指令碼的文章了《[kernel 啟動流程] 前篇——vmlinux.lds分析》，可以參考一下。參考如下，只提取了一部分：

ENTRY(_start)
//定義了地址為_start的地址，所以我們分析程式碼就是從這個函式開始分析的！！！
    . = 0x00000000;

//以下定義文字段
    . = ALIGN(4);
    .text :
    {
        __image_copy_start = .;
//定義__image_copy_start這個標號地址為當前地址
        *(.vectors)
//所有目標檔案的vectors段，也就是中斷向量表連線到這裡來
        CPUDIR/start.o (.text*)
//start.o檔案的.text段連結到這裡來
        *(.text*)
//所有目標檔案的.text段連結到這裡來
    }

//以下定義只讀資料段
    . = ALIGN(4);
    .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }

//以下定義資料段
    . = ALIGN(4);
    .data : {
        *(.data*)
//所有目標檔案的.data段連結到這裡來
    }

    . = ALIGN(4);

//以下定義u_boot_list段，具體功能未知
    . = ALIGN(4);
    .u_boot_list : {
        KEEP(*(SORT(.u_boot_list*)));
    }

    . = ALIGN(4);

    .image_copy_end :
    {
        *(.__image_copy_end)
    }
//定義__image_copy_end符號的地址為當前地址
//從__image_copy_start 到__image_copy_end的區間，包含了程式碼段和資料段。

    .rel_dyn_start :
    {
        *(.__rel_dyn_start)
    }
//定義__rel_dyn_start 符號的地址為當前地址，後續在程式碼中會使用到

    .rel.dyn : {
        *(.rel*)
    }

    .rel_dyn_end :
    {
        *(.__rel_dyn_end)
    }
//定義__rel_dyn_end 符號的地址為當前地址，後續在程式碼中會使用到
//從__rel_dyn_start 到__rel_dyn_end 的區間，應該是在程式碼重定向的過程中會使用到，後續遇到再說明。

    .end :
    {
        *(.__end)
    }

    _image_binary_end = .;
//定義_image_binary_end 符號的地址為當前地址

// 以下定義堆疊段
    .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));
    }
｝

2、以下以.vectors段做說明，

.vectors是uboot連結指令碼第一個連結的段，也就是_start被連結進來的部分，也負責連結異常中斷向量表先看一下程式碼project-x/u-boot/arch/arm/lib/vectors.S

.globl _start
    .section ".vectors", "ax"
@@ 定義在.vectors段中

_start:

    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

    .globl  _undefined_instruction
    .globl  _software_interrupt
    .globl  _prefetch_abort
    .globl  _data_abort
    .globl  _not_used
    .globl  _irq
    .globl  _fiq
@@ 定義了異常中斷向量表

通過“arm-none-linux-gnueabi-objdump -D u-boot > uboot_objdump.txt”進行反編譯之後，得到了如下指令

23e00000 <__image_copy_start>:
23e00000:   ea0000be    b   23e00300 <reset>
23e00004:   e59ff014    ldr pc, [pc, #20]   ; 23e00020 <_undefined_instruction>                                                                                                              
23e00008:   e59ff014    ldr pc, [pc, #20]   ; 23e00024 <_software_interrupt>
23e0000c:   e59ff014    ldr pc, [pc, #20]   ; 23e00028 <_prefetch_abort>
23e00010:   e59ff014    ldr pc, [pc, #20]   ; 23e0002c <_data_abort>
23e00014:   e59ff014    ldr pc, [pc, #20]   ; 23e00030 <_not_used>
23e00018:   e59ff014    ldr pc, [pc, #20]   ; 23e00034 <_irq> 
23e0001c:   e59ff014    ldr pc, [pc, #20]   ; 23e00038 <_fiq> 

// 可以看出以下是異常終端向量表
23e00020 <_undefined_instruction>:
23e00020:   23e00060    mvncs   r0, #96 ; 0x60 
// 其中，23e00020存放的是未定義指令處理函式的地址，也就是23e00060
// 以下以此類推

23e00024 <_software_interrupt>:
23e00024:   23e000c0    mvncs   r0, #192    ; 0xc0 

23e00028 <_prefetch_abort>:
23e00028:   23e00120    mvncs   r0, #8 

23e0002c <_data_abort>:
23e0002c:   23e00180    mvncs   r0, #32

23e00030 <_not_used>:
23e00030:   23e001e0    mvncs   r0, #56 ; 0x38 

23e00034 <_irq>:
23e00034:   23e00240    mvncs   r0, #4 

23e00038 <_fiq>:
23e00038:   23e002a0    mvncs   r0, #10
23e0003c:   deadbeef    cdple   14, 10, cr11, cr13, cr15, {7}

3、符號表中需要注意的符號

前面我們說過了在tiny210中把連線地址設定為0x23e00000。 project-x/build/out/u-boot/spl/u-boot.map

Linker script and memory map

Address of section .text set to 0x23e00000
.text           0x23e00000    0x29b28
 *(.__image_copy_start)
 .__image_copy_start
                0x23e00000        0x0 arch/arm/lib/built-in.o
                0x23e00000                __image_copy_start
 *(.vectors)
 .vectors       0x23e00000      0x300 arch/arm/lib/built-in.o
                0x23e00000                _start
                0x23e00020                _undefined_instruction
                0x23e00024                _software_interrupt
                0x23e00028                _prefetch_abort
                0x23e0002c                _data_abort
                0x23e00030                _not_used
                0x23e00034                _irq
                0x23e00038                _fiq
                0x23e00040                IRQ_STACK_START_IN
 *(.__image_copy_end)
 .__image_copy_end
                0x23e36b78        0x0 arch/arm/lib/built-in.o
 *(.__rel_dyn_start)
 .__rel_dyn_start
                0x23e36b78        0x0 arch/arm/lib/built-in.o
 *(.__rel_dyn_end)
 .__rel_dyn_end
                0x23e3cbb8        0x0 arch/arm/lib/built-in.o
                0x23e3cbb8                _image_binary_end = .
 *(.__bss_start)
 .__bss_start   0x23e36b78        0x0 arch/arm/lib/built-in.o
                0x23e36b78                __bss_start
 .__bss_end     0x23e6b514        0x0 arch/arm/lib/built-in.o
                0x23e6b514                __bss_end

重點關注 * __image_copy_start & __image_copy_end 界定了程式碼空間的位置，用於重定向程式碼的時候使用，在uboot relocate的過程中，需要把這部分拷貝到uboot的新的地址空間中，後續在新地址空間中執行。具體可以參考《[uboot] （番外篇）uboot relocation介紹》。 * _start 在u-boot-spl.lds中ENTRY(_start)，也就規定了程式碼的入口函式是_start。所以後續分析程式碼的時候就是從這裡開始分析。 * __rel_dyn_start & __rel_dyn_end 由連結器生成，存放了絕對地址符號的label的地址，用於修改uboot relocate過程中修改絕對地址符號的label的值。 具體可以參考《[uboot] （番外篇）uboot relocation介紹》。 * _image_binary_end

綜上，u-boot的編譯就完成了。

[uboot] （第四章）uboot流程——uboot編譯流程

一、uboot編譯和生成檔案

0、說明

1、編譯方法

2、生成檔案

二、uboot編譯流程

1、編譯整體流程

2、具體編譯流程分析

三、一些重點定義

四、uboot連結指令碼說明

1、連線指令碼整體分析

2、以下以.vectors段做說明，

3、符號表中需要注意的符號

[uboot] （第四章）uboot流程——uboot編譯流程

[uboot] （第五章）uboot流程——uboot啟動流程

[uboot] （第六章）uboot流程——命令列模式以及命令處理介紹

[uboot] （第三章）uboot流程——uboot-spl程式碼流程

python 3.5學習筆記（第四章）

java-web學習筆記（第四章）

Linux內核設計與實現總結筆記（第四章）進程調度

從《java程式設計基礎》開始學習（第四章），學會了if判斷語句，以及快捷判斷賦值

javascript高階程式設計學習筆記（第四章）

C++ Primer 學習（第四章）

Mastering_Rust(譯)：型別（第四章）（未完待續）

為什麼我要放棄javaScript資料結構與演算法（第四章）—— 佇列

Linux知識要點大全（第四章）

不測的祕密：精準測試之路----讀書筆記（第四章）

【無私分享：ASP.NET CORE 專案實戰（第四章）】Code First 建立資料庫和資料表

作業系統概念（第四章）執行緒

Python程式設計：從入門到實踐的動手試一試答案（第四章）

java 程式設計思想課後題（第四章）

從paxos到zookeeper讀書筆記（第四章）

實戰SpringCloud響應式微服務系列教程（第四章）

[uboot] （第四章）uboot流程——uboot編譯流程

一、uboot編譯和生成檔案

0、說明

1、編譯方法

2、生成檔案

二、uboot編譯流程

1、編譯整體流程

2、具體編譯流程分析

三、一些重點定義

四、uboot連結指令碼說明

1、連線指令碼整體分析

2、以下以.vectors段做說明，

3、符號表中需要注意的符號

相關推薦