uboot編程詳解教程

1、 U-Boot編程：教程介紹為了使U-Boot適應(yīng)自定義的硬件，通常需要對(duì)U-Boot進(jìn)行一些細(xì)微的更改。例如，支持特定于電路板的功能或添加一些例程，這些例程向終端用戶發(fā)出信號(hào)，表明設(shè)備確實(shí)已經(jīng)啟動(dòng)，并且在。啟動(dòng)的過(guò)程發(fā)生時(shí)發(fā)生了一些事情。這篇簡(jiǎn)短的教程主要介紹用于ARM的U-Boot，但是在其它架構(gòu)上上使用的技術(shù)是相似的，而且通常是完全相同的。假設(shè)讀者熟悉命令級(jí)的U-Boot用法以及編譯和部署。建議首先讀取項(xiàng)目根目錄中的自述文件。它包括以下主題：源文件樹結(jié)構(gòu)配置的含義定義U-Boot構(gòu)建說(shuō)明。如何將U-Boot移植到新平臺(tái)對(duì)Hush shell簡(jiǎn)介如何構(gòu)建Linux映像（mkimage）常見

2、環(huán)境變量列表“Hello world”示例及其使用方法boards.cfg包含支持的板的列表。也值得一看。本教程是針對(duì)U-Boot版本v2013.07編寫的，但是這些原則適用于各種版本。明智的黑客當(dāng)遇到大量的軟件資源時(shí)，最直接的本能是尋找第一個(gè)地方注入一個(gè)小的黑客，并對(duì)必要的功能進(jìn)行硬編碼。這不僅會(huì)在將來(lái)導(dǎo)致令人生畏的重新破解和重新編譯，而且也沒有必要：U-Boot實(shí)際上是為了方便添加自定義功能而設(shè)計(jì)的?？梢詫⒖赡艿男薷姆譃槿悾盒薷腢-Boot的初始化過(guò)程，以便盡早設(shè)置定制板的特定硬件通過(guò)添加或修改低級(jí)驅(qū)動(dòng)程序，增加對(duì)特定硬件的支持?jǐn)U展命令界面以支持所需功能，可能作為新硬件的前端在電路板的初

3、始化程序中添加幾行黑客代碼來(lái)執(zhí)行特定的操作可能很誘人。這很有可能有效，但正如剛剛提到的，硬編碼也有其缺點(diǎn)。如果硬件的設(shè)置可以推遲到命令執(zhí)行階段，那么編寫一個(gè)小型的自定義驅(qū)動(dòng)程序和命令支持就更加優(yōu)雅，而且可重用。本教程分為三個(gè)部分：關(guān)于U-Boot的概述（本部分）、關(guān)于如何添加功能的實(shí)際操作說(shuō)明（第二部分）以及一些有關(guān)U-Boot啟動(dòng)過(guò)程的背景知識(shí)，用于那些需要很早初始化某些東西的人使用（第三部分）。軟件組織Linux內(nèi)核黑客會(huì)對(duì)U-Boot感到相對(duì)舒服，因?yàn)楹芏嗑幋a風(fēng)格和組織方式都受到Linux內(nèi)核的啟發(fā)。然而，這種結(jié)構(gòu)更簡(jiǎn)單，但靈活性更低。在驅(qū)動(dòng)程序和用戶前端之間沒有中間層。例如，要獲取GP

4、IO pin的值，只需在代碼中的任何位置使用GPIO的pin編號(hào)調(diào)用gpio_get_value(gpio)。沒有地方可以將多個(gè)GPIO驅(qū)動(dòng)程序編譯到系統(tǒng)中：只能啟用一個(gè)定義此函數(shù)的源文件進(jìn)行編譯，否則鏈接將失敗。當(dāng)然，如果在某個(gè)地方使用了gpio_get_value（），則必須編譯這個(gè)源文件。因此，U-Boot中的“硬件驅(qū)動(dòng)程序”只是一段代碼，它實(shí)現(xiàn)了一組鏈接到全局名稱空間的函數(shù)。對(duì)于一個(gè)需要緊湊的實(shí)用程序來(lái)說(shuō)，這是有意義的：在任何不使用的東西中都沒有編譯，而且大多數(shù)時(shí)候都涉及一組固定的硬件，每種類型最多只能有一個(gè)實(shí)例。當(dāng)然，一個(gè)驅(qū)動(dòng)可能依賴另一個(gè)驅(qū)動(dòng)。例如，SOFT_I2C驅(qū)動(dòng)程序依賴于連

5、接到I2C設(shè)備的兩個(gè)GPIO引腳。這些引腳是使用GPIO的API函數(shù)訪問(wèn)的。任何其他軟件也可以訪問(wèn)GPIO API （希望不是相同的引腳）。make XXX_config的幕后任何建立過(guò)U-Boot的人都會(huì)輸入類似$ make zynq_zed_config在編譯項(xiàng)目之前，許多人還發(fā)現(xiàn)有一個(gè)/include/configs/目錄，在這個(gè)目錄中可以找到相應(yīng)的文件，例如zynq_zed.h，它的內(nèi)容如下（頂部的GPLv2標(biāo)頭未顯示在這里）：#ifndef _CONFIG_ZYNQ_ZED_H#define _CONFIG_ZYNQ_ZED_H#define PHYS_SDRAM_1_SIZE (5

6、12 * 1024 * 1024)#define CONFIG_ZYNQ_SERIAL_UART1#define CONFIG_ZYNQ_GEM0#define CONFIG_ZYNQ_GEM_PHY_ADDR00#define CONFIG_SYS_NO_FLASH#define CONFIG_ZYNQ_SDHCI0#define CONFIG_ZYNQ_QSPI#define CONFIG_ZYNQ_BOOT_FREEBSD#include #endif /* _CONFIG_ZYNQ_ZED_H */這其實(shí)只是冰山一角。其中，“make zynq_zed_config”命令生成inclu

7、de/config.h，如下所示：/* Automatically generated - do not edit */#define CONFIG_SYS_ARCH arm#define CONFIG_SYS_CPU armv7#define CONFIG_SYS_BOARD zynq#define CONFIG_SYS_VENDOR xilinx#define CONFIG_SYS_SOC zynq#define CONFIG_BOARDDIR board/xilinx/zynq#include #include #include #include #include #include 包含

8、的配置文件包含其他的#define（可能還有#undef）語(yǔ)句，其中大多數(shù)語(yǔ)句用于帶有CONFIG_*前綴的變量。在這一點(diǎn)上，很明顯，定義CONFIG_*編譯變量（以及其他變量）的頭文件有點(diǎn)混亂。這些因素通過(guò)兩種方式影響代碼的編譯方式：1.所有定義的CONFIG_*變量都會(huì)變成了include/autoconf.mk中的Makefile變量，其中每個(gè)剛剛定義的變量（與賦值相反）都得到值“y”。它在每個(gè)源目錄中的makefile中使用，以選擇哪些文件被編譯并鏈接到主可執(zhí)行文件中。2.這些編譯變量直接在編譯后的C源代碼中使用，并且可能包含特定于目標(biāo)的屬性。與Linux內(nèi)核不同，沒有KConfig實(shí)

9、用程序，因此這些定義是在特定于板的h文件中定義的。要添加一個(gè)新的“make config”目標(biāo)，請(qǐng)?jiān)趇nclude/configs/（或更好，復(fù)制一個(gè)類似的配置文件）創(chuàng)建一個(gè)新的配置文件，并在boards.cfg中添加一行U-Boot中代碼的三種功能可以將代碼分為三種類型（與上面提到的修改類型類似）：純初始化代碼：此代碼始終在U-Boot自身啟動(dòng)期間運(yùn)行。關(guān)于這一階段的更多信息，請(qǐng)參閱第三部分?！膀?qū)動(dòng)程序”：實(shí)現(xiàn)一組功能的代碼，允許訪問(wèn)某個(gè)硬件。其中大部分都可以在drivers/、fs/和其他文件中找到命令：向U-Boot shell添加命令，并實(shí)現(xiàn)其功能，通?；趯?duì)驅(qū)動(dòng)程序API的調(diào)用。它們

10、顯示為common/cmd_*.c這三種代碼類型都受到CONFIG定義的強(qiáng)烈影響。例如，啟用某個(gè)驅(qū)動(dòng)程序編譯的配置也可能導(dǎo)致初始化代碼片段選擇使用#ifdef。向U-Boot添加全新功能的典型方法是編寫驅(qū)動(dòng)程序代碼，為其編寫命令前端，并使用CONFIG標(biāo)志啟用它們。在某些情況下，在初始化序列中添加一個(gè)段，以便在發(fā)出任何命令之前準(zhǔn)備硬件。_繼續(xù)第二部分，它解釋了如何添加功能。示例：添加GPIO支持U-Boot支持多個(gè)平臺(tái)上的GPIO，但通常不啟用。我們將簡(jiǎn)要介紹啟用此功能的過(guò)程，可能是針對(duì)一個(gè)新平臺(tái)。在common/目錄中，很容易找到cmd_gpio.c文件。它包含在U-Boot的shell中處

11、理“gpio”命令的代碼。最后幾行是：U_BOOT_CMD(gpio, 3, 0, do_gpio, input/set/clear/toggle gpio pins, n - input/set/clear/toggle the specified pin);它將do_gpio（）聲明為要處理“gpio”命令的函數(shù)。它還說(shuō)最多允許兩個(gè)參數(shù)（數(shù)字3包括命令本身），并且不允許自動(dòng)重復(fù)，還有短的和長(zhǎng)的幫助字符串。U_BOOT_CMD宏在doc/README.commands文件中解釋。do_gpio()函數(shù)本質(zhì)上是一個(gè)argc/argv函數(shù)，帶有一些在大多數(shù)實(shí)現(xiàn)中沒有使用的額外參數(shù)。因此，這取決于

12、解析參數(shù)和調(diào)用較低級(jí)別的函數(shù)，通常來(lái)自某個(gè)驅(qū)動(dòng)程序API。詳細(xì)研究cmd gpio.c是毫無(wú)意義的-通過(guò)讀取命令和其他cmd_*.c文件，可以很容易地理解命令的解釋和執(zhí)行原理。在大多數(shù)情況下，這比人們想象的要簡(jiǎn)單。至于與構(gòu)建系統(tǒng)的交互，也很簡(jiǎn)單：在common/Makefile的某個(gè)地方，有一行代碼：COBJS-$(CONFIG_CMD_GPIO) += cmd_gpio.o在不深入構(gòu)建系統(tǒng)的復(fù)雜部分的情況下，這一行意味著，如果在配置鏈中定義了CONFIG_CMD_GPIO，則cmd_gpio.c將編譯為cmd_gpio.o，并鏈接到全局項(xiàng)目中。U_BOOT_CMD（）宏確保命令已登記在U-B

13、OOT shell解釋器中。但我們還沒說(shuō)完。例如，在cmd gpio.c中，有一個(gè)地方說(shuō)if (sub_cmd = GPIO_INPUT) gpio_direction_input(gpio); value = gpio_get_value(gpio);函數(shù)gpio_direction_input（）和gpio_get_value（）函數(shù)沒有在cmd_gpio.c中定義。更確切地說(shuō)，它們將由其他文件（“驅(qū)動(dòng)程序”）定義，該文件被編譯并鏈接到全局可執(zhí)行文件中。正如人們所料，drivers/gpio/中有許多候選C文件，每個(gè)文件都以其預(yù)期的平臺(tái)命名。它們都或多或少地實(shí)現(xiàn)了相同的一組函數(shù)，并且以非常

14、相似的方式實(shí)現(xiàn)。當(dāng)然，低層的實(shí)現(xiàn)各不相同。當(dāng)然，其中只有一個(gè)可以編譯。哪一個(gè)取決于定義了哪個(gè)配置（如果有的話）。drivers/gpio/中的Makefile與此類似，行如下 . COBJS-$(CONFIG_BCM2835_GPIO)+= bcm2835_gpio.oCOBJS-$(CONFIG_S3C2440_GPIO)+= s3c2440_gpio.oCOBJS-$(CONFIG_XILINX_GPIO)+= xilinx_gpio.oCOBJS-$(CONFIG_ADI_GPIO2)+= adi_gpio2.o . 總而言之，要使用Xilinx的GPIO，主板的配置文件中應(yīng)該出現(xiàn)以下兩

15、行：#define CONFIG_CMD_GPIO#define CONFIG_XILINX_GPIO請(qǐng)注意，有時(shí)需要額外的配置變量。通過(guò)閱讀驅(qū)動(dòng)程序的源代碼，通常最容易推斷出它們的含義。要為尚未支持的硬件添加驅(qū)動(dòng)程序，建議查看現(xiàn)有的驅(qū)動(dòng)程序，并查看是否有一個(gè)幾乎可以按要求工作的驅(qū)動(dòng)程序。有時(shí)可以用ifdef調(diào)整它，使其支持所需的硬件。如果情況不是這樣，建議的做法是復(fù)制看起來(lái)最接近所需功能的驅(qū)動(dòng)程序，并根據(jù)需要進(jìn)行更改。為了在構(gòu)建系統(tǒng)中包含新驅(qū)動(dòng)程序，請(qǐng)?jiān)谕荒夸浀腗akefile中添加一個(gè)COBJ-$（）+=行，并添加相應(yīng)的（新）CONFIG標(biāo)志來(lái)啟用它?？捎肁PIU-Boot中的每個(gè)函數(shù)都

16、可以被任何代碼訪問(wèn)，但是有些函數(shù)比其他函數(shù)更常用。查看其他驅(qū)動(dòng)程序和cmd*.c文件，通常可以了解如何編寫新代碼。許多經(jīng)典的C-API都得到了支持，甚至支持哪些在小的引導(dǎo)加載程序中也不可能實(shí)現(xiàn)的功能。API中有幾個(gè)函數(shù)值得一提：寄存器可以通過(guò)writel（）和readl（）等訪問(wèn)，就像在Linux中一樣，如arch/arm/include/asm/io.h中定義的那樣可以使用setenv(), setenv_ulong(), setenv_hex(), getenv(), getenv_ulong() and getenv_hex()等函數(shù)訪問(wèn)環(huán)境。這些函數(shù)和其他函數(shù)在common/cmd_i

17、nvedit.c中定義提供printf（）和vprintf（），以及getc（）、putc（）和puts（）。有g(shù)unzip（）和zunzip（）用于解壓縮數(shù)據(jù)。lib/目錄包含幾個(gè)庫(kù)函數(shù)，用于處理字符串、CRC、哈希表、排序、加密等。有必要在include/common.h中查找一些基本的API函數(shù)。_繼續(xù)第三部分，簡(jiǎn)要介紹U-Boot的啟動(dòng)過(guò)程。U-Boot程序設(shè)計(jì)教程第三部分U-Boot啟動(dòng)盡管在大多數(shù)情況下是不必要的，但有時(shí)需要修改U-Boot自身的啟動(dòng)過(guò)程，特別是在早期階段初始化自定義硬件時(shí)。本節(jié)介紹U-Boot的這一部分的基礎(chǔ)知識(shí)。U-Boot是處理器上首先運(yùn)行的東西之一，它可能負(fù)

18、責(zé)最基本的硬件初始化。在某些平臺(tái)上，當(dāng)U-Boot開始運(yùn)行時(shí)，處理器的RAM沒有配置，所以基本的假設(shè)是U-Boot可以直接從ROM（通常是閃存）運(yùn)行。因此，啟動(dòng)過(guò)程的關(guān)鍵事件是U-Boot將自己從開始運(yùn)行的地方復(fù)制到RAM中，從RAM運(yùn)行更復(fù)雜的任務(wù)（尤其是處理引導(dǎo)命令）。這種自復(fù)制稱為“重定位”。幾乎不用說(shuō)，處理器是在“real模式”下運(yùn)行的：如果有MMU的話，它就是關(guān)閉的。沒有內(nèi)存轉(zhuǎn)換，也沒有保護(hù)。U-Boot在這個(gè)基礎(chǔ)上玩了一些骯臟的把戲。總體而言，U-Boot加載程序運(yùn)行于以下階段：預(yù)重定位初始化（可能直接從閃存或其他類型的ROM）重新定位：將代碼復(fù)制到RAM。重新定位后初始化（從適當(dāng)

19、的RAM）。命令執(zhí)行：通過(guò)自動(dòng)引導(dǎo)或控制臺(tái)shell將控制權(quán)傳遞給Linux內(nèi)核（或其他目標(biāo)應(yīng)用程序）注意，在一些場(chǎng)景中，U-Boot首先從正確的RAM開始，因此沒有實(shí)際的重定位發(fā)生。在這些場(chǎng)景中，對(duì)搬遷前和搬遷后的劃分有些人為，但這是術(shù)語(yǔ)。更詳細(xì)的查看ARM架構(gòu)的序列可以從arch/arm/lib/crt0.S中推導(dǎo)出來(lái)，這絕對(duì)是第一個(gè)運(yùn)行的東西。這段匯編代碼調(diào)用函數(shù)如下（以及一些非常低級(jí)的初始化）：board_init_f（）（在arch/arm/lib/board.c中定義）：調(diào)用init_sequence_f函數(shù)指針數(shù)組中列出的函數(shù)（使用initcall_run_list（），此文件中

20、包含大量ifdef。該函數(shù)然后運(yùn)行各種依賴于ifdef的init片段。重新定位relocate_code()crt0.S直接調(diào)用coloured_LED_init() and red_led_on()。定義這些函數(shù)允許調(diào)用早期引導(dǎo)進(jìn)程的鉤子函數(shù)。board_init_r（）（也可能在arch/arm/lib/board.c中定義）：作為從RAM運(yùn)行的“正?！背绦蜻\(yùn)行初始化。相反，此函數(shù)永不返回。board_init_r（）在main_loop（）上永遠(yuǎn)循環(huán)（在common/main.c中定義）。這本質(zhì)上是命令解析器從輸入中自動(dòng)引導(dǎo)或執(zhí)行命令（可能是hush）。在某個(gè)階段，main_loop（）中的命令將控制權(quán)交