【ARM-Linux开发】U-Boot启动过程--详细版的完全分析
-------------------------------------------------------------------------------------------------------------------------------------------
?我們知道，bootloader是系統(tǒng)上電后最初加載運行的代碼。它提供了處理器上電復(fù)位后最開始需要執(zhí)行的初始化代碼。
??? 在PC機上引導(dǎo)程序一般由BIOS開始執(zhí)行，然后讀取硬盤中位于MBR(Main Boot Record，主引導(dǎo)記錄)中的Bootloader(例如LILO或GRUB),并進一步引導(dǎo)操作系統(tǒng)的啟動。
??? 然而在嵌入式系統(tǒng)中通常沒有像BIOS那樣的固件程序，因此整個系統(tǒng)的加載啟動就完全由bootloader來完成。它主要的功能是加載與引導(dǎo)內(nèi)核映像?
?
一個嵌入式的存儲設(shè)備通過通常包括四個分區(qū)：
第一分區(qū)：存放的當(dāng)然是u-boot
第二個分區(qū)：存放著u-boot要傳給系統(tǒng)內(nèi)核的參數(shù)
第三個分區(qū)：是系統(tǒng)內(nèi)核（kernel）
第四個分區(qū)：則是根文件系統(tǒng)
如下圖所示：
-------------------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------------------------------------
?
u-boot是一種普遍用于嵌入式系統(tǒng)中的Bootloader。
Bootloader介紹
Bootloader是進行嵌入式開發(fā)必然會接觸的一個概念，它是嵌入式學(xué)院<嵌入式工程師職業(yè)培訓(xùn)班>二期課程中嵌入式linux系統(tǒng)開發(fā)方面的重要內(nèi)容。本篇文章主要講解Bootloader的基本概念以及內(nèi)部原理，這部分內(nèi)容的掌握將對嵌入式linux系統(tǒng)開發(fā)的學(xué)習(xí)非常有幫助！
Bootloader的定義：Bootloader是在操作系統(tǒng)運行之前執(zhí)行的一小段程序，通過這一小段程序，我們可以初始化硬件設(shè)備、建立內(nèi)存空間的映射表，從而建立適當(dāng)?shù)南到y(tǒng)軟硬件環(huán)境，為最終調(diào)用操作系統(tǒng)內(nèi)核做好準(zhǔn)備。意思就是說如果我們要想讓一個操作系統(tǒng)在我們的板子上運轉(zhuǎn)起來，我們就必須首先對我們的板子進行一些基本配置和初始化，然后才可以將操作系統(tǒng)引導(dǎo)進來運行。具體在Bootloader中完成了哪些操作我們會在后面分析到，這里我們先來回憶一下PC的體系結(jié)構(gòu)：PC機中的引導(dǎo)加載程序是由BIOS和位于硬盤MBR中的OS Boot Loader（比如LILO和GRUB等）一起組成的，BIOS在完成硬件檢測和資源分配后，將硬盤MBR中的Boot Loader讀到系統(tǒng)的RAM中，然后將控制權(quán)交給OS Boot Loader。Boot Loader的主要運行任務(wù)就是將內(nèi)核映象從硬盤上讀到RAM中，然后跳轉(zhuǎn)到內(nèi)核的入口點去運行，即開始啟動操作系統(tǒng)。在嵌入式系統(tǒng)中，通常并沒有像BIOS那樣的固件程序（注：有的嵌入式cpu也會內(nèi)嵌一段短小的啟動程序），因此整個系統(tǒng)的加載啟動任務(wù)就完全由Boot Loader來完成。比如在一個基于ARM7TDMI core的嵌入式系統(tǒng)中，系統(tǒng)在上電或復(fù)位時通常都從地址0x00000000處開始執(zhí)行，而在這個地址處安排的通常就是系統(tǒng)的Boot Loader程序。（先想一下，通用PC和嵌入式系統(tǒng)為何會在此處存在如此的差異呢？）
Bootloader是基于特定硬件平臺來實現(xiàn)的，因此幾乎不可能為所有的嵌入式系統(tǒng)建立一個通用的Bootloader，不同的處理器架構(gòu)都有不同的Bootloader，Bootloader不但依賴于cpu的體系結(jié)構(gòu)，還依賴于嵌入式系統(tǒng)板級設(shè)備的配置。對于2塊不同的板子而言，即使他們使用的是相同的處理器，要想讓運行在一塊板子上的Bootloader程序也能運行在另一塊板子上，一般也需要修改Bootloader的源程序。
Bootloader的啟動方式
Bootloader的啟動方式主要有網(wǎng)絡(luò)啟動方式、磁盤啟動方式和Flash啟動方式。
1、網(wǎng)絡(luò)啟動方式
?
圖1??Bootloader網(wǎng)絡(luò)啟動方式示意圖
如圖1所示，里面主機和目標(biāo)板，他們中間通過網(wǎng)絡(luò)來連接，首先目標(biāo)板的DHCP/BIOS通過BOOTP服務(wù)來為Bootloader分配IP地址，配置網(wǎng)絡(luò)參數(shù)，這樣才能支持網(wǎng)絡(luò)傳輸功能。我們使用的u-boot可以直接設(shè)置網(wǎng)絡(luò)參數(shù)，因此這里就不用使用DHCP的方式動態(tài)分配IP了。接下來目標(biāo)板的Bootloader通過TFTP服務(wù)將內(nèi)核映像下載到目標(biāo)板上，然后通過網(wǎng)絡(luò)文件系統(tǒng)來建立主機與目標(biāo)板之間的文件通信過程，之后的系統(tǒng)更新通常也是使用Boot Loader的這種工作模式。工作于這種模式下的Boot Loader通常都會向它的終端用戶提供一個簡單的命令行接口。
2、磁盤啟動方式
這種方式主要是用在臺式機和服務(wù)器上的，這些計算機都使用BIOS引導(dǎo)，并且使用磁盤作為存儲介質(zhì)，這里面兩個重要的用來啟動linux的有LILO和GRUB，這里就不再具體說明了。
3、Flash啟動方式
這是我們最常用的方式。Flash有NOR Flash和NAND Flash兩種。NOR Flash可以支持隨機訪問，所以代碼可以直接在Flash上執(zhí)行，Bootloader一般是存儲在Flash芯片上的。另外Flash上還存儲著參數(shù)、內(nèi)核映像和文件系統(tǒng)。這種啟動方式與網(wǎng)絡(luò)啟動方式之間的不同之處就在于，在網(wǎng)絡(luò)啟動方式中，內(nèi)核映像和文件系統(tǒng)首先是放在主機上的，然后經(jīng)過網(wǎng)絡(luò)傳輸下載進目標(biāo)板的，而這種啟動方式中內(nèi)核映像和文件系統(tǒng)則直接是放在Flash中的，這兩點在我們u-boot的使用過程中都用到了。
U-boot的定義
U-boot，全稱Universal Boot Loader，是由DENX小組的開發(fā)的遵循GPL條款的開放源碼項目，它的主要功能是完成硬件設(shè)備初始化、操作系統(tǒng)代碼搬運，并提供一個控制臺及一個指令集在操作系統(tǒng)運行前操控硬件設(shè)備。U-boot之所以這么通用，原因是他具有很多特點：開放源代碼、支持多種嵌入式操作系統(tǒng)內(nèi)核、支持多種處理器系列、較高的穩(wěn)定性、高度靈活的功能設(shè)置、豐富的設(shè)備驅(qū)動源碼以及較為豐富的開發(fā)調(diào)試文檔與強大的網(wǎng)絡(luò)技術(shù)支持。另外u-boot對操作系統(tǒng)和產(chǎn)品研發(fā)提供了靈活豐富的支持，主要表現(xiàn)在：可以引導(dǎo)壓縮或非壓縮系統(tǒng)內(nèi)核，可以靈活設(shè)置/傳遞多個關(guān)鍵參數(shù)給操作系統(tǒng)，適合系統(tǒng)在不同開發(fā)階段的調(diào)試要求與產(chǎn)品發(fā)布，支持多種文件系統(tǒng)，支持多種目標(biāo)板環(huán)境參數(shù)存儲介質(zhì)，采用CRC32校驗，可校驗內(nèi)核及鏡像文件是否完好，提供多種控制臺接口，使用戶可以在不需要ICE的情況下通過串口/以太網(wǎng)/USB等接口下載數(shù)據(jù)并燒錄到存儲設(shè)備中去（這個功能在實際的產(chǎn)品中是很實用的，尤其是在軟件現(xiàn)場升級的時候），以及提供豐富的設(shè)備驅(qū)動等。
u-boot源代碼的目錄結(jié)構(gòu)
1、board中存放于開發(fā)板相關(guān)的配置文件，每一個開發(fā)板都以子文件夾的形式出現(xiàn)。
2、Commom文件夾實現(xiàn)u-boot行下支持的命令，每一個命令對應(yīng)一個文件。
3、cpu中存放特定cpu架構(gòu)相關(guān)的目錄，每一款cpu架構(gòu)都對應(yīng)了一個子目錄。
4、Doc是文檔目錄，有u-boot非常完善的文檔。
5、Drivers中是u-boot支持的各種設(shè)備的驅(qū)動程序。
6、Fs是支持的文件系統(tǒng)，其中最常用的是JFFS2文件系統(tǒng)。
7、Include文件夾是u-boot使用的頭文件，還有各種硬件平臺支持的匯編文件，系統(tǒng)配置文件和文件系統(tǒng)支持的文件。
8、Net是與網(wǎng)絡(luò)協(xié)議相關(guān)的代碼，bootp協(xié)議、TFTP協(xié)議、NFS文件系統(tǒng)得實現(xiàn)。
9、Tooles是生成U-boot的工具。
對u-boot的目錄有了一些了解后，分析啟動代碼的過程就方便多了，其中比較重要的目錄就是/board、/cpu、/drivers和/include目錄，如果想實現(xiàn)u-boot在一個平臺上的移植，就要對這些目錄進行深入的分析。
-------------------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------------------------------------
???????????????????????????????????????????????????????????????????????????????????????什么是《編譯地址》？什么是《運行地址》？
（一）編譯地址：?32位的處理器，它的每一條指令是4個字節(jié)，以4個字節(jié)存儲順序，進行順序執(zhí)行，CPU是順序執(zhí)行的，只要沒發(fā)生什么跳轉(zhuǎn)，它會順序進行執(zhí)行行， 編譯器會對每一條指令分配一個編譯地址，這是編譯器分配的，在編譯過程中分配的地址，我們稱之為編譯地址。
（二）運行地址：是指程序指令真正運行的地址，是由用戶指定的，用戶將運行地址燒錄到哪里，哪里就是運行的地址。
???? ?比如有一個指令的編譯地址是0x5，實際運行的地址是0x200，如果用戶將指令燒到0x200上，那么這條指令的運行地址就是0x200，
??????當(dāng)編譯地址和運行地址不同的時候會出現(xiàn)什么結(jié)果？結(jié)果是不能跳轉(zhuǎn)，編譯后會產(chǎn)生跳轉(zhuǎn)地址，如果實際地址和編譯后產(chǎn)生的地址不相等，那么就不能跳轉(zhuǎn)。
???? C語言編譯地址：都希望把編譯地址和實際運行地址放在一起的，但是匯編代碼因為不需要做C語言到匯編的轉(zhuǎn)換，可以認(rèn)為的去寫地址，所以直接寫的就是他的運行地址這就是為什么任何bootloader剛開始會有一段匯編代碼，因為起始代碼編譯地址和實際地址不相等，這段代碼和匯編無關(guān)，跳轉(zhuǎn)用的運行地址。????????????????????????????????????????????????????
????????????????????????????????????????????????????????????編譯地址和運行地址如何來算呢？
???1.??? 假如有兩個編譯地址a=0x10，b=0x7，b的運行地址是0x300，那么a的運行地址就是b的運行地址加上兩者編譯地址的差值，a-b=0x10-0x7=0x3，
?????? a的運行地址就是0x300+0x3=0x303。
?? ?2.?? 假設(shè)uboot上兩條指令的編譯地址為a=0x33000007和b=0x33000001，這兩條指令都落在bank6上，現(xiàn)在要計算出他們對應(yīng)的運行地址，要找出運行地址的始地址，這個是由用戶燒錄進去的，假設(shè)運行地址的首地址是0x0，則a的運行地址為0x7，b為0x1，就是這樣算出來的。
???????????????????????????????????????????? 為什么要分配編譯地址？這樣做有什么好處，有什么作用？
??????? 比如在函數(shù)a中定義了函數(shù)b，當(dāng)執(zhí)行到函數(shù)b時要進行指令跳轉(zhuǎn)，要跳轉(zhuǎn)到b函數(shù)所對應(yīng)的起始地址上去，編譯時，編譯器給每條指令都分配了編譯地址，如果編譯器已經(jīng)給分配了地址就可以直接進行跳轉(zhuǎn)，查找b函數(shù)跳轉(zhuǎn)指令所對應(yīng)的表，進行直接跳轉(zhuǎn)，因為有個編譯地址和指令對應(yīng)的一個表，如果沒有分配，編譯器就查找不到這個跳轉(zhuǎn)地址，要進行計算，非常麻煩。
?????????????????????????????????????????????????????????????????????? 什么是《相對地址》？
??????? 以NOR Flash為例，NOR Falsh是映射到bank0上面，SDRAM是映射到bank6上面，uboot和內(nèi)核最終是在SDRAM上面運行，最開始我們是從Nor Flash的零地址開始往后燒錄，uboot中至少有一段代碼編譯地址和運行地址是不一樣的，編譯uboot或內(nèi)核時，都會將編譯地址放入到SDRAM中，他們最終都會在SDRAM中執(zhí)行，剛開始uboot在Nor Flash中運行，運行地址是一個低端地址，是bank0中的一個地址，但編譯地址是bank6中的地址，這樣就會導(dǎo)致絕對跳轉(zhuǎn)指令執(zhí)行的失敗，所以就引出了相對地址的概念。
????????????????????????????????????????????????????????????????????? 那么什么是相對地址呢？
???? 至少在bank0中uboot這段代碼要知道不能用b+編譯地址這樣的方法去跳轉(zhuǎn)指令，因為這段代碼的編譯地址和運行地址不一樣，那如何去做呢？
??? 要去計算這個指令運行的真實地址，計算出來后再做跳轉(zhuǎn)，應(yīng)該是b+運行地址，不能出現(xiàn)b+編譯地址，而是b+運行地址，而運行地址是算出來的。
?? _TEXT_BASE:
? .word TEXT_BASE //0x33F80000,在board/config.mk中
這段話表示，用戶告訴編譯器編譯地址的起始地址
-------------------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------------------------------------?
?????? U-Boot工作過程
???
???? ?大多數(shù) Boot Loader 都包含兩種不同的操作模式:"啟動加載"模式和"下載"模式,這種區(qū)別僅對于開發(fā)人員才有意義。
???? 但從最終用戶的角度看,Boot Loader 的作用就是:用來加載操作系統(tǒng),而并不存在所謂的啟動加載模式與下載工作模式的區(qū)別。
???? (一)啟動加載(Boot loading)模式:這種模式也稱為"自主"(Autonomous)模式。
???? 也即 Boot Loader 從目標(biāo)機上的某個固態(tài)存儲設(shè)備上將操作系統(tǒng)加載到 RAM 中運行,整個過程并沒有用戶的介入。
???? 這種模式是 Boot Loader 的正常工作模式,因此在嵌入式產(chǎn)品發(fā)布的時侯,Boot Loader 顯然必須工作在這種模式下。
（二）下載(Downloading)模式:在這種模式下,目標(biāo)機上的 Boot Loader 將通過串口連接或網(wǎng)絡(luò)連接等通信手段從主機(Host)下載文件,比如:下載內(nèi)核映像和根文件系統(tǒng)映像等。從主機下載的文件通常首先被 Boot Loader保存到目標(biāo)機的RAM?中,然后再被 BootLoader寫到目標(biāo)機上的FLASH類固態(tài)存儲設(shè)備中。Boot Loader 的這種模式通常在第一次安裝內(nèi)核與根文件系統(tǒng)時被使用;此外,以后的系統(tǒng)更新也會使用 Boot Loader 的這種工作模式。工作于這種模式下的 Boot Loader 通常都會向它的終端用戶提供一個簡單的命令行接口。這種工作模式通常在第一次安裝內(nèi)核與跟文件系統(tǒng)時使用。或者在系統(tǒng)更新時使用。進行嵌入式系統(tǒng)調(diào)試時一般也讓bootloader工作在這一模式下。
????????? U-Boot 這樣功能強大的 Boot Loader 同時支持這兩種工作模式,而且允許用戶在這兩種工作模式之間進行切換。
???????? 大多數(shù) bootloader 都分為階段 1(stage1)和階段 2(stage2)兩大部分,u-boot 也不例外。依賴于 CPU 體系結(jié)構(gòu)的代碼(如 CPU 初始化代碼等)通常都放在階段 1 中且通常用匯編語言實現(xiàn),而階段 2 則通常用 C 語言來實現(xiàn),這樣可以實現(xiàn)復(fù)雜的功能,而且有更好的可讀性和移植性。
-------------------------------------------------------------------------------------------------------------------------------------------
第一、大概總結(jié)性得的分析
?????? 系統(tǒng)啟動的入口點。既然我們現(xiàn)在要分析u-boot的啟動過程，就必須先找到u-boot最先實現(xiàn)的是哪些代碼，最先完成的是哪些任務(wù)。
?????? 另一方面一個可執(zhí)行的image必須有一個入口點，并且只能有一個全局入口點，所以要通知編譯器這個入口在哪里。由此我們可以找到程序的入口點是在/board/lpc2210/u-boot.lds中指定的，其中ENTRY(_start)說明程序從_start開始運行，而他指向的是cpu/arm7tdmi/start.o文件。
因為我們用的是ARM7TDMI的cpu架構(gòu)，在復(fù)位后從地址0x00000000取它的第一條指令，所以我們將Flash映射到這個地址上，
這樣在系統(tǒng)加電后，cpu將首先執(zhí)行u-boot程序。u-boot的啟動過程是多階段實現(xiàn)的，分了兩個階段。
依賴于cpu體系結(jié)構(gòu)的代碼（如設(shè)備初始化代碼等）通常都放在stage1中，而且通常都是用匯編語言來實現(xiàn)，以達(dá)到短小精悍的目的。
而stage2則通常是用C語言來實現(xiàn)的，這樣可以實現(xiàn)復(fù)雜的功能，而且代碼具有更好的可讀性和可移植性。
下面我們先詳細(xì)分析下stage1中的代碼，如圖2所示：
?
圖2??Start.s程序流程
??????????代碼真正開始是在_start，設(shè)置異常向量表，這樣在cpu發(fā)生異常時就跳轉(zhuǎn)到/cpu/arm7tdmi/interrupts中去執(zhí)行相應(yīng)得中斷代碼。
?????????在interrupts文件中大部分的異常代碼都沒有實現(xiàn)具體的功能，只是打印一些異常消息，其中關(guān)鍵的是reset中斷代碼，跳到reset入口地址。
????????? reset復(fù)位入口之前有一些段的聲明。
??????????1.在reset中，首先是將cpu設(shè)置為svc32模式下，并屏蔽所有irq和fiq。
??????????2.在u-boot中除了定時器使用了中斷外，其他的基本上都不需要使用中斷，比如串口通信和網(wǎng)絡(luò)等通信等，在u-boot中只要完成一些簡單的通信就可以了，所以在這里屏蔽掉了所有的中斷響應(yīng)。
?????????3.初始化外部總線。這部分首先設(shè)置了I/O口功能，包括串口、網(wǎng)絡(luò)接口等的設(shè)置，其他I/O口都設(shè)置為GPIO。然后設(shè)置BCFG0~BCFG3，即外部總線控制器。這里bank0對應(yīng)Flash，設(shè)置為16位寬度，總線速度設(shè)為最慢，以實現(xiàn)穩(wěn)定的操作；Bank1對應(yīng)DRAM，設(shè)置和Flash相同；Bank2對應(yīng)RTL8019。
???????? 4.接下來是cpu關(guān)鍵設(shè)置，包括系統(tǒng)重映射（告訴處理器在系統(tǒng)發(fā)生中斷的時候到外部存儲器中去讀取中斷向量表）和系統(tǒng)頻率。
???????? 5.lowlevel_init，設(shè)定RAM的時序，并將中斷控制器清零。這些部分和特定的平臺有關(guān)，但大致的流程都是一樣的。
????????下面就是代碼的搬移階段了。為了獲得更快的執(zhí)行速度，
??????? 通常把stage2加載到RAM空間中來執(zhí)行，因此必須為加載Boot Loader的stage2準(zhǔn)備好一段可用的RAM空間范圍。空間大小最好是memory page大小(通常是4KB)的倍數(shù)
??????? 一般而言，1M的RAM空間已經(jīng)足夠了。
????????flash中存儲的u-boot可執(zhí)行文件中，代碼段、數(shù)據(jù)段以及BSS段都是首尾相連存儲的，
??????? 所以在計算搬移大小的時候就是利用了用BSS段的首地址減去代碼的首地址，這樣算出來的就是實際使用的空間。
?????? ?程序用一個循環(huán)將代碼搬移到0x81180000，即RAM底端1M空間用來存儲代碼。
?????? ?然后程序繼續(xù)將中斷向量表搬到RAM的頂端。由于stage2通常是C語言執(zhí)行代碼，所以還要建立堆棧去。
?????? 在堆棧區(qū)之前還要將malloc分配的空間以及全局?jǐn)?shù)據(jù)所需的空間空下來，他們的大小是由宏定義給出的，可以在相應(yīng)位置修改。
基本內(nèi)存分布圖：
圖3??搬移后內(nèi)存分布情況圖
???? 下來是u-boot啟動的第二個階段，是用c代碼寫的，
???? 這部分是一些相對變化不大的部分，我們針對不同的板子改變它調(diào)用的一些初始化函數(shù)，并且通過設(shè)置一些宏定義來改變初始化的流程，
???? 所以這些代碼在移植的過程中并不需要修改，也是錯誤相對較少出現(xiàn)的文件。
???? 在文件的開始先是定義了一個函數(shù)指針數(shù)組，通過這個數(shù)組，程序通過一個循環(huán)來按順序進行常規(guī)的初始化，并在其后通過一些宏定義來初始化一些特定的設(shè)備。
???? 在最后程序進入一個循環(huán)，main_loop。這個循環(huán)接收用戶輸入的命令，以設(shè)置參數(shù)或者進行啟動引導(dǎo)。
本篇文章將分析重點放在了前面的start.s上，是因為這部分無論在移植還是在調(diào)試過程中都是最容易出問題的地方，要解決問題就需要程序員對代碼進行修改，所以在這里簡單介紹了一下start.s的基本流程，希望能對大家有所幫助
-------------------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------------------------------------
第二、代碼分析
?
2.2 階段 1 介紹
u-boot 的 stage1 代碼通常放在 start.s 文件中,它用匯編語言寫成,其主要代碼部分如下:
2.2.1 定義入口
由于一個可執(zhí)行的 Image 必須有一個入口點,并且只能有一個全局入口,通常這個入口放在 ROM(Flash)的 0x0
地址,因此,必須通知編譯器以使其知道這個入口,該工作可通過修改連接器腳本來完成。
1. board/crane2410/u-boot.lds:? ENTRY(_start)?? ==> cpu/arm920t/start.S: .globl _start
2. uboot 代碼區(qū)(TEXT_BASE = 0x33F80000)定義在 board/crane2410/config.mk
U-Boot啟動內(nèi)核的過程可以分為兩個階段，兩個階段的功能如下：
?????? （1）第一階段的功能
?? 硬件設(shè)備初始化
?? 加載U-Boot第二階段代碼到RAM空間
?? 設(shè)置好棧
?? 跳轉(zhuǎn)到第二階段代碼入口
?????? （2）第二階段的功能
?? 初始化本階段使用的硬件設(shè)備
?? 檢測系統(tǒng)內(nèi)存映射
?? 將內(nèi)核從Flash讀取到RAM中
?? 為內(nèi)核設(shè)置啟動參數(shù)
?? 調(diào)用內(nèi)核
1.1.1???????????? U-Boot啟動第一階段代碼分析
?????? 第一階段對應(yīng)的文件是cpu/arm920t/start.S和board/samsung/mini2440/lowlevel_init.S。
?????? U-Boot啟動第一階段流程如下：
?
詳細(xì)分析
圖 2.1 U-Boot啟動第一階段流程
?
?????根據(jù)cpu/arm920t/u-boot.lds中指定的連接方式：
???? 看一下uboot.lds文件，在board/smdk2410目錄下面，uboot.lds是告訴編譯器這些段改怎么劃分，GUN編譯過的段，最基本的三個段是RO，RW，ZI，RO表示只讀，對應(yīng)于具體的指代碼段，RW是數(shù)據(jù)段，ZI是歸零段，就是全局變量的那段。Uboot代碼這么多，如何保證start.s會第一個執(zhí)行，編譯在最開始呢？就是通過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字節(jié)對齊
.text : //test指代碼段，上面3行標(biāo)識是不占用任何空間的
{
cpu/arm920t/start.o (.text) //這里把start.o放在第一位就表示把start.s編
譯時放到最開始，這就是為什么把uboot燒到起始地址上它肯定運行的是start.s
*(.text)
}
. = ALIGN(4); //前面的 “.” 代表當(dāng)前值，是計算一個當(dāng)前的值，是計算上
面占用的整個空間，再加一個單元就表示它現(xiàn)在的位置
.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的執(zhí)行。
1.????? 硬件設(shè)備初始化
（1）設(shè)置異常向量
????????? 下面代碼是系統(tǒng)啟動后U-boot上電后運行的第一段代碼，它是什么意思？
????????? u-boot對應(yīng)的第一階段代碼放在cpu/arm920t/start.S文件中，入口代碼如下：.
globl _startglobal??????????????????????????????????? /*聲明一個符號可被其它文件引用，相當(dāng)于聲明了一個全局變量，.globl與.global相同*/
_start:??? b???? start_code??????????????????? /* 復(fù)位 */b是不帶返回的跳轉(zhuǎn)(bl是帶返回的跳轉(zhuǎn))，意思是無條件直接跳轉(zhuǎn)到start_code標(biāo)號出執(zhí)行程序
?????? ldr?? pc, _undefined_instruction????? /*?未定義指令向量 l---dr相當(dāng)于mov操作*/
?????? ldr?? pc, _software_interrupt??????????? /* ?軟件中斷向量 */
?????? ldr?? pc, _prefetch_abort????????????????? /*? 預(yù)取指令異常向量 */
?????? ldr?? pc, _data_abort??????????????????????? /* ?數(shù)據(jù)操作異常向量 */
?????? ldr?? pc, _not_used?????????????????????????? /*? 未使用?? */
?????? ldr?? pc, _irq???????????????????????????????????? /*? irq中斷向量? */
?????? ldr?? pc, _fiq???????????????????????????????????? /*? fiq中斷向量? */
/*? 中斷向量表入口地址 */
_undefined_instruction:??? .word undefined_instruction? /*就是在當(dāng)前地址，即_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偽操作用于分配一段字內(nèi)存單元(分配的單元都是字對齊的)，并用偽操作中的expr初始化
?????? .balignl 16,0xdeadbeef
?????? 他們是系統(tǒng)定義的異常，一上電程序跳轉(zhuǎn)到start_code異常處執(zhí)行相應(yīng)的匯編指令，下面定義出的都是不同的異常，比如軟件發(fā)生軟中斷時，CPU就會去執(zhí)行軟中斷的指令，這些異常中斷在CUP中地址是從0開始，每個異常占4個字節(jié)
???????ldr pc, _undefined_instruction表示把_undefined_instruction存放的數(shù)值存放到pc指針上
????????????????? ?_undefined_instruction: .word undefined_instruction表示未定義的這個異常是由.word來定義的，它表示定義一個字，一個32位的數(shù)
.? word后面的數(shù)：表示把該標(biāo)識的編譯地址寫入當(dāng)前地址，標(biāo)識是不占用任何指令的。把標(biāo)識存放的數(shù)值copy到指針pc上面，那么標(biāo)識上存放的值是什么？
是由.word undefined_instruction來指定的，pc就代表你運行代碼的地址，她就實現(xiàn)了CPU要做一次跳轉(zhuǎn)時的工作。
???????以上代碼設(shè)置了ARM異常向量表，各個異常向量介紹如下：
表 2.1 ARM異常向量表
| ???????地址? | ? 異常? | ??? 進入模式 | 描述 |
| 0x00000000? | 復(fù)位 | ?? 管理模式 | ??? 復(fù)位電平有效時，產(chǎn)生復(fù)位異常，程序跳轉(zhuǎn)到復(fù)位處理程序處執(zhí)行 |
| 0x00000004? | 未定義指令 | ???未定義模式 | ?? 遇到不能處理的指令時，產(chǎn)生未定義指令異常 |
| 0x00000008 | 軟件中斷 | ?? 管理模式 | ??? 執(zhí)行SWI指令產(chǎn)生，用于用戶模式下的程序調(diào)用特權(quán)操作指令 |
| 0x0000000c | 預(yù)存指令 | ?? 中止模式 | ?? 處理器預(yù)取指令的地址不存在，或該地址不允許當(dāng)前指令訪問，產(chǎn)生指令預(yù)取中止異常 |
| 0x00000010 | 數(shù)據(jù)操作 | ?? 中止模式 | ?? 處理器數(shù)據(jù)訪問指令的地址不存在，或該地址不允許當(dāng)前指令訪問時，產(chǎn)生數(shù)據(jù)中止異常 |
| 0x00000014 | 未使用 | ???未使用 | ?? 未使用 |
| 0x00000018 | IRQ | ?? IRQ | ??? 外部中斷請求有效，且CPSR中的I位為0時，產(chǎn)生IRQ異常 |
| 0x0000001c | FIQ | ?? FIQ | ??? 快速中斷請求引腳有效，且CPSR中的F位為0時，產(chǎn)生FIQ異常 |
??????
????? 在cpu/arm920t/start.S中還有這些異常對應(yīng)的異常處理程序。當(dāng)一個異常產(chǎn)生時，CPU根據(jù)異常號在異常向量表中找到對應(yīng)的異常向量，然后執(zhí)行異常向量處的跳轉(zhuǎn)指令，CPU就跳轉(zhuǎn)到對應(yīng)的異常處理程序執(zhí)行。
?????? 其中復(fù)位異常向量的指令“b start_code”決定了U-Boot啟動后將自動跳轉(zhuǎn)到標(biāo)號“start_code”處執(zhí)行。
（2）CPU進入SVC模式
start_code:
?????? /*
?????? ?* set the cpu to SVC32 mode
?????? ?*/
?????? mrs r0, cpsr
?????? bic? r0, r0, #0x1f??????? /*工作模式位清零 */
?????? orr?? r0, r0, #0xd3????????????? /*工作模式位設(shè)置為“10011”（管理模式），并將中斷禁止位和快中斷禁止位置1 */
?????? msr cpsr, r0
?????? 以上代碼將CPU的工作模式位設(shè)置為管理模式，即設(shè)置相應(yīng)的CPSR程序狀態(tài)字，并將中斷禁止位和快中斷禁止位置一，從而屏蔽了IRQ和FIQ中斷。
?????? 操作系統(tǒng)先注冊一個總的中斷，然后去查是由哪個中斷源產(chǎn)生的中斷，再去查用戶注冊的中斷表，查出來后就去執(zhí)行用戶定義的用戶中斷處理函數(shù)。
（3）設(shè)置控制寄存器地址
# if defined(CONFIG_S3C2400)??????? /*關(guān)閉看門狗*/
#? 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開發(fā)板，以上代碼完成了WATCHDOG，INTMSK，INTSUBMSK，CLKDIVN四個寄存器的地址的設(shè)置。各個寄存器地址參見參考文獻[4] 。
（4）關(guān)閉看門狗
?????? ldr?? r0, =pWTCON?? /*將pwtcon寄存器地址賦給R0*/
?????? mov?????? r1, #0x0????? /*r1的內(nèi)容為0*/
?????? str?? r1, [r0]?????????????? ?/* 看門狗控制器的最低位為0時，看門狗不輸出復(fù)位信號 */
?????? 以上代碼向看門狗控制寄存器寫入0，關(guān)閉看門狗。否則在U-Boot啟動過程中，CPU將不斷重啟。
為什么要關(guān)看門狗？
??????? ?就是防止，不同得兩個以上得CPU，進行喂狗的時間間隔問題：說白了，就是你運行的代碼如果超出喂狗時間，而你不關(guān)狗，就會導(dǎo)致，你代碼還沒運行完又得去喂狗，就這樣反復(fù)得重啟CPU，那你代碼永遠(yuǎn)也運行不完，所以，得先關(guān)看門狗得原因，就是這樣。
關(guān)狗---詳細(xì)的原因：
????? 關(guān)閉看門狗，關(guān)閉中斷，所謂的喂狗是每隔一段時間給某個寄存器置位而已，在實際中會專門啟動一個線程或進程會專門喂狗，當(dāng)上層軟件出現(xiàn)故障時就會停止喂狗，
????? 停止喂狗之后，cpu會自動復(fù)位，一般都在外部專門有一個看門狗，做一個外部的電路，不在cpu內(nèi)部使用看門狗，cpu內(nèi)部的看門狗是復(fù)位的cpu
?????? 當(dāng)開發(fā)板很復(fù)雜時，有好幾個cpu時，就不能完全讓板子復(fù)位，但我們通常都讓整個板子復(fù)位。看門狗每隔短時間就會喂狗，問題是在兩次喂狗之間的時間間隔內(nèi)，運行的代碼的時間是否夠用，兩次喂狗之間的代碼是否在兩次喂狗的時間延遲之內(nèi)，如果在延遲之外的話，代碼還沒改完就又進行喂狗，代碼永遠(yuǎn)也改不完
（5）屏蔽中斷
?????? /*
?????? ?* mask all IRQs by setting all bits in the INTMR - default
?????? ?*/
?????? mov?????? r1, #0xffffffff???? /*屏蔽所有中斷，?某位被置1則對應(yīng)的中斷被屏蔽 */?/*寄存器中的值*/
?????? ldr?? r0, =INTMSK?????? /*將管理中斷的寄存器地址賦給ro*/
?????? str?? r1, [r0]??????????????????/*將全r1的值賦給ro地址中的內(nèi)容*/
?????? INTMSK是主中斷屏蔽寄存器，每一位對應(yīng)SRCPND（中斷源引腳寄存器）中的一位，表明SRCPND相應(yīng)位代表的中斷請求是否被CPU所處理。
???????? 根據(jù)參考文獻4，INTMSK寄存器是一個32位的寄存器，每位對應(yīng)一個中斷，向其中寫入0xffffffff就將INTMSK寄存器全部位置一，從而屏蔽對應(yīng)的中斷。
# if defined(CONFIG_S3C2440)
??? ????? ldr? r1, =0x7fff??????????????????
? ?????? ldr? r0, =INTSUBMSK??
???????? str? r1, [r0]????????????
?# endif
?????? INTSUBMSK每一位對應(yīng)SUBSRCPND中的一位，表明SUBSRCPND相應(yīng)位代表的中斷請求是否被CPU所處理。
?????? 根據(jù)參考文獻4，INTSUBMSK寄存器是一個32位的寄存器，但是只使用了低15位。向其中寫入0x7fff就是將INTSUBMSK寄存器全部有效位（低15位）置一，從而屏蔽對應(yīng)的中斷。
屏蔽所有中斷，為什么要關(guān)中斷？
中斷處理中l(wèi)dr pc是將代碼的編譯地址放在了指針上，而這段時間還沒有搬移代碼，所以編譯地址上面沒有這個代碼，如果進行跳轉(zhuǎn)就會跳轉(zhuǎn)到空指針上面
（6）設(shè)置MPLLCON,UPLLCON, CLKDIVN
# if defined(CONFIG_S3C2440)?
#define MPLLCON?? 0x4C000004
#define UPLLCON?? 0x4C000008??
??? ????? ldr? r0, =CLKDIVN???;設(shè)置時鐘
??? ????? 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上電幾毫秒后，晶振輸出穩(wěn)定，FCLK=Fin（晶振頻率），CPU開始執(zhí)行指令。但實際上，FCLK可以高于Fin，為了提高系統(tǒng)時鐘，需要用軟件來啟用PLL。這就需要設(shè)置CLKDIVN，MPLLCON，UPLLCON這3個寄存器。
???????CLKDIVN寄存器用于設(shè)置FCLK，HCLK，PCLK三者間的比例，可以根據(jù)表2.2來設(shè)置。
表 2.2 S3C2440 的CLKDIVN寄存器格式
| ??????????????????????? ?? CLKDIVN????????????? ?????????? | ?????????????? ? 位??????????????? | ? 說明 | ????????????????????????? ?初始值???????????????????? |
| HDIVN | [2:1] | ????? 00 : HCLK = FCLK/1. ??????01 : HCLK = FCLK/2. ????? 10 : HCLK = FCLK/4 （當(dāng) CAMDIVN[9] = 0 時） ????? HCLK= FCLK/8? （當(dāng) CAMDIVN[9] = 1 時） ????? 11 : HCLK = FCLK/3 （當(dāng) CAMDIVN[8] = 0 時） ????? HCLK = FCLK/6 （當(dāng) CAMDIVN[8] = 1時） | 00 |
| PDIVN | [0] | 0: PCLK = HCLK/1?? 1: PCLK = HCLK/2 | 0 |
?
?????? 設(shè)置CLKDIVN為5，就將HDIVN設(shè)置為二進制的10，由于CAMDIVN[9]沒有被改變過，取默認(rèn)值0，因此HCLK = FCLK/4。PDIVN被設(shè)置為1，因此PCLK= HCLK/2。因此分頻比FCLK:HCLK:PCLK = 1:4:8 。
?????? MPLLCON寄存器用于設(shè)置FCLK與Fin的倍數(shù)。MPLLCON的位[19:12]稱為MDIV，位[9:4]稱為PDIV，位[1:0]稱為SDIV。
?????? 對于S3C2440，FCLK與Fin的關(guān)系如下面公式：
?????? MPLL(FCLK) = (2×m×Fin)/(p× )
?????? 其中： m=MDIC+8，p=PDIV+2，s=SDIV
?????? MPLLCON與UPLLCON的值可以根據(jù)參考文獻4中“PLL VALUE SELECTION TABLE”設(shè)置。該表部分摘錄如下：
表 2.3 推薦PLL值
| ?????? 輸入頻率??????? | ??????????????????????? 輸出頻率????????????????????????? | ?????????????????????? MDIV??????????????????? | ???????????????????????? PDIV????????????????????? | ??????????????????????SDIV????????????????????? |
| 12.0000MHz | 48.00 MHz | 56(0x38) | 2 | 2 |
| 12.0000MHz | 405.00 MHz | 127(0x7f) | 2 | 1 |
?????? 當(dāng)mini2440系統(tǒng)主頻設(shè)置為405MHZ，USB時鐘頻率設(shè)置為48MHZ時，系統(tǒng)可以穩(wěn)定運行，因此設(shè)置MPLLCON與UPLLCON為：
?????? MPLLCON=(0x7f<<12) | (0x02<<4) | (0x01) = 0x7f021
?????? UPLLCON=(0x38<<12) | (0x02<<4) | (0x02) = 0x38022
默認(rèn)頻率為????? FCLK:HCLK:PCLK = 1:2:4,默認(rèn) FCLK 的值為 120 MHz,該值為 S3C2410 手冊的推薦值。
設(shè)置時鐘分頻，為什么要設(shè)置時鐘？
起始可以不設(shè)，系統(tǒng)能不能跑起來和頻率沒有任何關(guān)系，頻率的設(shè)置是要讓外圍的設(shè)備能承受所設(shè)置的頻率，如果頻率過高則會導(dǎo)致cpu操作外圍設(shè)備失敗
說白了：設(shè)置頻率，就為了CPU能去操作外圍設(shè)備
（7）關(guān)閉MMU，cache? ------（也就是做bank的設(shè)置）
?????? 接著往下看：
#ifndef CONFIG_SKIP_LOWLEVEL_INIT
?????? bl??? cpu_init_crit??/*?;跳轉(zhuǎn)并把轉(zhuǎn)移后面緊接的一條指令地址保存到鏈接寄存器LR(R14)中，以此來完成子程序的調(diào)用*/
#endif
?????? cpu_init_crit這段代碼在U-Boot正常啟動時才需要執(zhí)行，若將U-Boot從RAM中啟動則應(yīng)該注釋掉這段代碼。
?????? 下面分析一下cpu_init_crit到底做了什么：
320? #ifndef CONFIG_SKIP_LOWLEVEL_INIT
321? cpu_init_crit:
322? ??? /*
323? ??? ?* 使數(shù)據(jù)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失效 ，協(xié)處理器*/??
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的協(xié)處理器CP15的寄存器。其中c7是cache控制寄存器，c8是TLB控制寄存器。325~327行代碼將0寫入c7、c8，使Cache，TLB內(nèi)容無效。
?????? 第332~337行代碼關(guān)閉了MMU。這是通過修改CP15的c1寄存器來實現(xiàn)的，先看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 ：關(guān)閉ICaches；1 ：開啟ICaches
R、S : 用來與頁表中的描述符一起確定內(nèi)存的訪問權(quán)限
B : ?0 ：CPU為小字節(jié)序；1 ： CPU為大字節(jié)序
C : ?0：關(guān)閉DCaches；1：開啟DCaches
A : ?0：數(shù)據(jù)訪問時不進行地址對齊檢查；1：數(shù)據(jù)訪問時進行地址對齊檢查
M : ?0：關(guān)閉MMU；1：開啟MMU
?????? 332~337行代碼將c1的 M位置零，關(guān)閉了MMU。
為什么要關(guān)閉catch和MMU呢？catch和MMU是做什么用的？
????MMU是Memory Management Unit的縮寫，中文名是內(nèi)存管理單元，它是中央處理器（CPU）中用來管理虛擬存儲器、物理存儲器的控制線路
??? 同時也負(fù)責(zé)虛擬地址映射為物理地址，以及提供硬件機制的內(nèi)存訪問授權(quán)??????
概述：
一，關(guān)catch
?????? catch和MMU是通過CP15管理的，剛上電的時候，CPU還不能管理他們
?????? 上電的時候MMU必須關(guān)閉，指令catch可關(guān)閉，可不關(guān)閉，但數(shù)據(jù)catch一定要關(guān)閉
?????? 否則可能導(dǎo)致剛開始的代碼里面，去取數(shù)據(jù)的時候，從catch里面取，而這時候RAM中數(shù)據(jù)還沒有catch過來，導(dǎo)致數(shù)據(jù)預(yù)取異常
二：關(guān)MMU
????? 因為MMU是;把虛擬地址轉(zhuǎn)化為物理地址得作用
????? 而目的是設(shè)置控制寄存器，而控制寄存器本來就是實地址（物理地址），再使能MMU，不就是多此一舉了嗎？
詳細(xì)分析---
????? Catch是cpu內(nèi)部的一個2級緩存，它的作用是將常用的數(shù)據(jù)和指令放在cpu內(nèi)部，MMU是用來把虛實地址轉(zhuǎn)換為物理地址用的
????? 我們的目的:是設(shè)置控制的寄存器，寄存器都是實地址（物理地址），如果既要開啟MMU又要做虛實地址轉(zhuǎn)換的話，中間還多一步，多此一舉了嘛?
??
????? 先要把實地址轉(zhuǎn)換成虛地址，然后再做設(shè)置，但對uboot而言就是起到一個簡單的初始化的作用和引導(dǎo)操作系統(tǒng)，如果開啟MMU的話，很麻煩，也沒必要，所以關(guān)閉MMU.
????
????? ?說到catch就必須提到一個關(guān)鍵字Volatile，以后在設(shè)置寄存器時會經(jīng)常遇到，他的本質(zhì)：是告訴編譯器不要對我的代碼進行優(yōu)化，作用是讓編寫者感覺不倒變量的變化情況（也就是說，讓它執(zhí)行速度加快吧）
???????優(yōu)化的過程：是將常用的代碼取出來放到catch中，它沒有從實際的物理地址去取，它直接從cpu的緩存中去取，但常用的代碼就是為了感覺一些常用變量的變化
????????優(yōu)化原因：如果正在取數(shù)據(jù)的時候發(fā)生跳變，那么就感覺不到變量的變化了，所以在這種情況下要用Volatile關(guān)鍵字告訴編譯器不要做優(yōu)化，每次從實際的物理地址中去取指令，這就是為什么關(guān)閉catch關(guān)閉MMU。
??????? ?但在C語言中是不會關(guān)閉catch和MMU的，會打開，如果編寫者要感覺外界變化，或變化太快，從catch中取數(shù)據(jù)會有誤差，就加一個關(guān)鍵字Volatile。
（8）初始化RAM控制寄存器
???????????????????? bl lowlevel_init下來初始化各個bank，把各個bank設(shè)置必須搞清楚，對以后移植復(fù)雜的uboot有很大幫助
???????????????????? 設(shè)置完畢后拷貝uboot代碼到4k空間，拷貝完畢后執(zhí)行內(nèi)存中的uboot代碼
????? 其中的lowlevel_init就完成了內(nèi)存初始化的工作，由于內(nèi)存初始化是依賴于開發(fā)板的，因此lowlevel_init的代碼一般放在board下面相應(yīng)的目錄中。對于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個寄存器的值逐一賦值給對應(yīng)的寄存器*/
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個寄存器來實現(xiàn)RAM時鐘的初始化。lowlevel_init函數(shù)對于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內(nèi)部4KB的內(nèi)部RAM中。因此第137~146行的代碼將從CPU內(nèi)部RAM中復(fù)制寄存器的值到相應(yīng)的寄存器中。
?????? 對于U-Boot在NOR Flash啟動的情況，由于U-Boot連接時確定的地址是U-Boot在內(nèi)存中的地址，而此時U-Boot還在NOR Flash中，因此還需要在NOR Flash中讀取數(shù)據(jù)到RAM中。
?????? 由于NOR Flash的開始地址是0，而U-Boot的加載到內(nèi)存的起始地址是TEXT_BASE，SMRDATA標(biāo)號在Flash的地址就是SMRDATA－TEXT_BASE。
?????? 綜上所述，lowlevel_init的作用就是將SMRDATA開始的13個值復(fù)制給開始地址[BWSCON]的13個寄存器，從而完成了存儲控制器的設(shè)置。
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
?問題一：如果換一塊開發(fā)板有可能改哪些東西？
????????????????? ?首先，cpu的運行模式，如果需要對cpu進行設(shè)置那就設(shè)置，管看門狗，關(guān)中斷不用改，時鐘有可能要改，如果能正常使用則不用改，關(guān)閉catch和MMU不用改，設(shè)置bank有可能要改。最后一步拷貝時看地址會不會變，如果變化也要改，執(zhí)行內(nèi)存中代碼，地址有可能要改。
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
問題二：Nor Flash和Nand Flash本質(zhì)區(qū)別：
????????????????? 就在于是否進行代碼拷貝，也就是下面代碼所表述：無論是Nor Flash還是Nand Flash，核心思想就是將uboot代碼搬運到內(nèi)存中去運行，但是沒有拷貝bss后面這段代碼，只拷貝bss前面的代碼，bss代碼是放置全局變量的。Bss段代碼是為了清零，拷貝過去再清零重復(fù)操作
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
（9）復(fù)制U-Boot第二階段代碼到RAM
?????? cpu/arm920t/start.S原來的代碼是只支持從NOR Flash啟動的，經(jīng)過修改現(xiàn)在U-Boot在NOR Flash和NAND Flash上都能啟動了，實現(xiàn)的思路是這樣的：
?????? bl??? bBootFrmNORFlash /*? 判斷U-Boot是在NAND Flash還是NOR Flash啟動? */
?????? cmp?????? r0, #0????????? /*? r0存放bBootFrmNORFlash函數(shù)返回值，若返回0表示NAND Flash啟動，否則表示在NOR Flash啟動? */
?????? beq nand_boot???????? /*? 跳轉(zhuǎn)到NAND Flash啟動代碼? */
?
/*? NOR Flash啟動的代碼? */
?????? b???? stack_setup???????? /* 跳過NAND Flash啟動的代碼 */
?
nand_boot:
/*? NAND Flash啟動的代碼? */
?
stack_setup:???????
?????? /* 其他代碼 */
?
?????? 其中bBootFrmNORFlash函數(shù)作用是判斷U-Boot是在NAND Flash啟動還是NOR Flash啟動，若在NOR Flash啟動則返回1，否則返回0。根據(jù)ATPCS規(guī)則，函數(shù)返回值會被存放在r0寄存器中，因此調(diào)用bBootFrmNORFlash函數(shù)后根據(jù)r0的值就可以判斷U-Boot在NAND Flash啟動還是NOR Flash啟動。bBootFrmNORFlash函數(shù)在board/samsung/mini2440/nand_read.c中定義如下：
int bBootFrmNORFlash(void)
{
??? volatile unsigned int *pdw = (volatile unsigned int *)0;
??? unsigned int dwVal;
??
??? dwVal = *pdw;?????? ??/* 先記錄下原來的數(shù)據(jù) */
??? *pdw = 0x12345678;
??? if (*pdw != 0x12345678)?????? /* 寫入失敗，說明是在NOR Flash啟動 */
??? {
??????? return 1;?????
??? }
??? else?????? ??????????????????????????? /* 寫入成功，說明是在NAND Flash啟動 */
??? {
??????? *pdw = dwVal;??????? /* 恢復(fù)原來的數(shù)據(jù) */
??????? return 0;
??? }
}
???? 無論是從NOR Flash還是從NAND Flash啟動，地址0處為U-Boot的第一條指令“ b??? start_code”。
?????? 對于從NAND Flash啟動的情況，其開始4KB的代碼會被自動復(fù)制到CPU內(nèi)部4K內(nèi)存中，因此可以通過直接賦值的方法來修改。
?????? 對于從NOR Flash啟動的情況，NOR Flash的開始地址即為0，必須通過一定的命令序列才能向NOR Flash中寫數(shù)據(jù)，所以可以根據(jù)這點差別來分辨是從NAND Flash還是NOR Flash啟動：向地址0寫入一個數(shù)據(jù)，然后讀出來，如果發(fā)現(xiàn)寫入失敗的就是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中運行，若是，則不用?再復(fù)制到RAM中了，這種情況通常在調(diào)試U-Boot時才發(fā)生 */
210? ??? cmp ???? r0, r1????? /*_start等于_TEXT_BASE說明是下載到RAM中運行 */
211? ??? beq stack_setup
212? /* 以下直到nand_boot標(biāo)號前都是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個字的數(shù)據(jù) */
220? ??? stmia????? r1!, {r3-r10} /* 將r3至r10寄存器的數(shù)據(jù)復(fù)制給地址為[r1]的內(nèi)存 */
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]?? /* 設(shè)置NFCONF寄存器 */
?
?????? /* 設(shè)置NFCONT，初始化ECC編/解碼器，禁止NAND Flash片選 */
??? ldr r2, =( (1<<4)|(0<<1)|(1<<0) )
??? str r2, [r1, #oNFCONT]?
?
??? ldr r2, =(0x6)?????????? /* 設(shè)置NFSTAT */
str r2, [r1, #oNFSTAT]
?
?????? /* 復(fù)位命令，第一次使用NAND Flash前復(fù)位 */
??? mov r2, #0xff???????????
??? strb r2, [r1, #oNFCMD]
??? mov r3, #0??????????????
?
??? /* 為調(diào)用C函數(shù)nand_read_ll準(zhǔn)備堆棧 */
??? ldr sp, DW_STACK_START??
??? mov fp, #0??????????????
??? /* 下面先設(shè)置r0至r2，然后調(diào)用nand_read_ll函數(shù)將U-Boot讀入RAM */
??? ldr r0, =TEXT_BASE????? /* 目的地址：U-Boot在RAM的開始地址 */
??? mov r1, #0x0???? ????????? /* 源地址：U-Boot在NAND Flash中的開始地址 */
??? mov r2, #0x30000? ??????? /* 復(fù)制的大小，必須比u-boot.bin文件大，并且必須是NAND Flash塊大小的整數(shù)倍，這里設(shè)置為0x30000（192KB） */
??? bl? nand_read_ll?? ????????????? /* 跳轉(zhuǎn)到nand_read_ll函數(shù)，開始復(fù)制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各個控制寄存器的設(shè)置在S3C2440的數(shù)據(jù)手冊有詳細(xì)說明，這里就不介紹了。
?????? 代碼中nand_read_ll函數(shù)的作用是在NAND Flash中搬運U-Boot到RAM，該函數(shù)在board/samsung/mini2440/nand_read.c中定義。
?????? NAND Flash根據(jù)page大小可分為2種： 512B/page和2048B/page的。這兩種NAND Flash的讀操作是不同的。因此就需要U-Boot識別到NAND Flash的類型，然后采用相應(yīng)的讀操作，也就是說nand_read_ll函數(shù)要能自動適應(yīng)兩種NAND Flash。
?????? 參考S3C2440的數(shù)據(jù)手冊可以知道：根據(jù)NFCONF寄存器的Bit3（AdvFlash (Read only)）和Bit2 （PageSize (Read only)）可以判斷NAND Flash的類型。Bit2、Bit3與NAND Flash的block類型的關(guān)系如下表所示：
表 2.4 NFCONF的Bit3、Bit2與NAND Flash的關(guān)系
| ????????????????????????????????? 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這兩種，因此根據(jù)NFCONF寄存器的Bit3即可區(qū)分這兩種NAND Flash了。
?????? 完整代碼見board/samsung/mini2440/nand_read.c中的nand_read_ll函數(shù)，這里給出偽代碼：
int nand_read_ll(unsigned char *buf, unsigned long start_addr, int size)
{
//根據(jù)NFCONF寄存器的Bit3來區(qū)分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）設(shè)置堆棧
?????? /* ?設(shè)置堆棧 */
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 /*? 跳過全局?jǐn)?shù)據(jù)區(qū)?????????????? */
#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指針指向一段沒有被使用的內(nèi)存就完成棧的設(shè)置了。根據(jù)上面的代碼可以知道U-Boot內(nèi)存使用情況了，如下圖所示：
?
?
圖2.2 U-Boot內(nèi)存使用情況
?
（11）清除BSS段
clear_bss:
?????? ldr?? r0, _bss_start????????????? /* BSS段開始地址，在u-boot.lds中指定*/
?????? ldr?? r1, _bss_end?????????????? /* BSS段結(jié)束地址，在u-boot.lds中指定*/
?????? mov?????? r2, #0x00000000
clbss_l:str???? r2, [r0]????????? /* 將bss段清零*/
?????? add r0, r0, #4
?????? cmp ???? r0, r1
?????? ble? clbss_l
?????? 初始值為0，無初始值的全局變量，靜態(tài)變量將自動被放在BSS段。應(yīng)該將這些變量的初始值賦為0，否則這些變量的初始值將是一個隨機的值，若有些程序直接使用這些沒有初始化的變量將引起未知的后果。
（12）跳轉(zhuǎn)到第二階段代碼入口
?????? ldr?? pc,?_start_armboot
?
_start_armboot:?? .word? start_armboot
?????? 跳轉(zhuǎn)到第二階段代碼入口start_armboot處。
1.1.2?????????????U-Boot啟動第二階段代碼分析
?????? start_armboot函數(shù)在lib_arm/board.c中定義，是U-Boot第二階段代碼的入口。U-Boot啟動第二階段流程如下：
?
圖 2.3 U-Boot第二階段執(zhí)行流程
?????? 在分析start_armboot函數(shù)前先來看看一些重要的數(shù)據(jù)結(jié)構(gòu)：
（1）gd_t結(jié)構(gòu)體
?????? U-Boot使用了一個結(jié)構(gòu)體gd_t來存儲全局?jǐn)?shù)據(jù)區(qū)的數(shù)據(jù)，這個結(jié)構(gòu)體在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來記錄全局?jǐn)?shù)據(jù)區(qū)的地址：
#define DECLARE_GLOBAL_DATA_PTR???? register volatile gd_t *gd asm ("r8")
?????? DECLARE_GLOBAL_DATA_PTR定義一個gd_t全局?jǐn)?shù)據(jù)結(jié)構(gòu)的指針，這個指針存放在指定的寄存器r8中。這個聲明也避免編譯器把r8分配給其它的變量。任何想要訪問全局?jǐn)?shù)據(jù)區(qū)的代碼，只要代碼開頭加入“DECLARE_GLOBAL_DATA_PTR”一行代碼，然后就可以使用gd指針來訪問全局?jǐn)?shù)據(jù)區(qū)了。
?????? 根據(jù)U-Boot內(nèi)存使用圖中可以計算gd的值：
gd = TEXT_BASE －CONFIG_SYS_MALLOC_LEN － sizeof(gd_t)
（2）bd_t結(jié)構(gòu)體
?????? 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;????????????? /* 環(huán)境變量開始地址 */
??? ulong??? ??????? bi_arch_number;????? /* 開發(fā)板的機器碼 */
??? ulong??? ??????? bi_boot_params;?????? /* 內(nèi)核參數(shù)的開始地址 */
??? struct???????????????????????? /* RAM配置信息 */
??? {
????????????? ulong start;
????????????? ulong size;
?? ?}bi_dram[CONFIG_NR_DRAM_BANKS];?
} bd_t;
?????? U-Boot啟動內(nèi)核時要給內(nèi)核傳遞參數(shù)，這時就要使用gd_t，bd_t結(jié)構(gòu)體中的信息來設(shè)置標(biāo)記列表。
?????? 第一階段調(diào)用start_armboot指向C語言執(zhí)行代碼區(qū)，首先它要從內(nèi)存上的重定位數(shù)據(jù)獲得不完全配置的全局?jǐn)?shù)據(jù)表格和板級信息表格，即獲得gd_t和bd_t，
這兩個類型變量記錄了剛啟動時的信息，并將要記錄作為引導(dǎo)內(nèi)核和文件系統(tǒng)的參數(shù)，如bootargs等等，并且將來還會在啟動內(nèi)核時，由uboot交由kernel時會有所用。
（3）init_sequence數(shù)組
?????? U-Boot使用一個數(shù)組init_sequence來存儲對于大多數(shù)開發(fā)板都要執(zhí)行的初始化函數(shù)的函數(shù)指針。init_sequence數(shù)組中有較多的編譯選項，去掉編譯選項后init_sequence數(shù)組如下所示：
typedef int (init_fnc_t) (void);
?
init_fnc_t *init_sequence[] = {
?????? board_init,??? ? ?? /*開發(fā)板相關(guān)的配置--board/samsung/mini2440/mini2440.c */
?????? timer_init,??????????? /* 時鐘初始化-- cpu/arm920t/s3c24x0/timer.c */
?????? env_init,? ????????? /*初始化環(huán)境變量--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函數(shù)在board/samsung/mini2440/mini2440.c中定義，該函數(shù)設(shè)置了MPLLCOM，UPLLCON，以及一些GPIO寄存器的值，還設(shè)置了U-Boot機器碼和內(nèi)核啟動參數(shù)地址 ：
/* MINI2440開發(fā)板的機器碼 */
gd->bd->bi_arch_number = MACH_TYPE_MINI2440;
?
/* 內(nèi)核啟動參數(shù)地址 */
gd->bd->bi_boot_params?= 0x30000100;??
?????? 其中的dram_init函數(shù)在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的內(nèi)存，接在存儲控制器的BANK6，地址空間是0x30000000~0x34000000。
在include/configs/mini2440.h中PHYS_SDRAM_1和PHYS_SDRAM_1_SIZE 分別被定義為0x30000000和0x04000000（64M）。
?????? 分析完上述的數(shù)據(jù)結(jié)構(gòu)，下面來分析start_armboot函數(shù)：
void start_armboot (void)
{
?????? init_fnc_t **init_fnc_ptr;
?????? char *s;
?????? … …
?????? /* 計算全局?jǐn)?shù)據(jù)結(jié)構(gòu)的地址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;
?
/* 逐個調(diào)用init_sequence數(shù)組中的初始化函數(shù)? */
?????? 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
?????? … …
?????? /*配置環(huán)境變量，重新定位 */
?????? env_relocate ();
?????? … …
?????? /* 從環(huán)境變量中獲取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
?????? … …
?????? /* 網(wǎng)卡初始化 */
#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函數(shù)在common/main.c中定義。一般情況下，進入main_loop函數(shù)若干秒內(nèi)沒有
1.1.3???????????? U-Boot啟動Linux過程
?????? U-Boot使用標(biāo)記列表（tagged list）的方式向Linux傳遞參數(shù)。標(biāo)記的數(shù)據(jù)結(jié)構(gòu)式是tag，在U-Boot源代碼目錄include/asm-arm/setup.h中定義如下：
struct tag_header {
?????? u32 size;?????? /* 表示tag數(shù)據(jù)結(jié)構(gòu)的聯(lián)合u實質(zhì)存放的數(shù)據(jù)的大小*/
?????? u32 tag;??????? /* 表示標(biāo)記的類型 */
};
?
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來啟動已經(jīng)加載到內(nèi)存中的內(nèi)核。而bootm命令實際上調(diào)用的是do_bootm函數(shù)。對于Linux內(nèi)核，do_bootm函數(shù)會調(diào)用do_bootm_linux函數(shù)來設(shè)置標(biāo)記列表和啟動內(nèi)核。do_bootm_linux函數(shù)在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環(huán)境變量bootargs */
68?? #endif
?????? … …
73?? ??? theKernel = (void (*)(int, int, uint))images->ep; /* 獲取內(nèi)核入口地址 */
?????? … …
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);???????????????????????????????????? /* 設(shè)置ATAG_CORE標(biāo)志 */
?????? … …
100? #ifdef CONFIG_SETUP_MEMORY_TAGS
101? ??? setup_memory_tags (bd);????????????????????? ?????? /* 設(shè)置內(nèi)存標(biāo)記 */
102? #endif
103? #ifdef CONFIG_CMDLINE_TAG
104? ??? setup_commandline_tag (bd, commandline);????? /* 設(shè)置命令行標(biāo)記 */
105? #endif
?????? … …
113? ??? setup_end_tag (bd);?????????????????????????????? /* 設(shè)置ATAG_NONE標(biāo)志 */??????????
114? #endif
115?
116? ??? /* we assume that the kernel is in place */
117? ??? printf ("\nStarting kernel ...\n\n");
?????? … …
126? ??? cleanup_before_linux ();????????? /* 啟動內(nèi)核前對CPU作最后的設(shè)置 */
127?
128? ??? theKernel (0, machid, bd->bi_boot_params);????? /* 調(diào)用內(nèi)核 */
129? ??? /* does not return */
130?
131? ??? return 1;
132? }
?????? 其中的setup_start_tag，setup_memory_tags，setup_end_tag函數(shù)在lib_arm/bootm.c中定義如下：
?????? （1）setup_start_tag函數(shù)
static void setup_start_tag (bd_t *bd)
{
?????? params = (struct tag *) bd->bi_boot_params;? /* 內(nèi)核的參數(shù)的開始地址 */
?
?????? 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);
}
?????? 標(biāo)記列表必須以ATAG_CORE開始，setup_start_tag函數(shù)在內(nèi)核的參數(shù)的開始地址設(shè)置了一個ATAG_CORE標(biāo)記。
?????? （2）setup_memory_tags函數(shù)
static void setup_memory_tags (bd_t *bd)
{
?????? int i;
/*設(shè)置一個內(nèi)存標(biāo)記 */
?????? 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函數(shù)設(shè)置了一個ATAG_MEM標(biāo)記，該標(biāo)記包含內(nèi)存起始地址，內(nèi)存大小這兩個參數(shù)。
?????? （3）setup_end_tag函數(shù)
static void setup_end_tag (bd_t *bd)
{
?????? params->hdr.tag = ATAG_NONE;
?????? params->hdr.size = 0;
}
?????? 標(biāo)記列表必須以標(biāo)記ATAG_NONE結(jié)束，setup_end_tag函數(shù)設(shè)置了一個ATAG_NONE標(biāo)記，表示標(biāo)記列表的結(jié)束。
?????? U-Boot設(shè)置好標(biāo)記列表后就要調(diào)用內(nèi)核了。但調(diào)用內(nèi)核前，CPU必須滿足下面的條件：
（1）??? CPU寄存器的設(shè)置
?? r0=0
?? r1=機器碼
?? r2=內(nèi)核參數(shù)標(biāo)記列表在RAM中的起始地址
（2）??? CPU工作模式
?? 禁止IRQ與FIQ中斷
?? CPU為SVC模式
（3）??? 使數(shù)據(jù)Cache與指令Cache失效
?????? do_bootm_linux中調(diào)用的cleanup_before_linux函數(shù)完成了禁止中斷和使Cache失效的功能。cleanup_before_linux函數(shù)在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();????????????? /* 使數(shù)據(jù)Cache失效 */
?????? /* flush I/D-cache */
?????? cache_flush();??????????????????? /* 刷新Cache */
?
?????? return 0;
}
?????? 由于U-Boot啟動以來就一直工作在SVC模式，因此CPU的工作模式就無需設(shè)置了。
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行代碼將內(nèi)核的入口地址“images->ep”強制類型轉(zhuǎn)換為函數(shù)指針。根據(jù)ATPCS規(guī)則，函數(shù)的參數(shù)個數(shù)不超過4個時，使用r0~r3這4個寄存器來傳遞參數(shù)。因此第128行的函數(shù)調(diào)用則會將0放入r0，機器碼machid放入r1，內(nèi)核參數(shù)地址bd->bi_boot_params放入r2，從而完成了寄存器的設(shè)置，最后轉(zhuǎn)到內(nèi)核的入口地址。
?????? 到這里，U-Boot的工作就結(jié)束了，系統(tǒng)跳轉(zhuǎn)到Linux內(nèi)核代碼執(zhí)行。
1.1.4???????????? U-Boot添加命令的方法及U-Boot命令執(zhí)行過程
?????? 下面以添加menu命令（啟動菜單）為例講解U-Boot添加命令的方法。
（1）??? 建立common/cmd_menu.c
?????? 習(xí)慣上通用命令源代碼放在common目錄下，與開發(fā)板專有命令源代碼則放在board/<board_dir>目錄下，并且習(xí)慣以“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)
?????? 各個參數(shù)的意義如下：
name：命令名，非字符串，但在U_BOOT_CMD中用“#”符號轉(zhuǎn)化為字符串
maxargs：命令的最大參數(shù)個數(shù)
rep：是否自動重復(fù)（按Enter鍵是否會重復(fù)執(zhí)行）
cmd：該命令對應(yīng)的響應(yīng)函數(shù)
usage：簡短的使用說明（字符串）
help：較詳細(xì)的使用說明（字符串）
?????? 在內(nèi)存中保存命令的help字段會占用一定的內(nèi)存，通過配置U-Boot可以選擇是否保存help字段。若在include/configs/mini2440.h中定義了CONFIG_SYS_LONGHELP宏，則在U-Boot中使用help命令查看某個命令的幫助信息時將顯示usage和help字段的內(nèi)容，否則就只顯示usage字段的內(nèi)容。
?????? 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}
?????? “##”與“#”都是預(yù)編譯操作符，“##”有字符串連接的功能，“#”表示后面緊接著的是一個字符串。
?????? 其中的cmd_tbl_t在include/command.h中定義如下：
struct cmd_tbl_s {
?????? char????????????? *name;????????? /* 命令名 */
?????? int????????? maxargs;?????? /* 最大參數(shù)個數(shù) */
?????? int????????? repeatable;??? /* 是否自動重復(fù) */
?????? int????????? (*cmd)(struct cmd_tbl_s *, int, int, char *[]);? /* ?響應(yīng)函數(shù) */
?????? char????????????? *usage;???????? /* 簡短的幫助信息 */
#ifdef??? CONFIG_SYS_LONGHELP
?????? char????????????? *help;?????????? /* ?較詳細(xì)的幫助信息 */
#endif
#ifdef CONFIG_AUTO_COMPLETE
?????? /* 自動補全參數(shù) */
?????? 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結(jié)構(gòu)體變量包含了調(diào)用一條命令的所需要的信息。
?????? 其中Struct_Section在include/command.h中定義如下：
#define Struct_Section? __attribute__ ((unused,section (".u_boot_cmd")))
?????? 凡是帶有__attribute__ ((unused,section (".u_boot_cmd"))屬性聲明的變量都將被存放在".u_boot_cmd"段中，并且即使該變量沒有在代碼中顯式的使用編譯器也不產(chǎn)生警告信息。
?????? 在U-Boot連接腳本u-boot.lds中定義了".u_boot_cmd"段：
?????? . = .;
?????? __u_boot_cmd_start = .;????????? /*將 __u_boot_cmd_start指定為當(dāng)前地址 */
?????? .u_boot_cmd : { *(.u_boot_cmd) }
?????? __u_boot_cmd_end = .;?????????? /*? 將__u_boot_cmd_end指定為當(dāng)前地址? */
?????? 這表明帶有“.u_boot_cmd”聲明的函數(shù)或變量將存儲在“u_boot_cmd”段。這樣只要將U-Boot所有命令對應(yīng)的cmd_tbl_t變量加上“.u_boot_cmd”聲明，編譯器就會自動將其放在“u_boot_cmd”段，查找cmd_tbl_t變量時只要在__u_boot_cmd_start與__u_boot_cmd_end之間查找就可以了。
?????? 因此“menu”命令的定義經(jīng)過宏展開后如下：
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"}
?????? 實質(zhì)上就是用U_BOOT_CMD宏定義的信息構(gòu)造了一個cmd_tbl_t類型的結(jié)構(gòu)體。編譯器將該結(jié)構(gòu)體放在“u_boot_cmd”段，執(zhí)行命令時就可以在“u_boot_cmd”段查找到對應(yīng)的cmd_tbl_t類型結(jié)構(gòu)體。
（3）??? 實現(xiàn)命令的函數(shù)
?????? 在cmd_menu.c中添加“menu”命令的響應(yīng)函數(shù)的實現(xiàn)。具體的實現(xiàn)代碼略：
int do_menu (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
{
?????? /* 實現(xiàn)代碼略 */
}
（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命令執(zhí)行的過程
?????? 在U-Boot中輸入“menu”命令執(zhí)行時，U-Boot接收輸入的字符串“menu”，傳遞給run_command函數(shù)。run_command函數(shù)調(diào)用common/command.c中實現(xiàn)的find_cmd函數(shù)在__u_boot_cmd_start與__u_boot_cmd_end間查找命令，并返回menu命令的cmd_tbl_t結(jié)構(gòu)。然后run_command函數(shù)使用返回的cmd_tbl_t結(jié)構(gòu)中的函數(shù)指針調(diào)用menu命令的響應(yīng)函數(shù)do_menu，從而完成了命令的執(zhí)行。
?
? 作者：heaad
? ?http://www.cnblogs.com/heaad/?
郵箱：heaad@qq.com
? 本文摘選自作者所寫的一篇文章。轉(zhuǎn)載請注明，水平有限，歡迎拍磚。?
轉(zhuǎn)載于:https://www.cnblogs.com/huty/p/8517542.html
總結(jié)
以上是生活随笔為你收集整理的【ARM-Linux开发】U-Boot启动过程--详细版的完全分析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 赵老师_01
- 下一篇： Linux下查看/管理当前登录用户及用户