本文通過整理之前研發的一個項目(ARM7TDMI +uCLinux)，分析核心啟動過程及需要修改的檔案，以供核心移植者參考。整理過程中也同時參考了衆多網友的文章，在此謝過。由于整理過程匆忙，難免錯誤及講解的不夠清楚之處，請各位網友指正，這裡提前謝過。本文分以下部分進行介紹：
1. Bootloader及核心解壓
2. 核心啟動方式介紹
3. 核心啟動位址的确定
4. arch/armnommu/kernel/head-armv.S分析
5. start_kernel()函數分析
1. Bootloader及核心解壓
Bootloader将核心加載到記憶體中，設定一些寄存器，然後将控制權交由核心，該過程中，關閉MMU功能。通常，核心都是以壓縮的方式存放，如zImage，這裡有兩種解壓方法：
使用核心自解壓程式。
arch/arm/boot/compressed/head.S或arch/arm/boot/compressed/head-xxxxx.S
arch/arm/boot/compressed/misc.c
在Bootloader中增加解壓功能。
使用該方法時核心不需要帶有自解壓功能，而使用Bootloader中的解壓程式代替核心自解壓程式。其工作過程與核心自解壓過程相似：Bootloader把壓縮方式的核心解壓到記憶體中，然後跳轉到核心入口處開始執行。
2. 幾種核心啟動方式介紹
XIP (EXECUTE IN PLACE) 是指直接從存放代碼的位置上啟動運作。
2.1 非壓縮，非XIP
非XIP方式是指在運作之前需對代碼進行重定位。該類型的核心以非壓縮方式存放在Flash中，啟動時由Bootloader加載到記憶體後運作。
2.2 非壓縮，XIP
該類型的核心以非壓縮格式存放在ROM/Flash中，不需要加載到記憶體就能運作，Bootloader直接跳轉到其存放位址執行。Data段複制和BSS段清零的工作由核心自己完成。這種啟動方式常用于記憶體空間有限的系統中，另外，程式在ROM/Flash中運作的速度相對較慢。
2.3 RAM自解壓
壓縮格式的核心由開頭一段自解壓代碼和壓縮核心資料組成，由于以壓縮格式存放，核心隻能以非XIP方式運作。RAM自解壓過程如下：壓縮核心存放于ROM/Flash中，Bootloader啟動後加載到記憶體中的臨時空間，然後跳轉到壓縮核心入口位址執行自解壓代碼，核心被解壓到最終的目的位址然後運作。壓縮核心所占據的臨時空間随後被Linux回收利用。這種方式的核心在嵌入式産品中較為常見。
2.4 ROM自解壓
解壓縮代碼也能夠以XIP的方式在ROM/Flash中運作。ROM自解壓過程如下：壓縮核心存放在ROM/Flash中，不需要加載到記憶體就能運作，Bootloader直接跳轉到其存放位址執行其自解壓代碼，将壓縮核心解壓到最終的目的位址并運作。ROM自解壓方式存放的核心解壓縮速度慢，而且也不能節省記憶體空間。
3. 核心啟動位址的确定
核心自解壓方式
Head.S/head-XXX.S獲得核心解壓後首位址ZREALADDR，然後解壓核心，并把解壓後的核心放在ZREALADDR的位置上，最後跳轉到ZREALADDR位址上，開始真正的核心啟動。
arch/armnommu/boot/Makefile，定義ZRELADDR和ZTEXTADDR。ZTEXTADDR是自解壓代碼的起始位址，如果從記憶體啟動核心，設定為0即可，如果從Rom/Flash啟動，則設定ZTEXTADDR為相應的值。ZRELADDR是核心解壓縮後的執行位址。
arch/armnommu/boot/compressed/vmlinux.ld,引用LOAD_ADDR和TEXT_START。
arch/armnommu/boot/compressed/Makefile, 通過如下一行：
SEDFLAGS = s/TEXT_START/$(ZTEXTADDR)/;s/LOAD_ADDR/$(ZRELADDR)/;
使得TEXT_START = ZTEXTADDR，LOAD_ADDR = ZRELADDR。
說明：
執行完decompress_kernel函數後,代碼跳回head.S/head-XXX.S中,檢查解壓縮之後的kernel起始位址是否緊挨着kernel image。如果是,beqcall_kernel,執行解壓後的kernel。如果解壓縮之後的kernel起始位址不是緊挨着kernelimage,則執行relocate,将其拷貝到緊接着kernel image的地方,然後跳轉,執行解壓後的kernel。
Bootloader解壓方式
Bootloader把解壓後的核心放在記憶體的TEXTADDR位置上，然後跳轉到TEXTADDR位置上，開始核心啟動。
arch/armnommu/Makefile，一般設定TEXTADDR為PAGE_OFF+0x8000，如定義為0x00008000, 0xC0008000等。
arch/armnommu/vmlinux.lds，引用TEXTADDR
4. arch/armnommu/kernel/head-armv.S
該檔案是核心最先執行的一個檔案，包括核心入口ENTRY(stext)到start_kernel間的初始化代碼，主要作用是檢查CPUID，Architecture Type，初始化BSS等操作，并跳到start_kernel函數。在執行前，處理器應滿足以下狀态：
r0 - should be 0
r1 - unique architecture number
MMU - off
I-cache - on or off
D-cache – off
ENTRY(stext)
mov r0, #F_BIT | I_BIT | [email protected] make sure svc mode
msr cpsr_c, r0 @ and all irqs disabled
bl __lookup_processor_type
teq r10, #0 @ invalid processor?
moveq r0, #'p' @ yes, error 'p'
beq __error
bl __lookup_architecture_type
teq r7, #0 @ invalid architecture?
moveq r0, #'a' @ yes, error 'a'
beq __error
bl __create_page_tables
adr lr, __ret @ return address
add pc, r10, #12 @ initialise processor
b start_kernel
__lookup_processor_type這個函數根據晶片的ID從proc.info擷取proc_info_list結構，proc_info_list結構定義在include/asm-armnommu/proginfo.h中，該結構的資料定義在arch/armnommu/mm/proc-arm*.S檔案中，ARM7TDMI系列晶片的proc_info_list資料定義在arch/armnommu/mm/proc-arm6,7.S檔案中。函數__lookup_architecture_type從arch.info擷取machine_desc結構，machine_desc結構定義在include/asm-armnommu/mach/arch.h中，針對不同arch的資料定義在arch/armnommu/mach-*/arch.c檔案中。
在這裡如果知道processor_type和architecture_type,可以直接對相應寄存器進行指派。
5. start_kernel()函數分析
下面對start_kernel()函數及其相關函數進行分析。
5.1 lock_kernel()
extern __inline__ void lock_kernel(void)
{
if (!++current->lock_depth)
spin_lock(&kernel_flag);
}
kernel_flag是一個核心大自旋鎖，所有程序都通過這個大鎖來實作向核心态的遷移。隻有獲得這個大自旋鎖的處理器可以進入核心，如中斷處理程式等。在任何一對lock_kernel／unlock_kernel函數裡至多可以有一個程式占用CPU。程序的lock_depth成員初始化為-1，在kerenl/fork.c檔案中設定。在它小于0時（恒為-1），程序不擁有核心鎖；當大于或等于0時，程序得到核心鎖。
5.2 setup_arch()
setup_arch()函數做體系相關的初始化工作，函數的定義在arch/armnommu/kernel/setup.c檔案中，主要涉及下列主要函數及代碼。
5.2.1 setup_processor()
該函數主要通過
for (list = &__proc_info_begin; list < &__proc_info_end ; list++)
if ((processor_id & list->cpu_mask) == list->cpu_val)
break;
這樣一個循環來在.proc.info段中尋找比對的processor_id，processor_id在head_armv.S檔案
中設定。
5.2.2 setup_architecture(machine_arch_type)
該函數獲得體系結構的資訊，傳回mach-xxx/arch.c 檔案中定義的machine結構體的指針，包含以下内容：
MACHINE_START (xxx, “xxx”)
MAINTAINER ("xxx")
BOOT_MEM (xxx, xxx, xxx)
FIXUP (xxx)
MAPIO (xxx)
INITIRQ (xxx)
MACHINE_END
5.2.3記憶體設定代碼
if (meminfo.nr_banks == 0)
{
meminfo.nr_banks = 1;
meminfo.bank[0].start = PHYS_OFFSET;
meminfo.bank[0].size = MEM_SIZE;
}
meminfo結構表明記憶體情況，是對實體記憶體結構meminfo的預設初始化。nr_banks指定記憶體塊的數量，bank指定每塊記憶體的範圍，PHYS_OFFSET指定某塊記憶體塊的開始位址，MEM_SIZE指定某塊記憶體塊長度。PHYS_OFFSET和MEM_SIZE都定義在include/asm-armnommu/arch-XXX/memory.h檔案中，其中PHYS_OFFSET是記憶體的開始位址，MEM_SIZE就是記憶體的結束位址。這個結構在接下來記憶體的初始化代碼中起重要作用。
5.2.4 核心記憶體空間管理
init_mm.start_code = (unsigned long) &_text; 核心代碼段開始
init_mm.end_code = (unsigned long) &_etext; 核心代碼段結束
init_mm.end_data = (unsigned long) &_edata; 核心資料段開始
init_mm.brk = (unsigned long) &_end; 核心資料段結束
每一個任務都有一個mm_struct結構管理其記憶體空間，init_mm 是核心的mm_struct。其中設定成員變量* mmap指向自己， 意味着核心隻有一個記憶體管理結構，設定 pgd=swapper_pg_dir，
swapper_pg_dir是核心的頁目錄，ARM體系結構的核心頁目錄大小定義為16k。init_mm定義了整個核心的記憶體空間，核心線程屬于核心代碼，同樣使用核心空間，其通路記憶體空間的權限與核心一樣。
5.2.5 記憶體結構初始化
bootmem_init(&meminfo)函數根據meminfo進行記憶體結構初始化。bootmem_init(&meminfo)函數中調用reserve_node_zero(bootmap_pfn, bootmap_pages)函數，這個函數的作用是保留一部分記憶體使之不能被動态配置設定。這些記憶體塊包括：
reserve_bootmem_node(pgdat, __pa(&_stext), &_end - &_stext);
reserve_bootmem_node(pgdat, bootmap_pfn<<PAGE_SHIFT, bootmap_pages<<PAGE_SHIFT)
5.2.6 paging_init(&meminfo, mdesc)
建立核心頁表，映射所有實體記憶體和IO空間，對于不同的處理器，該函數差别比較大。下面簡單描述一下ARM體系結構的存儲系統及MMU相關的概念。
在ARM存儲系統中，使用記憶體管理單元(MMU)實作虛拟位址到實際實體位址的映射。利用MMU，可把SDRAM的位址完全映射到0x0起始的一片連續位址空間，而把原來占據這片空間的FLASH或者ROM映射到其他不相沖突的存儲空間位置。例如，FLASH的位址從0x00000000～0x00FFFFFF，而SDRAM的位址範圍是0x3000 0000～0x3lFFFFFF，則可把SDRAM位址映射為0x00000000～0xlFFFFFF，而FLASH的位址可以映射到0x90000000～0x90FFFFFF(此處位址空間為空閑，未被占用)。映射完成後，如果處理器發生異常，假設依然為IRQ中斷，PC指針指向0xl8處的位址，而這個時候PC實際上是從位于實體位址的0x30000018處讀取指令。通過MMU的映射，則可實作程式完全運作在SDRAM之中。在實際的應用中．可能會把兩片不連續的實體位址空間配置設定給SDRAM。而在作業系統中，習慣于把SDRAM的空間連續起來，友善記憶體管理，且應用程式申請大塊的記憶體時，作業系統核心也可友善地配置設定。通過MMU可實作不連續的實體位址空間映射為連續的虛拟位址空間。作業系統核心或者一些比較關鍵的代碼，一般是不希望被使用者應用程式通路。通過MMU可以控制位址空間的通路權限，進而保護這些代碼不被破壞。
MMU的實作過程，實際上就是一個查表映射的過程。建立頁表是實作MMU功能不可缺少的一步。頁表位于系統的記憶體中，頁表的每一項對應于一個虛拟位址到實體位址的映射。每一項的長度即是一個字的長度(在ARM中，一個字的長度被定義為4Bytes)。頁表項除完成虛拟位址到實體位址的映射功能之外，還定義了通路權限和緩沖特性等。
MMU的映射分為兩種，一級頁表的變換和二級頁表變換。兩者的不同之處就是實作的變換位址空間大小不同。一級頁表變換支援1 M大小的存儲空間的映射，而二級可以支援64 kB，4 kB和1 kB大小位址空間的映射。
動态表(頁表)的大小＝表項數＊每個表項所需的位數，即為整個記憶體空間建立索引表時，需要多大空間存放索引表本身。
表項數＝虛拟位址空間/每頁大小
每個表項所需的位數＝Log(實際頁表數)+适當控制位數
實際頁表數 ＝實體位址空間/每頁大小
下面分析paging_init（）函數的代碼。
在paging_init中配置設定起始頁（即第0頁）位址：
zero_page = 0xCXXXXXXX
memtable_init(mi); 如果目前微處理器帶有MMU，則為系統記憶體建立頁表；如果目前微處理器不支援MMU，比如ARM7TDMI上移植uCLinux作業系統時，則不需要此類步驟。可以通過如下一個宏定義實作靈活控制，對于帶有MMU的微處理器而言，memtable_init(mi)是paging_init()中最重要的函數。
#ifndef CONFIG_UCLINUX
memtable_init(mi);
……（此處省略若幹代碼）
free_area_init_node(node, pgdat, 0, zone_size,
bdata->node_boot_start, zhole_size);
}
#else
{
定義實體記憶體區域管理
unsigned long zone_size[MAX_NR_ZONES] = {0,0,0};
zone_size[ZONE_DMA] = 0;
zone_size[ZONE_NORMAL] = (END_MEM - PAGE_OFFSET) >> PAGE_SHIFT;
free_area_init_node(0, NULL, NULL, zone_size, PAGE_OFFSET, NULL);
}
#endif
uCLinux與其它嵌入式Linux最大的差別就是MMU管理這一塊，從上面代碼就明顯可以看到這點差別。下面繼續讨論針對帶MMU的微處理器的記憶體管理。
void __init memtable_init(struct meminfo *mi)
{
struct map_desc *init_maps, *p, *q;
unsigned long address = 0;
int i;
init_maps = p = alloc_bootmem_low_pages(PAGE_SIZE);
其中map_desc定義為：
struct map_desc {
unsigned long virtual;
unsigned long physical;
unsigned long length;
int //空
};init_maps
下面代碼對meminfo的區段進行周遊，在嵌入式系統中列舉所有可映射的記憶體，例如32M SDRAM, 4M FLASH等，用meminfo記錄這些記憶體區段。同時填寫init_maps 中的各項内容。meminfo結構如下：
struct meminfo {
int nr_banks;
unsigned long end;
struct {
unsigned long start;
unsigned long size;
int node;
} bank[NR_BANKS];
};
for (i = 0; i < mi->nr_banks; i++)
{
if (mi->bank.size == 0)
continue;
p->physical = mi->bank.start;
p->virtual = __phys_to_virt(p->physical);
p->length = mi->bank.size;
p->domain = DOMAIN_KERNEL;
p->prot_read = 0;
p->prot_write = 1;
p->cacheable = 1; //使用Cache
p->bufferable = 1; //使用write buffer
p ++; //下一個區段
}
#ifdef FLUSH_BASE
p->physical = FLUSH_BASE_PHYS;
p->virtual = FLUSH_BASE;
p->length = PGDIR_SIZE;
p->domain = DOMAIN_KERNEL;
p->prot_read = 1;
p->prot_write = 0;
p->cacheable = 1;
p->bufferable = 1;
p ++;
#endif
接下來的代碼是逐個區段建立頁表
q = init_maps;
do {
if (address < q->virtual || q == p) {
由于核心空間是從某個位址開始，如0xC0000000，是以0xC000 0000 以前的頁表項全部清空
clear_mapping在mm-armv.c中定義，其中clear_mapping()是個宏，根據處理器的不同，可以被展開為如下代碼
cpu_XXX_set_pmd(((pmd_t *)(((&init_mm )->pgd+ (( virt) >> 20 )))),((pmd_t){( 0 )}));
其中init_mm為核心的mm_struct，pgd指向 swapper_pg_dir，在arch/arm/kernel/init_task.c中定義。cpu_XXX_set_pmd定義在 proc_armXXX.S檔案中，參見ENTRY(cpu_XXX_set_pmd) 處代碼。
clear_mapping(address);
address += PGDIR_SIZE;
} else {
create_mapping(q);
address = q->virtual + q->length;
address = (address + PGDIR_SIZE - 1) & PGDIR_MASK;
q ++;
}
} while (address != 0);
/ * create_mapping函數也在mm-armv.c中定義 */
static void __init create_mapping(struct map_desc *md)
{
unsigned long virt, length;
int prot_sect, prot_pte;
long off;
大部分應用中均采用1級section模式的位址映射，一個section的大小為1M，也就是說從邏輯位址到實體位址的轉變是這樣的一個過程：
一個32位的位址，高12位決定了該位址在頁表中的index，這個index的内容決定了該邏輯section對應的實體section；低20位決定了該位址在section中的偏移（index）。例如：從0x0～0xFFFFFFFF的位址空間總共可以分成0x1000（4K）個 section（每個section大小為1M），頁表中每項的大小為32個bit，是以頁表的大小為0x4000（16K）。
每個頁表項的内容如下:
bit: 31 20 19 12 11 10 9 8 5 4 3 2 1 0
content: Section對應的實體位址 NULL AP 0 Domain 1 C B 1 0
最低兩位（10）是section分頁的辨別。
AP：Access Permission，區分隻讀、讀寫、SVC＆其它模式。
Domain：每個section都屬于某個Domain，每個Domain的屬性由寄存器控制。一般都隻要包含兩個Domain，一個可通路位址空間； 另一個不可通路位址空間。
C、B：這兩位決定了該section的cache＆write buffer屬性，這與該段的用途(RO or RW)有密切關系。不同的用途要做不同的設定。
C B 具體含義
0 0 無cache，無寫緩沖，任何對memory的讀寫都反映到總線上。對 memory 的操作過程中CPU需要等待。
0 1 無cache，有寫緩沖，讀操作直接反映到總線上。寫操作CPU将資料寫入到寫緩沖後繼續運作，由寫緩沖進行寫回操作。
1 0 有cache，寫通模式，讀操作首先考慮cache hit；寫操作時直接将資料寫入寫緩沖，如果同時出現cache hit，那麼也更新cache。
1 1 有cache，寫回模式，讀操作首先考慮cache hit；寫操作也首先考慮cache hit。
由于ARM中section表項的權限位和page表項的位置不同， 以下代碼根據struct map_desc 中的保護标志，分别計算頁表項中的AP, Domain和CB标志位。
prot_pte = L_PTE_PRESENT | L_PTE_YOUNG | L_PTE_DIRTY |
(md->prot_readprot_writecacheablebufferable
prot_sect = PMD_TYPE_SECT | PMD_DOMAIN(md->domain) |
(md->prot_readprot_writecacheablebufferable
設定虛拟位址，偏移位址和記憶體length
virt = md->virtual;
off = md->physical - virt;
length = md->length;
---------------------------------------------------------------------------------------------------
建立虛拟位址到實體位址的映射
while ((virt & 0xfffff || (virt + off) & 0xfffff) && length >= PAGE_SIZE) {
alloc_init_page(virt, virt + off, md->domain, prot_pte);
virt += PAGE_SIZE;
length -= PAGE_SIZE;
}
while (length >= PGDIR_SIZE) {
alloc_init_section(virt, virt + off, prot_sect);
virt += PGDIR_SIZE;
length -= PGDIR_SIZE;
}
while (length >= PAGE_SIZE) {
alloc_init_page(virt, virt + off, md->domain, prot_pte);
virt += PAGE_SIZE;
length -= PAGE_SIZE;
}
create_mapping的作用是設定虛位址virt 到實體位址virt + off_set的映射頁目錄和頁表。
init_maps->physical = virt_to_phys(init_maps);
init_maps->virtual = vectors_base();
init_maps->length = PAGE_SIZE;
init_maps->domain = DOMAIN_USER;
init_maps->prot_read = 0;
init_maps->prot_write = 0;
init_maps->cacheable = 1;
init_maps->bufferable = 0;
create_mapping(init_maps);
中斷向量表的虛位址init_maps，是用alloc_bootmem_low_pages配置設定的，通常是在PAGE_OFF+0x8000前面的某一頁，vectors_base()是個宏，ARM規定中斷向量表的位址隻能是0或0xFFFF0000，是以上述代碼映射一頁到0或0xFFFF0000，中斷處理程式中的部分代碼也被拷貝到這一頁中。
5.3 parse_options()
分析由核心引導程式發送給核心的啟動選項，在初始化過程中按照某些選項運作，并将剩餘部分傳送給init程序。這些選項可能已經存儲在配置檔案中，也可能是由使用者在系統啟動時敲入的。但核心并不關心這些，這些細節都是核心引導程式關注的内容，嵌入式系統更是如此。
5.4 trap_init()
這個函數用來做體系相關的中斷處理的初始化，在該函數中調用__trap_init((void*)vectors_base())函數将exceptionvector設定到vectors_base開始的位址上。__trap_init函數位于entry-armv.S檔案中，對于ARM處理器，共有複位、未定義指令、SWI、預取終止、資料終止、IRQ和FIQ幾種方式。SWI主要用來實作系統調用，而産生了IRQ之後，通過exceptionvector進入中斷處理過程，執行do_IRQ函數。
armnommu的trap_init（）函數在arch/armnommu/kernel/traps.c檔案中。vectors_base是寫中斷向量的開始位址，在include/asm-armnommu/proc-armv/system.h檔案中設定，位址為0或0XFFFF0000。
ENTRY(__trap_init)
stmfd sp!, {r4 - r6, lr}
mrs r1, cpsr @ code from 2.0.38
bic r1, r1, #MODE_MASK @ clear mode bits
orr r1, r1, #I_BIT|F_BIT|MODE_SVC @ set SVC mode, disable IRQ,FIQ
msr cpsr, r1
adr r1, .LCvectors @ set up the vectors
ldmia r1, {r1, r2, r3, r4, r5, r6, ip, lr}
stmia r0, {r1, r2, r3, r4, r5, r6, ip, lr}
add r2, r0, #0x200
adr r0, __stubs_start @ copy stubs to 0x200
adr r1, __stubs_end
1: ldr r3, [r0], #4
str r3, [r2], #4
cmp r0, r1
blt 1b
LOADREGS(fd, sp!, {r4 - r6, pc})
__stubs_start到__stubs_end的位址中包含了異常處理的代碼，是以拷貝到vectors_base+0x200的位置上。
5.5 init_IRQ()
void __init init_IRQ(void)
{
extern void init_dma(void);
int irq;
for (irq = 0; irq < NR_IRQS; irq++) {
irq_desc[irq].probe_ok = 0;
irq_desc[irq].valid = 0;
irq_desc[irq].noautoenable = 0;
irq_desc[irq].mask_ack = dummy_mask_unmask_irq;
irq_desc[irq].mask = dummy_mask_unmask_irq;
irq_desc[irq].unmask = dummy_mask_unmask_irq;
}
CSR_WRITE(AIC_MDCR, 0x7FFFE);
CSR_WRITE(CAHCNF,0x0);
CSR_WRITE(CAHCON,0x87);
while(CSR_READ(CAHCON)!=0);
CSR_WRITE(CAHCNF,0x7);
init_arch_irq();
init_dma();
}
這個函數用來做體系相關的irq處理的初始化，irq_desc數組是用來描述IRQ的請求隊列，每一個中斷号配置設定一個irq_desc結構，組成了一個數組。NR_IRQS代表中斷數目，這裡隻是對中斷結構irq_desc進行了初始化。在預設的初始化完成後調用初始化函數init_arch_irq，先執行arch/armnommu/kernel/irq-arch.c檔案中的函數genarch_init_irq()，然後就執行include/asm-armnommu/arch-xxxx/irq.h中的inline函數irq_init_irq，在這裡對irq_desc進行了實質的初始化。其中mask用阻塞中斷；unmask用來取消阻塞；mask_ack的作用是阻塞中斷，同時還回應ack給硬體表示這個中斷已經被處理了，否則硬體将再次發生同一個中斷。這裡，不是所有硬體需要這個ack回應，是以很多時候mask_ack與mask用的是同一個函數。
接下來執行init_dma（）函數，如果不支援DMA，可以設定include/asm-armnommu/arch-xxxx/dma.h中的MAX_DMA_CHANNELS為0，這樣在arch/armnommu/kernel/dma.c檔案中會根據這個定義使用不同的函數。
5.6 sched_init()
初始化系統排程程序，主要對定時器機制和時鐘中斷的BottomHalf的初始化函數進行設定。與時間相關的初始化過程主要有兩步：（1）調用init_timervecs()函數初始化核心定時器機制；（2）調用init_bh()函數将BH向量TIMER_BH、TQUEUE_BH和IMMEDIATE_BH所對應的BH函數分别設定成timer_bh()、tqueue_bh()和immediate_bh()函數
5.7 softirq_init()
核心的軟中斷機制初始化函數。調用tasklet_init初始化tasklet_struct結構，軟中斷的個數為32個。用于bh的tasklet_struct結構調用tasklet_init()以後，它們的函數指針func全都指向bh_action()。bh_action就是tasklet實作bh機制的代碼，但此時具體的bh函數還沒有指定。
HI_SOFTIRQ用于實作bottom half，TASKLET_SOFTIRQ用于公共的tasklet。
open_softirq(TASKLET_SOFTIRQ, tasklet_action, NULL);
open_softirq(HI_SOFTIRQ, tasklet_hi_action, NULL);
這裡順便講一下軟中斷的執行函數do_softirq()。
軟中斷服務不允許在一個硬中斷服務程式内部執行，也不允許在一個軟中斷服務程式内部執行，是以通過in_interrupt()加以檢查。h->action 就是串行化執行軟中斷，當bh 的tasklet_struct鍊入的時候，就能在這裡執行，在bh裡重新鎖定了所有CPU，導緻一個時間隻有一個CPU可以執行bh函數，但是do_softirq()是可以在多CPU上同時執行的。而每個tasklet_struct在一個時間上是不會出現在兩個CPU上的。另外，隻有當Linux初始化完成開啟中斷後，中斷系統才可以開始工作。
5.8 time_init()
這個函數用來做體系相關的timer的初始化，armnommu的在arch/armnommu/kernel/time.c。這裡調用了在include/asm-armnommu/arch-xxxx/time.h中的inline函數setup_timer，setup_timer（）函數的設計與硬體設計緊密相關，主要是根據硬體設計情況設定時鐘中斷号和時鐘頻率等。
void __inline__ setup_timer (void)
{
CSR_WRITE(TCR0, xxx);
CSR_WRITE (AIC_SCR7, xxx);
CSR_WRITE(TICR0, xxx);
timer_irq.handler = xxxxxx_timer_interrupt;
setup_arm_irq(IRQ_TIMER, &timer_irq);
INT_ENABLE(IRQ_TIMER);
CSR_WRITE(TISR, xxx);
CSR_WRITE(TCR0, xxx);
}
5.9 console_init()
控制台初始化。控制台也是一種驅動程式，由于其特殊性，提前到該處完成初始化，主要是為了提前看到輸出資訊，據此判斷核心運作情況。很多嵌入式Linux作業系統由于沒有在/dev目錄下正确配置console裝置，造成啟動時發生諸如unable to open an initialconsole的錯誤。
init_modules()函數到smp_init()函數之間的代碼一般不需要作修改，
如果平台具有特殊性，也隻需對相關函數進行必要修改。
這裡簡單注明了一下各個函數的功能，以便了解。
5.10 init_modules()
子產品初始化。如果編譯核心時使能該選項，則核心支援子產品化加載/解除安裝功能
5.11 kmem_cache_init()
核心Cache初始化。
5.12 sti()
使能中斷，這裡開始，中斷系統開始正常工作
---------------------------------------------------------------------------------------------------
5.13 calibrate_delay()
近似計算BogoMIPS數字的核心函數。作為第一次估算，calibrate_delay計算出在每一秒内執行多少次__delay循環，也就是每個定時器滴答（timer tick）―百分之一秒内延時循環可以執行多少次。這種計算隻是一種估算，結果并不能精确到納秒，但這個數字供核心使用已經足夠精确了。
BogoMIPS的數字由核心計算并在系統初始化的時候列印。它近似的給出了每秒鐘CPU可以執行一個短延遲循環的次數。在核心中，這個結果主要用于需要等待非常短周期的裝置驅動程式――例如，等待幾微秒并檢視裝置的某些資訊是否已經可用。
計算一個定時器滴答内可以執行多少次循環需要在滴答開始時就開始計數，或者應該盡可能與它接近。全局變量jiffies中存儲了從核心開始保持跟蹤時間開始到現在已經經過的定時器滴答數， jiffies保持異步更新，在一個中斷内——每秒一百次，核心暫時挂起正在處理的内容，更新變量，然後繼續剛才的工作。
5.14 mem_init()
記憶體初始化。本函數通過記憶體碎片的重組等方法标記目前剩餘記憶體, 設定記憶體上下界和頁表項初始值。
5.15 kmem_cache_sizes_init()
核心記憶體管理器的初始化，也就是初始化cache和SLAB配置設定機制。
5.16 pgtable_cache_init()
頁表cache初始化。
5.17 fork_init()
這裡根據硬體的記憶體情況，如果計算出的max_threads數量太大，可以自行定義。
5.18 proc_caches_init();
為proc檔案系統建立高速緩沖
5.19 vfs_caches_init(num_physpages);
為VFS建立SLAB高速緩沖
5.20 buffer_init(num_physpages);
初始化buffer
5.21 page_cache_init(num_physpages);
頁緩沖初始化
5.22 signals_init();
建立信号隊列高速緩沖
5.23 proc_root_init();
在記憶體中建立包括根結點在内的所有節點
5.24 check_bugs();
檢查與處理器相關的bug
5.25 smp_init();
5.26 rest_init(); 此函數調用kernel_thread(init, NULL, CLONE_FS | CLONE_FILES | CLONE_SIGNAL)函數。
5.26.1 kernel_thread()函數分析
這裡調用了arch/armnommu/kernel/process.c中的函數kernel_thread，kernel_thread函數中通過 __syscall(clone) 建立新線程。__syscall(clone)函數參見armnommu/kernel目錄下的entry-common.S檔案。
5.26.2 init()完成下列功能：
Init()函數通過kernel_thread(init, NULL, CLONE_FS | CLONE_FILES | CLONE_SIGNAL)的回調函數執行，完成下列功能。
do_basic_setup()
在該函數裡，sock_init()函數進行網絡相關的初始化，占用相當多的記憶體，如果所開發系統不支援網絡功能，可以把該函數的執行注釋掉。
do_initcalls()實作驅動的初始化, 這裡需要與vmlinux.lds聯系起來看才能明白其中奧妙。
static void __init do_initcalls(void)
{
initcall_t *call;
call = &__initcall_start;
do {
(*call)();
call++;
} while (call < &__initcall_end);
flush_scheduled_tasks();
}
檢視 /arch/i386/vmlinux.lds，其中有一段代碼
__initcall_start = .;
.initcall.init : { *(.initcall.init) }
__initcall_end = .;
其含義是__initcall_start指向代碼節.initcall.init的節首，而__initcall_end指向.initcall.init的節尾。
do_initcalls所作的是系統中有關驅動部分的初始化工作，那麼這些函數指針資料是怎樣放到了.initcall.init節呢？在include/linux/init.h檔案中有如下3個定義：
1. #define __init_call __attribute__ ((unused,__section__ (".initcall.init")))
__attribute__的含義就是建構一個在.initcall.init節的指向初始函數的指針。
2. #define __initcall(fn) static initcall_t __initcall_##fn __init_call = fn
##意思就是在可變參數使用宏定義的時候建構一個變量名稱為所指向的函數的名稱，并且在前面加上__initcall_
3. #define module_init(x) __initcall(x);
很多驅動中都有類似module_init(usb_init)的代碼，通過該宏定義逐層解釋存放到.initcall.int節中。
blkmem相關的修改(do_initcalls()初始化驅動時執行此代碼)
在blkmem_init()函數中，調用了blk_init_queue()函數，blk_init_queue()函數調用了 blk_init_free_list()函數，blk_init_free_list()函數又調用了blk_grow_request_list() 函數，在這個函數中會kmem_cache_alloc出nr_requests個request結構體。
這裡如果nr_requests的值太大，則将占用過多的記憶體，将造成硬體記憶體不夠，是以可以根據實際情況将其替換成了較小的值，比如32、16等。
free_initmem
這個函數在arch/armnommu/mm/init.c檔案中，其作用就是對init節的釋放，也可以通過修改代碼指定為不釋放。
5.26.3 init執行過程
在核心引導結束并啟動init之後，系統就轉入使用者态的運作，在這之後建立的一切程序，都是在使用者态進行。這裡先要清楚一個概念：就是init程序雖然是從核心開始的，即在前面所講的init/main.c中的init()函數在啟動後就已經是一個核心線程，但在轉到執行init程式（如 /sbin/init）之後，核心中的init()就變成了/sbin/init程式，狀态也轉變成了使用者态，也就是說核心線程變成了一個普通的程序。這樣一來，核心中的init函數實際上隻是使用者态init程序的入口，它在執行execve("/sbin/init",argv_init, envp_init)時改變成為一個普通的使用者程序。這也就是exec函數的乾坤大挪移法，在exec函數調用其他程式時，目前程序被其他程序“靈魂附體”。
除此之外，它們的代碼來源也有差别，核心中的init()函數的源代碼在/init/main.c中，是核心的一部分。而/sbin/init程式的源代碼是應用程式。
init程式啟動之後，要完成以下任務：檢查檔案系統，啟動各種背景服務程序，最後為每個終端和虛拟控制台啟動一個getty程序供使用者登入。由于所有其它使用者程序都是由init派生的，是以它又是其它一切使用者程序的父程序。
init程序啟動後，按照/etc/inittab的内容程序系統設定。很多嵌入式系統用的是BusyBox的init，它與一般所使用的init不一樣，會先執行/etc/init.d/rcS而非/etc/rc.d/rc.sysinit。
小結：
本想多整理一些相關資料，無奈又要開始新項目的奔波，start_kernel()函數也剛好差不多講完了，分析的不是很深入，希望對嵌入式Linux移植的網友們有一些幫助。最後列舉下面幾處未整理的知識點，有興趣的網友可作進一步探讨。
text.init和data.init說明
__init标示符在gcc編譯器中指定将該函數置于核心的特定區域。在核心完成自身初始化之後，就試圖釋放這個特定區域。實際上，核心中存在兩個這樣的區域，.text.init和.data.init――第一個是代碼初始化使用的，另外一個是資料初始化使用的。另外也可以看到 __initfunc和__initdata标志，前者和__init類似，标志初始化專用代碼，後者則标志初始化專用資料。
![2014年軟體業經濟運作情況[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)