inux 內(nèi)存管理系統(tǒng)：初始化
作者：Joe Knapka
臭翻：colyli
內(nèi)存管理系統(tǒng)的初始化處理流程分為三個(gè)基本階段：
激活頁內(nèi)存管理
在swapper_pg_dir中初始化內(nèi)核的頁表
初始化一系列和內(nèi)存管理相關(guān)的內(nèi)核數(shù)據(jù)
Turning On Paging (i386)
啟動(dòng)分頁機(jī)制(i386)
Kernel 代碼被加載到物理地址0x100000(1MB)，在分頁機(jī)制打開后被重新映射到
PAGE_OFFSET + 0x100000的位置（PAGE_OFFSET在IA32上為3GB，即進(jìn)程虛擬地址中用戶
空間與內(nèi)核空間的分界處）。這是通過將物理地址映射到編譯進(jìn)來的頁表 (在
arch/i386/kernel/head.S中)的0－8MB以及PAGE_OFFSET－PAGE_OFFSET+8MB實(shí)現(xiàn)的。然后
我們跳轉(zhuǎn)到init/main.c中的start_kernel，這個(gè)函數(shù)被定位到PAGE_OFFSET+某一個(gè)地址。
這看起來有些狡猾。要注意到在head.S中啟動(dòng)分頁機(jī)制的代碼是通過讓它自己所執(zhí)行的地
址空間不再有效的方式來實(shí)現(xiàn)這一點(diǎn)的；因此0－4MB被映射（不明白：hence the 0-4MB
identity mapping.）。在分頁機(jī)制沒有啟動(dòng)之前，start_kernel是不會(huì)被調(diào)用的，我們假
定他運(yùn)行在PAGE_OFFSET+某一個(gè)地方的位置。因此head.S中的頁表必須同樣映射內(nèi)核代碼
所使用的地址，這樣后繼才能跳轉(zhuǎn)到staert_kernel處；因此PAGE_OFFSET被映射（不明
白：hence the PAGE_OFFSET mapping.）。
下面在head.S中分頁機(jī)制啟動(dòng)時(shí)的一些神奇的代碼：
/*
* Enable paging
*/
3:
movl $swapper_pg_dir-__PAGE_OFFSET,%eax
movl %eax,%cr3 /* set the page table pointer.. */
movl %cr0,%eax
orl $0x80000000,%eax
movl %eax,%cr0 /* ..and set paging (PG) bit */
jmp 1f /* flush the prefetch-queue */
1:
movl $1f,%eax
jmp *%eax /* make sure eip is relocated */
1:
在兩個(gè)1的label之間的代碼將第二個(gè)label 1的地址加載到EAX中，然后跳轉(zhuǎn)到那里。這
時(shí)，指令指針寄存器EIP指向1MB＋某個(gè)數(shù)值的物理地址。而label都在內(nèi)核的虛擬地址空
間(PAGE_OFFSET+某個(gè)位置)，所以這段代碼將EIP有效的從物理地址空間重新定位到了虛
擬地址空間。
Start_kernel函數(shù)初始化了所有的內(nèi)核數(shù)據(jù)，然后啟動(dòng)了init內(nèi)核線程。Start_kernel中
最初的幾件事情之一就是調(diào)用setup_arch函數(shù)，這是一個(gè)和具體的體系結(jié)構(gòu)相關(guān)的設(shè)置函
數(shù)， 調(diào)用了更底層的初始化細(xì)節(jié)。對(duì)于x86 平臺(tái)而言， 這些函數(shù)在
arch/i386/kernel/setup.c中。
在setup_arch 中和內(nèi)存相關(guān)的第一件事就是計(jì)算低端內(nèi)存(low-memory) 和高端內(nèi)存
(high-memory)的有效頁的數(shù)目；每種內(nèi)存類型(each memory type)最高端的頁的數(shù)目分別
保存在全局變量highstart_pfn和highend_pfn中。高端內(nèi)存并不是直接映射到內(nèi)核的虛擬
內(nèi)存(VM)中；這是后面要討論的。
接下來，setup_arch 調(diào)用init_bootmem 函數(shù)以初始化啟動(dòng)時(shí)的內(nèi)存分配器(boot-time
memory allocator)。Bootmem內(nèi)存分配器僅僅在系統(tǒng)boot的過程中使用，為永久的內(nèi)核數(shù)
據(jù)分配頁。因此我們不會(huì)對(duì)它涉及太多。需要記住的就是bootmem 分配器(bootmem
allocator)在內(nèi)核初始化時(shí)提供頁，這些頁為內(nèi)核專門預(yù)留，就好像他們是從內(nèi)核景象文
件中載入的一樣，他們?cè)谙到y(tǒng)啟動(dòng)以后不參與任何的內(nèi)存管理活動(dòng)。
初始化內(nèi)核頁表
之后，setup_arch調(diào)用在arch/i386/mm/init.c中的paging_init函數(shù)。這個(gè)函數(shù)做了一些
事情。首先它調(diào)用pagetable_init函數(shù)去映射整個(gè)的物理內(nèi)存，或者在PAGE_OFFSET到4GB
之間的盡可能多的物理內(nèi)存，這是從PAGE_OFFSET處開始。
在pagetable_init函數(shù)中，我們?cè)趕wapper_pg_dir中精確的建立了內(nèi)核的頁表，映射到
截至PAGE_OFFSET的整個(gè)物理內(nèi)存。
這是一個(gè)將正確的數(shù)值填充到頁目錄和頁表中去的簡(jiǎn)單的算術(shù)活。映射建立在
swapper_pg_dir中，即kernel頁目錄；這也是初始化頁機(jī)制時(shí)所使用的頁目錄。（當(dāng)使用
4MB的頁表的時(shí)候，直到下一個(gè)4MB邊界的虛擬地址才會(huì)被映射在這里，但這沒有什么，
因?yàn)槲覀儾粫?huì)使用這個(gè)內(nèi)存所以沒有什么問題）。如果有這里有剩下物理內(nèi)存沒有被映射，
那就是大于4GB－PAGE_OFFSET范圍的內(nèi)存，這些內(nèi)存只有CONFIG_HIGHMEM選項(xiàng)被設(shè)置后
才能使用（即使用大于4GB的內(nèi)存）。
在接近pagetable_init函數(shù)的尾部，我們調(diào)用了fixrange_init為編譯時(shí)固定的虛擬內(nèi)存
映射預(yù)留頁表。這些表將硬編碼到Kernel中的虛擬地址進(jìn)行映射，但是他們并不是已經(jīng)加
載的內(nèi)核數(shù)據(jù)的一部分。Fixmap表在運(yùn)行時(shí)調(diào)用set_fixmap函數(shù)被映射到物理內(nèi)存。
在初始化了fixmap之后，如果CONFIG_HIGHMEM被設(shè)置了，我們還要分配一些頁表給kmap
分配器。Kmap允許kernel將物理地址的任何頁映射到kernel的虛擬地址空間，以臨時(shí)使用。
這很有用，例如對(duì)在pagetable_init中不能直接映射的物理內(nèi)存進(jìn)行映射。
Fixmap 和kmap 頁表們占據(jù)了kernel 虛擬空間頂部的一部分——因此這些地址不能在
PAGE_OFFSET映射中被永久的映射到物理頁上。由于這個(gè)原因，Kernel虛擬內(nèi)存的頂部的
128MB就被預(yù)留了（vmalloc分配器仍然是用這個(gè)范圍內(nèi)的地址）。（下面這句實(shí)在是不知
道怎么翻譯） Any physical pages that would otherwise be mapped into the
PAGE_OFFSET mapping in the 4GB-128MB range are instead (if CONFIG_HIGHMEM is
specified) included in the high memory zone, accessible to the kernel only via
kmap()。如果沒有設(shè)置CONFIG_HIGMEM，這些頁就完全是不可用的。這僅針對(duì)配置有大量?jī)?nèi)
存的機(jī)器（900多MB或者更多）。例如，如果PAGE_OFFSET=3GB，并且機(jī)器有2GB的RAM，
那么只有開始的1GB-128MB的物理內(nèi)存可以被映射到PAGE_OFFSET和fixmap/kmap地址范
圍之間。剩余的頁是不可用的——實(shí)際上對(duì)于用戶進(jìn)程映射來說，他們是可以直接映射的頁
——但是內(nèi)核不能夠直接訪問它們。
回到paging_init，我們可以通過調(diào)用kmap_init函數(shù)來初始化kmap系統(tǒng)，kmap_init簡(jiǎn)
單的緩存了最先的kmap_pagetable[在TLB？]。然后，我們通過計(jì)算zone的大小并調(diào)用
free_area_init 去建立mem_map 和初始化freelist，初始化了zone 分配器。所有的
freelist被初始化為空，并且所有的頁都被標(biāo)志為reserved（不可被VM系統(tǒng)訪問）；這
種情況之后會(huì)被糾正。
當(dāng)paging_init完成后，物理內(nèi)存的分布如下[注意在2.4的內(nèi)核中這不全對(duì)]：
0x00000000: 0-page
0x00100000: kernel-text
0x????????: kernel_data
0x???????? =_end: whole-mem pagetables
0x????????: fixmap pagetables
0x????????: zone data (mem_map, zone_structs, freelists &c)
0x???????? =start_mem: free pages
這塊內(nèi)存被swapper_pg_dir和whole-mem-pagetables映射以尋址PAGE_OFFSET。
進(jìn)一步的VM子系統(tǒng)初始化
現(xiàn)在我們回到start_kernel。在paging_init完成后，我們?yōu)閮?nèi)核的其他子系統(tǒng)進(jìn)行一些
額外的配置工作，它們中的一些使用bootmem分配器分配額外的內(nèi)核內(nèi)存。從內(nèi)存管理的觀
點(diǎn)來看，這其中最重要的是kmem_cache_init，他初始化了slab分配器的數(shù)據(jù)。
在kmem_cache_init 調(diào)用之后不久，我們調(diào)用了mem_init。這個(gè)通過清除空閑物理頁的
zone數(shù)據(jù)中的PG_RESERVED位在free_area_init的開始完成了初始化freelist的工作；
為不能被用為DMA的頁清除PG_DMA位；然后釋放所有可用的頁到他們各自的zone中。最后
一步，在bootmem.c 中的free_all_bootmem函數(shù)中完成，很有趣。他建立了伙伴位圖和
freelist描述了所有存在的沒有預(yù)留的頁，這是通過簡(jiǎn)單的釋放他們并讓free_page_ok
做正確的事情。一旦mem_init被調(diào)用了，bootmem分配器就不再使用了，所以它的所有的
頁也會(huì)被釋放到zone分配器的世界中。
段
段用來將線性地址空間劃分為專用的塊。線性空間是被VM子系統(tǒng)管理的。X86體系結(jié)構(gòu)從硬
件上支持段機(jī)制；你可以按照段+段內(nèi)偏移量的方式指定一個(gè)地址，這里地址被描述為一定
范圍的線性（虛擬地址）并帶有特定的屬性（如保護(hù)屬性）。實(shí)際上，在x86體系結(jié)構(gòu)中你
必須使用段機(jī)制。所以我們要設(shè)置4個(gè)段：
一個(gè)kernel text段：從0 到4GB
一個(gè)kernel data段：從0 到4GB
一個(gè)user text段：從0 到4GB
一個(gè)user data段：從0 到4GB
因此我們可以使用任何一個(gè)有效的段選擇器(segment selector)訪問整個(gè)虛擬地址空間。
問題：
段是在哪里被設(shè)置的？
答案：
全局描述符表（GDT）定義在head.s的450行。 GDT寄存器在250行被加載。
問題：
為什么將內(nèi)核段和用戶端分離開。是否他們都有權(quán)限訪問整個(gè)4GB的范圍？
答案：
這是因?yàn)閮?nèi)核和用戶段的保護(hù)機(jī)制有區(qū)別：
.quad 0x00cf9a000000ffff /* 0x10 kernel 4GB code at 0x00000000 */
.quad 0x00cf92000000ffff /* 0x18 kernel 4GB data at 0x00000000 */
.quad 0x00cffa000000ffff /* 0x23 user 4GB code at 0x00000000 */
.quad 0x00cff2000000ffff /* 0x2B user 4GB data at 0x00000000 */
段寄存器(CS，DS等)包含有一個(gè)13位的描述符表的索引，索引指向的描述符告訴CPU所選
擇的段的屬性。段選擇器的低3位沒有被用來索引描述符表，而是用來保存描述符類型（全
局或局部）以及需要的特權(quán)級(jí)。因此內(nèi)核段選擇器0x10和0x18使用特權(quán)級(jí)0（RPL0），用
戶選擇器0x23和0x2B使用最特權(quán)級(jí)RPL 3。
要注意到第三個(gè)高序字節(jié)的高位組對(duì)應(yīng)內(nèi)核和用戶也是不同的：對(duì)內(nèi)核，描述符特權(quán)級(jí)
（DPL）為0；對(duì)用戶DPL為3。如果你閱讀了Intel的文檔，你將看到確切的含義，但是由
于Linux內(nèi)核的x86段保護(hù)沒有涉及太多，所以我就不再討論太多了。
下面的命令是我自己增加的命令，不使用uImage，直接引導(dǎo)zImage文件。
具體方法是使用tftp命令從網(wǎng)絡(luò)下載zImage文件到內(nèi)存中或者直接讀取flash數(shù)據(jù)，拷貝到內(nèi)存中，假設(shè)拷貝到了A地址處，接下來就可以調(diào)用：
# bootzimage A
來引導(dǎo)linux內(nèi)核了，具體分析見下面說明。
Uboot在設(shè)置啟動(dòng)命令的時(shí)候使用的是Tag方式，也就是內(nèi)核現(xiàn)在期望使用的參數(shù)傳遞方式。還有一種引導(dǎo)設(shè)置方式，就是采用2.2以及以前版本使用的參數(shù)設(shè)置方式，2.4和2.6內(nèi)核為了兼容之前版本參數(shù)設(shè)置，對(duì)老版本參數(shù)數(shù)據(jù)進(jìn)行了解析，轉(zhuǎn)換成了內(nèi)部tag方式。這樣我們完全可以使用老版本的參數(shù)傳遞方式。
Setup.h文件中定義了老版本參數(shù)傳遞結(jié)構(gòu)：
#define COMMAND_LINE_SIZE 1024 // 命令行最多1024字節(jié)
/* This is the old deprecated way to pass parameters to the kernel */
struct param_struct {
union {
struct {
unsigned long page_size; // 內(nèi)存的頁面大小
unsigned long nr_pages; // 內(nèi)存頁面數(shù)量
unsigned long ramdisk_size; // RAM disk配置, 可以不用
unsigned long flags; /* 12 */
#define FLAG_READONLY 1
#define FLAG_RDLOAD 4
#define FLAG_RDPROMPT 8
unsigned long rootdev; /* 16 */
unsigned long video_num_cols; /* 20 */
unsigned long video_num_rows; /* 24 */
unsigned long video_x; /* 28 */
unsigned long video_y; /* 32 */
unsigned long memc_control_reg; /* 36 */
unsigned char sounddefault; /* 40 */
unsigned char adfsdrives; /* 41 */
unsigned char bytes_per_char_h; /* 42 */
unsigned char bytes_per_char_v; /* 43 */
unsigned long pages_in_bank[4]; /* 44 */
unsigned long pages_in_vram; /* 60 */
unsigned long initrd_start; /* 64 */
unsigned long initrd_size; /* 68 */
unsigned long rd_start; /* 72 */
unsigned long system_rev; /* 76 */
unsigned long system_serial_low; /* 80 */
unsigned long system_serial_high; /* 84 */
unsigned long mem_fclk_21285; /* 88 */
} s;
char unused[256];
} u1;
union {
char paths[8][128];
struct {
unsigned long magic;
char n[1024 - sizeof(unsigned long)];
} s;
} u2;
char commandline[COMMAND_LINE_SIZE]; // 命令行啟動(dòng)參數(shù)
};
在整個(gè)結(jié)構(gòu)中，最關(guān)鍵的部分是u1.s.page_size，u1.s.nr_pages和commandline域。這三個(gè)域也是必須設(shè)置的域！
代碼如下：
#define LINUX_MACHINE_ID 406 // 見后面說明
#define LINUX_PAGE_SHIFT 12 // 頁面大小4K
#define LINUX_PAGE_SIZE (1<<LINUX_PAGE_SHIFT)
int do_bootzimage(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
{
int i;
u32 addr;
char *cmdline = getenv ("bootargs"); // 獲得命令行參數(shù)
void (*run)(int zero, int arch); // 定義引導(dǎo)內(nèi)核的函數(shù)原型
// 設(shè)置引導(dǎo)參數(shù)所處的位置
struct param_struct *params = (struct param_struct *)0xa0000100;
// 設(shè)置內(nèi)核加載地址
if (argc<2)
addr = load_addr; // 默認(rèn)的加載地址
else
// 調(diào)用命令時(shí)參數(shù)傳遞了地址, 那么就使用指定的地址
addr = simple_strtoul(argv[1], NULL, 16);
// 接下來將結(jié)構(gòu)的數(shù)據(jù)清零, 不用的全部清零, 防止出錯(cuò)
for(i=0; i<(sizeof(struct param_struct)>>2); i++)
((u32 *)params)[i] = 0;
// 設(shè)置u1.s.page_size和u1.s.nr_pages參數(shù), 這兩個(gè)參數(shù)由內(nèi)核自動(dòng)解析.
params->u1.s.page_size = LINUX_PAGE_SIZE;
params->u1.s.nr_pages = (0x04000000 >> LINUX_PAGE_SHIFT);
// 拷貝命令行參數(shù)到命令位置
memcpy(params->commandline, cmdline, strlen(cmdline));
run = (void (*)(int, int))addr;
// 執(zhí)行內(nèi)核程序, 傳遞兩個(gè)參數(shù)進(jìn)去, 第2個(gè)參數(shù)指定了ARCH值, 必須與
// 內(nèi)核配置的相同, 否則會(huì)出現(xiàn)”Error: a”錯(cuò)誤!!
run(0, LINUX_MACHINE_ID);
}
// 最后定義bootzImage命令，實(shí)現(xiàn)函數(shù)是do_bootzimage。
U_BOOT_CMD(
bootzimage, 2, 1, do_bootzimage,
"bootzimage - boot zImage from ram.n",
" [addr] boot zImage directoly. "
);
這里我們?cè)谝龑?dǎo)的時(shí)候使用了老版本的參數(shù)傳遞方式，下面時(shí)Linux內(nèi)核在進(jìn)行參數(shù)解析時(shí)的代碼，可以看到，內(nèi)核將這些參數(shù)自動(dòng)轉(zhuǎn)換成能夠識(shí)別的類型：
內(nèi)核（2.6.9）的init/main.c文件中的start_kernel()函數(shù)中調(diào)用了setup_arch()函數(shù)：
asmlinkage void __init start_kernel(void)
{
char * command_line;
extern struct kernel_param __start___param[], __stop___param[];
/*
* Interrupts are still disabled. Do necessary setups, then
* enable them
*/
lock_kernel();
page_address_init();
printk(linux_banner);
setup_arch(&command_line); // 這個(gè)函數(shù)中將對(duì)傳遞的參數(shù)進(jìn)行解析
setup_per_cpu_areas();
…
setup_arch()函數(shù)位于體系結(jié)構(gòu)相關(guān)的代碼中，本例中存在于arch/arm/kernel/setup.c文件中。
以下是該函數(shù)的部分內(nèi)容
…
struct tag *tags = (struct tag *)&init_tags;
…
// 判斷是不是tag的ATAG_CORE, 老式的參數(shù)是不能滿足要求的, 如果是老式的
// 參數(shù)那么將會(huì)執(zhí)行convert_to_tag_list(tags)將老式參數(shù)轉(zhuǎn)換成新的參數(shù)類型.
if (tags->hdr.tag != ATAG_CORE)
convert_to_tag_list(tags);
convert_to_tag_list()函數(shù)實(shí)現(xiàn)在arch/arm/kernel/compat.c文件中，該函數(shù)隨后調(diào)用build_tag_list()函數(shù)進(jìn)行參數(shù)重組，具體可以參考內(nèi)核的源代碼。
vivi與Linux kernel的參數(shù)傳遞情景分析（下） - Vivi - CalmArrow
下面進(jìn)入Linux kernel部分，分析與bootloader參數(shù)傳遞對(duì)應(yīng)的部分。
移植Linux需要很大的工作量，其中之一就是HAL層的編寫。在具體實(shí)現(xiàn)上，HAL層以arch目錄的形式存在。顯然，該層需要與bootloader有一定的約定，否則就不能很好的支持。其實(shí)，這個(gè)地方應(yīng)該思考一個(gè)問題，就是說，boot loader可以做到Linuxkernel里面，但是這樣帶來的問題就是可移植性和靈活性都大為降低。而且，bootloader的功能并非操作系統(tǒng)的核心范疇，Linux的核心應(yīng)該始終關(guān)注操作系統(tǒng)的核心功能上，將其性能達(dá)到最優(yōu)。所以，bootloader分離出來單獨(dú)設(shè)計(jì)，是有一定的道理的。bootloader現(xiàn)在除了完成基本功能外，慢慢地變得“肥胖”了。在高性能bootloader設(shè)計(jì)中，可能會(huì)把調(diào)試內(nèi)核等的一些功能集成進(jìn)來，這樣在內(nèi)核移植尚未完成階段，bootloader可以充當(dāng)調(diào)試器的作用。功能趨于完善，也慢慢趨于復(fù)雜。廢話不說，進(jìn)入正題。
三、Linux kernel接受參數(shù)分析
這部分主要分析如下問題：
·Linux kernel支持壓縮映象和非壓縮映象兩種方式啟動(dòng)，那么這兩種流程和函數(shù)入口有何不同？
·如何使用非壓縮映象？做一下測(cè)試。
·zImage是如何生成的？其格式如何？
·啟動(dòng)之后，Linux kernel如何接收參數(shù)？
這里不具體區(qū)分每個(gè)問題，按照理解和開發(fā)的思路來進(jìn)行。
1、思考：前面做的基本實(shí)驗(yàn)中，并沒有采用壓縮映象。因?yàn)槌绦蛞?guī)模太小，壓縮帶來的時(shí)間開銷反而降低了性能。但是對(duì)Linuxkernel來說，映象還是比較大的，往往采用了壓縮。但是，同樣有需求希望Linuxkernel小一些，不采用壓縮方式來提高內(nèi)核啟動(dòng)的速度，對(duì)時(shí)間要求比較苛刻。那么，這樣就出現(xiàn)了兩種情況：壓縮映象和非壓縮映象。由此帶來的問題就在于：如果是壓縮映象，那么必須首先解壓縮，然后跳轉(zhuǎn)到解壓縮之后的代碼處執(zhí)行；如果是非壓縮映象，那么直接執(zhí)行。Linux必須對(duì)這兩種機(jī)制提供支持，這里就需要從整體上來看一下生成的映象類型了。
因?yàn)関ivi的Makefile都是直接來源于Linux，前面對(duì)vivi的Makefile已經(jīng)分析清楚了，這里看Linux的Makefile就容易多了，大同小異，而且還有豐富的文檔支持。
（1）非壓縮映象
$make vmlinux
| [armlinux@lqm linux-2.4.18]$ ls -l vmlinux
-rwxrwxr-x 1 armlinux armlinux 1799697 Sep 11 14:06 vmlinux
[armlinux@lqm linux-2.4.18]$ file vmlinux
vmlinux: ELF 32-bit LSB executable, ARM, version 1 (ARM), statically linked, not stripped
|
這里生成的是vmlinux，是ELF文件格式。這個(gè)文件是不能燒寫存儲(chǔ)介質(zhì)的，如果想了解ELF文件格式，需要參考專門的文章。當(dāng)然，這里，如果想要使用非壓縮映象，可以使用arm-linux-objcopy把上述ELF格式的vmlinux轉(zhuǎn)化為二進(jìn)制格式的vmlinux.bin，這樣就可以直接燒寫了。
于是我做了如下的修改，在Makefile中增加了：
| vmlinux: include/linux/version.h $(CONFIGURATION) init/main.o init/version.o linuxsubdirs
$(LD) $(LINKFLAGS) $(HEAD) init/main.o init/version.o \
--start-group \
$(CORE_FILES) \
$(DRIVERS) \
$(NETWORKS) \
$(LIBS) \
--end-group \
-o vmlinux
$(NM) vmlinux | grep -v '\(compiled\)\|\(\.o$$\)\|\( [aUw] \)\|\(\.\.ng$$\)\|\(LASH[RL]DI\)' | sort > System.map
$(OBJCOPY) -O binary -R .comment -R .stab -R .stabstr -S vmlinux vmlinux.bin
|
同時(shí)在clean file的列表中增加vmlinux.bin。這樣就可以生成vmlinux.bin了，前面的基礎(chǔ)實(shí)驗(yàn)都講過了。然后燒寫vmlinux.bin到nand flash的kernel分區(qū)，引導(dǎo)啟動(dòng)，正常，而且不會(huì)出現(xiàn)解壓縮提示：
| NOW, Booting Linux......
VIVI has completed the mission of
From now on, Linux kernel takes charge of all
Linux version 2.4.18-rmk7-pxa1 (armlinux@lqm) (gcc version 2.95.3 20010315 (release)) #2 Tue Sep 11 14:06:14 CST 2007
|
可見，可以通過非壓縮映象格式啟動(dòng)。
（2）壓縮映象
下面看看壓縮映象是如何得到的。頂層的Makefile沒有壓縮映象的生成，顯然就在包含的子Makefile中。容易查知在arch/arm/下的Makefile，可見：
| bzImage zImage zinstall Image bootpImage install: vmlinux
@$(MAKEBOOT) $@
|
也就是說，有bzImage、zImage幾種。其中arch/boot下有：
| SYSTEM =$(TOPDIR)/vmlinux
Image: $(CONFIGURE) $(SYSTEM)
$(OBJCOPY) -O binary -R .note -R .comment -S $(SYSTEM) $@
bzImage: zImage
zImage: $(CONFIGURE) compressed/vmlinux
$(OBJCOPY) -O binary -R .note -R .comment -S compressed/vmlinux $@
@echo " ^_^ The kernel image file is:" $(shell /bin/pwd)/$@
|
這里發(fā)現(xiàn)如果采用make Image，則生成的非壓縮映象的二進(jìn)制格式，可以直接燒寫，可見前面第一步的工作是浪費(fèi)了，Linux內(nèi)核還是很完善的，提供了這種方式，所以，如果想要生成非壓縮二進(jìn)制映象，那么就要使用make Image。
另外，這里提供了兩種壓縮的映象，其實(shí)就是一種，這里能夠看到的就是如果采用make zImage或者makebzImage，就要把compressed/vmlinux處理為二進(jìn)制格式，可以下載使用。下面就看compressed/vmlinux是什么。進(jìn)入compressed文件夾，看看Makefile：
| vmlinux: $(HEAD) $(OBJS) piggy.o vmlinux.lds
$(LD) $(ZLDFLAGS) $(HEAD) $(OBJS) piggy.o $(LIBGCC) -o vmlinux
|
很明顯了，這里的vmlinux是由四個(gè)部分組成：head.o、head-s3c2410.o、misc.o、piggy.o。關(guān)于這幾個(gè)文件是干什么用的，看看各自的編譯規(guī)則就非常清晰了：
| $(HEAD): $(HEAD:.o=.S) \
$(wildcard $(TOPDIR)/include/config/zboot/rom.h) \
$(wildcard $(TOPDIR)/include/config/cpu/32.h) \
$(wildcard $(TOPDIR)/include/config/cpu/26.h)
$(CC) $(AFLAGS) -traditional -c $(HEAD:.o=.S)
piggy.o: $(SYSTEM)
$(OBJCOPY) -O binary -R .note -R .comment -S $(SYSTEM) piggy
gzip $(GZFLAGS) < piggy > piggy.gz
$(LD) -r -o $@ -b binary piggy.gz
rm -f piggy piggy.gz
font.o: $(FONTC)
$(CC) $(CFLAGS) -Dstatic= -c -o $@ $(FONTC)
vmlinux.lds: vmlinux.lds.in Makefile $(TOPDIR)/arch/$(ARCH)/boot/Makefile $(TOPDIR)/.config
@sed "$(SEDFLAGS)" < vmlinux.lds.in > $@
clean:; rm -f vmlinux core piggy* vmlinux.lds
.PHONY: clean
misc.o: misc.c $(TOPDIR)/include/asm/arch/uncompress.h $(TOPDIR)/lib/inflate.c
|
可見，vmlinux是把頂層生成的非壓縮的ELF映象vmlinux進(jìn)行壓縮，同時(shí)加入了加壓縮代碼部分。真正的壓縮代碼就是lib/inflate.c?？梢钥纯?，主要是gunzip，具體的壓縮算法就不分析了。
至此，就可以用下圖作出總結(jié)了：
bootloader把存儲(chǔ)介質(zhì)中的kernel映象下載到mem_base+0x8000的位置，執(zhí)行完畢后，跳轉(zhuǎn)到這一位置，執(zhí)行此處的代碼。這一位置的入口可能有兩種情況，第一種是kernel映象為非壓縮格式，通過makeImage獲得，那么真正的入口就是arch/arm/kernel/head_armv.S（ENTRY(stext)）；第二種是kernel映象為壓縮格式，通過makezImage獲得，那么真正的入口就是arch/arm/boot/compressed/head.S（ENTRY(_start)）。這個(gè)地方并不是kernel判斷，也不需要判斷。道理很簡(jiǎn)單，cpu只會(huì)按照讀入的代碼執(zhí)行，兩種情況下執(zhí)行的代碼不同，自然也就有兩種不同的過程了。
（3）探討zImage的magic number的位置
可以看出，如果是zImage，那么程序的入口是arch/arm/boot/compressed/head.S。分析程序頭部：
| .align
start:
.type start,#function
//重復(fù)如下指令8次
.rept 8
mov r0, r0
.endr
//跳轉(zhuǎn)指令，跳到下面第一個(gè)標(biāo)號(hào)1處
b 1f
//這就是第10條指令的位置，也就是偏移為4*9個(gè)字節(jié)
.word 0x016f2818 @ Magic numbers to help the loader
.word start @ absolute load/run zImage address
.word _edata @ zImage end address
1: mov r7, r1 @ save architecture ID
mov r8, #0 @ save r0
|
可見前面8條指令均為mov r0, r0，從前面的zImage的16進(jìn)制格式中可以看出，前面8個(gè)字都是相同的，均為00 00A0 E1，第9條指令就是b 1f，然后就應(yīng)該是0x016f2818.這樣就與前面程序的判斷對(duì)應(yīng)上了，也就是說，此處的magicnumber是固定位置，固定數(shù)值的，注釋中也寫的很清晰，那就是magic numbers to help theloader，也就是說幫助bootloader確定映象的文件格式。但是應(yīng)該說明的是，在vivi的bootloader設(shè)計(jì)中，雖然檢測(cè)zImage的magicnumber，但是并沒有進(jìn)行未識(shí)別處理。也就是說，假定用ultra-edit32把此位置的0x016f2818破壞掉，其他不變，那么雖然vivi提示無法識(shí)別zImage映象，但是并不影響實(shí)際的執(zhí)行。當(dāng)然，你也可以有其他的設(shè)計(jì)思路。不過設(shè)計(jì)的哲學(xué)思想是，要完成一件事情，并不只有一種方式。所以，bootloader不能限死只是使用zImage格式，需要有一定的靈活性，為了引導(dǎo)內(nèi)核啟動(dòng)，可以采用不同的方式。
（4）完成了前面的理解，下面就要重點(diǎn)看解析參數(shù)一部分了。這里不將zImage方式的啟動(dòng)作為重點(diǎn)分析內(nèi)容，靜下心來跟蹤代碼并不是難事。從整體的角度理解，如果采用zImage，那么在執(zhí)行完成解壓縮之后，自然會(huì)調(diào)轉(zhuǎn)到解壓之后的kernel的第一條指令處。這時(shí)就是真正的啟動(dòng)內(nèi)核了。所以我們可以看arch/arm/kernel/head-armv.S，此處做的工作可以參考taoyuetao的分析，完成的功能比較簡(jiǎn)單。這里就感興趣的參數(shù)問題分析，需要注意的是，
| /*
* Kernel startup entry point.
*
* The rules are:
* r0 - should be 0
* r1 - unique architecture number
* MMU - off
* I-cache - on or off
* D-cache - off
*
* See linux/arch/arm/tools/mach-types for the complete list of numbers
* for r1.
*/
|
可見R0是0，R1是machtype，這些都是必須要設(shè)定的。在這里，并沒有限定R2必須為參數(shù)的起始地址。kernel本身并沒有使用R0-R2，如果設(shè)定了R2，在這里也不會(huì)修改其值。后面的工作也沒有設(shè)計(jì)接收參數(shù)，最后直接跳到start_kernel（【init/main.c】）
| asmlinkage void __init start_kernel(void)
{
char * command_line;
unsigned long mempages;
extern char saved_command_line[];
/*
* Interrupts are still disabled. Do necessary setups, then
* enable them
*/
lock_kernel();
printk(linux_banner);
setup_arch(&command_line);
printk("Kernel command line: %s\n", saved_command_line);
parse_options(command_line);
|
從開頭分析，首先是lock_kernel，這里是SMP相關(guān)，我的是單CPU，所以實(shí)際上該函數(shù)為空。然后打印版本信息，在vivi中已經(jīng)分析過這個(gè)機(jī)制了，兩者相同。下面的setup_arch就是分析的重點(diǎn)了，它要獲取命令行啟動(dòng)參數(shù)，然后打印獲得的命令行參數(shù)，然后進(jìn)行語法解析選項(xiàng)。我們關(guān)注的重點(diǎn)就在setup_arch上了。參數(shù)設(shè)置都在【arch/arm/kernel/setup.c】，這個(gè)函數(shù)也不例外，進(jìn)入setup.c。
| void __init setup_arch(char **cmdline_p)
{
struct tag *tags = NULL;
struct machine_desc *mdesc;
char *from = default_command_line;
ROOT_DEV = MKDEV(0, 255);
setup_processor();
mdesc = setup_machine(machine_arch_type);
machine_name = mdesc->name;
if (mdesc->soft_reboot)
reboot_setup("s");
if (mdesc->param_offset)
tags = phys_to_virt(mdesc->param_offset);
/*
* Do the machine-specific fixups before we parse the
* parameters or tags.
*/
if (mdesc->fixup)
mdesc->fixup(mdesc, (struct param_struct *)tags,
&from, &meminfo);
/*
* If we have the old style parameters, convert them to
* a tag list before.
*/
if (tags && tags->hdr.tag != ATAG_CORE)
convert_to_tag_list((struct param_struct *)tags,
meminfo.nr_banks == 0);
if (tags && tags->hdr.tag == ATAG_CORE)
parse_tags(tags);
if (meminfo.nr_banks == 0) {
meminfo.nr_banks = 1;
meminfo.bank[0].start = PHYS_OFFSET;
meminfo.bank[0].size = MEM_SIZE;
}
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;
memcpy(saved_command_line, from, COMMAND_LINE_SIZE);
saved_command_line[COMMAND_LINE_SIZE-1] = '\0';
parse_cmdline(&meminfo, cmdline_p, from);
bootmem_init(&meminfo);
paging_init(&meminfo, mdesc);
request_standard_resources(&meminfo, mdesc);
/*
* Set up various architecture-specific pointers
*/
init_arch_irq = mdesc->init_irq;
#ifdef CONFIG_VT
#if defined(CONFIG_VGA_CONSOLE)
conswitchp = &vga_con;
#elif defined(CONFIG_DUMMY_CONSOLE)
conswitchp = &dummy_con;
#endif
#endif
}
|
這里面涉及到3個(gè)比較復(fù)雜的結(jié)構(gòu)體，包括param_struct、tag、machine_desc。第一步的操作是關(guān)于根設(shè)備號(hào)，暫時(shí)不探討；第二步工作setup_processor，是設(shè)置處理器，這是多處理器相關(guān)部分，暫時(shí)不探討；第三步工作是setup_machine，這里就需要了解了。
首先，machine_arch_type沒有定義，僅僅在頭部有定義，這是全局變量，兩者之間一定存在聯(lián)系：
| unsigned int __machine_arch_type;
|
看看頭文件，應(yīng)該有#include<asm/mach-types.h>，但是未編譯時(shí)并沒有，可以確定是編譯前完成的。這里只有看Makefile了。因?yàn)閟etup.c在這里，首先看同層的Makefile。這一層沒有關(guān)于mach-types.h的信息，然后到上一層Makefile，發(fā)現(xiàn)了：
| MRPROPER_FILES += \
arch/arm/tools/constants.h* \
include/asm-arm/arch \
include/asm-arm/proc \
include/asm-arm/constants.h* \
include/asm-arm/mach-types.h
# We use MRPROPER_FILES and CLEAN_FILES now
archmrproper:
@/bin/true
archclean:
@$(MAKEBOOT) clean
archdep: scripts/mkdep archsymlinks
@$(MAKETOOLS) dep
@$(MAKEBOOT) dep
|
說現(xiàn)在使用MRPROPER_FILES，但是下面沒有出現(xiàn)，故而應(yīng)該看幾個(gè)宏的定義：
| MAKEBOOT = $(MAKE) -C arch/$(ARCH)/boot
MAKETOOLS = $(MAKE) -C arch/$(ARCH)/tools
|
由此知道，對(duì)應(yīng)的子文件夾包括boot和tools，boot是與啟動(dòng)相關(guān)，不太可能；而前面也看到，tools下有mach-types，所以判斷在tools下面，看看tools/Makefile：
| all: $(TOPDIR)/include/asm-arm/mach-types.h \
$(TOPDIR)/include/asm-arm/constants.h
$(TOPDIR)/include/asm-arm/mach-types.h: mach-types gen-mach-types
awk -f gen-mach-types mach-types > $@
|
由此判斷出，mach-types.h是如何生成的，主要是利用awk腳本處理生成。生成之后與s3c2410有關(guān)的部分為：
| #ifdef CONFIG_S3C2410_SMDK
# ifdef machine_arch_type
# undef machine_arch_type
# define machine_arch_type __machine_arch_type
# else
# define machine_arch_type MACH_TYPE_SMDK2410
# endif
# define machine_is_smdk2410() (machine_arch_type == MACH_TYPE_SMDK2410)
#else
# define machine_is_smdk2410() (0)
#endif
|
由此就知道了，這里的machine_arch_type為193，所以此函數(shù)實(shí)際上執(zhí)行：mdesc = setup_machine(193);它要填充結(jié)構(gòu)體machine_desc，如下：
| struct machine_desc {
/*
* Note! The first four elements are used
* by assembler code in head-armv.S
*/
unsigned int nr; /* architecture number */
unsigned int phys_ram; /* start of physical ram */
unsigned int phys_io; /* start of physical io */
unsigned int io_pg_offst; /* byte offset for io
* page tabe entry */
const char *name; /* architecture name */
unsigned int param_offset; /* parameter page */
unsigned int video_start; /* start of video RAM */
unsigned int video_end; /* end of video RAM */
unsigned int reserve_lp0 :1; /* never has lp0 */
unsigned int reserve_lp1 :1; /* never has lp1 */
unsigned int reserve_lp2 :1; /* never has lp2 */
unsigned int soft_reboot :1; /* soft reboot */
void (*fixup)(struct machine_desc *,
struct param_struct *, char **,
struct meminfo *);
void (*map_io)(void);/* IO mapping function */
void (*init_irq)(void);
};
|
另外，還提供了一系統(tǒng)的宏，用于填充該結(jié)構(gòu)體：
| /*
* Set of macros to define architecture features. This is built into
* a table by the linker.
*/
#define MACHINE_START(_type,_name) \
const struct machine_desc __mach_desc_##_type \
__attribute__((__section__(".arch.info"))) = { \
nr: MACH_TYPE_##_type, \
name: _name,
#define MAINTAINER(n)
#define BOOT_MEM(_pram,_pio,_vio) \
phys_ram: _pram, \
phys_io: _pio, \
io_pg_offst: ((_vio)>>18)&0xfffc,
#define BOOT_PARAMS(_params) \
param_offset: _params,
#define VIDEO(_start,_end) \
video_start: _start, \
video_end: _end,
#define DISABLE_PARPORT(_n) \
reserve_lp##_n: 1,
#define BROKEN_HLT /* unused */
#define SOFT_REBOOT \
soft_reboot: 1,
#define FIXUP(_func) \
fixup: _func,
#define MAPIO(_func) \
map_io: _func,
#define INITIRQ(_func) \
init_irq: _func,
#define MACHINE_END \
};
|
EDUKIT填充了一個(gè)結(jié)構(gòu)體，用如下的方式：
| MACHINE_START(SMDK2410, "Embest EduKit III (S3C2410x)")
BOOT_MEM(0x30000000, 0x48000000, 0xe8000000)
BOOT_PARAMS(0x30000100)
FIXUP(fixup_smdk)
MAPIO(smdk_map_io)
INITIRQ(s3c2410_init_irq)
MACHINE_END
|
看到有特殊的設(shè)置部分，那就是開始為之分配了一個(gè)段，段的名字是.arch.info，也就是說把這部分信息單獨(dú)作為一個(gè)段來進(jìn)行處理。下面把這個(gè)宏展開如下：
| const struct machine_desc __mach_desc_smdk2410 = {
nr: 193,
name: "EDUKIT-III (s3c2410)",
phys_ram: 0x30000000,
phys_to: 0x48000000,
io_pg_offset: 0x3a00,
param_offset: 0x30000100,
fixup: fixup_smdk,//實(shí)際上為空
map_io: smdk_map_io,
init_irq: s3c2410_init_irq,
};
|
可見，基本的信息已經(jīng)具備了，而且從這里，我們也可以看出，啟動(dòng)參數(shù)地址由這個(gè)段就可以完成，不需要傳遞了。當(dāng)然，必須保證bootloader的值，與此處的相同。這樣，也就說明如果不使用R2傳遞參數(shù)的起始地址，那么這個(gè)地方就需要把這個(gè)結(jié)構(gòu)體設(shè)置好。
下面看看這個(gè)函數(shù)完成什么功能：
| static struct machine_desc * __init setup_machine(unsigned int nr)
{
extern struct machine_desc __arch_info_begin, __arch_info_end;
struct machine_desc *list;
/*
* locate architecture in the list of supported architectures.
*/
for (list = &__arch_info_begin; list < &__arch_info_end; list++)
if (list->nr == nr)
break;
/*
* If the architecture type is not recognised, then we
* can co nothing...
*/
if (list >= &__arch_info_end) {
printk("Architecture configuration botched (nr %d), unable "
"to continue.\n", nr);
while (1);
}
printk("Machine: %s\n", list->name);
return list;
}
|
這個(gè)地方就是要把上面這一系列的信息連貫起來，那么就不難理解了。上述的宏已經(jīng)完成了.arch.info段，這個(gè)段實(shí)際上在內(nèi)存中就是一個(gè)machine_desc形式組織的信息（對(duì)Linux內(nèi)核來說，并不一定僅僅有一個(gè)結(jié)構(gòu)塊），上述函數(shù)的兩個(gè)變量__arch_info_begin和__arch_info_end很明顯是有鏈接腳本傳遞進(jìn)來。于是查看近層的鏈接腳本（【arch/arm/vmlinux-armv.lds.in】，可以發(fā)現(xiàn)：
| .init : { /* Init code and data */
_stext = .;
__init_begin = .;
*(.text.init)
__proc_info_begin = .;
*(.proc.info)
__proc_info_end = .;
__arch_info_begin = .;
*(.arch.info)
__arch_info_end = .;
__tagtable_begin = .;
*(.taglist)
__tagtable_end = .;
|
所以上述的功能就很簡(jiǎn)單了，就是查看是否有mach-type為193的結(jié)構(gòu)存在，如果存在就打印出name，這也就是開機(jī)啟動(dòng)后，出現(xiàn)Machine: Embest EduKit III (S3C2410)的原因了。
接下來關(guān)注：
| if (mdesc->param_offset)
tags = phys_to_virt(mdesc->param_offset);
|
很明顯，這里的mdesc->param_offset并不為0，而是0x30000100，所以要做一步變換，就是物理地址映射成虛擬地址。把這個(gè)地址附給tags指針。然后就是判斷是param_struct類型還是tags類型，如果是param_struct類型，那么首先轉(zhuǎn)換成tags類型，然后對(duì)tags類型進(jìn)行解析。
| if (tags && tags->hdr.tag != ATAG_CORE)
convert_to_tag_list((struct param_struct *)tags,
meminfo.nr_banks == 0);
|
| if (tags && tags->hdr.tag == ATAG_CORE)
parse_tags(tags);
|
要注意parse_tags函數(shù)是非常重要的，它有隱含的功能，不太容易分析。跟蹤上去，主要看這個(gè)函數(shù)：
| /*
* Scan the tag table for this tag, and call its parse function.
* The tag table is built by the linker from all the __tagtable
* declarations.
*/
static int __init parse_tag(const struct tag *tag)
{
extern struct tagtable __tagtable_begin, __tagtable_end;
struct tagtable *t;
for (t = &__tagtable_begin; t < &__tagtable_end; t++)
if (tag->hdr.tag == t->tag) {
t->parse(tag);
break;
}
return t < &__tagtable_end;
}
|
這里又用到鏈接器傳遞參數(shù)，現(xiàn)在就是來解析每個(gè)部分。先看一下tagtable是如何來的。首先看【include/asm-arm/setup.h】，看看宏的定義，也就是帶有__tag，就歸屬為.taglist段。
| #define __tag __attribute__((unused, __section__(".taglist")))
#define __tagtable(tag, fn) \
static struct tagtable __tagtable_##fn __tag = { tag, fn }
|
利用__tag有構(gòu)造了一個(gè)復(fù)雜的宏__tagtable，實(shí)際上就是定義了tagtable列表?，F(xiàn)在看setup.c中的宏形式示例：
| __tagtable(ATAG_CMDLINE, parse_tag_cmdline);
|
展開之后為：
| static struct tagtable __tagtable_ATAG_CMDLINE __tag = {
ATAG_CMDLINE,
parse_tag_cmdline
};
|
于是，段.taglist就是這樣一系列的結(jié)構(gòu)體。那么上述的函數(shù)實(shí)際上就是把傳遞進(jìn)來的tag與此表比較，如果tag標(biāo)記相同，證明設(shè)置了此部分功能，就執(zhí)行相應(yīng)的解析函數(shù)。以ATAG_CMDLINE為例，就要執(zhí)行：
| static int __init parse_tag_cmdline(const struct tag *tag)
{
#ifndef CONFIG_NO_TAG_CMDLINE
strncpy(default_command_line, tag->u.cmdline.cmdline, COMMAND_LINE_SIZE);
#endif
default_command_line[COMMAND_LINE_SIZE - 1] = '\0';
return 0;
}
|
這樣也就是實(shí)現(xiàn)了把tag中的命令行參數(shù)復(fù)制到了default_command_line中。
在返回來到函數(shù)【arch/arm/kernel/setup.c】，看函數(shù)setup_arch，定義中有：
| char *from = default_command_line;
|
說明from指向數(shù)組default_command_line。于是知道，當(dāng)你完成tag解析的時(shí)候，所有傳遞過來的參數(shù)實(shí)際上已經(jīng)復(fù)制到了相應(yīng)的部分，比如命令行設(shè)置復(fù)制到了default_command_line。其他類似，看相應(yīng)的解析行為函數(shù)就可以了。因?yàn)楝F(xiàn)在vivi只是傳遞了命令行，所以只是分析清楚這個(gè)。后面執(zhí)行：
| memcpy(saved_command_line, from, COMMAND_LINE_SIZE);
|
這就比較容易理解了，就是將傳遞進(jìn)來的命令行參數(shù)復(fù)制到saved_command_line，后面還可以打印出此信息。再往后的工作已經(jīng)與此情景關(guān)系不大，所以不再進(jìn)行詳細(xì)分析。
至此，vivi與Linux kernel的參數(shù)傳遞情景分析就完成了。
現(xiàn)在正在閱讀linux2.6.18內(nèi)核，在mainstone.c文件中，有如下的宏定義：
MACHINE_START(MAINSTONE, "Intel HCDDBBVA0 Development Platform (aka Mainstone)")
/* Maintainer: MontaVista Software Inc. */
.phys_io = 0x40000000,
.boot_params = 0xa0000100, /* BLOB boot parameter setting */
.io_pg_offst = (io_p2v(0x40000000) >> 1
& 0xfffc,
.map_io = mainstone_map_io,
.init_irq = mainstone_init_irq,
.timer = &pxa_timer,
.init_machine = mainstone_init,
MACHINE_END
請(qǐng)問各位大俠，這個(gè)宏定義甚么時(shí)候調(diào)用的，是誰調(diào)用的它，象里面的mainstone_init是哪個(gè)函數(shù)調(diào)用的它？是不是在main函數(shù)中的初始化的時(shí)候？
自己看宏的定義，主要是定義了"struct machine_desc"的類型，放在 section(".arch.info.init")，是初始化數(shù)據(jù)，Kernel 起來之后將被丟棄。
kernel boot 起來的時(shí)候期望 bootloader 傳參數(shù)進(jìn)來，其中包括 Machine Type，參考
arch/arm/tools/mach-types 并和 MACHINE_START() 第一個(gè)參數(shù)對(duì)上號(hào)。因此，哪個(gè)
MACHINE 是 run-time 的時(shí)候決定的，this way, you can pack as many machine as you
want, and dynamically initialize the specific platforms.
各個(gè)成員函數(shù)在不同時(shí)期被調(diào)用：
1. .init_machine 在 arch/arm/kernel/setup.c 中被 customize_machine 調(diào)用，放在 arch_initcall() 段里面，會(huì)自動(dòng)按順序被調(diào)用 start_kernel，參考 init/main.c
2. init_irq在start_kernel() --> init_IRQ() --> init_arch_irq() 被調(diào)用
3. map_io 在 setup_arch() --> paging_init() --> devicemaps_init()
其他主要都在 setup_arch() 中用到
