2.1       U-Boot Makefile分析

2.1.1             U-Boot編譯命令

       對於mini2440開發板，編譯U-Boot需要執行如下的命令：

$  make  mini2440_config

$  make  all

       使用上面的命令編譯U-Boot，編譯生成的所有檔案都儲存在原始碼目錄中。為了保持原始碼目錄的乾淨，可以使用如下命令將編譯生成的檔案輸出到一個外部目錄，而不是在原始碼目錄中，下面的2種方法都將編譯生成的檔案輸出到 /tmp/build目錄：

$  export  BUILD_DIR=/tmp/build

$  make  mini2440_config

$  make  all

或

$  make  O=/tmp/build  mini2440_config  （注意是字母O，而不是數字0）

$  make  all

       為了簡化分析過程，方便讀者理解，這裡主要針對第一種編譯方式（目標輸出到原始碼所在目錄）進行分析。

2.1.2             U-Boot配置、編譯、連線過程

       U-Boot開頭有一些跟主機軟硬體環境相關的程式碼，在每次執行make命令時這些程式碼都被執行一次。

1. 1.      U-Boot 配置過程

（1）定義主機系統架構

HOSTARCH := $(shell uname -m | \

       sed -e s/i.86/i386/ \

           -e s/sun4u/sparc64/ \

           -e s/arm.*/arm/ \

           -e s/sa110/arm/ \

           -e s/powerpc/ppc/ \

           -e s/ppc64/ppc/ \

           -e s/macppc/ppc/)

       “sed –e”表示後面跟的是一串命令指令碼，而表示式“s/abc/def/”表示要從標準輸入中，查詢到內容為“abc”的，然後替換成“def”。其中“abc”表示式用可以使用“.”作為萬用字元。

       命令“uname –m”將輸出主機CPU的體系架構型別。作者的電腦使用Intel Core2系列的CPU，因此“uname –m”輸出“i686”。 “i686”可以匹配命令“sed -e s/i.86/i386/”中的“i.86”，因此在作者的機器上執行Makefile，HOSTARCH將被設定成“i386” 。

（2）定義主機作業系統型別

HOSTOS := $(shell uname -s | tr '[:upper:]' '[:lower:]' | \

           sed -e 's/\(cygwin\).*/cygwin/')

       “uname –s”輸出主機核心名字，作者使用Linux發行版Ubuntu9.10，因此“uname –s”結果是“Linux”。“tr '[:upper:]' '[:lower:]'”作用是將標準輸入中的所有大寫字母轉換為響應的小寫字母。因此執行結果是將HOSTOS 設定為“linux”。

（3）定義執行shell指令碼的shell

# Set shell to bash if possible, otherwise fall back to sh

SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \

       else if [ -x /bin/bash ]; then echo /bin/bash; \

       else echo sh; fi; fi)

       "$$BASH"的作用實質上是生成了字串“$BASH”（前一個$號的作用是指明第二個$是普通的字元）。若執行當前Makefile的shell中定義了“$BASH”環境變數，且檔案“$BASH”是可執行檔案，則SHELL的值為“$BASH”。否則，若“/bin/bash”是可執行檔案，則SHELL值為“/bin/bash”。若以上兩條都不成立，則將“sh”賦值給SHELL變數。

       由於作者的機器安裝了bash shell，且shell預設環境變數中定義了“$BASH”，因此SHELL 被設定為$BASH 。

（4）設定編譯輸出目錄

ifdef O

ifeq ("$(origin O)", "command line")

BUILD_DIR := $(O)

endif

endif

       函式$( origin, variable) 輸出的結果是一個字串，輸出結果由變數variable定義的方式決定，若variable在命令列中定義過，則origin函式返回值為"command line"。假若在命令列中執行了“export BUILD_DIR=/tmp/build”的命令，則“$(origin O)”值為“command line”，而BUILD_DIR被設定為“/tmp/build”。

ifneq ($(BUILD_DIR),)

saved-output := $(BUILD_DIR)

# Attempt to create a output directory.

$(shell [ -d ${BUILD_DIR} ] || mkdir -p ${BUILD_DIR})

       若${BUILD_DIR}表示的目錄沒有定義，則建立該目錄。

# Verify if it was successful.

BUILD_DIR := $(shell cd $(BUILD_DIR) && /bin/pwd)

$(if $(BUILD_DIR),,$(error output directory "$(saved-output)" does not exist))

endif # ifneq ($(BUILD_DIR),)

       若$(BUILD_DIR)為空，則將其賦值為當前目錄路徑（原始碼目錄）。並檢查$(BUILD_DIR)目錄是否存在。

OBJTREE           := $(if $(BUILD_DIR),$(BUILD_DIR),$(CURDIR))

SRCTREE          := $(CURDIR)

TOPDIR             := $(SRCTREE)

LNDIR        := $(OBJTREE)

… …

MKCONFIG      := $(SRCTREE)/mkconfig

… …

ifneq ($(OBJTREE),$(SRCTREE))

obj := $(OBJTREE)/

src := $(SRCTREE)/

else

obj :=

src :=

endif

       CURDIR變數指示Make當前的工作目錄，由於當前Make在U-Boot頂層目錄執行Makefile，因此CURDIR此時就是U-Boot頂層目錄。

       執行完上面的程式碼後， SRCTREE，src變數就是U-Boot程式碼頂層目錄，而OBJTREE，obj變數就是輸出目錄，若沒有定義BUILD_DIR環境變數，則SRCTREE，src變數與OBJTREE，obj變數都是U-Boot原始碼目錄。而MKCONFIG則表示U-Boot根目錄下的mkconfig指令碼。

1. 2.      make mini2440_config命令執行過程

       下面分析命令“make mini2440_config”執行過程，為了簡化分析過程這裡主要分析將編譯目標輸出到原始碼目錄的情況。

mini2440_config :      unconfig

       @$(MKCONFIG) $(@:_config=) arm arm920t mini2440 samsung s3c24x0

       其中的依賴“unconfig”定義如下：

unconfig:

       @rm -f $(obj)include/config.h $(obj)include/config.mk \

              $(obj)board/*/config.tmp $(obj)board/*/*/config.tmp \

              $(obj)include/autoconf.mk $(obj)include/autoconf.mk.dep

        其中“@”的作用是執行該命令時不在shell顯示。“obj”變數就是編譯輸出的目錄，因此“unconfig”的作用就是清除上次執行make *_config命令生成的配置檔案（如include/config.h，include/config.mk等）。

       $(MKCONFIG)在上面指定為“$(SRCTREE)/mkconfig”。$(@:_config=)為將傳進來的所有引數中的_config替換為空（其中“@”指規則的目標檔名，在這裡就是“mini2440_config ”。$(text:patternA=patternB)，這樣的語法表示把text變數每一個元素中結尾的patternA的文字替換為patternB，然後輸出） 。因此$(@:_config=)的作用就是將mini2440_config中的_config去掉，得到mini2440。

       因此“@$(MKCONFIG) $(@:_config=) arm arm920t mini2440 samsung s3c24x0”實際上就是執行了如下命令：

./mkconfig mini2440 arm arm920t mini2440 samsung s3c24x0

       即將“mini2440 arm arm920t mini2440 samsung s3c24x0”作為引數傳遞給當前目錄下的mkconfig指令碼執行。

       在mkconfig指令碼中給出了mkconfig的用法：

# Parameters:  Target  Architecture  CPU  Board [VENDOR] [SOC]

       因此傳遞給mkconfig的引數的意義分別是：

mini2440：Target（目標板型號）

arm：Architecture （目標板的CPU架構）

arm920t：CPU （具體使用的CPU型號）

mini2440：Board

samsung：VENDOR（生產廠家名）

s3c24x0：SOC

       下面再來看看mkconfig指令碼到底做了什麼。

（1）確定開發板名稱BOARD_NAME

       在mkconfig指令碼中有如下程式碼：

APPEND=no      # no表示建立新的配置檔案，yes表示追加到配置檔案中

BOARD_NAME="" # Name to print in make output

TARGETS=""

while [ $# -gt 0 ] ; do

    case "$1" in

    --) shift ; break ;;

    -a) shift ; APPEND=yes ;;

    -n) shift ; BOARD_NAME="${1%%_config}" ; shift ;;

    -t) shift ; TARGETS="`echo $1 | sed 's:_: :g'` ${TARGETS}" ; shift ;;

    *)  break ;;

    esac

done

[ "${BOARD_NAME}" ] || BOARD_NAME="$1" 

       環境變數$#表示傳遞給指令碼的引數個數，這裡的命令有6個引數，因此$#是6 。shift的作用是使$1=$2，$2=$3，$3=$4….，而原來的$1將丟失。因此while迴圈的作用是，依次處理傳遞給mkconfig指令碼的選項。由於我們並沒有傳遞給mkconfig任何的選項，因此while迴圈中的程式碼不起作用。

       最後將BOARD_NAME的值設定為$1的值，在這裡就是“mini2440”。

（2）檢查引數合法性

[ $# -lt 4 ] && exit 1

[ $# -gt 6 ] && exit 1

if [ "${ARCH}" -a "${ARCH}" != "$2" ]; then

       echo "Failed: \$ARCH=${ARCH}, should be '$2' for ${BOARD_NAME}" 1>&2

       exit 1

fi

       上面程式碼的作用是檢查引數個數和引數是否正確，引數個數少於4個或多於6個都被認為是錯誤的。

（3）建立到目標板相關的目錄的連結

#

# Create link to architecture specific headers

#

if [ "$SRCTREE" != "$OBJTREE" ] ; then         #若編譯目標輸出到外部目錄，則下面的程式碼有效

       mkdir -p ${OBJTREE}/include

       mkdir -p ${OBJTREE}/include2

       cd ${OBJTREE}/include2

       rm -f asm

       ln -s ${SRCTREE}/include/asm-$2 asm

       LNPREFIX="http://www.cnblogs.com/include2/asm/"

       cd ../include

       rm -rf asm-$2

       rm -f asm

       mkdir asm-$2

       ln -s asm-$2 asm

else              

       cd ./include

       rm -f asm

       ln -s asm-$2 asm

fi

       若將目標檔案設定為輸出到原始檔所在目錄，則以上程式碼在include目錄下建立了到asm-arm目錄的符號連結asm。其中的ln -s asm-$2 asm即ln -s asm-arm asm 。

rm -f asm-$2/arch

if [ -z "$6" -o "$6" = "NULL" ] ; then

       ln -s ${LNPREFIX}arch-$3 asm-$2/arch

else

       ln -s ${LNPREFIX}arch-$6 asm-$2/arch

fi

       建立符號連結include/asm-arm/arch ，若$6（SOC）為空，則使其連結到include/asm-arm/arch-arm920t目錄，否則就使其連結到include/asm-arm/arch-s3c24x0目錄。（事實上include/asm-arm/arch-arm920t並不存在，因此$6是不能為空的，否則會編譯失敗）

if [ "$2" = "arm" ] ; then

       rm -f asm-$2/proc

       ln -s ${LNPREFIX}proc-armv asm-$2/proc

fi

       若目標板是arm架構，則上面的程式碼將建立符號連線include/asm-arm/proc，使其連結到目錄proc-armv目錄。

       建立以上的連結的好處：編譯U-Boot時直接進入連結檔案指向的目錄進行編譯，而不必根據不同開發板來選擇不同目錄。

（4）構建include/config.mk檔案

#

# Create include file for Make

#

echo "ARCH   = $2" >  config.mk

echo "CPU    = $3" >> config.mk

echo "BOARD  = $4" >> config.mk

[ "$5" ] && [ "$5" != "NULL" ] && echo "VENDOR = $5" >> config.mk

[ "$6" ] && [ "$6" != "NULL" ] && echo "SOC    = $6" >> config.mk

       上面程式碼將會把如下內容寫入檔案inlcude/config.mk檔案：

ARCH   = arm

CPU    = arm920t

BOARD  = mini2440

VENDOR = samsung

SOC    = s3c24x0

（5）指定開發板程式碼所在目錄

# Assign board directory to BOARDIR variable

if [ -z "$5" -o "$5" = "NULL" ] ; then

    BOARDDIR=$4

else

    BOARDDIR=$5/$4

fi

       以上程式碼指定board目錄下的一個目錄為當前開發板專有程式碼的目錄。若$5（VENDOR）為空則BOARDDIR設定為$4（BOARD），否則設定為$5/$4（VENDOR/BOARD）。在這裡由於$5不為空，因此BOARDDIR被設定為samsung/mini2440 。

（6）構建include/config.h檔案

#

# Create board specific header file

#

if [ "$APPEND" = "yes" ] # Append to existing config file

then

       echo >> config.h

else

       > config.h            # Create new config file

fi

echo "/* Automatically generated - do not edit */" >>config.h

for i in ${TARGETS} ; do

       echo "#define CONFIG_MK_${i} 1" >>config.h ;

done

cat << EOF >> config.h

#define CONFIG_BOARDDIR board/$BOARDDIR

#include <config_defaults.h>

#include <configs/$1.h>

#include <asm/config.h>

EOF

exit 0

       這裡的“cat << EOF >> config.h”表示將輸入的內容追加到config.h中，直到出現“EOF”這樣的標識為止。

       若APPEND為no，則建立新的include/config.h檔案。若APPEND為yes，則將新的配置內容追加到include/config.h檔案後面。由於APPEND的值保持“no”，因此config.h被建立了，並添加了如下的內容：

       /* Automatically generated - do not edit */

       #define CONFIG_BOARDDIR board/samsung/mini2440

       #include <config_defaults.h>

       #include <configs/mini2440.h>

       #include <asm/config.h>

       下面總結命令make mini2440_config執行的結果（僅針對編譯目標輸出到原始碼目錄的情況）：

（1）    建立到目標板相關的檔案的連結

       ln -s asm-arm asm

       ln -s arch-s3c24x0 asm-arm/arch

       ln -s proc-armv asm-arm/proc

（2）    建立include/config.mk檔案，內容如下所示：

       ARCH   = arm

       CPU    = arm920t

       BOARD  = mini2440

       VENDOR = samsung

       SOC    = s3c24x0

（3）    建立與目標板相關的檔案include/config.h，如下所示：

       /* Automatically generated - do not edit */

       #define CONFIG_BOARDDIR board/samsung/mini2440

       #include <config_defaults.h>

       #include <configs/mini2440.h>

       #include <asm/config.h>

1. 3.      make all命令執行過程

       若沒有執行過“make <board_name>_config”命令就直接執行“make all”命令則會出現如下的才錯誤資訊，然後停止編譯：

       System not configured - see README

       U-Boot是如何知道使用者沒有執行過“make <board_name>_config”命令的呢？閱讀U-Boot原始碼就可以發現了，Makefile中有如下程式碼：

ifeq ($(obj)include/config.mk,$(wildcard $(obj)include/config.mk)) # config.mk存在

all: 

sinclude $(obj)include/autoconf.mk.dep

sinclude $(obj)include/autoconf.mk

… …

else        # config.mk不存在

… …

       @echo "System not configured - see README" >&2

       @ exit 1

… …

endif      # config.mk

       若include/config.mk 檔案存在，則$(wildcard $(obj)include/config.mk) 命令執行的結果是“$(obj)include/config.mk”展開的字串，否則結果為空。由於include/config.mk是“make <board_name>_config”命令執行過程生成的，若從沒有執行過“make <board_name>_config”命令則include/config.mk必然不存在。因此Make就執行else分支的程式碼，在輸出“System not configured - see README”的資訊後就返回了。

       下面再來分析“make all”命令正常執行的過程，在Makefile中有如下程式碼：

（1）include/autoconf.mk生成過程

all:

sinclude $(obj)include/autoconf.mk.dep

sinclude $(obj)include/autoconf.mk

       include/autoconf.mk檔案中是與開發板相關的一些巨集定義，在Makefile執行過程中需要根據某些巨集來確定執行哪些操作。下面簡要分析include/autoconf.mk生成的過程，include/autoconf.mk生成的規則如下：

$(obj)include/autoconf.mk: $(obj)include/config.h

       @$(XECHO) Generating [email protected] ; \

       set -e ; \

       : Extract the config macros ; \

       $(CPP) $(CFLAGS) -DDO_DEPS_ONLY -dM include/common.h | \

              sed -n -f tools/scripts/define2mk.sed > [email protected] && \

       mv [email protected] [email protected]

       include/autoconf.mk依賴於make <board_name>_config 命令生成的include/config.h。因此執行make <board_name>_config命令後再執行make all將更新include/autoconf.mk。

       編譯選項“-dM”的作用是輸出include/common.h中定義的所有巨集。根據上面的規則，編譯器提取include/common.h中定義的巨集，然後輸出給tools/scripts/define2mk.sed指令碼處理，處理的結果就是include/autoconf.mk檔案。其中tools/scripts/define2mk.sed指令碼的主要完成了在include/common.h中查詢和處理以“CONFIG_”開頭的巨集定義的功能。

       include/common.h檔案包含了include/config.h檔案，而include/config.h檔案又包含了config_defaults.h，configs/mini2440.h，asm/config.h檔案。因此include/autoconf.mk實質上就是config_defaults.h，configs/mini2440.h，asm/config.h三個檔案中“CONFIG_”開頭的有效的巨集定義的集合。

       下面接著分析Makefile的執行。

# load ARCH, BOARD, and CPU configuration

include $(obj)include/config.mk

export    ARCH CPU BOARD VENDOR SOC

       將make mini2440_config命令生成的include/config.mk包含進來。

# 若主機架構與開發板結構相同，就使用主機的編譯器，而不是交叉編譯器

ifeq ($(HOSTARCH),$(ARCH))

CROSS_COMPILE ?=

endif

       若主機與目標機器體系架構相同，則使用gcc編譯器而不是交叉編譯器。

# load other configuration

include $(TOPDIR)/config.mk

       最後將U-Boot頂層目錄下的config.mk檔案包含進來，該檔案包含了對編譯的一些設定。下面對U-Boot頂層目錄下的config.mk檔案進行分析：

（2）config.mk檔案執行過程

1設定obj與src

       在U-Boot頂層目錄下的config.mk檔案中有如下程式碼：

ifneq ($(OBJTREE),$(SRCTREE))

ifeq ($(CURDIR),$(SRCTREE))

dir :=

else

dir := $(subst $(SRCTREE)/,,$(CURDIR))

endif

obj := $(if $(dir),$(OBJTREE)/$(dir)/,$(OBJTREE)/)

src := $(if $(dir),$(SRCTREE)/$(dir)/,$(SRCTREE)/)

$(shell mkdir -p $(obj))

else

obj :=

src :=

endif

       由於目標輸出到原始碼目錄下，因此執行完上面的程式碼後，src和obj都是空。

2設定編譯選項

PLATFORM_RELFLAGS =

PLATFORM_CPPFLAGS =          #編譯選項

PLATFORM_LDFLAGS =           #連線選項

       用這3個變量表示交叉編譯器的編譯選項，在後面Make會檢查交叉編譯器支援的編譯選項，然後將適當的選項新增到這3個變數中。

#

# Option checker (courtesy linux kernel) to ensure

# only supported compiler options are used

#

cc-option = $(shell if $(CC) $(CFLAGS) $(1) -S -o /dev/null -xc /dev/null \

              > /dev/null 2>&1; then echo "$(1)"; else echo "$(2)"; fi ;)

       變數CC和CFLAGS在後面的程式碼定義為延時變數，其中的CC即arm-linux-gcc。函式cc-option用於檢查編譯器CC是否支援某選項。將2個選項作為引數傳遞給cc-option函式，該函式呼叫CC編譯器檢查引數1是否支援，若支援則函式返回引數1，否則返回引數2 （因此CC編譯器必須支援引數1或引數2，若兩個都不支援則會編譯出錯）。可以像下面這樣呼叫cc-option函式，並將支援的選項新增到FLAGS中：

FLAGS +=$(call cc-option,option1,option2)

3指定交叉編譯工具

#

# Include the make variables (CC, etc...)

#

AS  = $(CROSS_COMPILE)as

LD  = $(CROSS_COMPILE)ld

CC  = $(CROSS_COMPILE)gcc

CPP       = $(CC) -E

AR = $(CROSS_COMPILE)ar

NM = $(CROSS_COMPILE)nm

LDR      = $(CROSS_COMPILE)ldr

STRIP   = $(CROSS_COMPILE)strip

OBJCOPY = $(CROSS_COMPILE)objcopy

OBJDUMP = $(CROSS_COMPILE)objdump

RANLIB      = $(CROSS_COMPILE)RANLIB

       對於arm開發板，其中的CROSS_COMPILE在lib_arm/config.mk檔案中定義：

CROSS_COMPILE ?= arm-linux-

       因此以上程式碼指定了使用字首為“arm-linux-”的編譯工具，即arm-linux-gcc，arm-linux-ld等等。

4包含與開發板相關的配置檔案

# Load generated board configuration

sinclude $(OBJTREE)/include/autoconf.mk

ifdef      ARCH

sinclude $(TOPDIR)/lib_$(ARCH)/config.mk   # include architecture dependend rules

endif

       $(ARCH)的值是“arm”，因此將“lib_arm/config.mk”包含進來。lib_arm/config.mk指令碼指定了交叉編譯器，添加了一些跟CPU架構相關的編譯選項，最後還指定了cpu/arm920t/u-boot.lds為U-Boot的連線指令碼。

ifdef      CPU

sinclude $(TOPDIR)/cpu/$(CPU)/config.mk             # include  CPU specific rules

endif

       $(CPU)的值是“arm920t”，因此將“cpu/arm920t/config.mk”包含進來。這個指令碼主要設定了跟arm920t處理器相關的編譯選項。

ifdef      SOC

sinclude $(TOPDIR)/cpu/$(CPU)/$(SOC)/config.mk       # include  SoC  specific rules

endif

       $(SOC)的值是s3c24x0，因此Make程式嘗試將cpu/arm920t/s3c24x0/config.mk包含進來，而這個檔案並不存在，但是由於用的是“sinclude”命令，所以並不會報錯。

ifdef      VENDOR

BOARDDIR = $(VENDOR)/$(BOARD)

else

BOARDDIR = $(BOARD)

endif

       $(BOARD)的值是mini2440，VENDOR的值是samsung，因此BOARDDIR的值是samsung/mini2440。BOARDDIR變量表示開發板特有的程式碼所在的目錄。

ifdef      BOARD

sinclude $(TOPDIR)/board/$(BOARDDIR)/config.mk   # include board specific rules

endif

       Make將“board/samsung/mini2440/config.mk”包含進來。該指令碼只有如下的一行程式碼：

TEXT_BASE = 0x33F80000

       U-Boot編譯時將使用TEXT_BASE作為程式碼段連線的起始地址。

LDFLAGS += -Bstatic -T $(obj)u-boot.lds $(PLATFORM_LDFLAGS)

ifneq ($(TEXT_BASE),)

LDFLAGS += -Ttext $(TEXT_BASE)

endif

       執行完以上程式碼後，LDFLAGS中包含了“-Bstatic -T u-boot.lds ”和“-Ttext 0x33F80000”的字樣。

5指定隱含的編譯規則

# Allow boards to use custom optimize flags on a per dir/file basis

BCURDIR := $(notdir $(CURDIR))

$(obj)%.s:     %.S

       $(CPP) $(AFLAGS) $(AFLAGS_$(@F)) $(AFLAGS_$(BCURDIR)) -o [email protected] $<

$(obj)%.o:    %.S

       $(CC)  $(AFLAGS) $(AFLAGS_$(@F)) $(AFLAGS_$(BCURDIR)) -o [email protected] $< -c

$(obj)%.o:    %.c

       $(CC)  $(CFLAGS) $(CFLAGS_$(@F)) $(CFLAGS_$(BCURDIR)) -o [email protected] $< -c

$(obj)%.i:     %.c

       $(CPP) $(CFLAGS) $(CFLAGS_$(@F)) $(CFLAGS_$(BCURDIR)) -o [email protected] $< -c

$(obj)%.s:     %.c

       $(CC)  $(CFLAGS) $(CFLAGS_$(@F)) $(CFLAGS_$(BCURDIR)) -o [email protected] $< -c -S

       例如：根據以上的定義，以“.s”結尾的目標檔案將根據第一條規則由同名但字尾為“.S”的原始檔來生成，若不存在“.S”結尾的同名檔案則根據最後一條規則由同名的“.c”檔案生成。

下面回來接著分析Makefile的內容：

# U-Boot objects....order is important (i.e. start must be first)

OBJS  = cpu/$(CPU)/start.o

LIBS += cpu/$(CPU)/lib$(CPU).a

ifdef SOC

LIBS += cpu/$(CPU)/$(SOC)/lib$(SOC).a

endif

ifeq ($(CPU),ixp)

LIBS += cpu/ixp/npe/libnpe.a

endif

LIBS += lib_$(ARCH)/lib$(ARCH).a

LIBS += fs/cramfs/libcramfs.a fs/fat/libfat.a fs/fdos/libfdos.a fs/jffs2/libjffs2.a \

       fs/reiserfs/libreiserfs.a fs/ext2/libext2fs.a fs/yaffs2/libyaffs2.a \

       fs/ubifs/libubifs.a

… …

LIBS += common/libcommon.a

LIBS += libfdt/libfdt.a

LIBS += api/libapi.a

LIBS += post/libpost.a

LIBS := $(addprefix $(obj),$(LIBS))

       LIBS變數指明瞭U-Boot需要的庫檔案，包括平臺/開發板相關的目錄、通用目錄下相應的庫，都通過相應的子目錄編譯得到的。

       對於mini2440開發板，以上跟平臺相關的有以下幾個：

cpu/$(CPU)/start.o

board/$(VENDOR)/common/lib$(VENDOR).a

cpu/$(CPU)/lib$(CPU).a

cpu/$(CPU)/$(SOC)/lib$(SOC).a

lib_$(ARCH)/lib$(ARCH).a

       其餘都是與平臺無關的。

ifeq ($(CONFIG_NAND_U_BOOT),y)

NAND_SPL = nand_spl

U_BOOT_NAND = $(obj)u-boot-nand.bin

endif

ifeq ($(CONFIG_ONENAND_U_BOOT),y)

ONENAND_IPL = onenand_ipl

U_BOOT_ONENAND = $(obj)u-boot-onenand.bin

ONENAND_BIN ?= $(obj)onenand_ipl/onenand-ipl-2k.bin

endif

       對於有的開發板，U-Boot支援在NAND Flash啟動，這些開發板的配置檔案定義了CONFIG_NAND_U_BOOT，CONFIG_ONENAND_U_BOOT。對於s3c2440，U-Boot原始程式碼並不支援NAND Flash啟動，因此也沒有定義這兩個巨集。

ALL += $(obj)u-boot.srec $(obj)u-boot.bin $(obj)System.map $(U_BOOT_NAND) $(U_BOOT_ONENAND)

all:         $(ALL)

       其中U_BOOT_NAND與U_BOOT_ONENAND 為空，而u-boot.srec，u-boot.bin，System.map都依賴與u-boot。因此執行“make all”命令將生成u-boot，u-boot.srec，u-boot.bin，System.map 。其中u-boot是ELF檔案，u-boot.srec是Motorola S-Record format檔案，System.map 是U-Boot的符號表，u-boot.bin是最終燒寫到開發板的二進位制可執行的檔案。

       下面再來分析u-boot.bin檔案生成的過程。ELF格式“u-boot”檔案生成規則如下：

$(obj)u-boot:       depend $(SUBDIRS) $(OBJS) $(LIBBOARD) $(LIBS) $(LDSCRIPT) $(obj)u-boot.lds

              $(GEN_UBOOT)

ifeq ($(CONFIG_KALLSYMS),y)

              smap=`$(call SYSTEM_MAP,u-boot) | \

                     awk '$$2 ~ /[tTwW]/ {printf $$1 $$3 "\\\\000"}'` ; \

              $(CC) $(CFLAGS) -DSYSTEM_MAP="\"$${smap}\"" \

                     -c common/system_map.c -o $(obj)common/system_map.o

              $(GEN_UBOOT) $(obj)common/system_map.o

endif

       這裡生成的$(obj)u-boot目標就是ELF格式的U-Boot檔案了。由於CONFIG_KALLSYMS未定義，因此ifeq ($(CONFIG_KALLSYMS),y)與endif間的程式碼不起作用。

       其中depend，$(SUBDIRS)，$(OBJS)，$(LIBBOARD)，$(LIBS)，$(LDSCRIPT)， $(obj)u-boot.lds是$(obj)u-boot的依賴，而$(GEN_UBOOT)編譯命令。

下面分析$(obj)u-boot的各個依賴：

1依賴目標depend

# Explicitly make _depend in subdirs containing multiple targets to prevent

# parallel sub-makes creating .depend files simultaneously.

depend dep: $(TIMESTAMP_FILE) $(VERSION_FILE) $(obj)include/autoconf.mk

              for dir in $(SUBDIRS) cpu/$(CPU) $(dir $(LDSCRIPT)) ; do \

                     $(MAKE) -C $$dir _depend ; done

對於$(SUBDIRS)，cpu/$(CPU)，$(dir $(LDSCRIPT))中的每個元素都進入該目錄執行“make _depend”，生成各個子目錄的.depend檔案，.depend列出每個目標檔案的依賴檔案。

       2依賴SUBDIRS

       SUBDIRS    = tools \

         examples/standalone \

         examples/api

       $(SUBDIRS):     depend

                     $(MAKE) -C [email protected] all

       執行tools ，examples/standalone ，examples/api目錄下的Makefile。

       3OBJS

       OBJS的值是“cpu/arm920t/start.o”。它使用如下程式碼編譯得到：

$(OBJS):      depend

       $(MAKE) -C cpu/$(CPU) $(if $(REMOTE_BUILD),[email protected],$(notdir [email protected]))

       以上規則表明，對於OBJS包含的每個成員，都進入cpu/$(CPU)目錄（即cpu/arm920t）編譯它們。

4LIBBOARD

LIBBOARD = board/$(BOARDDIR)/lib$(BOARD).a

LIBBOARD := $(addprefix $(obj),$(LIBBOARD))

… …

$(LIBBOARD): depend $(LIBS)

              $(MAKE) -C $(dir $(subst $(obj),,[email protected]))

       這裡LIBBOARD的值是 $(obj)board/samsung/mini2440/libmini2440.a。make執行board/samsung/mini2440/目錄下的Makefile，生成libmini2440.a 。

       5LIBS

       LIBS變數中的每個元素使用如下的規則編譯得到：

$(LIBS):       depend $(SUBDIRS)

              $(MAKE) -C $(dir $(subst $(obj),,[email protected]))

       上面的規則表明，對於LIBS中的每個成員，都進入相應的子目錄執行“make”命令編譯它們。例如對於LIBS中的“common/libcommon.a”成員，程式將進入common目錄執行Makefile，生成libcommon.a 。

6LDSCRIPT

LDSCRIPT := $(SRCTREE)/cpu/$(CPU)/u-boot.lds

… …

$(LDSCRIPT):   depend

              $(MAKE) -C $(dir [email protected]) $(notdir [email protected])

       “$(MAKE) -C $(dir [email protected]) $(notdir [email protected])”命令經過變數替換後就是“make -C cpu/arm920t/  u-boot.lds”。也就是轉到cpu/arm920t/目錄下，執行“make u-boot.lds”命令。

7$(obj)u-boot.lds

$(obj)u-boot.lds: $(LDSCRIPT)

              $(CPP) $(CPPFLAGS) $(LDPPFLAGS) -ansi -D__ASSEMBLY__ -P - <$^ >[email protected]

       以上執行結果實質上是將cpu/arm920t/u-boot.lds經編譯器簡單預處理後輸出到U-Boot頂層目錄下的u-boot.lds檔案。其中的cpu/arm920t/u-boot.lds檔案內容如下：

/* 輸出為ELF檔案，小端方式， */

OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")

OUTPUT_ARCH(arm)   

ENTRY(_start)

SECTIONS

{

       . = 0x00000000;

       . = ALIGN(4);

       .text :

       {

/* cpu/arm920t/start.o放在最前面，保證最先執行的是start.o */

                     cpu/arm920t/start.o    (.text)

/*以下2個檔案必須放在前4K，因此也放在前面，其中board/samsung/mini2440/lowlevel_init.o 包含記憶體初始化所需程式碼，而 board/samsung/mini2440/nand_read.o 包含U-Boot從NAND Flash搬運自身的程式碼 */

                board/samsung/mini2440/lowlevel_init.o (.text)

                 board/samsung/mini2440/nand_read.o (.text)

/* 其他檔案的程式碼段 */

              *(.text)

       }

/* 只讀資料段 */

       . = ALIGN(4);

       .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }

/* 程式碼段 */

       . = ALIGN(4);

       .data : { *(.data) }

/* u-boot自定義的got段 */

       . = ALIGN(4);

       .got : { *(.got) }

       . = .;

       __u_boot_cmd_start = .;          /*將 __u_boot_cmd_start指定為當前地址 */

       .u_boot_cmd : { *(.u_boot_cmd) }             /* 存放所有U-Boot命令對應的cmd_tbl_t結構體 */

       __u_boot_cmd_end = .;           /*  將__u_boot_cmd_end指定為當前地址  */

/* bss段 */

       . = ALIGN(4);

       __bss_start = .;

       .bss (NOLOAD) : { *(.bss) . = ALIGN(4); }

       _end = .;              /*  將_end指定為當前地址  */

}

       u-boot.lds實質上是U-Boot連線指令碼。對於生成的U-Boot編譯生成的“u-boot”檔案，可以使用objdump命令可以檢視它的分段資訊：

$  objdump -x u-boot | more

       部分輸出資訊如下：

u-boot:     file format elf32-little

u-boot

architecture: UNKNOWN!, flags 0x00000112:

EXEC_P, HAS_SYMS, D_PAGED

start address 0x33f80000

Program Header:

    LOAD off    0x00008000 vaddr 0x33f80000 paddr 0x33f80000 align 2**15

         filesz 0x0002f99c memsz 0x00072c94 flags rwx

   STACK off    0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**2

         filesz 0x00000000 memsz 0x00000000 flags rwx

Sections:

Idx Name          Size      VMA       LMA       File off  Algn

  0 .text         00024f50  33f80000  33f80000  00008000  2**5

                  CONTENTS, ALLOC, LOAD, READONLY, CODE

  1 .rodata       00008b78  33fa4f50  33fa4f50  0002cf50  2**3

                  CONTENTS, ALLOC, LOAD, READONLY, DATA

  2 .data         00001964  33fadac8  33fadac8  00035ac8  2**2

                  CONTENTS, ALLOC, LOAD, DATA

  3 .u_boot_cmd   00000570  33faf42c  33faf42c  0003742c  2**2

                  CONTENTS, ALLOC, LOAD, DATA

  4 .bss          00043294  33fafa00  33fafa00  0003799c  2**8

                  ALLOC

… …

       u-boot.lds還跟U-Boot啟動階段複製程式碼到RAM空間的過程以及U-Boot命令執行過程密切相關，具體請結合U-Boot原始碼理解。

       編譯命令GEN_UBOOT

GEN_UBOOT = \

              UNDEF_SYM=`$(OBJDUMP) -x $(LIBBOARD) $(LIBS) | \

              sed  -n -e 's/.*\($(SYM_PREFIX)__u_boot_cmd_.*\)/-u\1/p'|sort|uniq`;\

              cd $(LNDIR) && $(LD) $(LDFLAGS) $$UNDEF_SYM $(__OBJS) \

                     --start-group $(__LIBS) --end-group $(PLATFORM_LIBS) \

                     -Map u-boot.map -o u-boot

       以上命令使用$(LDFLAGS)作為連線指令碼，最終生成“u-boot”檔案。

u-boot.bin檔案生成過程

       生成u-boot.bin檔案的規則如下：

$(obj)u-boot.bin: $(obj)u-boot

              $(OBJCOPY) ${OBJCFLAGS} -O binary $< [email protected]

       從U-Boot編譯輸出資訊中可以知道上面的命令實質上展開為：

       arm-linux-objcopy --gap-fill=0xff -O binary u-boot u-boot.bin

       編譯命令中的“-O binary”選項指定了輸出的檔案為二進位制檔案。而“--gap-fill=0xff”選項指定使用“0xff”填充段與段間的空閒區域。這條編譯命令實現了ELF格式的U-Boot檔案到BIN格式的轉換。

System.map檔案的生成

System.map是U-Boot的符號表，它包含了U-Boot的全域性變數和函式的地址資訊。將System.map生成的規則如下：

SYSTEM_MAP = \

              $(NM) $1 | \

              grep -v '\(compiled\)\|\(\.o$$\)\|\( [aUw] \)\|\(\.\.ng$$\)\|\(LASH[RL]DI\)' | \

              LC_ALL=C sort

$(obj)System.map:     $(obj)u-boot

              @$(call SYSTEM_MAP,$<) > $(obj)System.map

arm-linux-nm u-boot | grep -v '\(compiled\)\|\(\.o$$\)\|\( [aUw] \)\|\(\.\.ng$$\)\|\(LASH[RL]DI\)' | LC_ALL=C sort  > System.map

       也就是將arm-linux-nm命令檢視u-boot的輸出資訊經過過濾和排序後輸出到System.map。為了瞭解System.map檔案的作用，開啟System.map：

33f80000 T _start

33f80020 t _undefined_instruction

33f80024 t _software_interrupt

33f80028 t _prefetch_abort

33f8002c t _data_abort

33f80030 t _not_used

33f80034 t _irq

33f80038 t _fiq

33f80040 t _TEXT_BASE

33f80044 T _armboot_start

33f80048 T _bss_start

33f8004c T _bss_end

… …

       System.map表示的是地址標號到該標號表示的地址的一個對映關係。System.map每一行的格式都是“addr type name”，addr是標號對應的地址值，name是標號名，type表示標號的型別。

     U-Boot的編譯和執行並不一定要生成System.map，這個檔案主要是提供給使用者或外部程式除錯時使用的。