U-Boot启动过程--详细版的完全分析
目錄：
一、初識u-boot?3
1，Bootloader介紹?3
2，Bootloader的啟動方式?3
（1）網絡啟動方式 4
（2）磁盤啟動方式 4
（3）Flash啟動方式?4
3，U-boot的定義?4
4，u-boot源代碼的目錄結構?4
5，U-boot中的地址?5
（1）什么是編譯地址？什么是運行地址？ 5
（2）編譯地址和運行地址如何來算呢？ 5
（3）為什么要分配編譯地址？這樣做有什么好處，有什么作用？ 5
（4）什么是相對地址？ 6
（5）如何去做呢？ 6
二、U-Boot總體分析 7
1，U-Boot第一階段?7
2，U-Boot第二階段?8
三、U-Boot代碼分析?9
1，U-Boot啟動第一階段代碼分析?9
（1）設置異常向量 11
（2）CPU進入SVC模式?12
（4）關閉看門狗?12
（5）屏蔽中斷?13
（8）初始化RAM控制寄存器?16
（9）復制U-Boot第二階段代碼到RAM?18
（10）設置堆棧?21
（11）清除BSS段?21
（12）跳轉到第二階段代碼入口?22
2，U-Boot啟動第二階段代碼分析?22
（1）gd_t結構體?23
（2）bd_t結構體?24
（3）init_sequence數組?24
（4）start_armboot函數?25
（5）U-Boot啟動Linux過程 27
（6）U-Boot添加命令的方法及U-Boot命令執行過程?30
一、初識u-boot
我們知道，bootloader是系統上電后最初加載運行的代碼。它提供了處理器上電復位后最開始需要執行的初始化代碼。
????在PC機上引導程序一般由BIOS開始執行，然后讀取硬盤中位于MBR(Main?Boot?Record，主引導記錄)中的Bootloader(例如LILO或GRUB),并進一步引導操作系統的啟動。
????然而在嵌入式系統中通常沒有像BIOS那樣的固件程序，因此整個系統的加載啟動就完全由bootloader來完成。它主要的功能是加載與引導內核映像?
?一個嵌入式的存儲設備通過通常包括四個分區：
l?第一個分區：存放的當然是u-boot
l?第二個分區：存放著u-boot要傳給系統內核的參數
l?第三個分區：是系統內核（kernel）
l?第四個分區：則是根文件系統
如下圖所示：
u-boot是一種普遍用于嵌入式系統中的Bootloader。
1，Bootloader介紹
Bootloader是進行嵌入式開發必然會接觸的一個概念。本篇文章主要講解Bootloader的基本概念以及內部原理，這部分內容的掌握將對嵌入式linux系統開發的學習非常有幫助！
Bootloader的定義：Bootloader是在操作系統運行之前執行的一小段程序，通過這一小段程序，我們可以初始化硬件設備、建立內存空間的映射表，從而建立適當的系統軟硬件環境，為最終調用操作系統內核做好準備。意思就是說如果我們要想讓一個操作系統在我們的板子上運轉起來，我們就必須首先對我們的板子進行一些基本配置和初始化，然后才可以將操作系統引導進來運行。
具體在Bootloader中完成了哪些操作我們會在后面分析到，這里我們先來回憶一下PC的體系結構：PC機中的引導加載程序是由BIOS和位于硬盤MBR中的OS?Boot?Loader（比如LILO和GRUB等）一起組成的，BIOS在完成硬件檢測和資源分配后，將硬盤MBR中的Boot?Loader讀到系統的RAM中，然后將控制權交給OS?Boot?Loader。Boot?Loader的主要運行任務就是將內核映象從硬盤上讀到RAM中，然后跳轉到內核的入口點去運行，即開始啟動操作系統。在嵌入式系統中，通常并沒有像BIOS那樣的固件程序（注：有的嵌入式cpu也會內嵌一段短小的啟動程序），因此整個系統的加載啟動任務就完全由Boot?Loader來完成。比如在一個基于ARM7TDMI?core的嵌入式系統中，系統在上電或復位時通常都從地址0x00000000處開始執行，而在這個地址處安排的通常就是系統的Boot?Loader程序。（先想一下，通用PC和嵌入式系統為何會在此處存在如此的差異呢？）
Bootloader是基于特定硬件平臺來實現的，因此幾乎不可能為所有的嵌入式系統建立一個通用的Bootloader，不同的處理器架構都有不同的Bootloader，Bootloader不但依賴于cpu的體系結構，還依賴于嵌入式系統板級設備的配置。對于2塊不同的板子而言，即使他們使用的是相同的處理器，要想讓運行在一塊板子上的Bootloader程序也能運行在另一塊板子上，一般也需要修改Bootloader的源程序。
2，Bootloader的啟動方式
Bootloader的啟動方式主要有網絡啟動方式、磁盤啟動方式和Flash啟動方式。
?
（1）網絡啟動方式
?
圖1??Bootloader網絡啟動方式示意圖
如圖1所示，里面主機和目標板，他們中間通過網絡來連接，首先目標板的DHCP/BIOS通過BOOTP服務來為Bootloader分配IP地址，配置網絡參數，這樣才能支持網絡傳輸功能。我們使用的u-boot可以直接設置網絡參數，因此這里就不用使用DHCP的方式動態分配IP了。接下來目標板的Bootloader通過TFTP服務將內核映像下載到目標板上，然后通過網絡文件系統來建立主機與目標板之間的文件通信過程，之后的系統更新通常也是使用Boot?Loader的這種工作模式。工作于這種模式下的Boot?Loader通常都會向它的終端用戶提供一個簡單的命令行接口。
（2）磁盤啟動方式
這種方式主要是用在臺式機和服務器上的，這些計算機都使用BIOS引導，并且使用磁盤作為存儲介質，這里面兩個重要的用來啟動linux的有LILO和GRUB，這里就不再具體說明了。
（3）Flash啟動方式
這是我們最常用的方式。Flash有NOR?Flash和NAND?Flash兩種。NOR?Flash可以支持隨機訪問，所以代碼可以直接在Flash上執行，Bootloader一般是存儲在Flash芯片上的。另外Flash上還存儲著參數、內核映像和文件系統。這種啟動方式與網絡啟動方式之間的不同之處就在于，在網絡啟動方式中，內核映像和文件系統首先是放在主機上的，然后經過網絡傳輸下載進目標板的，而這種啟動方式中內核映像和文件系統則直接是放在Flash中的，這兩點在我們u-boot的使用過程中都用到了。
3，U-boot的定義
U-boot全稱Universal?Boot?Loader，是由DENX小組的開發的遵循GPL條款的開放源碼項目，它的主要功能是完成硬件設備初始化、操作系統代碼搬運，并提供一個控制臺及一個指令集在操作系統運行前操控硬件設備。U-boot之所以這么通用，原因是他具有很多特點：開放源代碼、支持多種嵌入式操作系統內核、支持多種處理器系列、較高的穩定性、高度靈活的功能設置、豐富的設備驅動源碼以及較為豐富的開發調試文檔與強大的網絡技術支持。另外u-boot對操作系統和產品研發提供了靈活豐富的支持，主要表現在：可以引導壓縮或非壓縮系統內核，可以靈活設置/傳遞多個關鍵參數給操作系統，適合系統在不同開發階段的調試要求與產品發布，支持多種文件系統，支持多種目標板環境參數存儲介質，采用CRC32校驗，可校驗內核及鏡像文件是否完好，提供多種控制臺接口，使用戶可以在不需要ICE的情況下通過串口/以太網/USB等接口下載數據并燒錄到存儲設備中去（這個功能在實際的產品中是很實用的，尤其是在軟件現場升級的時候），以及提供豐富的設備驅動等。
4，u-boot源代碼的目錄結構
l?Board：中存放于開發板相關的配置文件，每一個開發板都以子文件夾的形式出現。
l?Commom：文件夾實現u-boot行下支持的命令，每一個命令對應一個文件。
l?Cpu：中存放特定cpu架構相關的目錄，每一款cpu架構都對應了一個子目錄。
l?Doc：是文檔目錄，有u-boot非常完善的文檔。
l?Drivers：中是u-boot支持的各種設備的驅動程序。
l?Fs：是支持的文件系統，其中最常用的是JFFS2文件系統。
l?Include：文件夾是u-boot使用的頭文件，還有各種硬件平臺支持的匯編文件，系統配置文件和文件系統支持的文件。
l?Net：是與網絡協議相關的代碼，bootp協議、TFTP協議、NFS文件系統得實現。
l?Tooles：是生成U-boot的工具。
對u-boot的目錄有了一些了解后，分析啟動代碼的過程就方便多了，其中比較重要的目錄就是/board、/cpu、/drivers和/include目錄，如果想實現u-boot在一個平臺上的移植，就要對這些目錄進行深入的分析。?
5，U-boot中的地址??????????????????????????????????????????????????????
（1）什么是編譯地址？什么是運行地址？
1）編譯地址
32位的處理器，它的每一條指令是4個字節，以4個字節存儲順序，進行順序執行，CPU是順序執行的，只要沒發生什么跳轉，它會順序進行執行，編譯器會對每一條指令分配一個編譯地址，這是編譯器分配的，在編譯過程中分配的地址，我們稱之為編譯地址。
2）運行地址
是指程序指令真正運行的地址，是由用戶指定的，用戶將運行地址燒錄到哪里，哪里就是運行的地址。
????比如有一個指令的編譯地址是0x5，如果用戶將指令燒到0x200上，那么這條指令的運行地址就是0x200，
????當編譯地址和運行地址不同的時候會出現什么結果？結果是不能跳轉，編譯后會產生跳轉地址，如果實際地址和編譯后產生的地址不相等，那么就不能跳轉。
????C語言編譯地址：都希望把編譯地址和實際運行地址放在一起的，但是匯編代碼因為不需要做C語言到匯編的轉換，可以認為的去寫地址，直接寫的就是他的運行地址。這就是為什么任何bootloader剛開始會有一段匯編代碼，因為起始代碼編譯地址和實際地址不相等，這段代碼和匯編無關，跳轉用的運行地址。????????????????????????????????????????????????????????????????????????????????????????
（2）編譯地址和運行地址如何來算呢？
???1，假如有兩個編譯地址a=0x10，b=0x7，b的運行地址是0x300，那么a的運行地址就是b的運行地址加上兩者編譯地址的差值，a-b=0x10-0x7=0x3，a的運行地址就是0x300+0x3=0x303。
???2，假設uboot上兩條指令的編譯地址為a=0x33000007和b=0x33000001，這兩條指令都落在bank6上，現在要計算出他們對應的運行地址，要找出運行地址的起始地址，這個是由用戶燒錄進去的，假設運行地址的首地址是0x0，則a的運行地址為0x7，b為0x1，就是這樣算出來的。
（3）為什么要分配編譯地址？這樣做有什么好處，有什么作用？
比如在函數a中定義了函數b，當執行到函數b時要進行指令跳轉，要跳轉到b函數所對應的起始地址上去，編譯時，編譯器給每條指令都分配了編譯地址，如果編譯器已經給分配了地址就可以直接進行跳轉，查找b函數跳轉指令所對應的表，進行直接跳轉，因為有個編譯地址和指令對應的一個表，如果沒有分配，編譯器就查找不到這個跳轉地址，要進行計算，非常麻煩。
（4）什么是相對地址？
以NOR?Flash為例，NOR?Falsh是映射到bank0上面，SDRAM是映射到bank6上面，uboot和內核最終是在SDRAM上面運行。最開始我們是從Nor?Flash的零地址開始往后燒錄，uboot中至少有一段代碼編譯地址和運行地址是不一樣的，編譯uboot或內核時，都會將編譯地址放入到SDRAM中，他們最終都會在SDRAM中執行，剛開始uboot在Nor?Flash中運行，運行地址是一個低端地址，是bank0中的一個地址，但編譯地址是bank6中的地址，這樣就會導致絕對跳轉指令執行的失敗，所以就引出了相對地址的概念。
至少在bank0中uboot這段代碼要知道不能用b+編譯地址這樣的方法去跳轉指令，因為這段代碼的編譯地址和運行地址不一樣。
（5）如何去做呢？
要去計算這個指令運行的真實地址，計算出來后再做跳轉，應該是b+運行地址，不能出現b+編譯地址，而是b+運行地址，而運行地址是算出來的。
_TEXT_BASE:
.word?TEXT_BASE?//0x33F80000,在board/config.mk中
這段話表示，用戶告訴編譯器編譯地址的起始地址。
二、U-Boot總體分析
1，U-Boot第一階段
系統啟動的入口點。既然我們現在要分析u-boot的啟動過程，就必須先找到u-boot最先實現的是哪些代碼，最先完成的是哪些任務。
另一方面一個可執行的image必須有一個入口點，并且只能有一個全局入口點，所以要通知編譯器這個入口在哪里。由此我們可以找到程序的入口點是在/board/lpc2210/u-boot.lds中指定的，其中ENTRY(_start)說明程序從_start開始運行，而他指向的是cpu/arm7tdmi/start.o文件。
因為我們用的是ARM7TDMI的cpu架構，在復位后從地址0x00000000取它的第一條指令，所以我們將Flash映射到這個地址上，這樣在系統加電后，cpu將首先執行u-boot程序。u-boot的啟動過程是多階段實現的，分了兩個階段。
依賴于cpu體系結構的代碼（如設備初始化代碼等）通常都放在stage1中，而且通常都是用匯編語言來實現，以達到短小精悍的目的。
而stage2則通常是用C語言來實現的，這樣可以實現復雜的功能，而且代碼具有更好的可讀性和可移植性。
下面我們先詳細分析下stage1中的代碼，如圖2所示：
?
圖2??Start.s程序流程
代碼真正開始是在_start，設置異常向量表，這樣在cpu發生異常時就跳轉到/cpu/arm7tdmi/interrupts中去執行相應得中斷代碼。
在interrupts文件中大部分的異常代碼都沒有實現具體的功能，只是打印一些異常消息，其中關鍵的是reset中斷代碼，跳到reset入口地址。
reset復位入口之前有一些段的聲明。
1.在reset中，首先是將cpu設置為svc32模式下，并屏蔽所有irq和fiq。
2.在u-boot中除了定時器使用了中斷外，其他的基本上都不需要使用中斷，比如串口通信和網絡等通信等，在u-boot中只要完成一些簡單的通信就可以了，所以在這里屏蔽掉了所有的中斷響應。
3.初始化外部總線。這部分首先設置了I/O口功能，包括串口、網絡接口等的設置，其他I/O口都設置為GPIO。然后設置BCFG0~BCFG3，即外部總線控制器。這里bank0對應Flash，設置為16位寬度，總線速度設為最慢，以實現穩定的操作；Bank1對應DRAM，設置和Flash相同；Bank2對應RTL8019。
4.接下來是cpu關鍵設置，包括系統重映射（告訴處理器在系統發生中斷的時候到外部存儲器中去讀取中斷向量表）和系統頻率。
5.lowlevel_init，設定RAM的時序，并將中斷控制器清零。這些部分和特定的平臺有關，但大致的流程都是一樣的。
下面就是代碼的搬移階段了。為了獲得更快的執行速度，通常把stage2加載到RAM空間中來執行，因此必須為加載Boot?Loader的stage2準備好一段可用的RAM空間范圍。空間大小最好是memory?page大小(通常是4KB)的倍數。一般而言，1M的RAM空間已經足夠了。
flash中存儲的u-boot可執行文件中，代碼段、數據段以及BSS段都是首尾相連存儲的，所以在計算搬移大小的時候就是利用了用BSS段的首地址減去代碼的首地址，這樣算出來的就是實際使用的空間。
程序用一個循環將代碼搬移到0x81180000，即RAM底端1M空間用來存儲代碼。
然后程序繼續將中斷向量表搬到RAM的頂端。由于stage2通常是C語言執行代碼，所以還要建立堆棧去。
在堆棧區之前還要將malloc分配的空間以及全局數據所需的空間空下來，他們的大小是由宏定義給出的，可以在相應位置修改。
基本內存分布圖：
圖3??搬移后內存分布情況圖
2，U-Boot第二階段
下來是u-boot啟動的第二個階段，是用c代碼寫的，這部分是一些相對變化不大的部分，我們針對不同的板子改變它調用的一些初始化函數，并且通過設置一些宏定義來改變初始化的流程，所以這些代碼在移植的過程中并不需要修改，也是錯誤相對較少出現的文件。
在文件的開始先是定義了一個函數指針數組，通過這個數組，程序通過一個循環來按順序進行常規的初始化，并在其后通過一些宏定義來初始化一些特定的設備。
在最后程序進入一個循環，main_loop。這個循環接收用戶輸入的命令，以設置參數或者進行啟動引導。
本篇文章將分析重點放在了前面的start.s上，是因為這部分無論在移植還是在調試過程中都是最容易出問題的地方，要解決問題就需要程序員對代碼進行修改，所以在這里簡單介紹了一下start.s的基本流程，希望能對大家有所幫助。
三、U-Boot代碼分析
1，U-Boot啟動第一階段代碼分析
第一階段對應的文件是cpu/arm920t/start.S和board/samsung/mini2440/lowlevel_init.S。
U-Boot啟動第一階段流程如下：
?
詳細分析
圖?2.1?U-Boot啟動第一階段流程
?
?????根據cpu/arm920t/u-boot.lds中指定的連接方式：
?????看一下uboot.lds文件，在board/smdk2410目錄下面，uboot.lds是告訴編譯器這些段改怎么劃分，GUN編譯過的段，最基本的三個段是RO、RW、ZI。RO表示只讀，對應于具體的指代碼段，RW是數據段，ZI是歸零段，就是全局變量的那段。Uboot代碼這么多，如何保證start.s會第一個執行，編譯在最開始呢？就是通過uboot.lds鏈接文件進行。
OUTPUT_FORMAT("elf32-littlearm",?"elf32-littlearm",?"elf32-littlearm")
/*OUTPUT_FORMAT("elf32-arm",?"elf32-arm",?"elf32-arm")*/
OUTPUT_ARCH(arm)
ENTRY(_start)
SECTIONS
{
.?=?0x00000000;?//起始地址
.?=?ALIGN(4);?//4字節對齊
.text?:?//test指代碼段，上面3行標識是不占用任何空間的
{
cpu/arm920t/start.o?(.text)?//這里把start.o放在第一位就表示把start.s編譯時放到最開始，
????????????????????????????????????//這就是為什么把uboot燒到起始地址上它肯定運行的是start.s
*(.text)
}
.?=?ALIGN(4);?//前面的?“.”?代表當前值，是計算一個當前的值，是計算上面占用的整個空間，
????????????????????????//再加一個單元就表示它現在的位置
.rodata?:?{?*(.rodata)?}
.?=?ALIGN(4);
.data?:?{?*(.data)?}
.?=?ALIGN(4);
.got?:?{?*(.got)?}
.?=?.;
__u_boot_cmd_start?=?.;
.u_boot_cmd?:?{?*(.u_boot_cmd)?}
__u_boot_cmd_end?=?.;
.?=?ALIGN(4);
__bss_start?=?.;?//bss表示歸零段
.bss?:?{?*(.bss)?}
_end?=?.;
}
第一個鏈接的是cpu/arm920t/start.o，因此u-boot.bin的入口代碼在cpu/arm920t/start.o中，其源代碼在cpu/arm920t/start.S中。下面我們來分析cpu/arm920t/start.S的執行。
（1）設置異常向量
下面代碼是系統啟動后U-boot上電后運行的第一段代碼，它是什么意思？
u-boot對應的第一階段代碼放在cpu/arm920t/start.S文件中，入口代碼如下：.
globl?_start??//聲明一個符號可被其它文件引用，相當于聲明了一個全局變量，.globl與.global相同
_start:????b?????start_code//復位?b是不帶返回的跳轉(bl是帶返回的跳轉)，
????????????????????????????//意思是無條件直接跳轉到start_code標號出執行程序
ldr???pc,?_undefined_instruction/*?未定義指令向量?ldr相當于mov操作?*/
ldr???pc,?_software_interrupt????????????/*?軟件中斷向量?*/
ldr???pc,?_prefetch_abort?????????????????/*?預取指令異常向量?*/
ldr???pc,?_data_abort?????????????????????/*?數據操作異常向量?*/
ldr???pc,?_not_used??????????????????????/*?未使用?*/
ldr???pc,?_irq????????????????????????????/*?irq中斷向量?*/
ldr???pc,?_fiq????????????????????????????/*?fiq中斷向量?*/
/*??中斷向量表入口地址?*/
_undefined_instruction:????.word?undefined_instruction??//就是在當前地址，
?????????????????????????????????????????????//即_undefined_instruction?處存放?undefined_instruction
_software_interrupt:??.word?software_interrupt
_prefetch_abort:??.word?prefetch_abort
_data_abort:????????.word?data_abort
_not_used:??????????.word?not_used
_irq:????????????????.word?irq
_fiq:????????????????.word?fiq?
//word偽操作用于分配一段字內存單元(分配的單元都是字對齊的)，并用偽操作中的expr初始化
.balignl?16,0xdeadbeef
他們是系統定義的異常，一上電程序跳轉到start_code異常處執行相應的匯編指令，下面定義出的都是不同的異常，比如軟件發生軟中斷時，CPU就會去執行軟中斷的指令，這些異常中斷在CUP中地址是從0開始，每個異常占4個字節
ldr?pc,?_undefined_instruction表示把_undefined_instruction存放的數值存放到pc指針上。
_undefined_instruction:?.word?undefined_instruction表示未定義的這個異常是由.word來定義的，它表示定義一個字，一個32位的數。
.word后面的數：表示把該標識的編譯地址寫入當前地址，標識是不占用任何指令的。把標識存放的數值copy到指針pc上面，那么標識上存放的值是什么？
是由.word?undefined_instruction來指定的，pc就代表你運行代碼的地址，她就實現了CPU要做一次跳轉時的工作。
以上代碼設置了ARM異常向量表，各個異常向量介紹如下：
表?2.1?ARM異常向量表
| 地址? | 異常 | 進入模式 | 描述 |
| 0x00000000? | 復位 | 管理模式 | 復位電平有效時，產生復位異常，程序跳轉到復位處理程序處執行 |
| 0x00000004? | 未定義指令 | 未定義模式 | 遇到不能處理的指令時，產生未定義指令異常 |
| 0x00000008 | 軟件中斷 | 管理模式 | 執行SWI指令產生，用于用戶模式下的程序調用特權操作指令 |
| 0x0000000c | 預存指令 | 中止模式 | 處理器預取指令的地址不存在，或該地址不允許當前指令訪問，產生指令預取中止異常 |
| 0x00000010 | 數據操作 | 中止模式 | 處理器數據訪問指令的地址不存在，或該地址不允許當前指令訪問時，產生數據中止異常 |
| 0x00000014 | 未使用 | 未使用 | 未使用 |
| 0x00000018 | IRQ | IRQ | 外部中斷請求有效，且CPSR中的I位為0時，產生IRQ異常 |
| 0x0000001c | FIQ | FIQ | 快速中斷請求引腳有效，且CPSR中的F位為0時，產生FIQ異常 |
在cpu/arm920t/start.S中還有這些異常對應的異常處理程序。當一個異常產生時，CPU根據異常號在異常向量表中找到對應的異常向量，然后執行異常向量處的跳轉指令，CPU就跳轉到對應的異常處理程序執行。
其中復位異常向量的指令“b?start_code”決定了U-Boot啟動后將自動跳轉到標號“start_code”處執行。
（2）CPU進入SVC模式
start_code:
???????/*
????????*?set?the?cpu?to?SVC32?mode
????????*/
???????mrs?r0,?cpsr
???????bic??r0,?r0,?#0x1f??????/*工作模式位清零?*/
???????orr??r0,?r0,?#0xd3??????/*工作模式位設置為“10011”（管理模式），并將中斷禁止位和快中斷禁止位置1?*/
???????msr?cpsr,?r0
以上代碼將CPU的工作模式位設置為管理模式，即設置相應的CPSR程序狀態字，并將中斷禁止位和快中斷禁止位置一，從而屏蔽了IRQ和FIQ中斷。
操作系統先注冊一個總的中斷，然后去查是由哪個中斷源產生的中斷，再去查用戶注冊的中斷表，查出來后就去執行用戶定義的用戶中斷處理函數。
（3）設置控制寄存器地址
#?if?defined(CONFIG_S3C2400)????????/*關閉看門狗*/
#??define?pWTCON?0x15300000?????/*;看門狗寄存器*/
#??define?INTMSK??0x14400008?????/*;中斷屏蔽寄存器*/
#??define?CLKDIVN0x14800014?/*;時鐘分頻寄存器*/
#else??????/*?s3c2410與s3c2440下面4個寄存器地址相同?*/
#??define?pWTCON?0x53000000???/*?WATCHDOG控制寄存器地址?*/
#??define?INTMSK??0x4A000008????/*?INTMSK寄存器地址??*/
#??define?INTSUBMSK?0x4A00001C????/*?INTSUBMSK寄存器地址?次級中斷屏蔽寄存器*/
#??define?CLKDIVN??????0x4C000014????/*?CLKDIVN寄存器地址?;時鐘分頻寄存器*/
#?endif
對與s3c2440開發板，以上代碼完成了WATCHDOG，INTMSK，INTSUBMSK，CLKDIVN四個寄存器的地址的設置。各個寄存器地址參見參考文獻[4]?。
（4）關閉看門狗
???????ldr???r0,?=pWTCON???/*?將pwtcon寄存器地址賦給R0?*/
???????mov?r1,?#0x0??????/*?r1的內容為0?*/
???????str???r1,?[r0]??????????/*?看門狗控制器的最低位為0時，看門狗不輸出復位信號?*/
以上代碼向看門狗控制寄存器寫入0，關閉看門狗。否則在U-Boot啟動過程中，CPU將不斷重啟。
為什么要關看門狗？說白了，就是你運行的代碼如果超出喂狗時間，而你不關狗，就會導致，你代碼還沒運行完又得去喂狗，就這樣反復得重啟CPU，那你代碼永遠也運行不完，所以，得先關看門狗得原因，就是這樣。
關狗——詳細的原因：
關閉看門狗，關閉中斷，所謂的喂狗是每隔一段時間給某個寄存器置位而已，在實際中會專門啟動一個線程或進程會專門喂狗，當上層軟件出現故障時就會停止喂狗，
停止喂狗之后，cpu會自動復位，一般都在外部專門有一個看門狗，做一個外部的電路，不在cpu內部使用看門狗，cpu內部的看門狗是復位的cpu。
當開發板很復雜時，有好幾個cpu時，就不能完全讓板子復位，但我們通常都讓整個板子復位。看門狗每隔一段時間就會喂狗，問題是在兩次喂狗之間的時間間隔內，運行的代碼的時間是否夠用，兩次喂狗之間的代碼是否在兩次喂狗的時間延遲之內，如果在延遲之外的話，代碼還沒改完就又進行喂狗，代碼永遠也改不完。
（5）屏蔽中斷
???????/*
????????*?mask?all?IRQs?by?setting?all?bits?in?the?INTMR?-?default
????????*/
???????mov?r1,?#0xffffffff?????/*?屏蔽所有中斷，某位被置1則對應的中斷被屏蔽?*/
???????ldr??r0,?=INTMSK????/*?將管理中斷的寄存器地址賦給r0?*/
???????str??r1,?[r0]??????????/*?將全r1的值賦給r0地址中的內容?*/
INTMSK是主中斷屏蔽寄存器，每一位對應SRCPND（中斷源引腳寄存器）中的一位，表明SRCPND相應位代表的中斷請求是否被CPU所處理。
根據參考文獻4，INTMSK寄存器是一個32位的寄存器，每位對應一個中斷，向其中寫入0xffffffff就將INTMSK寄存器全部位置一，從而屏蔽對應的中斷。
#?if?defined(CONFIG_S3C2440)
???????ldr??r1,?=0x7fff????
???????ldr??r0,?=INTSUBMSK
???????str??r1,?[r0]
?#?endif
INTSUBMSK每一位對應SUBSRCPND中的一位，表明SUBSRCPND相應位代表的中斷請求是否被CPU所處理。
根據參考文獻4，INTSUBMSK寄存器是一個32位的寄存器，但是只使用了低15位。向其中寫入0x7fff就是將INTSUBMSK寄存器全部有效位（低15位）置一，從而屏蔽對應的中斷。
屏蔽所有中斷，為什么要關中斷？
中斷處理中ldr?pc是將代碼的編譯地址放在了指針上，而這段時間還沒有搬移代碼，所以編譯地址上面沒有這個代碼，如果進行跳轉就會跳轉到空指針上面。
（6）設置MPLLCON，UPLLCON，CLKDIVN
#?if?defined(CONFIG_S3C2440)?
#define?MPLLCON???0x4C000004
#define?UPLLCON???0x4C000008??
??????????ldr??r0,?=CLKDIVN???//?設置時鐘
??????????mov??r1,?#5
??????????str??r1,?[r0]
?
??????????ldr??r0,?=MPLLCON
??????????ldr??r1,?=0x7F021?
??????????str??r1,?[r0]
?
??????ldr??r0,?=UPLLCON?
??????????ldr??r1,?=0x38022
??????????str??r1,?[r0]
#?else
?????????/*?FCLK:HCLK:PCLK?=?1:2:4?*/
??????????/*?default?FCLK?is?120?MHz?!?*/
??????????ldr???r0,?=CLKDIVN
??????????mov??r1,?#3
??????????str???r1,?[r0]
#endif
CPU上電幾毫秒后，晶振輸出穩定，FCLK=Fin（晶振頻率），CPU開始執行指令。但實際上，FCLK可以高于Fin，為了提高系統時鐘，需要用軟件來啟用PLL。這就需要設置CLKDIVN，MPLLCON，UPLLCON這3個寄存器。
CLKDIVN寄存器用于設置FCLK，HCLK，PCLK三者間的比例，可以根據表2.2來設置。
表?2.2?S3C2440?的CLKDIVN寄存器格式
| CLKDIVN? | 位 | 說明 | 初始值 |
| HDIVN | [2:1] | 00?:?HCLK?=?FCLK/1. 01?:?HCLK?=?FCLK/2. 10?:?HCLK?=?FCLK/4?（當?CAMDIVN[9]?=?0?時） ????HCLK=?FCLK/8??（當?CAMDIVN[9]?=?1?時） 11?:?HCLK?=?FCLK/3?（當?CAMDIVN[8]?=?0?時） ????HCLK?=?FCLK/6?（當?CAMDIVN[8]?=?1時） | 00 |
| PDIVN | [0] | 0:?PCLK?=?HCLK/1???1:?PCLK?=?HCLK/2 | 0 |
設置CLKDIVN為5，就將HDIVN設置為二進制的10，由于CAMDIVN[9]沒有被改變過，取默認值0，因此HCLK?=?FCLK/4。PDIVN被設置為1，因此PCLK=?HCLK/2。因此分頻比FCLK:HCLK:PCLK?=?1:4:8。
MPLLCON寄存器用于設置FCLK與Fin的倍數。MPLLCON的位[19:12]稱為MDIV，位[9:4]稱為PDIV，位[1:0]稱為SDIV。
對于S3C2440，FCLK與Fin的關系如下面公式：
MPLL(FCLK)?=?(2×m×Fin)/(p×)
其中：m=MDIC+8，p=PDIV+2，s=SDIV
MPLLCON與UPLLCON的值可以根據參考文獻4中“PLL?VALUE?SELECTION?TABLE”設置。該表部分摘錄如下：
表?2.3?推薦PLL值
| 輸入頻率??????? | ?輸出頻率????????????????????????? | MDIV??????????????????? | PDIV????????????????????? | SDIV????????????????????? |
| 12.0000MHz | 48.00?MHz | 56(0x38) | 2 | 2 |
| 12.0000MHz | 405.00?MHz | 127(0x7f) | 2 | 1 |
???????
當mini2440系統主頻設置為405MHZ，USB時鐘頻率設置為48MHZ時，系統可以穩定運行。因此設置MPLLCON與UPLLCON為：
MPLLCON?=?(0x7f<<12)?|?(0x02<<4)?|?(0x01)?=?0x7f021
UPLLCON?=?(0x38<<12)?|?(0x02<<4)?|?(0x02)?=?0x38022
默認頻率為FCLK:HCLK:PCLK?=?1:2:4，默認?FCLK?的值為120MHz，該值為?S3C2410?手冊的推薦值。
設置時鐘分頻，為什么要設置時鐘？
起始可以不設，系統能不能跑起來和頻率沒有任何關系，頻率的設置是要讓外圍的設備能承受所設置的頻率，如果頻率過高則會導致cpu操作外圍設備失敗
說白了：設置頻率，就為了CPU能去操作外圍設備！
（7）關閉MMU，cache（也就是做bank的設置）
接著往下看：
#ifndef?CONFIG_SKIP_LOWLEVEL_INIT
???????bl??cpu_init_crit???//?跳轉并把轉移后面緊接的一條指令地址保存到鏈接寄存器LR(R14)中，
????????????????????????//?以此來完成子程序的調用
#endif
cpu_init_crit這段代碼在U-Boot正常啟動時才需要執行，若將U-Boot從RAM中啟動則應該注釋掉這段代碼。
下面分析一下cpu_init_crit到底做了什么：
320??#ifndef?CONFIG_SKIP_LOWLEVEL_INIT
321??cpu_init_crit:
322??????/*
323???????*?使數據cache與指令cache無效?*/
324???????*/?
325??????movr0,?#0
326??????mcr?p15,?0,?r0,?c7,?c7,?0????/*?向c7寫入0將使ICache與DCache無效*/
327??????mcr?p15,?0,?r0,?c8,?c7,?0????/*?向c8寫入0將使TLB失效?，協處理器*/?
328?
329??????/*
330???????*?disable?MMU?stuff?and?caches
331???????*/
332??????mrc?p15,?0,?r0,?c1,?c0,?0????/*??讀出控制寄存器到r0中??*/
333??????bic??r0,?r0,?#0x00002300???@?clear?bits?13,?9:8?(--V-?--RS)
334??????bic??r0,?r0,?#0x00000087???@?clear?bits?7,?2:0?(B---?-CAM)
335??????orr???r0,?r0,?#0x00000002???@?set?bit?2?(A)?Align
336??????orr???r0,?r0,?#0x00001000???@?set?bit?12?(I)?I-Cache
337??????mcr?p15,?0,?r0,?c1,?c0,?0????/*??保存r0到控制寄存器??*/
338?
339??????/*
340???????*?before?relocating,?we?have?to?setup?RAM?timing
341???????*?because?memory?timing?is?board-dependend,?you?will
342???????*?find?a?lowlevel_init.S?in?your?board?directory.
343???????*/
344??????movip,?lr
345?
346??????bl????lowlevel_init
347?
348??????movlr,?ip
349??????movpc,?lr
350??#endif?/*?CONFIG_SKIP_LOWLEVEL_INIT?*/
代碼中的c0，c1，c7，c8都是ARM920T的協處理器CP15的寄存器。其中c7是cache控制寄存器，c8是TLB控制寄存器。325~327行代碼將0寫入c7、c8，使Cache，TLB內容無效。
第332~337行代碼關閉了MMU。這是通過修改CP15的c1寄存器來實現的，先看CP15的c1寄存器的格式（僅列出代碼中用到的位）：
表?2.3?CP15的c1寄存器格式（部分）
| 15??????? | 14?????? | 13????? | 12?????? | 11?????? | 10????? | 9?????? | 8?????? | 7?????? | 6??????? | 5?????? | 4????? | 3????? | 2????? | 1???? | 0???????? |
| . | . | V | I | . | . | R | S | B | . | . | . | . | C | A | M |
???????
各個位的意義如下：
V?:表示異常向量表所在的位置，0：異常向量在0x00000000；1：異常向量在?0xFFFF0000
I?:??0?：關閉ICaches；1?：開啟ICaches
R、S?:?用來與頁表中的描述符一起確定內存的訪問權限
B?:?0?：CPU為小字節序；1?：?CPU為大字節序
C?:?0：關閉DCaches；1：開啟DCaches
A?:?0：數據訪問時不進行地址對齊檢查；1：數據訪問時進行地址對齊檢查。
M?:?0：關閉MMU；1：開啟MMU
332~337行代碼將c1的?M位置零，關閉了MMU。
為什么要關閉catch和MMU呢？catch和MMU是做什么用的？
MMU是Memory?Management?Unit的縮寫，中文名是內存管理單元，它是中央處理器（CPU）中用來管理虛擬存儲器、物理存儲器的控制線路。
同時也負責虛擬地址映射為物理地址，以及提供硬件機制的內存訪問授權。
概述：
一，關catch
catch和MMU是通過CP15管理的，剛上電的時候，CPU還不能管理他們。
上電的時候MMU必須關閉，指令catch可關閉，可不關閉，但數據catch一定要關閉。否則可能導致剛開始的代碼里面，去取數據的時候，從catch里面取，而這時候RAM中數據還沒有catch過來，導致數據預取異常
二：關MMU
因為MMU是把虛擬地址轉化為物理地址的作用。
我們的目的是設置控制寄存器，而控制寄存器本來就是實地址（物理地址），再使能MMU，不就是多此一舉了嗎？
詳細分析：
Catch是cpu內部的一個2級緩存，它的作用是將常用的數據和指令放在cpu內部，MMU是用來把虛實地址轉換為物理地址用的。
我們的目的是設置控制的寄存器，寄存器都是實地址（物理地址），如果既要開啟MMU又要做虛實地址轉換的話，中間還多一步，多此一舉了嘛?
先要把實地址轉換成虛地址，然后再做設置，但對uboot而言就是起到一個簡單的初始化的作用和引導操作系統，如果開啟MMU的話，很麻煩，也沒必要，所以關閉MMU。
說到catch就必須提到一個關鍵字Volatile，以后在設置寄存器時會經常遇到，他的本質：是告訴編譯器不要對我的代碼進行優化，作用是讓編寫者感覺不倒變量的變化情況（也就是說，讓它執行速度加快吧）。
優化的過程：是將常用的代碼取出來放到catch中，它沒有從實際的物理地址去取，它直接從cpu的緩存中去取，但常用的代碼就是為了感覺一些常用變量的變化。
優化原因：如果正在取數據的時候發生跳變，那么就感覺不到變量的變化了，所以在這種情況下要用Volatile關鍵字告訴編譯器不要做優化，每次從實際的物理地址中去取指令，這就是為什么關閉catch關閉MMU。
但在C語言中是不會關閉catch和MMU的，會打開，如果編寫者要感覺外界變化，或變化太快，從catch中取數據會有誤差，就加一個關鍵字Volatile。
（8）初始化RAM控制寄存器
bl?lowlevel_init下來初始化各個bank，把各個bank設置必須搞清楚，對以后移植復雜的uboot有很大幫助。
設置完畢后拷貝uboot代碼到4k空間，拷貝完畢后執行內存中的uboot代碼。
其中的lowlevel_init就完成了內存初始化的工作，由于內存初始化是依賴于開發板的，因此lowlevel_init的代碼一般放在board下面相應的目錄中。對于mini2440，lowlevel_init在board/samsung/mini2440/lowlevel_init.S中定義如下：
45??#define?BWSCON???0x48000000????????/*?13個存儲控制器的開始地址?*/
??…?…
129??_TEXT_BASE:
130??????.word?????TEXT_BASE??//?0x33F80000,?board/config.mk中這段話表示，
?????????????????????????????????//用戶告訴編譯器編譯地址的起始地址
131?
132??.globl?lowlevel_init
133??lowlevel_init:
134??????/*?memory?control?configuration?*/
135??????/*?make?r0?relative?the?current?location?so?that?it?*/
136??????/*?reads?SMRDATA?out?of?FLASH?rather?than?memory?!?*/
137??????ldrr0,?=SMRDATA
138??????ldrr1,?_TEXT_BASE
139??????sub??r0,?r0,?r1?????????/*?SMRDATA減?_TEXT_BASE就是13個寄存器的偏移地址?*/
140??????ldr???r1,?=BWSCON???/*?Bus?Width?Status?Controller?*/
141??????add?r2,?r0,?#13*4
142??0:
143??????ldr?r3,?[r0],?#4??????/*將13個寄存器的值逐一賦值給對應的寄存器*/
144??????str??r3,?[r1],?#4
145??????cmp?r2,?r0
146??????bne?0b
147?
148??????/*?everything?is?fine?now?*/
149??????mov?pc,?lr
150?
151??????.ltorg
152??/*?the?literal?pools?origin?*/
153?
154??SMRDATA:????????????/*??下面是13個寄存器的值??*/
155??.word??…?…
156???.word??…?…
?…?…
lowlevel_init初始化了13個寄存器來實現RAM時鐘的初始化。lowlevel_init函數對于U-Boot從NAND?Flash或NOR?Flash啟動的情況都是有效的。
U-Boot.lds鏈接腳本有如下代碼：
???????.text?:
???????{
????????????????cpu/arm920t/start.o????(.text)
????????????????board/samsung/mini2440/lowlevel_init.o?(.text)
????????????????board/samsung/mini2440/nand_read.o?(.text)
??????????????…?…
???????}
board/samsung/mini2440/lowlevel_init.o將被鏈接到cpu/arm920t/start.o后面，因此board/samsung/mini2440/lowlevel_init.o也在U-Boot的前4KB的代碼中。
U-Boot在NAND?Flash啟動時，lowlevel_init.o將自動被讀取到CPU內部4KB的內部RAM中。因此第137~146行的代碼將從CPU內部RAM中復制寄存器的值到相應的寄存器中。
對于U-Boot在NOR?Flash啟動的情況，由于U-Boot連接時確定的地址是U-Boot在內存中的地址，而此時U-Boot還在NOR?Flash中，因此還需要在NOR?Flash中讀取數據到RAM中。
由于NOR?Flash的開始地址是0，而U-Boot的加載到內存的起始地址是TEXT_BASE，SMRDATA標號在Flash的地址就是SMRDATA－TEXT_BASE。
綜上所述，lowlevel_init的作用就是將SMRDATA開始的13個值復制給開始地址[BWSCON]的13個寄存器，從而完成了存儲控制器的設置。
?問題一：如果換一塊開發板有可能改哪些東西？
首先，cpu的運行模式，如果需要對cpu進行設置那就設置，關看門狗，關中斷不用改，時鐘有可能要改，如果能正常使用則不用改，關閉catch和MMU不用改，設置bank有可能要改。最后一步拷貝時看地址會不會變，如果變化也要改，執行內存中代碼，地址有可能要改。
問題二：Nor?Flash和Nand?Flash本質區別：
就在于是否進行代碼拷貝，也就是下面代碼所表述：無論是Nor?Flash還是Nand?Flash，核心思想就是將uboot代碼搬運到內存中去運行，但是沒有拷貝bss后面這段代碼，只拷貝bss前面的代碼，bss代碼是放置全局變量的。Bss段代碼是為了清零，拷貝過去再清零重復操作
（9）復制U-Boot第二階段代碼到RAM
cpu/arm920t/start.S原來的代碼只支持從NOR?Flash啟動的，經過修改現在U-Boot在NOR?Flash和NAND?Flash上都能啟動了，實現的思路是這樣的：
???????bl????bBootFrmNORFlash?/*?判斷U-Boot是在NAND?Flash還是NOR?Flash啟動?*/
???????cmpr0,?#0?????????//?r0存放bBootFrmNORFlash函數返回值，若返回0表示NAND?Flash啟動，
??????????????????????????????//?否則表示在NOR?Flash啟動
???????beq?nand_boot?????/*?跳轉到NAND?Flash啟動代碼?*/
?
/*?NOR?Flash啟動的代碼?*/
???????b?????stack_setup????????/*?跳過NAND?Flash啟動的代碼?*/
?
nand_boot:
/*?NAND?Flash啟動的代碼?*/
?
stack_setup:
???????/*?其他代碼?*/
其中bBootFrmNORFlash函數作用是判斷U-Boot是在NAND?Flash啟動還是NOR?Flash啟動，若在NOR?Flash啟動則返回1，否則返回0。根據ATPCS規則，函數返回值會被存放在r0寄存器中，因此調用bBootFrmNORFlash函數后根據r0的值就可以判斷U-Boot在NAND?Flash啟動還是NOR?Flash啟動。bBootFrmNORFlash函數在board/samsung/mini2440/nand_read.c中定義如下：
int?bBootFrmNORFlash(void)
{
????volatile?unsigned?int?*pdw?=?(volatile?unsigned?int?*)0;
????unsigned?int?dwVal;
??
????dwVal?=?*pdw;?????????/*?先記錄下原來的數據?*/
????*pdw?=?0x12345678;
????if?(*pdw?!=?0x12345678)????/*?寫入失敗，說明是在NOR?Flash啟動?*/
????{
????????return?1;
????}
????else?????????????????????/*?寫入成功，說明是在NAND?Flash啟動?*/
????{
????????*pdw?=?dwVal;????????/*?恢復原來的數據?*/
????????return?0;
????}
}
無論是從NOR?Flash還是從NAND?Flash啟動，地址0處為U-Boot的第一條指令“?b????start_code”。
對于從NAND?Flash啟動的情況，其開始4KB的代碼會被自動復制到CPU內部4K內存中，因此可以通過直接賦值的方法來修改。
對于從NOR?Flash啟動的情況，NOR?Flash的開始地址即為0，必須通過一定的命令序列才能向NOR?Flash中寫數據，所以可以根據這點差別來分辨是從NAND?Flash還是NOR?Flash啟動：向地址0寫入一個數據，然后讀出來，如果發現寫入失敗的就是NOR?Flash，否則就是NAND?Flash。
下面來分析NOR?Flash啟動部分代碼：
208??????adr??r0,?_start??????????????/*?r0?<-?current?position?of?code???*/
209??????ldr???r1,?_TEXT_BASE????????????/*?test?if?we?run?from?flash?or?RAM?*/
?
/*?判斷U-Boot是否是下載到RAM中運行，若是，則不用再復制到RAM中了，這種情況通常在調試U-Boot時才發生?*/
210??????cmp??r0,?r1??????/*_start等于_TEXT_BASE說明是下載到RAM中運行?*/
211??????beq?stack_setup
212??/*?以下直到nand_boot標號前都是NOR?Flash啟動的代碼?*/
213??????ldr???r2,?_armboot_start????/*?flash中armboot_start的起始地址?*/
214??????ldr???r3,?_bss_start?????????/*?uboot_bss的起始地址?*/
215??????sub??r2,?r3,?r2??????????????/*?r2?<-?size?of?armboot??uboot實際程序代碼的大小?*/
216??????add?r2,?r0,?r2??????????????/*?r2?<-?source?end?address?*/
217??/*?搬運U-Boot自身到RAM中?*/
218??copy_loop:
219??????ldmia?r0!,?{r3-r10}?/*?從地址為[r0]的NOR?Flash中讀入8個字的數據?*/
220??????stmia?r1!,?{r3-r10}?/*?將r3至r10寄存器的數據復制給地址為[r1]的內存?*/
221??????cmp?r0,?r2????????/*?until?source?end?addreee?[r2]?*/
222??????ble??copy_loop
223??????b???stack_setup??/*?跳過NAND?Flash啟動的代碼?*/
下面再來分析NAND?Flash啟動部分代碼：
nand_boot:
????mov?r1,?#NAND_CTL_BASE?
????ldr?r2,?=(?(7<<12)|(7<<8)|(7<<4)|(0<<0)?)
????str?r2,?[r1,?#oNFCONF]???/*?設置NFCONF寄存器?*/
?
???????/*?設置NFCONT，初始化ECC編/解碼器，禁止NAND?Flash片選?*/
????ldr?r2,?=(?(1<<4)|(0<<1)|(1<<0)?)
????str?r2,?[r1,?#oNFCONT]?
?
????ldr?r2,?=(0x6)???????????/*?設置NFSTAT?*/
str?r2,?[r1,?#oNFSTAT]
?
???????/*?復位命令，第一次使用NAND?Flash前復位?*/
????mov?r2,?#0xff???????????
????strb?r2,?[r1,?#oNFCMD]
????mov?r3,?#0??????????????
?
????/*?為調用C函數nand_read_ll準備堆棧?*/
????ldr?sp,?DW_STACK_START??
????mov?fp,?#0??????????????
????/*?下面先設置r0至r2，然后調用nand_read_ll函數將U-Boot讀入RAM?*/
????ldr?r0,?=TEXT_BASE??????/*?目的地址：U-Boot在RAM的開始地址?*/
????mov?r1,?#0x0???????????????/*?源地址：U-Boot在NAND?Flash中的開始地址?*/
????mov?r2,?#0x30000??????????/*?復制的大小，必須比u-boot.bin文件大，并且必須是NAND?Flash塊大小的整數倍，這里設置為0x30000（192KB）?*/
????bl??nand_read_ll??????????/*?跳轉到nand_read_ll函數，開始復制U-Boot到RAM?*/
tst??r0,?#0x0??????????????/*?檢查返回值是否正確?*/
beq?stack_setup
bad_nand_read:
loop2:?b?loop2????//infinite?loop
?
.align?2
DW_STACK_START:?.word?STACK_BASE+STACK_SIZE-4
???????其中NAND_CTL_BASE，oNFCONF等在include/configs/mini2440.h中定義如下：
#define?NAND_CTL_BASE??0x4E000000??//?NAND?Flash控制寄存器基址
?
#define?STACK_BASE??0x33F00000?????//base?address?of?stack
#define?STACK_SIZE??0x8000?????????//size?of?stack
?
#define?oNFCONF??0x00??????/*?NFCONF相對于NAND_CTL_BASE偏移地址?*/
#define?oNFCONT??0x04??????/*?NFCONT相對于NAND_CTL_BASE偏移地址*/
#define?oNFADDR??0x0c??????/*?NFADDR相對于NAND_CTL_BASE偏移地址*/
#define?oNFDATA??0x10??????/*?NFDATA相對于NAND_CTL_BASE偏移地址*/
#define?oNFCMD???0x08?????/*?NFCMD相對于NAND_CTL_BASE偏移地址*/
#define?oNFSTAT??0x20??????/*?NFSTAT相對于NAND_CTL_BASE偏移地址*/
#define?oNFECC???0x2c??????/*?NFECC相對于NAND_CTL_BASE偏移地址*/
NAND?Flash各個控制寄存器的設置在S3C2440的數據手冊有詳細說明，這里就不介紹了。
代碼中nand_read_ll函數的作用是在NAND?Flash中搬運U-Boot到RAM，該函數在board/samsung/mini2440/nand_read.c中定義。
NAND?Flash根據page大小可分為2種：?512B/page和2048B/page的。這兩種NAND?Flash的讀操作是不同的。因此就需要U-Boot識別到NAND?Flash的類型，然后采用相應的讀操作，也就是說nand_read_ll函數要能自動適應兩種NAND?Flash。
參考S3C2440的數據手冊可以知道：根據NFCONF寄存器的Bit3（AdvFlash?(Read?only)）和Bit2?（PageSize?(Read?only)）可以判斷NAND?Flash的類型。Bit2、Bit3與NAND?Flash的block類型的關系如下表所示：
表?2.4?NFCONF的Bit3、Bit2與NAND?Flash的關系
| Bit2????Bit3???????????????????????????????? | 0????????????????????????????????? | 1??????????????????????????????????????? |
| 0 | 256?B/page | 512?B/page |
| 1 | 1024?B/page | 2048?B/page |
?
由于的NAND?Flash只有512B/page和2048?B/page這兩種，因此根據NFCONF寄存器的Bit3即可區分這兩種NAND?Flash了。
完整代碼見board/samsung/mini2440/nand_read.c中的nand_read_ll函數，這里給出偽代碼：
int?nand_read_ll(unsigned?char?*buf,?unsigned?long?start_addr,?int?size)
{
//根據NFCONF寄存器的Bit3來區分2種NAND?Flash
???????if(?NFCONF?&?0x8?)????????/*?Bit是1，表示是2KB/page的NAND?Flash?*/
???????{
??????????????
??????????????讀取2K?block?的NAND?Flash
??????????????
????????}
???????else??????????????????????/*?Bit是0，表示是512B/page的NAND?Flash?*/
???????{
??????????????/
??????????????讀取512B?block?的NAND?Flash
??????????????/
???????}
???????return?0;
}
（10）設置堆棧
/*?設置堆棧?*/
stack_setup:
ldr???r0,?_TEXT_BASE????????????/*?upper?128?KiB:?relocated?uboot?*/
sub??r0,?r0,?#CONFIG_SYS_MALLOC_LEN???/*?malloc?area?*/
sub??r0,?r0,?#CONFIG_SYS_GBL_DATA_SIZE?/*?跳過全局數據區?*/
#ifdef?CONFIG_USE_IRQ
sub??r0,?r0,?#(CONFIG_STACKSIZE_IRQ+CONFIG_STACKSIZE_FIQ)
#endif
sub??sp,?r0,?#12???????????/*?leave?3?words?for?abort-stack??*/
只要將sp指針指向一段沒有被使用的內存就完成棧的設置了。根據上面的代碼可以知道U-Boot內存使用情況了，如下圖所示：
?
?
圖2.2?U-Boot內存使用情況
?（11）清除BSS段
clear_bss:
ldr???r0,?_bss_start??????????????/*?BSS段開始地址，在u-boot.lds中指定?*/
ldr???r1,?_bss_end???????????????/*?BSS段結束地址，在u-boot.lds中指定?*/
mov???r2,?#0x00000000
clbss_l:str??r2,?[r0]??????????/*?將bss段清零?*/
add?r0,?r0,?#4
cmp??r0,?r1
ble??clbss_l
初始值為0，無初始值的全局變量，靜態變量將自動被放在BSS段。應該將這些變量的初始值賦為0，否則這些變量的初始值將是一個隨機的值，若有些程序直接使用這些沒有初始化的變量將引起未知的后果。
（12）跳轉到第二階段代碼入口
ldr???pc,?_start_armboot
?_start_armboot:???.word??start_armboot
跳轉到第二階段代碼入口start_armboot處。
2，U-Boot啟動第二階段代碼分析
start_armboot函數在lib_arm/board.c中定義，是U-Boot第二階段代碼的入口。U-Boot啟動第二階段流程如下：
?
圖?2.3?U-Boot第二階段執行流程
在分析start_armboot函數前先來看看一些重要的數據結構：
（1）gd_t結構體
U-Boot使用了一個結構體gd_t來存儲全局數據區的數據，這個結構體在include/asm-arm/global_data.h中定義如下：
typedef??struct?????global_data?{
???????bd_t??????????????*bd;
???????unsigned?long??????flags;
???????unsigned?long??????baudrate;
???????unsigned?long??????have_console;??????/*?serial_init()?was?called?*/
???????unsigned?long??????env_addr;?????/*?Address??of?Environment?struct?*/
???????unsigned?long??????env_valid;????/*?Checksum?of?Environment?valid??*/
???????unsigned?long??????fb_base;?/*?base?address?of?frame?buffer?*/
???????void??????????????**jt;??????????????/*?jump?table?*/
}?gd_t;
U-Boot使用了一個存儲在寄存器中的指針gd來記錄全局數據區的地址：
#define?DECLARE_GLOBAL_DATA_PTR?????register?volatile?gd_t?*gd?asm?("r8")
DECLARE_GLOBAL_DATA_PTR定義一個gd_t全局數據結構的指針，這個指針存放在指定的寄存器r8中。這個聲明也避免編譯器把r8分配給其它的變量。任何想要訪問全局數據區的代碼，只要代碼開頭加入“DECLARE_GLOBAL_DATA_PTR”一行代碼，然后就可以使用gd指針來訪問全局數據區了。
根據U-Boot內存使用圖中可以計算gd的值：
gd?=?TEXT_BASE?－CONFIG_SYS_MALLOC_LEN?－?sizeof(gd_t)
（2）bd_t結構體
bd_t在include/asm-arm.u/u-boot.h中定義如下：
typedef?struct?bd_info?{
????int????????????????bi_baudrate;?????????/*?串口通訊波特率?*/
????unsigned?long?????bi_ip_addr;??????????/*?IP?地址*/
????struct?environment_s?????*bi_env;??????????/*?環境變量開始地址?*/
????ulong????????????bi_arch_number;?????/*?開發板的機器碼?*/
????ulong????????????bi_boot_params;?????/*?內核參數的開始地址?*/
????struct?????????????????????????/*?RAM配置信息?*/
????{
??????????????ulong?start;
??????????????ulong?size;
????}bi_dram[CONFIG_NR_DRAM_BANKS];?
}?bd_t;
U-Boot啟動內核時要給內核傳遞參數，這時就要使用gd_t，bd_t結構體中的信息來設置標記列表。
第一階段調用start_armboot指向C語言執行代碼區，首先它要從內存上的重定位數據獲得不完全配置的全局數據表格和板級信息表格，即獲得gd_t和bd_t。
這兩個類型變量記錄了剛啟動時的信息，并將要記錄作為引導內核和文件系統的參數，如bootargs等等，并且將來還會在啟動內核時，由uboot交由kernel時會有所用。
（3）init_sequence數組
U-Boot使用一個數組init_sequence來存儲對于大多數開發板都要執行的初始化函數的函數指針。init_sequence數組中有較多的編譯選項，去掉編譯選項后init_sequence數組如下所示：
typedef?int?(init_fnc_t)?(void);
init_fnc_t?*init_sequence[]?=?{
???????board_init,?????????/*開發板相關的配置--board/samsung/mini2440/mini2440.c?*/
???????timer_init,????????????/*?時鐘初始化--?cpu/arm920t/s3c24x0/timer.c?*/
???????env_init,????????????/*初始化環境變量--common/env_flash.c?或common/env_nand.c*/
???????init_baudrate,??????/*初始化波特率--?lib_arm/board.c?*/
???????serial_init,????????????/*?串口初始化--?drivers/serial/serial_s3c24x0.c?*/
???????console_init_f,????/*?控制通訊臺初始化階段1--?common/console.c?*/
???????display_banner,???/*打印U-Boot版本、編譯的時間--?gedit?lib_arm/board.c?*/
???????dram_init,????????????/*配置可用的RAM--?board/samsung/mini2440/mini2440.c?*/
???????display_dram_config,??/*?顯示RAM大小--?lib_arm/board.c?*/
???????NULL,
};
其中的board_init函數在board/samsung/mini2440/mini2440.c中定義，該函數設置了MPLLCOM，UPLLCON，以及一些GPIO寄存器的值，還設置了U-Boot機器碼和內核啟動參數地址?：
/*?MINI2440開發板的機器碼?*/
gd->bd->bi_arch_number?=?MACH_TYPE_MINI2440;
?
/*?內核啟動參數地址?*/
gd->bd->bi_boot_params=?0x30000100;??
其中的dram_init函數在board/samsung/mini2440/mini2440.c中定義如下：
int?dram_init?(void)
{
??????/*?由于mini2440只有?*/
??????gd->bd->bi_dram[0].start?=?PHYS_SDRAM_1;
??????gd->bd->bi_dram[0].size?=?PHYS_SDRAM_1_SIZE;
?
??????return?0;
}
mini2440使用2片32MB的SDRAM組成了64MB的內存，接在存儲控制器的BANK6，地址空間是0x30000000~0x34000000。
在include/configs/mini2440.h中PHYS_SDRAM_1和PHYS_SDRAM_1_SIZE?分別被定義為0x30000000和0x04000000（64M）。
（4）start_armboot函數
分析完上述的數據結構，下面來分析start_armboot函數：
void?start_armboot?(void)
{
???????init_fnc_t?**init_fnc_ptr;
???????char?*s;
???????…?…
???????/*?計算全局數據結構的地址gd?*/
???????gd?=?(gd_t*)(_armboot_start?-?CONFIG_SYS_MALLOC_LEN?-?sizeof(gd_t));
???????…?…
???????memset?((void*)gd,?0,?sizeof?(gd_t));
???????gd->bd?=?(bd_t*)((char*)gd?-?sizeof(bd_t));
???????memset?(gd->bd,?0,?sizeof?(bd_t));
???????gd->flags?|=?GD_FLG_RELOC;
?
???????monitor_flash_len?=?_bss_start?-?_armboot_start;
?
???/*?逐個調用init_sequence數組中的初始化函數??*/
???????for?(init_fnc_ptr?=?init_sequence;?*init_fnc_ptr;?++init_fnc_ptr)?{
??????????????if?((*init_fnc_ptr)()?!=?0)?{
?????????????????????hang?();
??????????????}
???????}
?
??/*?armboot_start?在cpu/arm920t/start.S?中被初始化為u-boot.lds連接腳本中的_start?*/
???????mem_malloc_init?(_armboot_start?-?CONFIG_SYS_MALLOC_LEN,
?????????????????????CONFIG_SYS_MALLOC_LEN);
?
/*?NOR?Flash初始化?*/
#ifndef?CONFIG_SYS_NO_FLASH
???????/*?configure?available?FLASH?banks?*/
???????display_flash_config?(flash_init?());
#endif?/*?CONFIG_SYS_NO_FLASH?*/
?
???????…?…
/*?NAND?Flash?初始化*/
#if?defined(CONFIG_CMD_NAND)
???????puts?("NAND:??");
???????nand_init();?????????/*?go?init?the?NAND?*/
#endif
???????…?…
???????/*?配置環境變量，重新定位?*/
???????env_relocate?();
???????…?…
???????/*?從環境變量中獲取IP地址?*/
???????gd->bd->bi_ip_addr?=?getenv_IPaddr?("ipaddr");
???????stdio_init?();?/*?get?the?devices?list?going.?*/
???????jumptable_init?();
???????…?…
???????console_init_r?();?/*?fully?init?console?as?a?device?*/
???????…?…
???????/*?enable?exceptions?*/
???????enable_interrupts?();
?
#ifdef?CONFIG_USB_DEVICE
???????usb_init_slave();
#endif
?
???????/*?Initialize?from?environment?*/
???????if?((s?=?getenv?("loadaddr"))?!=?NULL)?{
??????????????load_addr?=?simple_strtoul?(s,?NULL,?16);
???????}
#if?defined(CONFIG_CMD_NET)
???????if?((s?=?getenv?("bootfile"))?!=?NULL)?{
??????????????copy_filename?(BootFile,?s,?sizeof?(BootFile));
???????}
#endif
???????…?…
???????/*?網卡初始化?*/
#if?defined(CONFIG_CMD_NET)
#if?defined(CONFIG_NET_MULTI)
???????puts?("Net:???");
#endif
???????eth_initialize(gd->bd);
…?…
#endif
?
???????/*?main_loop()?can?return?to?retry?autoboot,?if?so?just?run?it?again.?*/
???????for?(;;)?{
??????????????main_loop?();
???????}
???????/*?NOTREACHED?-?no?way?out?of?command?loop?except?booting?*/
}
???????main_loop函數在common/main.c中定義。一般情況下，進入main_loop函數若干秒內沒有
（5）U-Boot啟動Linux過程
U-Boot使用標記列表（tagged?list）的方式向Linux傳遞參數。標記的數據結構式是tag，在U-Boot源代碼目錄include/asm-arm/setup.h中定義如下：
struct?tag_header?{
???????u32?size;???????/*?表示tag數據結構的聯合u實質存放的數據的大小*/
???????u32?tag;????????/*?表示標記的類型?*/
};
?
struct?tag?{
???????struct?tag_header?hdr;
???????union?{
??????????????struct?tag_core???????????core;
??????????????struct?tag_mem32??????mem;
??????????????struct?tag_videotext???videotext;
??????????????struct?tag_ramdisk?????ramdisk;
??????????????struct?tag_initrd??initrd;
??????????????struct?tag_serialnr???????serialnr;
??????????????struct?tag_revision??????revision;
??????????????struct?tag_videolfb?????videolfb;
??????????????struct?tag_cmdline?????cmdline;
?
??????????????/*
???????????????*?Acorn?specific
???????????????*/
??????????????struct?tag_acorn??acorn;
??????????????/*
???????????????*?DC21285?specific
???????????????*/
??????????????struct?tag_memclk??????memclk;
???????}?u;
};
U-Boot使用命令bootm來啟動已經加載到內存中的內核。而bootm命令實際上調用的是do_bootm函數。對于Linux內核，do_bootm函數會調用do_bootm_linux函數來設置標記列表和啟動內核。do_bootm_linux函數在lib_arm/bootm.c?中定義如下：
59???int?do_bootm_linux(int?flag,?int?argc,?char?*argv[],?bootm_headers_t?*images)
60???{
61???????bd_t???????*bd?=?gd->bd;
62???????char???????*s;
63???????int???machid?=?bd->bi_arch_number;
64???????void???????(*theKernel)(int?zero,?int?arch,?uint?params);
65??
66???#ifdef?CONFIG_CMDLINE_TAG
67???????char?*commandline?=?getenv?("bootargs");???/*?U-Boot環境變量bootargs?*/
68???#endif
???????…?…
73???????theKernel?=?(void?(*)(int,?int,?uint))images->ep;?/*?獲取內核入口地址?*/
???????…?…
86???#if?defined?(CONFIG_SETUP_MEMORY_TAGS)?||?\
87???????defined?(CONFIG_CMDLINE_TAG)?||?\
88???????defined?(CONFIG_INITRD_TAG)?||?\
89???????defined?(CONFIG_SERIAL_TAG)?||?\
90???????defined?(CONFIG_REVISION_TAG)?||?\
91???????defined?(CONFIG_LCD)?||?\
92???????defined?(CONFIG_VFD)
93???????setup_start_tag?(bd);?????????????????????????????????????/*?設置ATAG_CORE標志?*/
???????…?…
100??#ifdef?CONFIG_SETUP_MEMORY_TAGS
101??????setup_memory_tags?(bd);?????????????????????????????/*?設置內存標記?*/
102??#endif
103??#ifdef?CONFIG_CMDLINE_TAG
104??????setup_commandline_tag?(bd,?commandline);??????/*?設置命令行標記?*/
105??#endif
???????…?…
113??????setup_end_tag?(bd);???????????????????????????????/*?設置ATAG_NONE標志?*/??????????
114??#endif
115?
116??????/*?we?assume?that?the?kernel?is?in?place?*/
117??????printf?("\nStarting?kernel?...\n\n");
???????…?…
126??????cleanup_before_linux?();??????????/*?啟動內核前對CPU作最后的設置?*/
127?
128??????theKernel?(0,?machid,?bd->bi_boot_params);??????/*?調用內核?*/
129??????/*?does?not?return?*/
130?
131??????return?1;
132??}
其中的setup_start_tag，setup_memory_tags，setup_end_tag函數在lib_arm/bootm.c中定義如下：
1）setup_start_tag函數
static?void?setup_start_tag?(bd_t?*bd)
{
???????params?=?(struct?tag?*)?bd->bi_boot_params;??/*?內核的參數的開始地址?*/
?
???????params->hdr.tag?=?ATAG_CORE;
???????params->hdr.size?=?tag_size?(tag_core);
?
???????params->u.core.flags?=?0;
???????params->u.core.pagesize?=?0;
???????params->u.core.rootdev?=?0;
?
???????params?=?tag_next?(params);
}
標記列表必須以ATAG_CORE開始，setup_start_tag函數在內核的參數的開始地址設置了一個ATAG_CORE標記。
2）setup_memory_tags函數
static?void?setup_memory_tags?(bd_t?*bd)
{
???????int?i;
/*設置一個內存標記?*/
???????for?(i?=?0;?i?<?CONFIG_NR_DRAM_BANKS;?i++)?{???
??????????????params->hdr.tag?=?ATAG_MEM;
??????????????params->hdr.size?=?tag_size?(tag_mem32);
?
??????????????params->u.mem.start?=?bd->bi_dram[i].start;
??????????????params->u.mem.size?=?bd->bi_dram[i].size;
?
??????????????params?=?tag_next?(params);
???????}
}
setup_memory_tags函數設置了一個ATAG_MEM標記，該標記包含內存起始地址，內存大小這兩個參數。
3）setup_end_tag函數
static?void?setup_end_tag?(bd_t?*bd)
{
???????params->hdr.tag?=?ATAG_NONE;
???????params->hdr.size?=?0;
}
標記列表必須以標記ATAG_NONE結束，setup_end_tag函數設置了一個ATAG_NONE標記，表示標記列表的結束。
U-Boot設置好標記列表后就要調用內核了。但調用內核前，CPU必須滿足下面的條件：
1）CPU寄存器的設置
l?r0=0
l?r1=機器碼
l?r2=內核參數標記列表在RAM中的起始地址
2）CPU工作模式
l?禁止IRQ與FIQ中斷
l?CPU為SVC模式
3）使數據Cache與指令Cache失效
do_bootm_linux中調用的cleanup_before_linux函數完成了禁止中斷和使Cache失效的功能。cleanup_before_linux函數在cpu/arm920t/cpu.中定義：
int?cleanup_before_linux?(void)
{
???????/*
????????*?this?function?is?called?just?before?we?call?linux
????????*?it?prepares?the?processor?for?linux
????????*
????????*?we?turn?off?caches?etc?...
????????*/
?
???????disable_interrupts?();?????????/*?禁止FIQ/IRQ中斷?*/
?
???????/*?turn?off?I/D-cache?*/
???????icache_disable();???????????????/*?使指令Cache失效?*/
???????dcache_disable();??????????????/*?使數據Cache失效?*/
???????/*?flush?I/D-cache?*/
???????cache_flush();????????????????????/*?刷新Cache?*/
?
???????return?0;
}
由于U-Boot啟動以來就一直工作在SVC模式，因此CPU的工作模式就無需設置了。
do_bootm_linux中：
64???????void???????(*theKernel)(int?zero,?int?arch,?uint?params);
…?…
73???????theKernel?=?(void?(*)(int,?int,?uint))images->ep;
…?…
128??????theKernel?(0,?machid,?bd->bi_boot_params);
第73行代碼將內核的入口地址“images->ep”強制類型轉換為函數指針。根據ATPCS規則，函數的參數個數不超過4個時，使用r0~r3這4個寄存器來傳遞參數。因此第128行的函數調用則會將0放入r0，機器碼machid放入r1，內核參數地址bd->bi_boot_params放入r2，從而完成了寄存器的設置，最后轉到內核的入口地址。
到這里，U-Boot的工作就結束了，系統跳轉到Linux內核代碼執行。
（6）U-Boot添加命令的方法及U-Boot命令執行過程
下面以添加menu命令（啟動菜單）為例講解U-Boot添加命令的方法。
1）建立common/cmd_menu.c
習慣上通用命令源代碼放在common目錄下，與開發板專有命令源代碼則放在board/<board_dir>目錄下，并且習慣以“cmd_<命令名>.c”為文件名。
2）定義“menu”命令
在cmd_menu.c中使用如下的代碼定義“menu”命令：
_BOOT_CMD(
???????menu,????3,????0,????do_menu,
???????"menu?-?display?a?menu,?to?select?the?items?to?do?something\n",
???????"?-?display?a?menu,?to?select?the?items?to?do?something"
);
其中U_BOOT_CMD命令格式如下：
U_BOOT_CMD(name,maxargs,rep,cmd,usage,help)
各個參數的意義如下：
l?name：命令名，非字符串，但在U_BOOT_CMD中用“#”符號轉化為字符串
l?maxargs：命令的最大參數個數
l?rep：是否自動重復（按Enter鍵是否會重復執行）
l?cmd：該命令對應的響應函數
l?usage：簡短的使用說明（字符串）
l?help：較詳細的使用說明（字符串）
在內存中保存命令的help字段會占用一定的內存，通過配置U-Boot可以選擇是否保存help字段。若在include/configs/mini2440.h中定義了CONFIG_SYS_LONGHELP宏，則在U-Boot中使用help命令查看某個命令的幫助信息時將顯示usage和help字段的內容，否則就只顯示usage字段的內容。
U_BOOT_CMD宏在include/command.h中定義：
#define?U_BOOT_CMD(name,maxargs,rep,cmd,usage,help)?\
cmd_tbl_t?__u_boot_cmd_##name?Struct_Section?=?{#name,?maxargs,?rep,?cmd,?usage,?help}
“##”與“#”都是預編譯操作符，“##”有字符串連接的功能，“#”表示后面緊接著的是一個字符串。
其中的cmd_tbl_t在include/command.h中定義如下：
struct?cmd_tbl_s?{
???????char????????*name;??????????/*?命令名?*/
???????int??????????maxargs;???????/*?最大參數個數?*/
???????int??????????repeatable;????/*?是否自動重復?*/
???????int??????????(*cmd)(struct?cmd_tbl_s?*,?int,?int,?char?*[]);??/*??響應函數?*/
???????char????????*usage;?????????/*?簡短的幫助信息?*/
#ifdef????CONFIG_SYS_LONGHELP
???????char????????*help;???????????/*??較詳細的幫助信息?*/
#endif
#ifdef?CONFIG_AUTO_COMPLETE
???????/*?自動補全參數?*/
???????int??????????(*complete)(int?argc,?char?*argv[],?char?last_char,?int?maxv,?char?*cmdv[]);
#endif
};
typedef?struct?cmd_tbl_s??cmd_tbl_t;
一個cmd_tbl_t結構體變量包含了調用一條命令的所需要的信息。
其中Struct_Section在include/command.h中定義如下：
#define?Struct_Section??__attribute__?((unused,section?(".u_boot_cmd")))
凡是帶有__attribute__?((unused,section?(".u_boot_cmd"))屬性聲明的變量都將被存放在".u_boot_cmd"段中，并且即使該變量沒有在代碼中顯式的使用編譯器也不產生警告信息。
在U-Boot連接腳本u-boot.lds中定義了".u_boot_cmd"段：
.?=?.;
__u_boot_cmd_start?=?.;??????????/*將?__u_boot_cmd_start指定為當前地址?*/
.u_boot_cmd?:?{?*(.u_boot_cmd)?}
__u_boot_cmd_end?=?.;???????????/*??將__u_boot_cmd_end指定為當前地址??*/
這表明帶有“.u_boot_cmd”聲明的函數或變量將存儲在“u_boot_cmd”段。這樣只要將U-Boot所有命令對應的cmd_tbl_t變量加上“.u_boot_cmd”聲明，編譯器就會自動將其放在“u_boot_cmd”段，查找cmd_tbl_t變量時只要在__u_boot_cmd_start與__u_boot_cmd_end之間查找就可以了。
因此“menu”命令的定義經過宏展開后如下：
cmd_tbl_t?__u_boot_cmd_menu?__attribute__?((unused,section?(".u_boot_cmd")))?=?{menu,?3,?0,?do_menu,?"menu?-?display?a?menu,?to?select?the?items?to?do?something\n",?"?-?display?a?menu,?to?select?the?items?to?do?something"}
實質上就是用U_BOOT_CMD宏定義的信息構造了一個cmd_tbl_t類型的結構體。編譯器將該結構體放在“u_boot_cmd”段，執行命令時就可以在“u_boot_cmd”段查找到對應的cmd_tbl_t類型結構體。
3）實現命令的函數
在cmd_menu.c中添加“menu”命令的響應函數的實現。具體的實現代碼略：
int?do_menu?(cmd_tbl_t?*cmdtp,?int?flag,?int?argc,?char?*argv[])
{
???????/*?實現代碼略?*/
}
4）將common/cmd_menu.c編譯進u-boot.bin
在common/Makefile中加入如下代碼：
COBJS-$(CONFIG_BOOT_MENU)?+=?cmd_menu.o
在include/configs/mini2440.h加入如代碼：
#define?CONFIG_BOOT_MENU?1
重新編譯下載U-Boot就可以使用menu命令了
5）menu命令執行的過程
在U-Boot中輸入“menu”命令執行時，U-Boot接收輸入的字符串“menu”，傳遞給run_command函數。run_command函數調用common/command.c中實現的find_cmd函數在__u_boot_cmd_start與__u_boot_cmd_end間查找命令，并返回menu命令的cmd_tbl_t結構。然后run_command函數使用返回的cmd_tbl_t結構中的函數指針調用menu命令的響應函數do_menu，從而完成了命令的執行。
(改編自：http://blog.csdn.net/hare_lee/article/details/6916325)
總結
以上是生活随笔為你收集整理的U-Boot启动过程--详细版的完全分析的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Uboot启动流程分析
- 下一篇： 信号量、互斥体和自旋锁