注：本文是由瘋仔整理的筆記，基於uboot-1.3.4和s5pc11x分析。

話不多說直接上程式碼

(1)uboot的版本號分3個級別：
VERSION：主機板本號
PATCHLEVEL：次版本號
SUBLEVEL：再次版本號
EXTRAVERSION:另外附加的版本資訊
這4個用.分隔開共同構成了最終的版本號。
(2)Makefile中版本號最終生成了一個變數U_BOOT_VERSION，這個變數記錄了Makefile中配置的版本號。
(3)include/version_autogenerated.h檔案是編譯過程中自動生成的一個檔案，所以源目錄中沒有，但是編譯過後的uboot中就有了。它裡面的內容是一個巨集定義，巨集定義的值內容就是我們在Makefile中配置的uboot的版本號。
(4)驗證方法：自己修改主Makefile中幾個Version有關的變數，然後重新編譯uboot，然後燒錄到SD卡中，從SD卡啟動，然後去看啟動時uboot打印出來的版本資訊，看看變化是不是和自己的分析一致。

“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” 。

HOSTARCH和HOSTOS
(1)直接在shell中執行uname -m得到i686，得到的值其實你當前執行這個命令的電腦的CPU的版本號。
(2)shell中的|叫做管道，管道的作用就是把管道前面一個運算式的輸出作為後面一個的輸入再去做處理，最終的輸出才是我們整個式子的輸出。
(3)HOSTARCH這個名字：HOST是主機，就是當前在做開發用的這臺電腦就叫主機；ARCH是architecture(架構)的縮寫，表示CPU的架構。所以HOSTARCH就表示主機的CPU的架構。
(4)這兩個環境變數是主機的作業系統和主機的CPU架構，得出後儲存備用，後面自然會用到。

通過findstring函式來找MAKEFLAGS是否有匹配s的關鍵詞，如果沒有則ifeq就為真。那麼變數XECHO就等於echo；

在 linux shell 裡面，冒號後面的命令不執行。
所以在非靜默編譯的時候 XECHO = echo
在靜默編譯的時候 XECHO = :

靜默編譯（50-54行）
(1)平時預設編譯時命令列會打印出來很多編譯資訊。但是有時候我們不希望看到這些編譯資訊，就後臺編譯即可。這就叫靜默編譯。
(2)使用方法就是編譯時make -s，-s會作為MAKEFLAGS傳給Makefile，在50-54行這段程式碼作用下XECHO變數就會被變成空（預設等於echo），於是實現了靜默編譯。

這裡主要說明origin的語法：

origin函式不像其它的函式，他並不操作變數的值，他只是告訴你你的這個變數是哪裡來的？其語法是：
     $(origin <variable>;)
注意，<variable>;是變數的名字，不應該是引用。所以你最好不要在<variable>;中使用“$”字元。Origin函式會以其返回值來告訴你這個變數的“出生情況”，下面，是origin函式的返回值:

“command line”
       如果<variable>;這個變數是被命令列定義的。

預設的就是原地編譯。如果需要指定具體的輸出目錄編譯則有2種方式來指定輸出目錄。（具體參考Makefile 56-76行註釋內容）
第一種：make O=輸出目錄
第二種：export BUILD_DIR=輸出目錄 然後再make
如果兩個都指定了（既有BUILD_DIR環境變數存在，又有O=xx），則O=xx具有更高優先順序，聽他的。
兩種編譯的實現程式碼在Makefile的78-123行。

$(shell [ -d ${BUILD_DIR} ] || mkdir -p ${BUILD_DIR})判斷當前是否有個｛BUILD_DIR｝目錄，如果沒有執行mkdir -p ${BUILD_DIR}，建立｛BUILD_DIR｝目錄,這個變數為空。

OBJTREE、SRCTREE、TOPDIR
(1)OBJTREE：編譯出的.o檔案存放的目錄的根目錄。在預設編譯下，OBJTREE等於當前目錄；在O=xx編譯下，OBJTREE就等於我們設定的那個輸出目錄。
(2)SRCTREE: 原始碼目錄，其實就是原始碼的根目錄，也就是當前目錄。
總結：在預設編譯下，OBJTREE和SRCTREE相等；在O=xx這種編譯下OBJTREE和SRCTREE不相等。Makefile中定義這兩個變數，其實就是為了記錄編譯後的.o檔案往哪裡放，就是為了實現O=xx的這種編譯方式的。

MKCONFIG（Makefile的101行）
Makefile中定義的一個變數（在這裡定義，在後面使用），它的值就是我們原始碼根目錄下面的mkconfig。這個mkconfig是一個指令碼，這個指令碼就是uboot配置階段的配置指令碼。

由以上可知obj,src都為空

include $(obj)include/config.mk（133行）
(1)include/config.mk不是原始碼自帶的（你在沒有編譯過的原始碼目錄下是找不到這個檔案的），要在配置過程（make x210_sd_config）中才會生成這個檔案。因此這個檔案的值和我們配置過程有關，是由配置過程根據我們的配置自動生成的。
(2)我們X210在iNand情況下配置生成的config.mk內容為：
ARCH   = arm
CPU    = s5pc11x
BOARD  = x210
VENDOR = samsung
SOC    = s5pc110

(3)我們在下一行（134行）export匯出了這5個變數作為環境變數。所以著兩行加起來其實就是為當前makefile定義了5個環境變數而已。之所以不直接給出這5個環境變數的值，是因為我們希望這5個值是可以被人很容易的、集中的配置的。
(4)這裡的配置值來自於2589行那裡的配置項。如果我們要更改這裡的某個配置值要到2589行那裡呼叫MKCONFIG指令碼傳參時的引數。

在編譯uboot之前需要進行配置(帶引數執行mkconfig指令碼+其他)

以make x210_sd_config為例：

make x210_sd_config時會相應的去執行Makefile中的：

x210_sd_config :    unconfig
@$(MKCONFIG) $(@:_config=) arm s5pc11x x210 samsung s5pc110
@echo "TEXT_BASE = 0xc3e00000" > $(obj)board/samsung/x210/config.mk

• 1
• 2
• 3
• 4

@$(MKCONFIG)就表示呼叫目錄下的mkconfig指令碼，後面是mkconfig指令碼的6個引數，不是五個 
$(@:_config=) arm s5pc11x x210 samsung s5pc110

$和@結合: 是Makefile自動變數的一種，會被替換成目標x210_sd
冒號表示加工，怎麼加工呢？就是把目標中的_config等於空(等號後面沒東西表示空)。即x210_sd_config裡的_config部分用空替換，得到：x210_sd，這就是第一個引數，則：

$1:    x210_sd
$2:    arm
$3: s5pc11x
$4:    x210
$5: samsumg
$6:    s5pc110
所以，$# = 6

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8

TEXT_BASE = 0xc3e00000：指定uboot的連結地址，因為uboot中啟用了虛擬地址對映，因此這個C3E00000地址就等於0x23E00000(也可能是33E00000具體地址要取決於uboot中做的虛擬地址對映關係）

$(TOPDIR)/config.mk（主Makefile的185行）
編譯工具定義（config.mk 94-107行）

包含開發板配置專案（config.mk, 112行）

(1)autoconfig.mk檔案不是原始碼提供的，是配置過程自動生成的。
(2)這個檔案的作用就是用來指導整個uboot的編譯過程。這個檔案的內容其實就是很多CONFIG_開頭的巨集（可以理解為變數），這些巨集/變數會影響我們uboot編譯過程的走向（原理就是條件編譯）。在uboot程式碼中有很多地方使用條件編譯進行編寫，這個條件編譯是用來實現可移植性的。（可以說uboot的原始碼在很大程度來說是拼湊起來的，同一個程式碼包含了各種不同開發板的適用程式碼，用條件編譯進行區別。）
(3)這個檔案不是憑空產生的，配置過程也是需要原材料來產生這個檔案的。原材料在原始碼目錄的inlcude/configs/xxx.h標頭檔案。（X210開發板中為include/configs/x210_sd.h）。這個h標頭檔案裡面全都是巨集定義，這些巨集定義就是我們對當前開發板的移植。每一個開發板的移植都對應這個目錄下的一個頭檔案，這個標頭檔案裡每一個巨集定義都很重要，這些配置的巨集定義就是我們移植uboot的關鍵所在。

連結指令碼（config.mk 142-149行）

(1)如果定義了CONFIG_NAND_U_BOOT巨集，則連結指令碼叫u-boot-nand.lds，如果未定義這個巨集則連結指令碼叫u-boot.lds。
(2)從字面意思分析，即可知：CONFIG_NAND_U_BOOT是在Nand版本情況下才使用的，我們使用的X210都是iNand版本的，因此這個巨集沒有的。
(3)實際在board\samsung\x210目錄下有u-boot.lds，這個就是連結指令碼。我們在分析uboot的編譯連結過程時就要考慮這個連結指令碼。


TEXT_BASE（config.mk 156-158行）

(1)Makefile中在配置X210開發板時，在board/samsung/x210目錄下生成了一個檔案config.mk，其中的內容就是：TEXT_BASE = 0xc3e00000相當於定義了一個變數。
(2)TEXT_BASE是將來我們整個uboot連結時指定的連結地址。因為uboot中啟用了虛擬地址對映，因此這個C3E00000地址就等於0x23E00000(也可能是33E00000具體地址要取決於uboot中做的虛擬地址對映關係)。
(3)回顧裸機中講的連結地址的問題，再想想dnw方式先下載x210_usb.bin然後再下載uboot.bin時為什麼第二個地址是23E00000.

自動推導規則（config.mk 239-256行）

(1)我們在講Makefile時提到過自動推導規則，具體理解可以參考《跟我一起學Makefile》

(1)291行出現了整個主Makefile中第一個目標all（也就是預設目標，我們直接在uboot根目錄下make其實就等於make all，就等於make這個目標）
(2)目標中有一些比較重要的。譬如：u-boot是最終編譯連結生成的elf格式的可執行檔案，
(3)unconfig字面意思來理解就是未配置。這個符號用來做為我們各個開發板配置目標的依賴。目標是當我們已經配置過一個開發板後再次去配置時還可以配置。
(4)我們配置開發板時使用：make x210_sd_config，因此分析x210_sd_config肯定是主Makefile中的一個目標。

uboot配置過程詳解1

(1)mkconfig指令碼的6個引數
$(@:_config=) arm s5pc11x x210 samsung s5pc110


x210_sd_config裡的_config部分用空替換，得到：x210_sd，這就是第一個引數，所以：
$1:x210_sd
$2:arm
$3: s5pc11x
$4:x210
$5: samsumg
$6:s5pc110
所以，$# = 6


(2)第23行：其實就是看BOARD_NAME變數是否有值，如果有值就維持不變；如果無值就給他賦值為$1，實際分析結果：BOARD_NAME=x210_sd
(3)第25行：如果$#小於4，則exit 1（mkconfig指令碼返回1）
(4)第26行：如果$#大於6，則也返回1.
所以：mkconfig指令碼傳參只能是4、5、6，如果大於6或者小於4都不行。
(5)從第33行到第118行，都是在建立符號連結。為什麼要建立符號連結？這些符號連結檔案的存在就是整個配置過程的核心，這些符號連結檔案（資料夾）的主要作用是給標頭檔案包含等過程提供指向性連線。根本目的是讓uboot具有可移植性。
uboot可移植性的實現原理：在uboot中有很多彼此平行的程式碼，各自屬於各自不同的架構/CPU/開發板，我們在具體到一個開發板的編譯時用符號連線的方式提供一個具體的名字的資料夾供編譯時使用。這樣就可以在配置的過程中通過不同的配置使用不同的檔案，就可以正確的包含正確的檔案。


(6)建立的符號連結：
第一個：在include目錄下建立asm檔案，指向asm-arm。（46-48行）
第二個：在inlcude/asm-arm下建立一個arch檔案，指向include/asm-arm/arch-s5pc110
第三個：在include目錄下建立regs.h檔案，指向include/s5pc110.h
刪除第二個。
第四個：在inlcude/asm-arm下建立一個arch檔案，指向include/asm-arm/arch-s5pc11x
第五個：在include/asm-arm下建立一個proc檔案，指向include/asm-arm/proc-armv


總結：一共建立了4個符號連結。這4個符號連結將來在寫程式碼過程中，標頭檔案包含時非常有用。譬如一個頭檔案包含可能是：#include <asm/xx.h>




uboot配置過程詳解2
(1)建立include/config.mk檔案（mkconfig檔案123-129行）
(2)建立include/config.mk檔案是為了讓主Makefile在第133行去包含的。

config.mk節選

(3)思考：uboot的配置和編譯過程的配合。編譯的時候需要ARCH=arm、CPU=xx等這些變數來指導編譯，配置的時候就是為編譯階段提供這些變數。那為什麼不在Makefile中直接定義這些變數去使用，而要在mkconfig指令碼中建立config.mk檔案然後又在Makefile中include這些檔案呢？
(4)理解這些指令碼時，時刻要注意自己當前所處的路徑。
(5)建立（預設情況）/追加（make -a時追加）include/config.h檔案（mkconfig檔案的134-141行）。
(6)這個檔案裡面的內容就一行#include <configs/x210_sd.h>，這個標頭檔案是我們移植x210開發板時，對開發板的巨集定義配置檔案。這個檔案是我們移植x210時最主要的檔案。
(7)x210_sd.h檔案會被用來生成一個autoconfig.mk檔案，這個檔案會被主Makefile引入，指導整個編譯過程。這裡面的這些巨集定義會影響我們對uboot中大部分.c檔案中一些條件編譯的選擇。從而實現最終的可移植性。


注意：uboot的整個配置過程，很多檔案之間是有關聯的（有時候這個檔案是在那個檔案中創建出來的；有時候這個檔案被那個檔案包含進去；有時候這個檔案是由那個檔案的內容生成的決定的）
注意：uboot中配置和編譯過程，所有的檔案或者全域性變數都是字串形式的（不是指的C語言字串的概念，指的是都是字元組成的序列）。這意味著我們整個uboot的配置過程都是字串匹配的，所以一定要細節，注意大小寫，要注意不要輸錯字元，因為一旦錯一個最後會出現一些莫名其妙的錯誤，很難排查，這個是uboot移植過程中新手來說最難的地方。




uboot的連結指令碼

(1)uboot的連結指令碼和我們之前裸機中的連結指令碼並沒有本質區別，只是複雜度高一些，檔案多一些，使用到的技巧多一些。
(2)ENTRY(_start)用來指定整個程式的入口地址。所謂入口地址就是整個程式的開頭地址，可以認為就是整個程式的第一句指令。有點像C語言中的main。
(3)之前在裸機中告訴大家，指定程式的連結地址有2種方法：一種是在Makefile中ld的flags用-Ttext 0x20000000來指定；第二種是在連結指令碼的SECTIONS開頭用.=0x20000000來指定。兩種都可以實現相同效果。其實，這兩種技巧是可以共同配合使用的，也就是說既在連結指令碼中指定也在ld flags中用-Ttext來指定。兩個都指定以後以-Ttext指定的為準。

(4)uboot的最終連結起始地址就是在Makefile中用-Ttext 來指定的，具體參見2.4.5.2節，注意TEXT_BASE變數。最終來源是Makefile中配置對應的命令中，在make xxx_config時得到的。
(5)在程式碼段中注意檔案排列的順序。指定必須放在前面部分的那些檔案就是那些必須安排在前16KB內的檔案，這些檔案中的函式在前16KB會被呼叫。在後面第二部分（16KB之後）中呼叫的程式，前後順序就無所謂了。
(6)連結指令碼中除了.text  .data .rodata .bss段等編譯工具自帶的段之外，編譯工具還允許我們自定義段。譬如uboot總的.u_boot_cmd段就是自定義段。自定義段很重要。