接著上一章節的內容，繼續往下分析start_armboot函式；
1.for迴圈執行init_sequence
**如下：
for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr)
}
（1）init_fnc_ptr二重指標指向了init_sequence，init_sequence是乙個函式指標陣列，陣列中儲存了很多個函式指標，這些指向指向的函式都是init_fnc_t型別（特徵是接收引數是void型別，返回值是int）。
init_sequence在定義時就同時給了初始化，初始化的函式指標都是一些函式名。（函式名的實質就是函式指標）
**如下：
typedef int (init_fnc_t) (void);
init_fnc_t *init_sequence = ;
遍歷指標陣列一般有兩種方法，一種是根據陣列下標來進行遍歷，第二種是在陣列的有效元素末尾放乙個標誌，依次遍歷到標準處即可截至。**中的for迴圈遍歷方式採用的是第二種方式，這張遍歷方式的好處是不用知道陣列元素的個數，可以在陣列中進行增減元素。
（3）init_fnc_t的這些函式的返回值定義方式一樣的，都是：函式執行正確時返回0，不正確時返回-1.所以我們在遍歷時去檢查函式返回值，如果遍歷中有乙個函式返回值不等於0則hang()掛起。從分析hang函式可知：uboot啟動過程中初始化板級硬體時不能出任何錯誤，只要有乙個錯誤整個啟動就終止，除了重啟開發板沒有任何辦法。hang()**如下：
void hang (void)
2.cpu_init
這個是cpu內部的初始化，在u-boot的第一階段已經完成了，所以這裡的函式體為空的；
3.board_init
int board_init(void)
這個函式中主要是網絡卡的gpio和埠的配置，而不是驅動。因為網絡卡的驅動都是現成的正確的，移植的時候驅動是不需要改動的，關鍵是這裡的基本初始化，因為這些基本初始化是硬體相關的。
（2）gd->bd->bi_arch_number = mach_type;（3）gd->bd->bi_boot_params = (phys_sdram_1+0x100);
這句**是linux核心啟動時的傳參的記憶體位址賦值給bi_boot_params。
(1)bd_info中另乙個主要元素，bi_boot_params表示uboot給linux kernel啟動時的傳參的記憶體位址。也就是說uboot給linux核心傳參的時候是這麼傳的：uboot事先將準備好的傳參（字串，就是bootargs）放在記憶體的乙個位址處（就是bi_boot_params），然後uboot就啟動了核心（uboot在啟動核心時真正是通過暫存器r0 r1 r2來直接傳遞引數的，其中有乙個暫存器中就是bi_boot_params）。核心啟動後從暫存器中讀取bi_boot_params就知道了uboot給我傳遞的引數到底在記憶體的**。然後自己去記憶體的那個地方去找bootargs。
(2)phys_sdram_1是第乙個記憶體片的起始位址，大小為0x30000000。所以經過計算，x210中bi_boot_params的值為0x30000100
u boot第二階段分析（一）
一 start armboot函式簡介 start armboot函式是乙個長函式，在uboot lib arm board.c的第444 908行，其中也呼叫了其他函式，共同構成了u boot的第二階段。1.第二階段的主要工作 我們之前已經分析過了第一階段，主要是初始化了soc內部的一些部件和初始...
u boot第二階段原始碼分析
typedef int init fnc t void init fnc t init sequence void start armboot void 理解 1 init fnc t宣告為函式型別，這個函式型別的引數為空，函式返回值為int整型。2 init fnc t init sequence...
uboot第二階段啟動流程
include typedef unsigned long ulong typedef struct environment s env t typedef struct bd info bi dram 1 bd t int main int argc,const char argv include...