编译内核之启动流程分析
源码配置编译：
本文主要是针对linux-2.6.22.6来进行配置编译和源码的分析，这里韦老师已经做好补丁文件和配置文件，直接在此基础上进行配置编译
解压缩
tar xjf 压缩文件
打补丁
patch -p1 < 补丁文件 (这里韦老师已经为我们做好了补丁文件)
配置
linux有两种配置方式
1. 通过make xxx_defconfig命令在默认的配置上进行修改,然后再输入make menuconfig配置菜单
make s3c2410_defconfig （根据自己的板子选择）
配置完后可以看到打印信息中最后出现“configuration written to .config”，表示将所有config配置都写入到.config文件中
make menuconfig (启动X-windows图形配置界面，选择一些内核的配置选项)
2.使用厂家提供的配置config_ok文件 （我们这里使用的就是韦老师配置好的config_ok文件）
在linux-2.6.22.6目录下，使用cp config_ok .config命令将config_ok复制成新的.config文件(通过 ls -la 命令可以查看隐藏文件.config)，
然后执行make menuconfig 回去读取.config文件
问题： make menuconfig时出现段错误
Makefile:14: recipe for target 'menuconfig' failed make[1]: *** [menuconfig] Segmentation fault (core dumped)
Makefile:417: recipe for target 'menuconfig' failed make: *** [menuconfig] Error 2
解决办法：由于ubuntu的版本过新不能编译老的版本所以需要安装一些库
sudo apt-get install libncurses*
make menuconfig时提示makefile错误
linux-2.6.22.6/Makefile:416: *** mixed implicit and normal rules: deprecated syntax
linux-2.6.22.6/Makefile:1449: *** mixed implicit and normal rules: deprecated syntax
解决办法：系统的make工具太新，make的旧版规则已经无法兼容新版
config %config: scripts_basic outputmakefile FORCE 改为%config: scripts_basic outputmakefile FORCE
/ %/: prepare scripts FORCE 改为%/: prepare scripts FORCE
编译
make uImage
Makefile分析:
要想快速的分析源码，一般通过分析配置编译的过程快速切入以了解实际的启动流程，我们之前通过make s3c2410_defconfig命令对内核源码进行配置过后会生成一个.config文件,首先需要分析.config文件的内容。
CONFIG_DM9000=y 配置项 =y表示选中,会被编译进内核
以dm9000为例，在源码中搜索可以知道，在makefile中使用过CONFIG_DM9000，但是这个是由autoconf.h文件中定义的，然后我们平常的配置CONFIG_DM9000=y 就是生成了在autoconf.h中将CONFIG_DM9000定义了
drivers/net/dm9ks.c:445:#define CONFIG_DM9000_BASE 0x20000000
drivers/net/dm9ks.c:446: iobase = ioremap(CONFIG_DM9000_BASE, 0x100000) + 0x300;
drivers/net/Makefile:197:obj-$(CONFIG_DM9000) += dm9dev9000c.o
drivers/net/Makefile:198:#obj-$(CONFIG_DM9000) += dm9000.o
drivers/net/Makefile:199:#obj-$(CONFIG_DM9000) += dm9ks.o
include/linux/autoconf.h:145:#define CONFIG_DM9000 1
include/config/auto.conf:144:CONFIG_DM9000=yCONFIG_DM9000=m就会被编辑成模块，这些.o文件就会被连接成.ko文件
#obj-$(CONFIG_DM9000) += dm9000.o
#obj-$(CONFIG_DM9000) += dm9ks.o所以当我们执行make uImage时就执行了.config文件中的内容，然后就生成了include/linux/autoconf.h 和 include/config/auto.conf 这两个文件
对于所有的makefile，内核中有一个文件专门进行了讲解 linux-2.6.22.6\Documentation\kbuild\makefiles.txt 有时间可以仔细细看
然后我们方便分析，直接从编译命令 make uImage入手，我们发现在顶层的makefile中并没有发现uImage的踪影，相反在arch/arm/makefile文件中有
zImage Image xipImage bootpImage uImage: vmlinux
$(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $(boot)/$@所以推测在顶层的makefile中肯定包含了arm目录下的makefile，然后查找可得
ARCH ?= arm
include $(srctree)/arch/$(ARCH)/Makefile
然后我们从arm下可知uImage依赖于vmlinux，在顶层中，第一个目标就是vmlinux
# The all: target is the default when no target is given on the
# command line.
# This allow a user to issue only 'make' to build a kernel including modules
# Defaults vmlinux but it is usually overridden in the arch makefile
all: vmlinux
我们再找到vmlinux的依赖
vmlinux: $(vmlinux-lds) $(vmlinux-init) $(vmlinux-main) $(kallsyms.o) FORCE
再继续找到这些依赖指向哪里
vmlinux-init := $(head-y) $(init-y)
vmlinux-main := $(core-y) $(libs-y) $(drivers-y) $(net-y)
vmlinux-all := $(vmlinux-init) $(vmlinux-main)
vmlinux-lds := arch/$(ARCH)/kernel/vmlinux.lds
head-y在顶层里没有定义，在arm下有个定义
head-y := arch/arm/kernel/head$(MMUEXT).o arch/arm/kernel/init_task.o MMUEXT没有定义就变成了空的 arch/arm/kernel/head.oinit-y := init/
init-y := $(patsubst %/, %/built-in.o, $(init-y)) ---> init-y = init//built-in.ocore-y := usr/
core-y += kernel/ mm/ fs/ ipc/ security/ crypto/ block/
core-y := $(patsubst %/, %/built-in.o, $(core-y)) ---> core-y = usr/built-in.o kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o security/built-in.o crypto/built-in.o block/built-in.o libs-y := lib/
libs-y1 := $(patsubst %/, %/lib.a, $(libs-y))
libs-y2 := $(patsubst %/, %/built-in.o, $(libs-y))
libs-y := $(libs-y1) $(libs-y2) ---> libs-y = lib/lib.a lib/built-in.odrivers-y := drivers/ sound/
drivers-y := $(patsubst %/, %/built-in.o, $(drivers-y)) ---> drivers-y := drivers/ sound/built-in.onet-y := net/
net-y := $(patsubst %/, %/built-in.o, $(net-y)) ---> net-y := net/built-in.o
想知道上面的这些文件如何编译到内核，直接编译内核看它的编译过程
make uImage v=1 （v=1 表示更详细的打印编译信息）然后查看编译流程，找到有用的信息：
arm-linux-ld -EL -p --no-undefined -X -o vmlinux -T arch/arm/kernel/vmlinux.lds -> $(vmlinux-lds)
arch/arm/kernel/head.o arch/arm/kernel/init_task.o init/built-in.o --start-group usr/built-in.o arch/arm/kernel/built-in.o arch/arm/mm/built-in.o arch/arm/common/built-in.o -> head-y
arch/arm/mach-s3c2410/built-in.o arch/arm/mach-s3c2400/built-in.o
arch/arm/mach-s3c2412/built-in.o arch/arm/mach-s3c2440/built-in.o arch/arm/mach-s3c2442/built-in.o arch/arm/mach-s3c2443/built-in.o arch/arm/nwfpe/built-in.o
arch/arm/plat-s3c24xx/built-in.o kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o security/built-in.o crypto/built-in.o block/built-in.o
arch/arm/lib/lib.a lib/lib.a arch/arm/lib/built-in.o lib/built-in.o drivers/built-in.o sound/built-in.o net/built-in.o --end-group .tmp_kallsyms2.o -> libs-y然后通过上面的对比，就能直接对应起来，不需要再去找每个依赖的下一级依赖，从这里我们知道了我们的链接脚本位于arch/arm/kernel/vmlinux.lds ，第一个链接的文件arch/arm/kernel/head.s
启动流程分析：
从head.s入手，
.section ".text.head", "ax"
.type stext, %function
ENTRY(stext)
msr cpsr_c, #PSR_F_BIT | PSR_I_BIT | SVC_MODE @ ensure svc mode//确保进入管理模式（设置 CPSR寄存器）
@ and irqs disabled //禁止中断
mrc p15, 0, r9, c0, c0 @ get processor id //读取CPU ID（CP15寄存器）,存入r9寄存器
bl __lookup_processor_type @ r5=procinfo r9=cpuid// 调用函数，输入参数r9=cpuid，返回值r5=procinfo 判断是否支持cpu
movs r10, r5 @ invalid processor (r5=0)?//如果不支持当前cpu，则返回值r5=0
beq __error_p @ yes, error 'p' //如果r5=0，则打印错误
bl __lookup_machine_type @ r5=machinfo // 调用函数，返回值r5=machinfo，判断是否支持单板
movs r8, r5 @ invalid machine (r5=0)?//如果不支持当前机器，则返回值r5 =0
beq __error_a @ yes, error 'a' // 如果r5=0，则打印错误
bl __create_page_tables//创建页表 建立虚拟地址和物理地址的映射关系为了启动mmu上面主要是实现几个流程
1. 判断是否支持处理器 -> bl __lookup_processor_type
2. 判断是否支持单板（根据uboot传入的机器id） -> bl __lookup_machine_type
__lookup_machine_type的实现：
= (0xc0000000) + 0x00008000;
text.head : {
_stext = .;
_sinittext = .;
*(.text.head)
init : { /* Init code and data */
*(.init.text)
_einittext = .;
__proc_info_begin = .;
*(.proc.info.init)
__proc_info_end = .;
__arch_info_begin = .; /*链接脚本中__arch_info_begin的地址（虚拟地址）*/
*(.arch.info.init)
__arch_info_end = .; 3: .long . @表示当前这行代码编译链接后的虚拟地址
.long __arch_info_begin
.long __arch_info_end
__lookup_machine_type:
adr r3, 3b //r3等于3b的地址 物理地址 __arch_info_begin
ldmia r3, {r4, r5, r6} //从r3里读取内容到r4，r5，r6，r4 = "." r5 ="__arch_info_begin" r6 ="__arch_info_end"
sub r3, r3, r4 @ get offset between virt&phys//物理地址和虚拟地址的偏移量
add r5, r5, r3 @ convert virt addresses to//计算r5,r6对应的物理地址
add r6, r6, r3 @ physical address space
1: ldr r3, [r5, #MACHINFO_TYPE] @ get machine type //这下面就是开始不断比较传入的机器id是否能够被改内核支持
teq r3, r1 @ matches loader number? //r1存放的就uboot存进来的机器id
beq 2f @ found 从*(.arch.info.init)段中对比id，找到就退出
add r5, r5, #SIZEOF_MACHINE_DESC @ next machine_desc 没找到继续往下找直到地址到末尾__arch_info_end
cmp r5, r6
blo 1b
mov r5, #0 @ unknown machine
2: mov pc, lr //比较完成就会返回直接调用处这种将机器id如何存放到链接脚本中指定的段中，我们可以从他的实现来分析，搜索.arch.info.init可以知道
#define MACHINE_START(_type,_name) \
static const struct machine_desc __mach_desc_##_type \
__used \
__attribute__((__section__(".arch.info.init"))) = { \
.nr = MACH_TYPE_##_type, \
.name = _name,
#define MACHINE_END \
};然后找到调用MACHINE_START宏的函数，这里就是2440，可以看出来每种单板都会调用该函数
arch.h (E:\print\linux-2.6-100ask\linux-2.6.22.6\include\asm-arm\mach) line 50 : #define MACHINE_START(_type,_name) \
mach-amlm5900.c (E:\print\linux-2.6-100ask\linux-2.6.22.6\arch\arm\mach-s3c2410) line 247 : MACHINE_START(AML_M5900, "AML_M5900")
mach-anubis.c (E:\print\linux-2.6-100ask\linux-2.6.22.6\arch\arm\mach-s3c2440) line 317 : MACHINE_START(ANUBIS, "Simtec-Anubis")
mach-bast.c (E:\print\linux-2.6-100ask\linux-2.6.22.6\arch\arm\mach-s3c2410) line 500 : MACHINE_START(BAST, "Simtec-BAST")
mach-h1940.c (E:\print\linux-2.6-100ask\linux-2.6.22.6\arch\arm\mach-s3c2410) line 239 : MACHINE_START(H1940, "IPAQ-H1940")
mach-n30.c (E:\print\linux-2.6-100ask\linux-2.6.22.6\arch\arm\mach-s3c2410) line 121 : MACHINE_START(N30, "Acer-N30")
mach-nexcoder.c (E:\print\linux-2.6-100ask\linux-2.6.22.6\arch\arm\mach-s3c2440) line 148 : MACHINE_START(NEXCODER_2440, "NexVision - Nexcoder 2440")
mach-osiris.c (E:\print\linux-2.6-100ask\linux-2.6.22.6\arch\arm\mach-s3c2440) line 343 : MACHINE_START(OSIRIS, "Simtec-OSIRIS")
mach-otom.c (E:\print\linux-2.6-100ask\linux-2.6.22.6\arch\arm\mach-s3c2410) line 115 : MACHINE_START(OTOM, "Nex Vision - Otom 1.1")
mach-qt2410.c (E:\print\linux-2.6-100ask\linux-2.6.22.6\arch\arm\mach-s3c2410) line 433 : MACHINE_START(QT2410, "QT2410")
mach-rx3715.c (E:\print\linux-2.6-100ask\linux-2.6.22.6\arch\arm\mach-s3c2440) line 231 : MACHINE_START(RX3715, "IPAQ-RX3715")
mach-smdk2410.c (E:\print\linux-2.6-100ask\linux-2.6.22.6\arch\arm\mach-s3c2410) line 198 : MACHINE_START(SMDK2410, "SMDK2410") /* @TODO: request a new identifier and switch
mach-smdk2440.c (E:\print\linux-2.6-100ask\linux-2.6.22.6\arch\arm\mach-s3c2440) line 339 : MACHINE_START(S3C2440, "SMDK2440")
mach-vr1000.c (E:\print\linux-2.6-100ask\linux-2.6.22.6\arch\arm\mach-s3c2410) line 422 : MACHINE_START(VR1000, "Thorcom-VR1000")我们将2440的宏展开来分析
#define MACHINE_START(_type,_name) \ MACHINE_START(S3C2440, "SMDK2440")
static const struct machine_desc __mach_desc_##_type \ /* Maintainer: Ben Dooks */
__used \ .phys_io = S3C2410_PA_UART,
__attribute__((__section__(".arch.info.init"))) = { \ .io_pg_offst = (((u32)S3C24XX_VA_UART) >> 18) & 0xfffc,
.nr = MACH_TYPE_##_type, \ .boot_params = S3C2410_SDRAM_PA + 0x100,
.name = _name,
.init_irq = s3c24xx_init_irq,
.map_io = smdk2440_map_io,
#define MACHINE_END \ .init_machine = smdk2440_machine_init,
}; .timer = &s3c24xx_timer,
MACHINE_END
static const struct machine_desc __mach_desc_##S3C2440 \
__used \
__attribute__((__section__(".arch.info.init"))) = { \
.nr = MACH_TYPE_##S3C2440, \
.name = "SMDK2440",
.phys_io = S3C2410_PA_UART,
.io_pg_offst = (((u32)S3C24XX_VA_UART) >> 18) & 0xfffc,
.boot_params = S3C2410_SDRAM_PA + 0x100,
.init_irq = s3c24xx_init_irq,
.map_io = smdk2440_map_io,
.init_machine = smdk2440_machine_init,
.timer = &s3c24xx_timer,
}; 这样之后S3C2410所有的信息都存在了machine_desc结构体中，然后这个结构体被定义了一个属性，段强制设成了".arch.info.init",存放在链接脚本中的指定地址中，所以对于不同的开发板传入各自的machine_desc结构体就好了，然后将各自结构体的文件编进内核就能支持该单板
3. 建立页表 -> bl __create_page_table
4. 使能MMU -> adr lr, __enable_mmu
5. 复制数据段，清bss等 -> __mmap_switched
__mmap_switched:
adr r3, __switch_data + 4
ldmia r3!, {r4, r5, r6, r7}
cmp r4, r5 @ Copy data segment if needed //复制数据段
1: cmpne r5, r6
ldrne fp, [r4], #4
strne fp, [r5], #4
bne 1b
mov fp, #0 @ Clear BSS (and zero fp) //清除bss段
1: cmp r6, r7
strcc fp, [r6],#4
bcc 1b
ldmia r3, {r4, r5, r6, sp} //设置栈指针
str r9, [r4] @ Save processor ID //保存CPU_ID到processor_id变量
str r1, [r5] @ Save machine type //保存机器id
bic r4, r0, #CR_A @ Clear 'A' bit
stmia r6, {r0, r4} @ Save control register values //跳转到kernel
b start_kernel
6. 跳转到start_kernel,进入内核启动的第二阶段 -> b start_kernel
第二阶段函数解析：
start_kernel里主要是一系列的初始化函数，里面跟单板挂钩比较重要的是
setup_arch(&command_line)函数分析：
void __init setup_arch(char **cmdline_p)
{
struct tag *tags = (struct tag *)&init_tags;
struct machine_desc *mdesc;
char *from = default_command_line;
setup_processor(); // 进行处理器的相关一些设置 获得proc_info_list结构 就是cpu相关的信息
mdesc = setup_machine(machine_arch_type); // 获得开发板的machine_desc结构 就是单板相关的信息
machine_name = mdesc->name;
if (mdesc->soft_reboot) // 定义了bootloader传入参数的地址
reboot_setup("s");
if (mdesc->boot_params)
tags = phys_to_virt(mdesc->boot_params); // 这个地址就是tag列表的首地址 0x30000100
/*
* If we have the old style parameters, convert them to
* a tag list.
*/
if (tags->hdr.tag != ATAG_CORE)
convert_to_tag_list(tags);
if (tags->hdr.tag != ATAG_CORE)
tags = (struct tag *)&init_tags;
if (mdesc->fixup)
mdesc->fixup(mdesc, tags, &from, &meminfo);
if (tags->hdr.tag == ATAG_CORE) {
if (meminfo.nr_banks != 0) //如果在内核中已经定义了meminfo结构
squash_mem_tags(tags); // 则忽略内存tag
parse_tags(tags); // 解释每个tag 调用tagtable里面的函数，对各种tag进行操作
}
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(boot_command_line, from, COMMAND_LINE_SIZE);
boot_command_line[COMMAND_LINE_SIZE-1] = '\0';
parse_cmdline(cmdline_p, from);//解析uboot传进来的命令行，如果没有传进来就使用默认的default_command_line
paging_init(&meminfo, mdesc); // 重新初始化页表大致流程如下所示：
parse_tags(tags)函数的实现，主要是依赖于“.taglist.init”段预先已经存放了各个tag的函数，然后通过for循环逐步调用各个tag函数的实现，以parse_tag_mem32为例：
#define __tag __used __attribute__((__section__(".taglist.init")))
#define __tagtable(tag, fn) \
static struct tagtable __tagtable_##fn __tag = { tag, fn }
static int __init parse_tag_mem32(const struct tag *tag)
{
if (meminfo.nr_banks >= NR_BANKS) {
printk(KERN_WARNING
"Ignoring memory bank 0x%08x size %dKB\n",
tag->u.mem.start, tag->u.mem.size / 1024);
return -EINVAL;
}
arm_add_memory(tag->u.mem.start, tag->u.mem.size); //增加内存的描述信息
return 0;
}
__tagtable(ATAG_MEM, parse_tag_mem32);__attribute__是一个特殊的GNU关键字，在这里的用法是：告诉编译器需要将其作用的函数或者数据放入”.taglist.init”这一段区域,也就是说由__tagtable定义的函数将会被放在section“.taglist.init” 这个区域,所以在parse_tag()做for循环调用的时候，必然会调用到parse_tag_mem32()。其中一点要注意的是，parse_tag_mem32()的TAG为ATAG_MEM, 所以在boot传过来的TAG参数如果是要定义为memory参数的话TAG一定要定义为ATAG_MEM,否则parse_tag_mem32()是无法解析到的！
console_init()函数分析：
call = __con_initcall_start;
while (call < __con_initcall_end) {
(*call)();
call++;
}这里只要是调用__con_initcall_start和__con_initcall_end之间定义的每个函数，这些函数都存在连接脚本中的 *(.con_initcall.init)中，搜索脚本文件
__con_initcall_start = .;
*(.con_initcall.init)
__con_initcall_end = .;
rest_init()函数分析：
rest_init()主要功能是挂接根文件系统然后执行应用程序，具体流程如下
rest_init()
kernel_init();
prepare_namespace();
mount_root(); //挂接根文件系统
init_post(); //打开dev/console,执行应用程序
启动参数的分析：
以挂接根文件系统为例，分析内核是怎么处理这些命令行参数的。例如在命令行中有个参数为"root=/dev/mtdblock3"，那么内核是如何将该参数记录并执行的呢？
在rest_init()函数中有个prepare_namespace()主要的任务就是挂接根文件系统的，代码如下
void __init prepare_namespace(void)
{
int is_floppy;
if (root_delay) {
printk(KERN_INFO "Waiting %dsec before mounting root device...\n",
root_delay);
ssleep(root_delay);
}
/* wait for the known devices to complete their probing */
while (driver_probe_done() != 0)
msleep(100);
md_run_setup();
if (saved_root_name[0]) { //查看是否存在root这个参数（其实这个参数就是我们读取的命令行）
root_device_name = saved_root_name;
if (!strncmp(root_device_name, "mtd", 3)) {
mount_block_root(root_device_name, root_mountflags); //去该地址的地方去挂接
goto out;
}
ROOT_DEV = name_to_dev_t(root_device_name);
if (strncmp(root_device_name, "/dev/", 5) == 0)
root_device_name += 5;
}
is_floppy = MAJOR(ROOT_DEV) == FLOPPY_MAJOR;
if (initrd_load())
goto out;
if (is_floppy && rd_doload && rd_load_disk(0))
ROOT_DEV = Root_RAM0;
mount_root(); //挂接根文件系统这里最终实现的是 mount_root()函数，实现挂接根文件系统，在这之前我们可以看到还有一些参数需要设置，例如从哪个地址挂接，这个就跟我们要分析的传入的命令行参数有关了，在mount_root()之前我们可以看到saved_root_name[0]就是我们之前保存的参数，然后对该参数判断再执行该参数，所以对别的参数来说肯定也是类型，先对保存的参数做判断，然后再执行，那么我们是如何实现对参数的保存的呢，我们可以搜索saved_root_name，然后可以看到如下代码：
static int __init root_dev_setup(char *line)
{
strlcpy(saved_root_name, line, sizeof(saved_root_name));
return 1;
}
__setup("root=", root_dev_setup);这里实现的就是当遇到root参数时，__setup("root=", root_dev_setup)函数就会去执行root_dev_setup函数，然后这个root_dev_setup(char *line)函数就会保存这个参数到saved_root_name，__setup("root=", root_dev_setup)的实现跟之前proc_info_list结构体和machine_desc结构体一样，__setup("root=", root_dev_setup)肯定也是将该参数放进一个结构体中,来看下__setup的具体实现
#define __setup(str, fn) \ //存在include/linux/init.h
__setup_param(str, fn, fn, 0)
#define __setup_param(str, unique_id, fn, early) \
static char __setup_str_##unique_id[] __initdata = str; \
static struct obs_kernel_param __setup_##unique_id \
__attribute_used__ \
__attribute__((__section__(".init.setup"))) \ //强制段属性
__attribute__((aligned((sizeof(long))))) \
= { __setup_str_##unique_id, fn, early }
——————> __setup_##unique_id = {str,fn,0}通过*(.init.setup)，可以知道这个肯定又是链接脚本中定义的一个段，在链接脚本中搜索有
__setup_start = .;
*(.init.setup)
__setup_end = .;好了这些就是我们root参数的保存，在*(.init.setup)段中定义了一个obs_kernel_param类型的结构体，里面的参数就是{"root=",root_dev_setup,0},但是这里我们只是定义了，还没有执行root_dev_setup函数去保存我们的参数至saved_root_name中，所以搜索__setup_start我们可以来看到是如何调用*(.init.setup)段内的函数，我们可以搜到在start_kernel()中有：
parse_early_param()
do_early_param
从setup_start到setup_end 调用early(1)函数
static int __init do_early_param(char *param, char *val)
{
struct obs_kernel_param *p;
for (p = __setup_start; p < __setup_end; p++) {
if (p->early && strcmp(param, p->str) == 0) {
if (p->setup_func(val) != 0)
printk(KERN_WARNING
"Malformed early option '%s'\n", param);
}
}
/* We accept everything at this stage. */
return 0;
}当early为1的时候才会去调用p->setup_func(val)函数，这里就是root_dev_setup函数，保存root参数
unknown_bootoption
obsolete_checksetup
从setup_start到setup_end 调用非early(0)函数
static int __init obsolete_checksetup(char *line)
{
struct obs_kernel_param *p;
int had_early_param = 0;
p = __setup_start;
do {
int n = strlen(p->str);
if (!strncmp(line, p->str, n)) {
if (p->early) {
/* Already done in parse_early_param?
* (Needs exact match on param part).
* Keep iterating, as we can have early
* params and __setups of same names 8( */
if (line[n] == '\0' || line[n] == '=')
had_early_param = 1;
} else if (!p->setup_func) {
printk(KERN_WARNING "Parameter %s is obsolete,"
" ignored\n", p->str);
return 1;
} else if (p->setup_func(line + n))
return 1;
}当early为0的时候才会去调用p->setup_func函数，这里就是root_dev_setup函数，保存root参数
调用完成后后面再去执行rest_init()函数去挂接根文件系统，此时root参数已经完全保存完毕，在执行prepare_namespace()函数时就可以直接调用saved_root_names数组里面的值了，其他环境参数的实现过程也是大致的过程
mtdblock3分区在代码中已经写死，就跟uboot传给内核的环境参数一样