基於OMAP-L138電路板的U-boot移植

最近參加了一個項目，主板採用的是TI的OMAP-L138,為了引導linux核心，準備採用u-boot作為bootloader。在搜集資料的過程中發現關於移植u-boot到基於OMAP-L138電路板的資料非常少，而且TI的OMAP-L138採用三級boot,比其他單arm9核的SOC要複雜的多，因此糾結了很長時間。好不容易參照hawkboard的配置把u-boot-2011.03移植到我們的板子（gcboard）上，在此記錄下我的一點經驗，希望能對後來者有所協助。

step 1.移植準備
u-boot-2011.03 已經包含了對hawkboard開發板的完整支援，這是一款基於OMAP-L138的開發板，它的外設主要有：
1）128MB DDR2 SDRAM
2）128MB NAND Flash
3）一個標準RS232串口
4）一個10M/100M高速網卡
而我們的項目所用的開發板與hawkboard主要的區別在於沒有nand flash,多了一塊SPI flash(採用STMicro公司的M25P128,)
移植u-boot主要是為了在開發初期調試核心，檔案系統，後期一般他只需要做適當的初始化，再引導核心就可以了，所以移植需要關注的基本就是這些。
為了熟悉程式結構，首先使用hawkboard的預設配置對uboot進行編譯：
make hawkboard_config
make
編譯完成後可以看到在主目錄下產生了uboot.bin檔案，為了方便分析，使用如下命令將其反組譯碼：
arm-linux-objdump -D -m arm u-boot > u-boot.asm
利用u-boot.asm 和 system.map，u-boot.lds這三個檔案，再配合原始碼，我們可以很容易的剖析器流程：
首先看u-boot.lds檔案,它指定了程式連結順序，在最初幾行我們可以看到：init_sequence

OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
OUTPUT_ARCH(arm)
ENTRY(_start)
SECTIONS
{
. = 0x00000000;
. = ALIGN(4);
.text :
{
arch/arm/cpu/arm926ejs/start.o (.text)
*(.text)
}
...
}

可知程式是從arch/arm/cpu/arm926ejs/start.s開始的（這是老生常談了，百度一下，幾乎任何一篇介紹uboot的文章都會介紹這一點），開啟這個檔案我們可以看到程式的54行：

.globl _start
_start:
b reset

首先跳到reset 標號處執行，在第108行：

reset:
/*
* set the cpu to SVC32 mode
*/
mrs r0,cpsr
bic r0,r0,#0x1f
orr r0,r0,#0xd3
msr cpsr,r0

/*
* we do sys-critical inits only at reboot,
* not when booting from ram!
*/
#ifndef CONFIG_SKIP_LOWLEVEL_INIT
bl cpu_init_crit
#endif

這裡是否會執行 bl cpu_init_crit這一句指令呢？需要到設定檔中去找答案，開啟include/configs/hawkboard.h檔案我們可以看到，由於定義了宏CONFIG_SKIP_LOWLEVEL_INIT,這一句被跳過，這是由OMAP-L138 的啟動方式決定的。接下來看第179行:

call_board_init_f:
ldr sp, =(CONFIG_SYS_INIT_SP_ADDR)
bic sp, sp, #7 /* 8-byte alignment for ABI compliance */
ldr r0,=0x00000000
bl board_init_f

首先設定好棧，然後調用了一個c函數（使用r0來傳遞參數），找到這個函數有一個比較麻煩的方法，首先在u-boot.asm中找到board_init_f標號，它在第1100行，對應的地址為c1180e9c,在uboot主目錄下輸入如下命令：
addr2line -e u-boot c1180e9c
顯示該函數是在u-boot-2011.03/arch/arm/lib/board.c:283行（當然在linux下我們還可以使用命令: grep "board_init_f" ./ -R，在u-boot源碼目錄下尋找所有包含"board_init_f"的檔案，只是要找出這個函數在哪個檔案還得再費點功夫）
開啟board.c,這個是所有arm結構的班子共用的板級初始設定檔案，可以看到該函數主要做了如下工作：
1.調用init_sequence數組中包含的所有初始化函數，這些函數包括
env_init, /* initialize environment */
init_baudrate, /* initialze baudrate settings */
serial_init, /* serial communications setup */
console_init_f, /* stage 1 init of console */
display_banner, /* say that we are here */
dram_init,
另外有一些初始化函數由宏定義開關來決定是否執行
2.對gd_t這個結構進行填充（非常重要，定義在arch/arm/include/asm/global_data.h中）。這個結構記錄了系統的記憶體大小，傳輸速率等資訊。
最後調用relocate_code函數進行代碼重定位，這是一個彙編函數，在start.s第195行定義：
elocate_code:
mov r4, r0 /* save addr_sp */
mov r5, r1 /* save addr of gd */
mov r6, r2 /* save addr of destination */

/* Set up the stack */
stack_setup:
mov sp, r4

adr r0, _start
cmp r0, r6
beq clear_bss /* skip relocation */
mov r1, r6 /* r1 <- scratch for copy loop */
ldr r3, _bss_start_ofs
add r2, r0, r3 /* r2 <- source end address */

copy_loop:
ldmia r0!, {r9-r10} /* copy from source address [r0] */
stmia r1!, {r9-r10} /* copy to target address [r1] */
cmp r0, r2 /* until source end address [r2] */
blo copy_loop

函數執行之前先檢查自己是否已經在記憶體中，由於TI的OMAP-L138採用三重啟動，U-boot在啟動時已經被UBL裝載到記憶體中，所以這一步跳過，直接跳轉到clear_bss,清資料區段，然後跳轉到board.c中的board_init_r函數中，開始了第二階段的初始化，最後進入U-boot的主迴圈。

step 2.根據上述流程，對u-boot作如下移植：
將/include/configs/hawkboard.h複製為gcboard.h，開啟gcboard.h,作如下修改：
1）注釋掉#define CONFIG_SYS_USE_NAND,這樣所有跟nand flash 有關的代碼都不會被編譯了。
2）添加如下宏定義：
#define CONFIG_SPI_FLASH 1 //添加SPI Flash 支援
#ifdef CONFIG_SPI_FLASH
#define CONFIG_SPI_FLASH_STMICRO 1 //添加STMicro 的SPI FLASH 驅動
#define CONFIG_SYS_NO_FLASH 1 //務必添加這個宏，否則會引入CFI Flash的驅動編譯
#define CONFIG_DEFAULT_SPI_BUS 1 //定義SPI FLASH所在的匯流排，這裡指定SPI1
#define CONFIG_DAVINCI_SPI 1 //架構相關的SPI驅動
#define CONFIG_SYS_SPI_BASE 0x01f0e000 //指定SPI1 寄存器的基地址
#define CONFIG_SYS_SPI_CLK 50000000 //最大工作頻率50Mhz，由器件手冊得到
#define CONFIG_MAX_SPI_SECT 64 //從這裡開始的三個宏是我自己定義的，為了方便記憶，他們不是必要的
#define CONFIG_MAX_SPI_BANKS 1 //
#define CONFIG_MAX_SPI_CAPACITY 0x1000000 //
#define CONFIG_SPI_SECT_SIZE 0x40000 //M25P128每個sector是256KB

#define CONFIG_ENV_IS_IN_SPI_FLASH 1 //環境變數儲存在SPI FLASH 中
#define CONFIG_ENV_SPI_MODE SPI_MODE_0 //其實不用指定，預設值也可以
#define CONFIG_ENV_SPI_BUS 1 //
#define CONFIG_ENV_SPI_CS 0 //必須是CS0
#define CONFIG_ENV_SPI_MAX_HZ 50000000
#define CONFIG_ENV_SIZE 0x40000
#define CONFIG_ENV_SECT_SIZE 0x40000
#define CONFIG_ENV_OFFSET (CONFIG_MAX_SPI_CAPACITY-CONFIG_SPI_SECT_SIZE) //儲存在最後一塊，以免誤操作把U-boot給擦掉了

#define CONFIG_CMD_SPI 1 //
#define CONFIG_SPIBOOTLDR 1 //
#define CONFIG_CMD_SF 1 //在U-boot中增加SF（SPI FLASH命令），否則不能對SPI FLASH進行操作

3）驅動的修改。在u-boot-2011.03中，davinci 架構的SPI FLASH 驅動中有一個問題就是，在檢測SPI FLASH 時只檢測SPI0的CS0，由此導致的問題是:若你的SPI FLASH掛在SPI1上，而你想要在U-boot 中使用SF probe 檢測SPI FLASH 就會提示"can't setup slave"的問題，因此找到/drivers/spi/davinci_spi.c中的setup_slave函數，將其中的：
if (!spi_cs_is_valid(bus, cs))
return NULL;
這一段注釋掉。實際上spi_cs_is_valid函數只有一句:
return bus == 0 && cs == 0
可見這樣檢測的話我們的SPI FLASH 是不可能被檢測出來的。

4）添加自訂配置gcboard.h。u-boot-2011.03使用新的組建組態檔案方法，為了在執行make gcboard_config時能夠自動讀取我們的設定檔，需要編輯u-boot主目錄下的boards.cfg檔案，在其中搜尋hawkboard,可以看到第84行:
hawkboard arm arm926ejs da8xxevm davinci davinci
hawkboard_nand arm arm926ejs da8xxevm davinci davinci hawkboard:NAND_U_BOOT
hawkboard_uart arm arm926ejs da8xxevm davinci davinci hawkboard:UART_U_BOOT
仿照這種格式我們添加如下行：
gcboard arm arm926ejs da8xxevm davinci davinci
這樣make的時候會自動讀取我們的配置

5）重新編譯u-boot
make clean
make distclean
make gcboard_config
make

這樣就產生了針對gcboard的u-boot,當然，下一步還需要將u-boot.bin使用TI的工具轉換為AIS格式映像，下載到已經裝有UBL的SPI FLASH才能引導板子啟動

最近參加了一個項目，主板採用的是TI的OMAP-L138,為了引導linux核心，準備採用u-boot作為bootloader。在搜集資料的過程中發現關於移植u-boot到基於OMAP-L138電路板的資料非常少，而且TI的OMAP-L138採用三級boot,比其他單arm9核的SOC要複雜的多，因此糾結了很長時間。好不容易參照hawkboard的配置把u-boot-2011.03移植到我們的板子（gcboard）上，在此記錄下我的一點經驗，希望能對後來者有所協助。

step 1.移植準備
u-boot-2011.03 已經包含了對hawkboard開發板的完整支援，這是一款基於OMAP-L138的開發板，它的外設主要有：
1）128MB DDR2 SDRAM
2）128MB NAND Flash
3）一個標準RS232串口
4）一個10M/100M高速網卡
而我們的項目所用的開發板與hawkboard主要的區別在於沒有nand flash,多了一塊SPI flash(採用STMicro公司的M25P128,)
移植u-boot主要是為了在開發初期調試核心，檔案系統，後期一般他只需要做適當的初始化，再引導核心就可以了，所以移植需要關注的基本就是這些。
為了熟悉程式結構，首先使用hawkboard的預設配置對uboot進行編譯：
make hawkboard_config
make
編譯完成後可以看到在主目錄下產生了uboot.bin檔案，為了方便分析，使用如下命令將其反組譯碼：
arm-linux-objdump -D -m arm u-boot > u-boot.asm
利用u-boot.asm 和 system.map，u-boot.lds這三個檔案，再配合原始碼，我們可以很容易的剖析器流程：
首先看u-boot.lds檔案,它指定了程式連結順序，在最初幾行我們可以看到：init_sequence

OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
OUTPUT_ARCH(arm)
ENTRY(_start)
SECTIONS
{
. = 0x00000000;
. = ALIGN(4);
.text :
{
arch/arm/cpu/arm926ejs/start.o (.text)
*(.text)
}
...
}

可知程式是從arch/arm/cpu/arm926ejs/start.s開始的（這是老生常談了，百度一下，幾乎任何一篇介紹uboot的文章都會介紹這一點），開啟這個檔案我們可以看到程式的54行：

.globl _start
_start:
b reset

首先跳到reset 標號處執行，在第108行：

reset:
/*
* set the cpu to SVC32 mode
*/
mrs r0,cpsr
bic r0,r0,#0x1f
orr r0,r0,#0xd3
msr cpsr,r0

/*
* we do sys-critical inits only at reboot,
* not when booting from ram!
*/
#ifndef CONFIG_SKIP_LOWLEVEL_INIT
bl cpu_init_crit
#endif

這裡是否會執行 bl cpu_init_crit這一句指令呢？需要到設定檔中去找答案，開啟include/configs/hawkboard.h檔案我們可以看到，由於定義了宏CONFIG_SKIP_LOWLEVEL_INIT,這一句被跳過，這是由OMAP-L138 的啟動方式決定的。接下來看第179行:

call_board_init_f:
ldr sp, =(CONFIG_SYS_INIT_SP_ADDR)
bic sp, sp, #7 /* 8-byte alignment for ABI compliance */
ldr r0,=0x00000000
bl board_init_f

首先設定好棧，然後調用了一個c函數（使用r0來傳遞參數），找到這個函數有一個比較麻煩的方法，首先在u-boot.asm中找到board_init_f標號，它在第1100行，對應的地址為c1180e9c,在uboot主目錄下輸入如下命令：
addr2line -e u-boot c1180e9c
顯示該函數是在u-boot-2011.03/arch/arm/lib/board.c:283行（當然在linux下我們還可以使用命令: grep "board_init_f" ./ -R，在u-boot源碼目錄下尋找所有包含"board_init_f"的檔案，只是要找出這個函數在哪個檔案還得再費點功夫）
開啟board.c,這個是所有arm結構的班子共用的板級初始設定檔案，可以看到該函數主要做了如下工作：
1.調用init_sequence數組中包含的所有初始化函數，這些函數包括
env_init, /* initialize environment */
init_baudrate, /* initialze baudrate settings */
serial_init, /* serial communications setup */
console_init_f, /* stage 1 init of console */
display_banner, /* say that we are here */
dram_init,
另外有一些初始化函數由宏定義開關來決定是否執行
2.對gd_t這個結構進行填充（非常重要，定義在arch/arm/include/asm/global_data.h中）。這個結構記錄了系統的記憶體大小，傳輸速率等資訊。
最後調用relocate_code函數進行代碼重定位，這是一個彙編函數，在start.s第195行定義：
elocate_code:
mov r4, r0 /* save addr_sp */
mov r5, r1 /* save addr of gd */
mov r6, r2 /* save addr of destination */

/* Set up the stack */
stack_setup:
mov sp, r4

adr r0, _start
cmp r0, r6
beq clear_bss /* skip relocation */
mov r1, r6 /* r1 <- scratch for copy loop */
ldr r3, _bss_start_ofs
add r2, r0, r3 /* r2 <- source end address */

copy_loop:
ldmia r0!, {r9-r10} /* copy from source address [r0] */
stmia r1!, {r9-r10} /* copy to target address [r1] */
cmp r0, r2 /* until source end address [r2] */
blo copy_loop

函數執行之前先檢查自己是否已經在記憶體中，由於TI的OMAP-L138採用三重啟動，U-boot在啟動時已經被UBL裝載到記憶體中，所以這一步跳過，直接跳轉到clear_bss,清資料區段，然後跳轉到board.c中的board_init_r函數中，開始了第二階段的初始化，最後進入U-boot的主迴圈。

step 2.根據上述流程，對u-boot作如下移植：
將/include/configs/hawkboard.h複製為gcboard.h，開啟gcboard.h,作如下修改：
1）注釋掉#define CONFIG_SYS_USE_NAND,這樣所有跟nand flash 有關的代碼都不會被編譯了。
2）添加如下宏定義：
#define CONFIG_SPI_FLASH 1 //添加SPI Flash 支援
#ifdef CONFIG_SPI_FLASH
#define CONFIG_SPI_FLASH_STMICRO 1 //添加STMicro 的SPI FLASH 驅動
#define CONFIG_SYS_NO_FLASH 1 //務必添加這個宏，否則會引入CFI Flash的驅動編譯
#define CONFIG_DEFAULT_SPI_BUS 1 //定義SPI FLASH所在的匯流排，這裡指定SPI1
#define CONFIG_DAVINCI_SPI 1 //架構相關的SPI驅動
#define CONFIG_SYS_SPI_BASE 0x01f0e000 //指定SPI1 寄存器的基地址
#define CONFIG_SYS_SPI_CLK 50000000 //最大工作頻率50Mhz，由器件手冊得到
#define CONFIG_MAX_SPI_SECT 64 //從這裡開始的三個宏是我自己定義的，為了方便記憶，他們不是必要的
#define CONFIG_MAX_SPI_BANKS 1 //
#define CONFIG_MAX_SPI_CAPACITY 0x1000000 //
#define CONFIG_SPI_SECT_SIZE 0x40000 //M25P128每個sector是256KB

#define CONFIG_ENV_IS_IN_SPI_FLASH 1 //環境變數儲存在SPI FLASH 中
#define CONFIG_ENV_SPI_MODE SPI_MODE_0 //其實不用指定，預設值也可以
#define CONFIG_ENV_SPI_BUS 1 //
#define CONFIG_ENV_SPI_CS 0 //必須是CS0
#define CONFIG_ENV_SPI_MAX_HZ 50000000
#define CONFIG_ENV_SIZE 0x40000
#define CONFIG_ENV_SECT_SIZE 0x40000
#define CONFIG_ENV_OFFSET (CONFIG_MAX_SPI_CAPACITY-CONFIG_SPI_SECT_SIZE) //儲存在最後一塊，以免誤操作把U-boot給擦掉了

#define CONFIG_CMD_SPI 1 //
#define CONFIG_SPIBOOTLDR 1 //
#define CONFIG_CMD_SF 1 //在U-boot中增加SF（SPI FLASH命令），否則不能對SPI FLASH進行操作

3）驅動的修改。在u-boot-2011.03中，davinci 架構的SPI FLASH 驅動中有一個問題就是，在檢測SPI FLASH 時只檢測SPI0的CS0，由此導致的問題是:若你的SPI FLASH掛在SPI1上，而你想要在U-boot 中使用SF probe 檢測SPI FLASH 就會提示"can't setup slave"的問題，因此找到/drivers/spi/davinci_spi.c中的setup_slave函數，將其中的：
if (!spi_cs_is_valid(bus, cs))
return NULL;
這一段注釋掉。實際上spi_cs_is_valid函數只有一句:
return bus == 0 && cs == 0
可見這樣檢測的話我們的SPI FLASH 是不可能被檢測出來的。

4）添加自訂配置gcboard.h。u-boot-2011.03使用新的組建組態檔案方法，為了在執行make gcboard_config時能夠自動讀取我們的設定檔，需要編輯u-boot主目錄下的boards.cfg檔案，在其中搜尋hawkboard,可以看到第84行:
hawkboard arm arm926ejs da8xxevm davinci davinci
hawkboard_nand arm arm926ejs da8xxevm davinci davinci hawkboard:NAND_U_BOOT
hawkboard_uart arm arm926ejs da8xxevm davinci davinci hawkboard:UART_U_BOOT
仿照這種格式我們添加如下行：
gcboard arm arm926ejs da8xxevm davinci davinci
這樣make的時候會自動讀取我們的配置

5）重新編譯u-boot
make clean
make distclean
make gcboard_config
make

這樣就產生了針對gcboard的u-boot,當然，下一步還需要將u-boot.bin使用TI的工具轉換為AIS格式映像，下載到已經裝有UBL的SPI FLASH才能引導板子啟動

最近參加了一個項目，主板採用的是TI的OMAP-L138,為了引導linux核心，準備採用u-boot作為bootloader。在搜集資料的過程中發現關於移植u-boot到基於OMAP-L138電路板的資料非常少，而且TI的OMAP-L138採用三級boot,比其他單arm9核的SOC要複雜的多，因此糾結了很長時間。好不容易參照hawkboard的配置把u-boot-2011.03移植到我們的板子（gcboard）上，在此記錄下我的一點經驗，希望能對後來者有所協助。

step 1.移植準備
u-boot-2011.03 已經包含了對hawkboard開發板的完整支援，這是一款基於OMAP-L138的開發板，它的外設主要有：
1）128MB DDR2 SDRAM
2）128MB NAND Flash
3）一個標準RS232串口
4）一個10M/100M高速網卡
而我們的項目所用的開發板與hawkboard主要的區別在於沒有nand flash,多了一塊SPI flash(採用STMicro公司的M25P128,)
移植u-boot主要是為了在開發初期調試核心，檔案系統，後期一般他只需要做適當的初始化，再引導核心就可以了，所以移植需要關注的基本就是這些。
為了熟悉程式結構，首先使用hawkboard的預設配置對uboot進行編譯：
make hawkboard_config
make
編譯完成後可以看到在主目錄下產生了uboot.bin檔案，為了方便分析，使用如下命令將其反組譯碼：
arm-linux-objdump -D -m arm u-boot > u-boot.asm
利用u-boot.asm 和 system.map，u-boot.lds這三個檔案，再配合原始碼，我們可以很容易的剖析器流程：
首先看u-boot.lds檔案,它指定了程式連結順序，在最初幾行我們可以看到：init_sequence

OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
OUTPUT_ARCH(arm)
ENTRY(_start)
SECTIONS
{
. = 0x00000000;
. = ALIGN(4);
.text :
{
arch/arm/cpu/arm926ejs/start.o (.text)
*(.text)
}
...
}

可知程式是從arch/arm/cpu/arm926ejs/start.s開始的（這是老生常談了，百度一下，幾乎任何一篇介紹uboot的文章都會介紹這一點），開啟這個檔案我們可以看到程式的54行：

.globl _start
_start:
b reset

首先跳到reset 標號處執行，在第108行：

reset:
/*
* set the cpu to SVC32 mode
*/
mrs r0,cpsr
bic r0,r0,#0x1f
orr r0,r0,#0xd3
msr cpsr,r0

/*
* we do sys-critical inits only at reboot,
* not when booting from ram!
*/
#ifndef CONFIG_SKIP_LOWLEVEL_INIT
bl cpu_init_crit
#endif

這裡是否會執行 bl cpu_init_crit這一句指令呢？需要到設定檔中去找答案，開啟include/configs/hawkboard.h檔案我們可以看到，由於定義了宏CONFIG_SKIP_LOWLEVEL_INIT,這一句被跳過，這是由OMAP-L138 的啟動方式決定的。接下來看第179行:

call_board_init_f:
ldr sp, =(CONFIG_SYS_INIT_SP_ADDR)
bic sp, sp, #7 /* 8-byte alignment for ABI compliance */
ldr r0,=0x00000000
bl board_init_f

首先設定好棧，然後調用了一個c函數（使用r0來傳遞參數），找到這個函數有一個比較麻煩的方法，首先在u-boot.asm中找到board_init_f標號，它在第1100行，對應的地址為c1180e9c,在uboot主目錄下輸入如下命令：
addr2line -e u-boot c1180e9c
顯示該函數是在u-boot-2011.03/arch/arm/lib/board.c:283行（當然在linux下我們還可以使用命令: grep "board_init_f" ./ -R，在u-boot源碼目錄下尋找所有包含"board_init_f"的檔案，只是要找出這個函數在哪個檔案還得再費點功夫）
開啟board.c,這個是所有arm結構的班子共用的板級初始設定檔案，可以看到該函數主要做了如下工作：
1.調用init_sequence數組中包含的所有初始化函數，這些函數包括
env_init, /* initialize environment */
init_baudrate, /* initialze baudrate settings */
serial_init, /* serial communications setup */
console_init_f, /* stage 1 init of console */
display_banner, /* say that we are here */
dram_init,
另外有一些初始化函數由宏定義開關來決定是否執行
2.對gd_t這個結構進行填充（非常重要，定義在arch/arm/include/asm/global_data.h中）。這個結構記錄了系統的記憶體大小，傳輸速率等資訊。
最後調用relocate_code函數進行代碼重定位，這是一個彙編函數，在start.s第195行定義：
elocate_code:
mov r4, r0 /* save addr_sp */
mov r5, r1 /* save addr of gd */
mov r6, r2 /* save addr of destination */

/* Set up the stack */
stack_setup:
mov sp, r4

adr r0, _start
cmp r0, r6
beq clear_bss /* skip relocation */
mov r1, r6 /* r1 <- scratch for copy loop */
ldr r3, _bss_start_ofs
add r2, r0, r3 /* r2 <- source end address */

copy_loop:
ldmia r0!, {r9-r10} /* copy from source address [r0] */
stmia r1!, {r9-r10} /* copy to target address [r1] */
cmp r0, r2 /* until source end address [r2] */
blo copy_loop

函數執行之前先檢查自己是否已經在記憶體中，由於TI的OMAP-L138採用三重啟動，U-boot在啟動時已經被UBL裝載到記憶體中，所以這一步跳過，直接跳轉到clear_bss,清資料區段，然後跳轉到board.c中的board_init_r函數中，開始了第二階段的初始化，最後進入U-boot的主迴圈。

step 2.根據上述流程，對u-boot作如下移植：
將/include/configs/hawkboard.h複製為gcboard.h，開啟gcboard.h,作如下修改：
1）注釋掉#define CONFIG_SYS_USE_NAND,這樣所有跟nand flash 有關的代碼都不會被編譯了。
2）添加如下宏定義：
#define CONFIG_SPI_FLASH 1 //添加SPI Flash 支援
#ifdef CONFIG_SPI_FLASH
#define CONFIG_SPI_FLASH_STMICRO 1 //添加STMicro 的SPI FLASH 驅動
#define CONFIG_SYS_NO_FLASH 1 //務必添加這個宏，否則會引入CFI Flash的驅動編譯
#define CONFIG_DEFAULT_SPI_BUS 1 //定義SPI FLASH所在的匯流排，這裡指定SPI1
#define CONFIG_DAVINCI_SPI 1 //架構相關的SPI驅動
#define CONFIG_SYS_SPI_BASE 0x01f0e000 //指定SPI1 寄存器的基地址
#define CONFIG_SYS_SPI_CLK 50000000 //最大工作頻率50Mhz，由器件手冊得到
#define CONFIG_MAX_SPI_SECT 64 //從這裡開始的三個宏是我自己定義的，為了方便記憶，他們不是必要的
#define CONFIG_MAX_SPI_BANKS 1 //
#define CONFIG_MAX_SPI_CAPACITY 0x1000000 //
#define CONFIG_SPI_SECT_SIZE 0x40000 //M25P128每個sector是256KB

#define CONFIG_ENV_IS_IN_SPI_FLASH 1 //環境變數儲存在SPI FLASH 中
#define CONFIG_ENV_SPI_MODE SPI_MODE_0 //其實不用指定，預設值也可以
#define CONFIG_ENV_SPI_BUS 1 //
#define CONFIG_ENV_SPI_CS 0 //必須是CS0
#define CONFIG_ENV_SPI_MAX_HZ 50000000
#define CONFIG_ENV_SIZE 0x40000
#define CONFIG_ENV_SECT_SIZE 0x40000
#define CONFIG_ENV_OFFSET (CONFIG_MAX_SPI_CAPACITY-CONFIG_SPI_SECT_SIZE) //儲存在最後一塊，以免誤操作把U-boot給擦掉了

#define CONFIG_CMD_SPI 1 //
#define CONFIG_SPIBOOTLDR 1 //
#define CONFIG_CMD_SF 1 //在U-boot中增加SF（SPI FLASH命令），否則不能對SPI FLASH進行操作

3）驅動的修改。在u-boot-2011.03中，davinci 架構的SPI FLASH 驅動中有一個問題就是，在檢測SPI FLASH 時只檢測SPI0的CS0，由此導致的問題是:若你的SPI FLASH掛在SPI1上，而你想要在U-boot 中使用SF probe 檢測SPI FLASH 就會提示"can't setup slave"的問題，因此找到/drivers/spi/davinci_spi.c中的setup_slave函數，將其中的：
if (!spi_cs_is_valid(bus, cs))
return NULL;
這一段注釋掉。實際上spi_cs_is_valid函數只有一句:
return bus == 0 && cs == 0
可見這樣檢測的話我們的SPI FLASH 是不可能被檢測出來的。

4）添加自訂配置gcboard.h。u-boot-2011.03使用新的組建組態檔案方法，為了在執行make gcboard_config時能夠自動讀取我們的設定檔，需要編輯u-boot主目錄下的boards.cfg檔案，在其中搜尋hawkboard,可以看到第84行:
hawkboard arm arm926ejs da8xxevm davinci davinci
hawkboard_nand arm arm926ejs da8xxevm davinci davinci hawkboard:NAND_U_BOOT
hawkboard_uart arm arm926ejs da8xxevm davinci davinci hawkboard:UART_U_BOOT
仿照這種格式我們添加如下行：
gcboard arm arm926ejs da8xxevm davinci davinci
這樣make的時候會自動讀取我們的配置

5）重新編譯u-boot
make clean
make distclean
make gcboard_config
make

這樣就產生了針對gcboard的u-boot,當然，下一步還需要將u-boot.bin使用TI的工具轉換為AIS格式映像，下載到已經裝有UBL的SPI FLASH才能引導板子啟動