我們知道，bootloader是系統上電後最初加載運行的代碼。它提供了處理器上電覆位後最開始需要執行的初始化代碼。
在PC機上引導程序一般由BIOS開始執行，然後讀取硬盤中位於MBR(Main Boot Record，主引導記錄)中的Bootloader(例如LILO或GRUB),並進一步引導操作系統的啓動。
然而在嵌入式系統中通常沒有像BIOS那樣的固件程序，因此整個系統的加載啓動就完全由bootloader來完成。它主要的功能是加載與引導內核映像
一個嵌入式的存儲設備通過通常包括四個分區：
第一分區：存放的當然是u-boot
第二個分區：存放着u-boot要傳給系統內核的參數
第三個分區：是系統內核（kernel）
第四個分區：則是根文件系統
如下圖所示：
-------------------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------------------------------------
u-boot是一種普遍用於嵌入式系統中的Bootloader。
Bootloader介紹
Bootloader是進行嵌入式開發必然會接觸的一個概念，它是嵌入式學院<嵌入式工程師職業培訓班>二期課程中嵌入式linux系統開發方面的重要內容。本篇文章主要講解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的源程序。
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的使用過程中都用到了。
U-boot的定義
U-boot，全稱Universal Boot Loader，是由DENX小組的開發的遵循GPL條款的開放源碼項目，它的主要功能是完成硬件設備初始化、操作系統代碼搬運，並提供一個控制檯及一個指令集在操作系統運行前操控硬件設備。U-boot之所以這麼通用，原因是他具有很多特點：開放源代碼、支持多種嵌入式操作系統內核、支持多種處理器系列、較高的穩定性、高度靈活的功能設置、豐富的設備驅動源碼以及較爲豐富的開發調試文檔與強大的網絡技術支持。另外u-boot對操作系統和產品研發提供了靈活豐富的支持，主要表現在：可以引導壓縮或非壓縮系統內核，可以靈活設置/傳遞多個關鍵參數給操作系統，適合系統在不同開發階段的調試要求與產品發佈，支持多種文件系統，支持多種目標板環境參數存儲介質，採用CRC32校驗，可校驗內核及鏡像文件是否完好，提供多種控制檯接口，使用戶可以在不需要ICE的情況下通過串口/以太網/USB等接口下載數據並燒錄到存儲設備中去（這個功能在實際的產品中是很實用的，尤其是在軟件現場升級的時候），以及提供豐富的設備驅動等。
u-boot源代碼的目錄結構
1、board中存放於開發板相關的配置文件，每一個開發板都以子文件夾的形式出現。
2、Commom文件夾實現u-boot行下支持的命令，每一個命令對應一個文件。
3、cpu中存放特定cpu架構相關的目錄，每一款cpu架構都對應了一個子目錄。
4、Doc是文檔目錄，有u-boot非常完善的文檔。
5、Drivers中是u-boot支持的各種設備的驅動程序。
6、Fs是支持的文件系統，其中最常用的是JFFS2文件系統。
7、Include文件夾是u-boot使用的頭文件，還有各種硬件平臺支持的彙編文件，系統配置文件和文件系統支持的文件。
8、Net是與網絡協議相關的代碼，bootp協議、TFTP協議、NFS文件系統得實現。
9、Tooles是生成U-boot的工具。
對u-boot的目錄有了一些瞭解後，分析啓動代碼的過程就方便多了，其中比較重要的目錄就是/board、/cpu、/drivers和/include目錄，如果想實現u-boot在一個平臺上的移植，就要對這些目錄進行深入的分析。
-------------------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------------------------------------
什麼是《編譯地址》？什麼是《運行地址》？
（一）編譯地址： 32位的處理器，它的每一條指令是4個字節，以4個字節存儲順序，進行順序執行，CPU是順序執行的，只要沒發生什麼跳轉，它會順序進行執行行， 編譯器會對每一條指令分配一個編譯地址，這是編譯器分配的，在編譯過程中分配的地址，我們稱之爲編譯地址。
（二）運行地址：是指程序指令真正運行的地址，是由用戶指定的，用戶將運行地址燒錄到哪裏，哪裏就是運行的地址。
比如有一個指令的編譯地址是0x5，實際運行的地址是0x200，如果用戶將指令燒到0x200上，那麼這條指令的運行地址就是0x200，
當編譯地址和運行地址不同的時候會出現什麼結果？結果是不能跳轉，編譯後會產生跳轉地址，如果實際地址和編譯後產生的地址不相等，那麼就不能跳轉。
C語言編譯地址：都希望把編譯地址和實際運行地址放在一起的，但是彙編代碼因爲不需要做C語言到彙編的轉換，可以認爲的去寫地址，所以直接寫的就是他的運行地址這就是爲什麼任何bootloader剛開始會有一段彙編代碼，因爲起始代碼編譯地址和實際地址不相等，這段代碼和彙編無關，跳轉用的運行地址。
編譯地址和運行地址如何來算呢？
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，就是這樣算出來的。
爲什麼要分配編譯地址？這樣做有什麼好處，有什麼作用？
比如在函數a中定義了函數b，當執行到函數b時要進行指令跳轉，要跳轉到b函數所對應的起始地址上去，編譯時，編譯器給每條指令都分配了編譯地址，如果編譯器已經給分配了地址就可以直接進行跳轉，查找b函數跳轉指令所對應的表，進行直接跳轉，因爲有個編譯地址和指令對應的一個表，如果沒有分配，編譯器就查找不到這個跳轉地址，要進行計算，非常麻煩。
什麼是《相對地址》？
以NOR Flash爲例，NOR Falsh是映射到bank0上面，SDRAM是映射到bank6上面，uboot和內核最終是在SDRAM上面運行，最開始我們是從Nor Flash的零地址開始往後燒錄，uboot中至少有一段代碼編譯地址和運行地址是不一樣的，編譯uboot或內核時，都會將編譯地址放入到SDRAM中，他們最終都會在SDRAM中執行，剛開始uboot在Nor Flash中運行，運行地址是一個低端地址，是bank0中的一個地址，但編譯地址是bank6中的地址，這樣就會導致絕對跳轉指令執行的失敗，所以就引出了相對地址的概念。
那麼什麼是相對地址呢？
至少在bank0中uboot這段代碼要知道不能用b+編譯地址這樣的方法去跳轉指令，因爲這段代碼的編譯地址和運行地址不一樣，那如何去做呢？
要去計算這個指令運行的真實地址，計算出來後再做跳轉，應該是b+運行地址，不能出現b+編譯地址，而是b+運行地址，而運行地址是算出來的。
_TEXT_BASE:
.word TEXT_BASE //0x33F80000,在board/config.mk中
這段話表示，用戶告訴編譯器編譯地址的起始地址
-------------------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------------------------------------
U-Boot工作過程
大多數 Boot Loader 都包含兩種不同的操作模式:"啓動加載"模式和"下載"模式,這種區別僅對於開發人員纔有意義。
但從最終用戶的角度看,Boot Loader 的作用就是:用來加載操作系統,而並不存在所謂的啓動加載模式與下載工作模式的區別。
(一)啓動加載(Boot loading)模式:這種模式也稱爲"自主"(Autonomous)模式。
也即 Boot Loader 從目標機上的某個固態存儲設備上將操作系統加載到 RAM 中運行,整個過程並沒有用戶的介入。
這種模式是 Boot Loader 的正常工作模式,因此在嵌入式產品發佈的時侯,Boot Loader 顯然必須工作在這種模式下。
（二）下載(Downloading)模式:在這種模式下,目標機上的 Boot Loader 將通過串口連接或網絡連接等通信手段從主機(Host)下載文件,比如:下載內核映像和根文件系統映像等。從主機下載的文件通常首先被 Boot Loader保存到目標機的RAM 中,然後再被 BootLoader寫到目標機上的FLASH類固態存儲設備中。Boot Loader 的這種模式通常在第一次安裝內核與根文件系統時被使用;此外,以後的系統更新也會使用 Boot Loader 的這種工作模式。工作於這種模式下的 Boot Loader 通常都會向它的終端用戶提供一個簡單的命令行接口。這種工作模式通常在第一次安裝內核與跟文件系統時使用。或者在系統更新時使用。進行嵌入式系統調試時一般也讓bootloader工作在這一模式下。
UBoot 這樣功能強大的 Boot Loader 同時支持這兩種工作模式,而且允許用戶在這兩種工作模式之間進行切換。
大多數 bootloader 都分爲階段 1(stage1)和階段 2(stage2)兩大部分,uboot 也不例外。依賴於 CPU 體系結構的代碼(如 CPU 初始化代碼等)通常都放在階段 1 中且通常用匯編語言實現,而階段 2 則通常用 C 語言來實現,這樣可以實現複雜的功能,而且有更好的可讀性和移植性。
-------------------------------------------------------------------------------------------------------------------------------------------
第一、大概總結性得的分析
系統啓動的入口點。既然我們現在要分析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 搬移後內存分佈情況圖
下來是u-boot啓動的第二個階段，是用c代碼寫的，
這部分是一些相對變化不大的部分，我們針對不同的板子改變它調用的一些初始化函數，並且通過設置一些宏定義來改變初始化的流程，
所以這些代碼在移植的過程中並不需要修改，也是錯誤相對較少出現的文件。
在文件的開始先是定義了一個函數指針數組，通過這個數組，程序通過一個循環來按順序進行常規的初始化，並在其後通過一些宏定義來初始化一些特定的設備。
在最後程序進入一個循環，main_loop。這個循環接收用戶輸入的命令，以設置參數或者進行啓動引導。
本篇文章將分析重點放在了前面的start.s上，是因爲這部分無論在移植還是在調試過程中都是最容易出問題的地方，要解決問題就需要程序員對代碼進行修改，所以在這裏簡單介紹了一下start.s的基本流程，希望能對大家有所幫助
-------------------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------------------------------------
第二、代碼分析
2.2 階段 1 介紹
uboot 的 stage1 代碼通常放在 start.s 文件中,它用匯編語言寫成,其主要代碼部分如下:
2.2.1 定義入口
由於一個可執行的 Image 必須有一個入口點,並且只能有一個全局入口,通常這個入口放在 ROM(Flash)的 0x0
地址,因此,必須通知編譯器以使其知道這個入口,該工作可通過修改連接器腳本來完成。
1. board/crane2410/uboot.lds: ENTRY(_start) ==> cpu/arm920t/start.S: .globl _start
2. uboot 代碼區(TEXT_BASE = 0x33F80000)定義在 board/crane2410/config.mk
U-Boot啓動內核的過程可以分爲兩個階段，兩個階段的功能如下：
（1）第一階段的功能
Ø 硬件設備初始化
Ø 加載U-Boot第二階段代碼到RAM空間
Ø 設置好棧
Ø 跳轉到第二階段代碼入口
（2）第二階段的功能
Ø 初始化本階段使用的硬件設備
Ø 檢測系統內存映射
Ø 將內核從Flash讀取到RAM中
Ø 爲內核設置啓動參數
Ø 調用內核
1.1.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. 硬件設備初始化
（1）設置異常向量
下面代碼是系統啓動後U-boot上電後運行的第一段代碼，它是什麼意思？
u-boot對應的第一階段代碼放在cpu/arm920t/start.S文件中，入口代碼如下：.
globl _startglobal /*聲明一個符號可被其它文件引用，相當於聲明瞭一個全局變量，.globl與.global相同*/
_start: b start_code /* 復位 */b是不帶返回的跳轉(bl是帶返回的跳轉)，意思是無條件直接跳轉到start_code標號出執行程序
ldr pc, _undefined_instruction /* 未定義指令向量 l---dr相當於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 CLKDIVN 0x14800014 /*;時鐘分頻寄存器*/
#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
當開發板很複雜時，有好幾個cpu時，就不能完全讓板子復位，但我們通常都讓整個板子復位。看門狗每隔短時間就會餵狗，問題是在兩次餵狗之間的時間間隔內，運行的代碼的時間是否夠用，兩次餵狗之間的代碼是否在兩次餵狗的時間延遲之內，如果在延遲之外的話，代碼還沒改完就又進行餵狗，代碼永遠也改不完
（5）屏蔽中斷
/*
* mask all IRQs by setting all bits in the INTMR - default
*/
mov r1, #0xffffffff /*屏蔽所有中斷， 某位被置1則對應的中斷被屏蔽 */ /*寄存器中的值*/
ldr r0, =INTMSK /*將管理中斷的寄存器地址賦給ro*/
str r1, [r0] /*將全r1的值賦給ro地址中的內容*/
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 的值爲 120 MHz,該值爲 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 mov r0, #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 mov ip, lr
345
346 bl lowlevel_init
347
348 mov lr, ip
349 mov pc, 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 ldr r0, =SMRDATA
138 ldr r1, _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啓動 */
cmp r0, #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處。
1.1.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）。
分析完上述的數據結構，下面來分析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函數若干秒內沒有
1.1.3 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寄存器的設置
Ø r0=0
Ø r1=機器碼
Ø r2=內核參數標記列表在RAM中的起始地址
（2） CPU工作模式
Ø 禁止IRQ與FIQ中斷
Ø 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內核代碼執行。
1.1.4 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)
各個參數的意義如下：
name：命令名，非字符串，但在U_BOOT_CMD中用“#”符號轉化爲字符串
maxargs：命令的最大參數個數
rep：是否自動重複（按Enter鍵是否會重複執行）
cmd：該命令對應的響應函數
usage：簡短的使用說明（字符串）
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，從而完成了命令的執行。
作者：heaad
http://www.cnblogs.com/heaad/
本文摘選自作者所寫的一篇文章。轉載請註明，水平有限，歡迎拍磚。
-------------------------------------------------------------------------------------------------------------------------------------------
我們知道，bootloader是系統上電後最初加載運行的代碼。它提供了處理器上電覆位後最開始需要執行的初始化代碼。
在PC機上引導程序一般由BIOS開始執行，然後讀取硬盤中位於MBR(Main Boot Record，主引導記錄)中的Bootloader(例如LILO或GRUB),並進一步引導操作系統的啓動。
然而在嵌入式系統中通常沒有像BIOS那樣的固件程序，因此整個系統的加載啓動就完全由bootloader來完成。它主要的功能是加載與引導內核映像
一個嵌入式的存儲設備通過通常包括四個分區：
第一分區：存放的當然是u-boot
第二個分區：存放着u-boot要傳給系統內核的參數
第三個分區：是系統內核（kernel）
第四個分區：則是根文件系統
如下圖所示：
-------------------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------------------------------------
u-boot是一種普遍用於嵌入式系統中的Bootloader。
Bootloader介紹
Bootloader是進行嵌入式開發必然會接觸的一個概念，它是嵌入式學院<嵌入式工程師職業培訓班>二期課程中嵌入式linux系統開發方面的重要內容。本篇文章主要講解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的源程序。
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的使用過程中都用到了。
U-boot的定義
U-boot，全稱Universal Boot Loader，是由DENX小組的開發的遵循GPL條款的開放源碼項目，它的主要功能是完成硬件設備初始化、操作系統代碼搬運，並提供一個控制檯及一個指令集在操作系統運行前操控硬件設備。U-boot之所以這麼通用，原因是他具有很多特點：開放源代碼、支持多種嵌入式操作系統內核、支持多種處理器系列、較高的穩定性、高度靈活的功能設置、豐富的設備驅動源碼以及較爲豐富的開發調試文檔與強大的網絡技術支持。另外u-boot對操作系統和產品研發提供了靈活豐富的支持，主要表現在：可以引導壓縮或非壓縮系統內核，可以靈活設置/傳遞多個關鍵參數給操作系統，適合系統在不同開發階段的調試要求與產品發佈，支持多種文件系統，支持多種目標板環境參數存儲介質，採用CRC32校驗，可校驗內核及鏡像文件是否完好，提供多種控制檯接口，使用戶可以在不需要ICE的情況下通過串口/以太網/USB等接口下載數據並燒錄到存儲設備中去（這個功能在實際的產品中是很實用的，尤其是在軟件現場升級的時候），以及提供豐富的設備驅動等。
u-boot源代碼的目錄結構
1、board中存放於開發板相關的配置文件，每一個開發板都以子文件夾的形式出現。
2、Commom文件夾實現u-boot行下支持的命令，每一個命令對應一個文件。
3、cpu中存放特定cpu架構相關的目錄，每一款cpu架構都對應了一個子目錄。
4、Doc是文檔目錄，有u-boot非常完善的文檔。
5、Drivers中是u-boot支持的各種設備的驅動程序。
6、Fs是支持的文件系統，其中最常用的是JFFS2文件系統。
7、Include文件夾是u-boot使用的頭文件，還有各種硬件平臺支持的彙編文件，系統配置文件和文件系統支持的文件。
8、Net是與網絡協議相關的代碼，bootp協議、TFTP協議、NFS文件系統得實現。
9、Tooles是生成U-boot的工具。
對u-boot的目錄有了一些瞭解後，分析啓動代碼的過程就方便多了，其中比較重要的目錄就是/board、/cpu、/drivers和/include目錄，如果想實現u-boot在一個平臺上的移植，就要對這些目錄進行深入的分析。
-------------------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------------------------------------
什麼是《編譯地址》？什麼是《運行地址》？
（一）編譯地址： 32位的處理器，它的每一條指令是4個字節，以4個字節存儲順序，進行順序執行，CPU是順序執行的，只要沒發生什麼跳轉，它會順序進行執行行， 編譯器會對每一條指令分配一個編譯地址，這是編譯器分配的，在編譯過程中分配的地址，我們稱之爲編譯地址。
（二）運行地址：是指程序指令真正運行的地址，是由用戶指定的，用戶將運行地址燒錄到哪裏，哪裏就是運行的地址。
比如有一個指令的編譯地址是0x5，實際運行的地址是0x200，如果用戶將指令燒到0x200上，那麼這條指令的運行地址就是0x200，
當編譯地址和運行地址不同的時候會出現什麼結果？結果是不能跳轉，編譯後會產生跳轉地址，如果實際地址和編譯後產生的地址不相等，那麼就不能跳轉。
C語言編譯地址：都希望把編譯地址和實際運行地址放在一起的，但是彙編代碼因爲不需要做C語言到彙編的轉換，可以認爲的去寫地址，所以直接寫的就是他的運行地址這就是爲什麼任何bootloader剛開始會有一段彙編代碼，因爲起始代碼編譯地址和實際地址不相等，這段代碼和彙編無關，跳轉用的運行地址。
編譯地址和運行地址如何來算呢？
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，就是這樣算出來的。
爲什麼要分配編譯地址？這樣做有什麼好處，有什麼作用？
比如在函數a中定義了函數b，當執行到函數b時要進行指令跳轉，要跳轉到b函數所對應的起始地址上去，編譯時，編譯器給每條指令都分配了編譯地址，如果編譯器已經給分配了地址就可以直接進行跳轉，查找b函數跳轉指令所對應的表，進行直接跳轉，因爲有個編譯地址和指令對應的一個表，如果沒有分配，編譯器就查找不到這個跳轉地址，要進行計算，非常麻煩。
什麼是《相對地址》？
以NOR Flash爲例，NOR Falsh是映射到bank0上面，SDRAM是映射到bank6上面，uboot和內核最終是在SDRAM上面運行，最開始我們是從Nor Flash的零地址開始往後燒錄，uboot中至少有一段代碼編譯地址和運行地址是不一樣的，編譯uboot或內核時，都會將編譯地址放入到SDRAM中，他們最終都會在SDRAM中執行，剛開始uboot在Nor Flash中運行，運行地址是一個低端地址，是bank0中的一個地址，但編譯地址是bank6中的地址，這樣就會導致絕對跳轉指令執行的失敗，所以就引出了相對地址的概念。
那麼什麼是相對地址呢？
至少在bank0中uboot這段代碼要知道不能用b+編譯地址這樣的方法去跳轉指令，因爲這段代碼的編譯地址和運行地址不一樣，那如何去做呢？
要去計算這個指令運行的真實地址，計算出來後再做跳轉，應該是b+運行地址，不能出現b+編譯地址，而是b+運行地址，而運行地址是算出來的。
_TEXT_BASE:
.word TEXT_BASE //0x33F80000,在board/config.mk中
這段話表示，用戶告訴編譯器編譯地址的起始地址
-------------------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------------------------------------
U-Boot工作過程
大多數 Boot Loader 都包含兩種不同的操作模式:"啓動加載"模式和"下載"模式,這種區別僅對於開發人員纔有意義。
但從最終用戶的角度看,Boot Loader 的作用就是:用來加載操作系統,而並不存在所謂的啓動加載模式與下載工作模式的區別。
(一)啓動加載(Boot loading)模式:這種模式也稱爲"自主"(Autonomous)模式。
也即 Boot Loader 從目標機上的某個固態存儲設備上將操作系統加載到 RAM 中運行,整個過程並沒有用戶的介入。
這種模式是 Boot Loader 的正常工作模式,因此在嵌入式產品發佈的時侯,Boot Loader 顯然必須工作在這種模式下。
（二）下載(Downloading)模式:在這種模式下,目標機上的 Boot Loader 將通過串口連接或網絡連接等通信手段從主機(Host)下載文件,比如:下載內核映像和根文件系統映像等。從主機下載的文件通常首先被 Boot Loader保存到目標機的RAM 中,然後再被 BootLoader寫到目標機上的FLASH類固態存儲設備中。Boot Loader 的這種模式通常在第一次安裝內核與根文件系統時被使用;此外,以後的系統更新也會使用 Boot Loader 的這種工作模式。工作於這種模式下的 Boot Loader 通常都會向它的終端用戶提供一個簡單的命令行接口。這種工作模式通常在第一次安裝內核與跟文件系統時使用。或者在系統更新時使用。進行嵌入式系統調試時一般也讓bootloader工作在這一模式下。
UBoot 這樣功能強大的 Boot Loader 同時支持這兩種工作模式,而且允許用戶在這兩種工作模式之間進行切換。
大多數 bootloader 都分爲階段 1(stage1)和階段 2(stage2)兩大部分,uboot 也不例外。依賴於 CPU 體系結構的代碼(如 CPU 初始化代碼等)通常都放在階段 1 中且通常用匯編語言實現,而階段 2 則通常用 C 語言來實現,這樣可以實現複雜的功能,而且有更好的可讀性和移植性。
-------------------------------------------------------------------------------------------------------------------------------------------
第一、大概總結性得的分析
系統啓動的入口點。既然我們現在要分析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 搬移後內存分佈情況圖
下來是u-boot啓動的第二個階段，是用c代碼寫的，
這部分是一些相對變化不大的部分，我們針對不同的板子改變它調用的一些初始化函數，並且通過設置一些宏定義來改變初始化的流程，
所以這些代碼在移植的過程中並不需要修改，也是錯誤相對較少出現的文件。
在文件的開始先是定義了一個函數指針數組，通過這個數組，程序通過一個循環來按順序進行常規的初始化，並在其後通過一些宏定義來初始化一些特定的設備。
在最後程序進入一個循環，main_loop。這個循環接收用戶輸入的命令，以設置參數或者進行啓動引導。
本篇文章將分析重點放在了前面的start.s上，是因爲這部分無論在移植還是在調試過程中都是最容易出問題的地方，要解決問題就需要程序員對代碼進行修改，所以在這裏簡單介紹了一下start.s的基本流程，希望能對大家有所幫助
-------------------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------------------------------------
第二、代碼分析
2.2 階段 1 介紹
uboot 的 stage1 代碼通常放在 start.s 文件中,它用匯編語言寫成,其主要代碼部分如下:
2.2.1 定義入口
由於一個可執行的 Image 必須有一個入口點,並且只能有一個全局入口,通常這個入口放在 ROM(Flash)的 0x0
地址,因此,必須通知編譯器以使其知道這個入口,該工作可通過修改連接器腳本來完成。
1. board/crane2410/uboot.lds: ENTRY(_start) ==> cpu/arm920t/start.S: .globl _start
2. uboot 代碼區(TEXT_BASE = 0x33F80000)定義在 board/crane2410/config.mk
U-Boot啓動內核的過程可以分爲兩個階段，兩個階段的功能如下：
（1）第一階段的功能
Ø 硬件設備初始化
Ø 加載U-Boot第二階段代碼到RAM空間
Ø 設置好棧
Ø 跳轉到第二階段代碼入口
（2）第二階段的功能
Ø 初始化本階段使用的硬件設備
Ø 檢測系統內存映射
Ø 將內核從Flash讀取到RAM中
Ø 爲內核設置啓動參數
Ø 調用內核
1.1.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. 硬件設備初始化
（1）設置異常向量
下面代碼是系統啓動後U-boot上電後運行的第一段代碼，它是什麼意思？
u-boot對應的第一階段代碼放在cpu/arm920t/start.S文件中，入口代碼如下：.
globl _startglobal /*聲明一個符號可被其它文件引用，相當於聲明瞭一個全局變量，.globl與.global相同*/
_start: b start_code /* 復位 */b是不帶返回的跳轉(bl是帶返回的跳轉)，意思是無條件直接跳轉到start_code標號出執行程序
ldr pc, _undefined_instruction /* 未定義指令向量 l---dr相當於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 CLKDIVN 0x14800014 /*;時鐘分頻寄存器*/
#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
當開發板很複雜時，有好幾個cpu時，就不能完全讓板子復位，但我們通常都讓整個板子復位。看門狗每隔短時間就會餵狗，問題是在兩次餵狗之間的時間間隔內，運行的代碼的時間是否夠用，兩次餵狗之間的代碼是否在兩次餵狗的時間延遲之內，如果在延遲之外的話，代碼還沒改完就又進行餵狗，代碼永遠也改不完
（5）屏蔽中斷
/*
* mask all IRQs by setting all bits in the INTMR - default
*/
mov r1, #0xffffffff /*屏蔽所有中斷， 某位被置1則對應的中斷被屏蔽 */ /*寄存器中的值*/
ldr r0, =INTMSK /*將管理中斷的寄存器地址賦給ro*/
str r1, [r0] /*將全r1的值賦給ro地址中的內容*/
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 的值爲 120 MHz,該值爲 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 mov r0, #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 mov ip, lr
345
346 bl lowlevel_init
347
348 mov lr, ip
349 mov pc, 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 ldr r0, =SMRDATA
138 ldr r1, _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啓動 */
cmp r0, #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處。
1.1.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）。
分析完上述的數據結構，下面來分析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函數若干秒內沒有
1.1.3 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寄存器的設置
Ø r0=0
Ø r1=機器碼
Ø r2=內核參數標記列表在RAM中的起始地址
（2） CPU工作模式
Ø 禁止IRQ與FIQ中斷
Ø 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內核代碼執行。
1.1.4 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)
各個參數的意義如下：
name：命令名，非字符串，但在U_BOOT_CMD中用“#”符號轉化爲字符串
maxargs：命令的最大參數個數
rep：是否自動重複（按Enter鍵是否會重複執行）
cmd：該命令對應的響應函數
usage：簡短的使用說明（字符串）
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，從而完成了命令的執行。
作者：heaad
http://www.cnblogs.com/heaad/
本文摘選自作者所寫的一篇文章。轉載請註明，水平有限，歡迎拍磚。