電子發(fā)燒友App
一、uboot編譯和生成文件
說明
現(xiàn)在的uboot已經(jīng)做得和kernel很像，最主要的一點(diǎn)是，uboot也使用了dtb的方法，將設(shè)備樹和代碼分離開來（當(dāng)然可以通過宏來控制）。
project-x/u-boot/configs/tiny210_defconfig
CONFIG_OF_CONTROL=y
// 用于表示是否使用了dtb的方式
CONFIG_OF_SEPARATE=y
// 是否將dtb和uboot分離表一
所以在uboot的編譯中，和spl的最大區(qū)別是還要編譯dtb。 （前面我們將的spl是沒有使用dtb的，當(dāng)然好像也可以使用dtb，只是我沒有試過）。
U-Boot編譯命令
對于mini2440開發(fā)板，編譯U-Boot需要執(zhí)行如下的命令：
$ make mini2440_config
$ make all
使用上面的命令編譯U-Boot，編譯生成的所有文件都保存在源代碼目錄中。為了保持源代碼目錄的干凈，可以使用如下命令將編譯生成的文件輸出到一個(gè)外部目錄，而不是在源代碼目錄中，下面的2種方法都將編譯生成的文件輸出到 /tmp/build目錄：
$ export BUILD_DIR=/tmp/build
$ make mini2440_config
$ make all
或
$ make O=/tmp/build mini2440_config （注意是字母O，而不是數(shù)字0）
$ make all
為了簡化分析過程，方便讀者理解，這里主要針對第一種編譯方式（目標(biāo)輸出到源代碼所在目錄）進(jìn)行分析。
uboot編譯流程
編譯整體流程
根據(jù)一、2生成的文件說明可知簡單流程如下：
（1）各目錄下built-in.o的生成
源文件、代碼文件編譯、匯編目標(biāo)文件同目錄目標(biāo)文件連接built-in目標(biāo)文件
?。?）由所有built-in.o以u-boot.lds為連接腳本通過連接來生成u-boot
built-in目標(biāo)文件以u-boot.lds為連接腳本進(jìn)行統(tǒng)一連接u-boot
?。?）由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追加整合兩個(gè)文件u-boot-dtb.bin
?。?）由u-boot-dtb.bin復(fù)制生成u-boot.bin
u-boot-dtb.bin復(fù)制u-boot.bin
U-Boot配置、編譯、連接過程
U-Boot開頭有一些跟主機(jī)軟硬件環(huán)境相關(guān)的代碼，在每次執(zhí)行make命令時(shí)這些代碼都被執(zhí)行一次。
1. U-Boot配置過程
（1）定義主機(jī)系統(tǒng)架構(gòu)
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”表示后面跟的是一串命令腳本，而表達(dá)式“s/abc/def/”表示要從標(biāo)準(zhǔn)輸入中，查找到內(nèi)容為“abc”的，然后替換成“def”。其中“abc”表達(dá)式用可以使用“。”作為通配符。
命令“uname –m”將輸出主機(jī)CPU的體系架構(gòu)類型。作者的電腦使用Intel Core2系列的CPU，因此“uname–m”輸出“i686”?！癷686”可以匹配命令“sed -e s/i.86/i386/”中的“i.86”，因此在作者的機(jī)器上執(zhí)行Makefile，HOSTARCH將被設(shè)置成“i386” 。
?。?）定義主機(jī)操作系統(tǒng)類型
HOSTOS ：= $（shell uname -s | tr‘［：upper：］’ ‘［：lower：］’ | \
sed -e ‘s/cygwin.*/cygwin/’）
“uname –s”輸出主機(jī)內(nèi)核名字，作者使用Linux發(fā)行版Ubuntu9.10，因此“uname –s”結(jié)果是“Linux”。“tr ‘［：upper：］’ ‘［：lower：］’”作用是將標(biāo)準(zhǔn)輸入中的所有大寫字母轉(zhuǎn)換為響應(yīng)的小寫字母。因此執(zhí)行結(jié)果是將HOSTOS設(shè)置為“l(fā)inux”。
?。?）定義執(zhí)行shell腳本的shell
# Set shell to bash if possible， otherwisefall back to sh
SHELL ：= $（shell if ［ -x“
BASH”］;thenecho
BASH; \
elseif ［ -x /bin/bash ］; then echo /bin/bash; \
elseecho sh; fi; fi）
“$$BASH”的作用實(shí)質(zhì)上是生成了字符串“$BASH”（前一個(gè)$號的作用是指明第二個(gè)$是普通的字符）。若執(zhí)行當(dāng)前Makefile的shell中定義了“$BASH”環(huán)境變量，且文件“$BASH”是可執(zhí)行文件，則SHELL的值為“$BASH”。否則，若“/bin/bash”是可執(zhí)行文件，則SHELL值為“/bin/bash”。若以上兩條都不成立，則將“sh”賦值給SHELL變量。
由于作者的機(jī)器安裝了bash shell，且shell默認(rèn)環(huán)境變量中定義了“$BASH”，因此SHELL 被設(shè)置為$BASH 。
?。?）設(shè)定編譯輸出目錄
ifdef O
ifeq （“$（origin O）”，“command line”）
BUILD_DIR ：= $（O）
endif
endif
函數(shù)$（ origin， variable） 輸出的結(jié)果是一個(gè)字符串，輸出結(jié)果由變量variable定義的方式?jīng)Q定，若variable在命令行中定義過，則origin函數(shù)返回值為“command line”。假若在命令行中執(zhí)行了“exportBUILD_DIR=/tmp/build”的命令，則“$（origin O）”值為“command line”，而BUILD_DIR被設(shè)置為“/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}表示的目錄沒有定義，則創(chuàng)建該目錄。
# 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）為空，則將其賦值為當(dāng)前目錄路徑（源代碼目錄）。并檢查$（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當(dāng)前的工作目錄，由于當(dāng)前Make在U-Boot頂層目錄執(zhí)行Makefile，因此CURDIR此時(shí)就是U-Boot頂層目錄。
執(zhí)行完上面的代碼后， SRCTREE，src變量就是U-Boot代碼頂層目錄，而OBJTREE，obj變量就是輸出目錄，若沒有定義BUILD_DIR環(huán)境變量，則SRCTREE，src變量與OBJTREE，obj變量都是U-Boot源代碼目錄。而MKCONFIG則表示U-Boot根目錄下的mkconfig腳本。
2. makemini2440_config命令執(zhí)行過程
下面分析命令“make mini2440_config”執(zhí)行過程，為了簡化分析過程這里主要分析將編譯目標(biāo)輸出到源代碼目錄的情況。
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
其中“@”的作用是執(zhí)行該命令時(shí)不在shell顯示?！皁bj”變量就是編譯輸出的目錄，因此“unconfig”的作用就是清除上次執(zhí)行make *_config命令生成的配置文件（如include/config.h，include/config.mk等）。
$（MKCONFIG）在上面指定為“$（SRCTREE）/mkconfig”。$（@：_config=）為將傳進(jìn)來的所有參數(shù)中的_config替換為空（其中“@”指規(guī)則的目標(biāo)文件名，在這里就是“mini2440_config ”。$（text:patternA=patternB），這樣的語法表示把text變量每一個(gè)元素中結(jié)尾的patternA的文本替換為patternB，然后輸出） 。因此$（@：_config=）的作用就是將mini2440_config中的_config去掉，得到mini2440。
因此“@$（MKCONFIG） $（@：_config=） armarm920t mini2440 samsung s3c24x0”實(shí)際上就是執(zhí)行了如下命令：
。/mkconfig mini2440 arm arm920t mini2440samsung s3c24x0
即將“mini2440 arm arm920t mini2440samsung s3c24x0”作為參數(shù)傳遞給當(dāng)前目錄下的mkconfig腳本執(zhí)行。
在mkconfig腳本中給出了mkconfig的用法：
# Parameters： Target Architecture CPU Board ［VENDOR］ ［SOC］
因此傳遞給mkconfig的參數(shù)的意義分別是：
mini2440：Target（目標(biāo)板型號）
arm：Architecture （目標(biāo)板的CPU架構(gòu)）
arm920t：CPU （具體使用的CPU型號）
mini2440：Board
samsung：VENDOR（生產(chǎn)廠家名）
s3c24x0：SOC
下面再來看看mkconfig腳本到底做了什么。
?。?）確定開發(fā)板名稱BOARD_NAME
在mkconfig腳本中有如下代碼：
APPEND=no #no表示創(chuàng)建新的配置文件，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”
環(huán)境變量$#表示傳遞給腳本的參數(shù)個(gè)數(shù)，這里的命令有6個(gè)參數(shù)，因此$#是6 。shift的作用是使$1=$2，$2=$3，$3=$4…。，而原來的$1將丟失。因此while循環(huán)的作用是，依次處理傳遞給mkconfig腳本的選項(xiàng)。由于我們并沒有傳遞給mkconfig任何的選項(xiàng)，因此while循環(huán)中的代碼不起作用。
最后將BOARD_NAME的值設(shè)置為$1的值，在這里就是“mini2440”。
?。?）檢查參數(shù)合法性
?。?$# -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
exit1
fi
上面代碼的作用是檢查參數(shù)個(gè)數(shù)和參數(shù)是否正確，參數(shù)個(gè)數(shù)少于4個(gè)或多于6個(gè)都被認(rèn)為是錯誤的。
?。?）創(chuàng)建到目標(biāo)板相關(guān)的目錄的鏈接
#
# Create link to architecture specificheaders
#
if ［ “$SRCTREE” ！=“$OBJTREE” ］ ; then #若編譯目標(biāo)輸出到外部目錄，則下面的代碼有效
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
mkdirasm-$2
ln-s asm-$2 asm
else
cd./include
rm-f asm
ln-s asm-$2 asm
fi
若將目標(biāo)文件設(shè)定為輸出到源文件所在目錄，則以上代碼在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目錄。（事實(shí)上include/asm-arm/arch-arm920t并不存在，因此$6是不能為空的，否則會編譯失敗）
if ［ “$2” = “arm” ］ ;then
rm-f asm-$2/proc
ln-s ${LNPREFIX}proc-armv asm-$2/proc
fi
若目標(biāo)板是arm架構(gòu)，則上面的代碼將建立符號連接include/asm-arm/proc，使其鏈接到目錄proc-armv目錄。
建立以上的鏈接的好處：編譯U-Boot時(shí)直接進(jìn)入鏈接文件指向的目錄進(jìn)行編譯，而不必根據(jù)不同開發(fā)板來選擇不同目錄。
?。?）構(gòu)建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
上面代碼將會把如下內(nèi)容寫入文件inlcude/config.mk文件：
ARCH = arm
CPU = arm920t
BOARD = mini2440
VENDOR = samsung
SOC = s3c24x0
?。?）指定開發(fā)板代碼所在目錄
# Assign board directory to BOARDIRvariable
if ［ -z “$5” -o “$5” =“NULL” ］ ; then
BOARDDIR=$4
else
BOARDDIR=$5/$4
fi
以上代碼指定board目錄下的一個(gè)目錄為當(dāng)前開發(fā)板專有代碼的目錄。若$5（VENDOR）為空則BOARDDIR設(shè)置為$4（BOARD），否則設(shè)置為$5/$4（VENDOR/BOARD）。在這里由于$5不為空，因此BOARDDIR被設(shè)置為samsung/mini2440 。
?。?）構(gòu)建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 configfile
fi
echo “/* Automatically generated - donot 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”表示將輸入的內(nèi)容追加到config.h中，直到出現(xiàn)“EOF”這樣的標(biāo)識為止。
若APPEND為no，則創(chuàng)建新的include/config.h文件。若APPEND為yes，則將新的配置內(nèi)容追加到include/config.h文件后面。由于APPEND的值保持“no”，因此config.h被創(chuàng)建了，并添加了如下的內(nèi)容：
/*Automatically generated - do not edit */
#defineCONFIG_BOARDDIR board/samsung/mini2440
#include《config_defaults.h》
#include《configs/mini2440.h》
#include《asm/config.h》
?
下面總結(jié)命令make mini2440_config執(zhí)行的結(jié)果（僅針對編譯目標(biāo)輸出到源代碼目錄的情況）：
（1） 創(chuàng)建到目標(biāo)板相關(guān)的文件的鏈接
ln-s asm-arm asm
ln-s arch-s3c24x0 asm-arm/arch
ln-s proc-armv asm-arm/proc
?。?） 創(chuàng)建include/config.mk文件，內(nèi)容如下所示：
ARCH = arm
CPU = arm920t
BOARD = mini2440
VENDOR= samsung
SOC = s3c24x0
（3） 創(chuàng)建與目標(biāo)板相關(guān)的文件include/config.h，如下所示：
/*Automatically generated - do not edit */
#defineCONFIG_BOARDDIR board/samsung/mini2440
#include《config_defaults.h》
#include《configs/mini2440.h》
#include《asm/config.h》
3. makeall命令執(zhí)行過程
若沒有執(zhí)行過“make《board_name》_config”命令就直接執(zhí)行“make all”命令則會出現(xiàn)如下的才錯誤信息，然后停止編譯：
System not configured - see README
U-Boot是如何知道用戶沒有執(zhí)行過“make《board_name》_config”命令的呢？閱讀U-Boot源代碼就可以發(fā)現(xiàn)了，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） 命令執(zhí)行的結(jié)果是“$（obj）include/config.mk”展開的字符串，否則結(jié)果為空。由于include/config.mk是“make 《board_name》_config”命令執(zhí)行過程生成的，若從沒有執(zhí)行過“make 《board_name》_config”命令則include/config.mk必然不存在。因此Make就執(zhí)行else分支的代碼，在輸出“System not configured -see README”的信息后就返回了。
下面再來分析“make all”命令正常執(zhí)行的過程，在Makefile中有如下代碼：
?。?）include/autoconf.mk生成過程
all：
sinclude $（obj）include/autoconf.mk.dep
sinclude $（obj）include/autoconf.mk
include/autoconf.mk文件中是與開發(fā)板相關(guān)的一些宏定義，在Makefile執(zhí)行過程中需要根據(jù)某些宏來確定執(zhí)行哪些操作。下面簡要分析include/autoconf.mk生成的過程，include/autoconf.mk生成的規(guī)則如下：
$（obj）include/autoconf.mk：$（obj）include/config.h
@$（XECHO）Generating $@ ; \
set-e ; \
?。篍xtract the config macros ; \
$（CPP）$（CFLAGS） -DDO_DEPS_ONLY -dM include/common.h | \
sed-n -f tools/scripts/define2mk.sed 》 $@.tmp && \
mv$@.tmp $@
include/autoconf.mk依賴于make 《board_name》_config 命令生成的include/config.h。因此執(zhí)行make 《board_name》_config命令后再執(zhí)行make all將更新include/autoconf.mk。
編譯選項(xiàng)“-dM”的作用是輸出include/common.h中定義的所有宏。根據(jù)上面的規(guī)則，編譯器提取include/common.h中定義的宏，然后輸出給tools/scripts/define2mk.sed腳本處理，處理的結(jié)果就是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實(shí)質(zhì)上就是config_defaults.h，configs/mini2440.h，asm/config.h三個(gè)文件中“CONFIG_”開頭的有效的宏定義的集合。
下面接著分析Makefile的執(zhí)行。
# load ARCH， BOARD， and CPU configuration
include $（obj）include/config.mk
export ARCHCPU BOARD VENDOR SOC
將make mini2440_config命令生成的include/config.mk包含進(jìn)來。
# 若主機(jī)架構(gòu)與開發(fā)板結(jié)構(gòu)相同，就使用主機(jī)的編譯器，而不是交叉編譯器
ifeq （$（HOSTARCH），$（ARCH））
CROSS_COMPILE ？=
endif
若主機(jī)與目標(biāo)機(jī)器體系架構(gòu)相同，則使用gcc編譯器而不是交叉編譯器。
# load other configuration
include $（TOPDIR）/config.mk
最后將U-Boot頂層目錄下的config.mk文件包含進(jìn)來，該文件包含了對編譯的一些設(shè)置。下面對U-Boot頂層目錄下的config.mk文件進(jìn)行分析：
?。?）config.mk文件執(zhí)行過程
1設(shè)置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
由于目標(biāo)輸出到源代碼目錄下，因此執(zhí)行完上面的代碼后，src和obj都是空。
2設(shè)置編譯選項(xiàng)
PLATFORM_RELFLAGS =
PLATFORM_CPPFLAGS = #編譯選項(xiàng)
PLATFORM_LDFLAGS = #連接選項(xiàng)
用這3個(gè)變量表示交叉編譯器的編譯選項(xiàng)，在后面Make會檢查交叉編譯器支持的編譯選項(xiàng)，然后將適當(dāng)?shù)倪x項(xiàng)添加到這3個(gè)變量中。
#
# 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在后面的代碼定義為延時(shí)變量，其中的CC即arm-linux-gcc。函數(shù)cc-option用于檢查編譯器CC是否支持某選項(xiàng)。將2個(gè)選項(xiàng)作為參數(shù)傳遞給cc-option函數(shù)，該函數(shù)調(diào)用CC編譯器檢查參數(shù)1是否支持，若支持則函數(shù)返回參數(shù)1，否則返回參數(shù)2 （因此CC編譯器必須支持參數(shù)1或參數(shù)2，若兩個(gè)都不支持則會編譯出錯）?？梢韵裣旅孢@樣調(diào)用cc-option函數(shù)，并將支持的選項(xiàng)添加到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開發(fā)板，其中的CROSS_COMPILE在lib_arm/config.mk文件中定義：
CROSS_COMPILE ？= arm-linux-
因此以上代碼指定了使用前綴為“arm-linux-”的編譯工具，即arm-linux-gcc，arm-linux-ld等等。
4包含與開發(fā)板相關(guān)的配置文件
# Load generated board configuration
sinclude $（OBJTREE）/include/autoconf.mk
ifdef ARCH
sinclude $（TOPDIR）/lib_$（ARCH）/config.mk # include architecture dependend rules
endif
$（ARCH）的值是“arm”，因此將“l(fā)ib_arm/config.mk”包含進(jìn)來。lib_arm/config.mk腳本指定了交叉編譯器，添加了一些跟CPU架構(gòu)相關(guān)的編譯選項(xiàng)，最后還指定了cpu/arm920t/u-boot.lds為U-Boot的連接腳本。
ifdef CPU
sinclude $（TOPDIR）/cpu/$（CPU）/config.mk # include CPU specificrules
endif
$（CPU）的值是“arm920t”，因此將“cpu/arm920t/config.mk”包含進(jìn)來。這個(gè)腳本主要設(shè)定了跟arm920t處理器相關(guān)的編譯選項(xiàng)。
ifdef SOC
sinclude$（TOPDIR）/cpu/$（CPU）/$（SOC）/config.mk #include SoC specific rules
endif
$（SOC）的值是s3c24x0，因此Make程序嘗試將cpu/arm920t/s3c24x0/config.mk包含進(jìn)來，而這個(gè)文件并不存在，但是由于用的是“sinclude”命令，所以并不會報(bào)錯。
ifdef VENDOR
BOARDDIR = $（VENDOR）/$（BOARD）
else
BOARDDIR = $（BOARD）
endif
$（BOARD）的值是mini2440，VENDOR的值是samsung，因此BOARDDIR的值是samsung/mini2440。BOARDDIR變量表示開發(fā)板特有的代碼所在的目錄。
ifdef BOARD
sinclude$（TOPDIR）/board/$（BOARDDIR）/config.mk #include board specific rules
endif
Make將“board/samsung/mini2440/config.mk”包含進(jìn)來。該腳本只有如下的一行代碼：
TEXT_BASE = 0x33F80000
U-Boot編譯時(shí)將使用TEXT_BASE作為代碼段連接的起始地址。
LDFLAGS += -Bstatic -T $（obj）u-boot.lds$（PLATFORM_LDFLAGS）
ifneq （$（TEXT_BASE），）
LDFLAGS += -Ttext $（TEXT_BASE）
endif
執(zhí)行完以上代碼后，LDFLAGS中包含了“-Bstatic -T u-boot.lds ”和“-Ttext 0x33F80000”的字樣。
5指定隱含的編譯規(guī)則
# Allow boards to use custom optimizeflags on a per dir/file basis
BCURDIR ：= $（notdir $（CURDIR））
$（obj）%.s： %.S
$（CPP）$（AFLAGS） $（AFLAGS_$（@F）） $（AFLAGS_$（BCURDIR）） -o $@ $《
$（obj）%.o： %.S
$（CC） $（AFLAGS） $（AFLAGS_$（@F））$（AFLAGS_$（BCURDIR）） -o $@ $《 -c
$（obj）%.o： %.c
$（CC） $（CFLAGS） $（CFLAGS_$（@F））$（CFLAGS_$（BCURDIR）） -o $@ $《 -c
$（obj）%.i： %.c
$（CPP）$（CFLAGS） $（CFLAGS_$（@F）） $（CFLAGS_$（BCURDIR）） -o $@ $《 -c
$（obj）%.s： %.c
$（CC） $（CFLAGS） $（CFLAGS_$（@F））$（CFLAGS_$（BCURDIR）） -o $@ $《 -c -S
例如：根據(jù)以上的定義，以“.s”結(jié)尾的目標(biāo)文件將根據(jù)第一條規(guī)則由同名但后綴為“.S”的源文件來生成，若不存在“.S”結(jié)尾的同名文件則根據(jù)最后一條規(guī)則由同名的“.c”文件生成。
下面回來接著分析Makefile的內(nèi)容：
# 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.afs/fat/libfat.a fs/fdos/libfdos.a fs/jffs2/libjffs2.a \
fs/reiserfs/libreiserfs.afs/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需要的庫文件，包括平臺/開發(fā)板相關(guān)的目錄、通用目錄下相應(yīng)的庫，都通過相應(yīng)的子目錄編譯得到的。
對于mini2440開發(fā)板，以上跟平臺相關(guān)的有以下幾個(gè)：
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
其余都是與平臺無關(guān)的。
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
對于有的開發(fā)板，U-Boot支持在NAND Flash啟動，這些開發(fā)板的配置文件定義了CONFIG_NAND_U_BOOT，CONFIG_ONENAND_U_BOOT。對于s3c2440，U-Boot原始代碼并不支持NAND Flash啟動，因此也沒有定義這兩個(gè)宏。
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。因此執(zhí)行“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是最終燒寫到開發(fā)板的二進(jìn)制可執(zhí)行的文件。
下面再來分析u-boot.bin文件生成的過程。ELF格式“u-boot”文件生成規(guī)則如下：
$（obj）u-boot： depend $（SUBDIRS） $（OBJS） $（LIBBOARD） $（LIBS） $（LDSCRIPT）$（obj）u-boot.lds
$（GEN_UBOOT）
ifeq （$（CONFIG_KALLSYMS），y）
smap=`$（callSYSTEM_MAP，u-boot） | \
awk‘
2 ~ /［tTwW］/ {printf
1 $$3 “\\\\000”}’` ; \
$（CC）$（CFLAGS） -DSYSTEM_MAP=“\”$${smap}\“” \
-ccommon/system_map.c -o $（obj）common/system_map.o
$（GEN_UBOOT）$（obj）common/system_map.o
endif
這里生成的$（obj）u-boot目標(biāo)就是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的各個(gè)依賴：
1依賴目標(biāo)depend
# Explicitly make _depend in subdirscontaining multiple targets to prevent
# parallel sub-makes creating .depend filessimultaneously.
depend dep： $（TIMESTAMP_FILE） $（VERSION_FILE） $（obj）include/autoconf.mk
fordir in $（SUBDIRS） cpu/$（CPU） $（dir $（LDSCRIPT）） ; do \
$（MAKE）-C $$dir _depend ; done
對于$（SUBDIRS），cpu/$（CPU），$（dir $（LDSCRIPT））中的每個(gè)元素都進(jìn)入該目錄執(zhí)行“make_depend”，生成各個(gè)子目錄的.depend文件，.depend列出每個(gè)目標(biāo)文件的依賴文件。
2依賴SUBDIRS
SUBDIRS = tools \
examples/standalone \
examples/api
$（SUBDIRS）： depend
$（MAKE）-C $@ all
執(zhí)行tools ，examples/standalone ，examples/api目錄下的Makefile。
3OBJS
OBJS的值是“cpu/arm920t/start.o”。它使用如下代碼編譯得到：
$（OBJS）： depend
$（MAKE）-C cpu/$（CPU） $（if $（REMOTE_BUILD），$@，$（notdir $@））
以上規(guī)則表明，對于OBJS包含的每個(gè)成員，都進(jìn)入cpu/$（CPU）目錄（即cpu/arm920t）編譯它們。
4LIBBOARD
LIBBOARD = board/$（BOARDDIR）/lib$（BOARD）.a
LIBBOARD ：= $（addprefix$（obj），$（LIBBOARD））
… …
$（LIBBOARD）： depend $（LIBS）
$（MAKE）-C $（dir $（subst $（obj），，$@））
這里L(fēng)IBBOARD的值是$（obj）board/samsung/mini2440/libmini2440.a。make執(zhí)行board/samsung/mini2440/目錄下的Makefile，生成libmini2440.a 。
5LIBS
LIBS變量中的每個(gè)元素使用如下的規(guī)則編譯得到：
$（LIBS）： depend$（SUBDIRS）
$（MAKE）-C $（dir $（subst $（obj），，$@））
上面的規(guī)則表明，對于LIBS中的每個(gè)成員，都進(jìn)入相應(yīng)的子目錄執(zhí)行“make”命令編譯它們。例如對于LIBS中的“common/libcommon.a”成員，程序?qū)⑦M(jìn)入common目錄執(zhí)行Makefile，生成libcommon.a 。
6LDSCRIPT
LDSCRIPT ：= $（SRCTREE）/cpu/$（CPU）/u-boot.lds
… …
$（LDSCRIPT）： depend
$（MAKE）-C $（dir $@） $（notdir $@）
“$（MAKE） -C $（dir $@）$（notdir $@）”命令經(jīng)過變量替換后就是“make-C cpu/arm920t/ u-boot.lds”。也就是轉(zhuǎn)到cpu/arm920t/目錄下，執(zhí)行“make u-boot.lds”命令。
7$（obj）u-boot.lds
$（obj）u-boot.lds： $（LDSCRIPT）
$（CPP）$（CPPFLAGS） $（LDPPFLAGS） -ansi -D__ASSEMBLY__ -P - 《$^ 》$@
以上執(zhí)行結(jié)果實(shí)質(zhì)上是將cpu/arm920t/u-boot.lds經(jīng)編譯器簡單預(yù)處理后輸出到U-Boot頂層目錄下的u-boot.lds文件。其中的cpu/arm920t/u-boot.lds文件內(nèi)容如下：
/* 輸出為ELF文件，小端方式， */
OUTPUT_FORMAT（“elf32-littlearm”，“elf32-littlearm”， “elf32-littlearm”）
OUTPUT_ARCH（arm）
ENTRY（_start）
SECTIONS
{
。= 0x00000000;
。= ALIGN（4）;
.text：
{
/* cpu/arm920t/start.o放在最前面，保證最先執(zhí)行的是start.o */
cpu/arm920t/start.o （.text）
/*以下2個(gè)文件必須放在前4K，因此也放在前面，其中board/samsung/mini2440/lowlevel_init.o包含內(nèi)存初始化所需代碼，而board/samsung/mini2440/nand_read.o 包含U-Boot從NAND Flash搬運(yùn)自身的代碼 */
board/samsung/mini2440/lowlevel_init.o（.text）
board/samsung/mini2440/nand_read.o（.text）
/* 其他文件的代碼段 */
*（.text）
}
/* 只讀數(shù)據(jù)段 */
。= 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指定為當(dāng)前地址 */
.u_boot_cmd： { *（.u_boot_cmd） } /* 存放所有U-Boot命令對應(yīng)的cmd_tbl_t結(jié)構(gòu)體 */
__u_boot_cmd_end= 。; /* 將__u_boot_cmd_end指定為當(dāng)前地址 */
/* bss段 */
。= ALIGN（4）;
__bss_start= 。;
.bss（NOLOAD） ： { *（.bss） 。 = ALIGN（4）; }
_end= 。; /* 將_end指定為當(dāng)前地址 */
}
u-boot.lds實(shí)質(zhì)上是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 vaddr0x33f80000 paddr 0x33f80000 align 2**15
filesz 0x0002f99c memsz 0x00072c94 flags rwx
STACK off 0x00000000 vaddr0x00000000 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啟動階段復(fù)制代碼到RAM空間的過程以及U-Boot命令執(zhí)行過程密切相關(guān)，具體請結(jié)合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） \
-Mapu-boot.map -o u-boot
以上命令使用$（LDFLAGS）作為連接腳本，最終生成“u-boot”文件。
u-boot.bin文件生成過程
生成u-boot.bin文件的規(guī)則如下：
$（obj）u-boot.bin： $（obj）u-boot
$（OBJCOPY）${OBJCFLAGS} -O binary $《 $@
從U-Boot編譯輸出信息中可以知道上面的命令實(shí)質(zhì)上展開為：
arm-linux-objcopy--gap-fill=0xff -O binary u-boot u-boot.bin
編譯命令中的“-O binary”選項(xiàng)指定了輸出的文件為二進(jìn)制文件。而“--gap-fill=0xff”選項(xiàng)指定使用“0xff”填充段與段間的空閑區(qū)域。這條編譯命令實(shí)現(xiàn)了ELF格式的U-Boot文件到BIN格式的轉(zhuǎn)換。
System.map文件的生成
System.map是U-Boot的符號表，它包含了U-Boot的全局變量和函數(shù)的地址信息。將System.map生成的規(guī)則如下：
SYSTEM_MAP = \
$（NM）$1 | \
grep-v ‘compiled\|\.o$$\|［aUw］\|\。\.ng$$\|LASH［RL］DI’ | \
LC_ALL=Csort
$（obj）System.map： $（obj）u-boot
@$（callSYSTEM_MAP，$《） 》 $（obj）System.map
arm-linux-nm u-boot | grep -v‘compiled\|\.o$$\|［aUw］\|\。\.ng$$\|LASH［RL］DI’ | LC_ALL=Csort 》 System.map
也就是將arm-linux-nm命令查看u-boot的輸出信息經(jīng)過過濾和排序后輸出到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表示的是地址標(biāo)號到該標(biāo)號表示的地址的一個(gè)映射關(guān)系。System.map每一行的格式都是“addr type name”，addr是標(biāo)號對應(yīng)的地址值，name是標(biāo)號名，type表示標(biāo)號的類型。
U-Boot的編譯和運(yùn)行并不一定要生成System.map，這個(gè)文件主要是提供給用戶或外部程序調(diào)試時(shí)使用的。
工商網(wǎng)監(jiān)
評論