原创，转载时请注明，谢谢。邮箱：[email protected]，?地址：http://www.cnblogs.com/embedded-tzp

?

墨迹这么久，总算开始内核源代码分析了。

1. 阶段1

阶段1大部分为汇编, 以程序启动到执行到start_kernel函数为第一阶段。

变量与文件的对应关系。

THUMB: src\arch\arm\include\asm\unified.h

head.S的很多定义在src\arch\arm\kernel\head-common.S

struct proc_info_list ：src\arch\arm\include\asm\procinfo.h

PROC_INFO_SZ ： build\include\generated\asm-offsets.h:

proc.info.init ： src\arch\arm\mm\proc-arm920.S

?

首先从从程序入口处开始分析，linux内核下文件多不胜数，那么从哪里开始找到程序入口地址呢？

在【linux】内核源代码下载与阅读: http://www.cnblogs.com/embedded-tzp/p/4443611.html 中有提到vmlinux.lds，该文件指导arm-linux-ld如何工作，该文件在src\arch\arm\kernel\vmlinux.lds。该文件开始有

OUTPUT_ARCH(arm)

ENTRY(stext)

jiffies = jiffies_64;

SECTIONS

{

…………..

. = 0xC0000000 + 0x00008000;

?

可见程序入口为段 stext，代码开始地址0xC0000000 + 0x00008000，即3G + 0x8000，使用source insight的search→search files，找到head.S (src\arch\arm\kernel):ENTRY(stext)，点击定位到该处。往下看，有

mrc????p15, 0, r9, c0, c0????????@ get processor id，协处理器操作，详细见ARM920T_TRM1_S.pdf

????bl????__lookup_processor_type????????@ r5=procinfo r9=cpuid

上述r9的内容为0x41009200，见下图，详细见ARM920T_TRM1_S.pdf。

入口找到了，接下来就好办了，只要有点arm汇编基础，读懂代码是没有问题的，本来想自己慢慢写的，但是发现网上别人已经写的好好的了，就没有必要重新写了。详细见：Linux内核启动分析之 __lookup_processor_type函数:http://blog.sina.com.cn/s/blog_63ac1cef0100vbcj.html 。

解释下为什么 adr获取的是实际运行的物理地址：

__lookup_processor_type: ????adr????r3, __lookup_processor_type_data

????????mov r0, #1

__lookup_processor_type_data: .long????

如上，adr是将当前PC值加一个偏移，得到目标地址，假如程序运行到上述第一条语句时：PC = 16, 因为 __lookup_processor_type_data与其相差8个字节的偏移，所以得到r3 = PC + 8 = 24; 而因为此时程序是运行的，PC代表的就是物理地址，所以adr获取的也就是物理地址了(严格来说这是不对的，因为PC是预取的，但是为了说明问题，不考虑预取功能，不然越说越复杂了)

?

此处对linux的adr计算真实物理地址讨论下，挺有意思的。Arm本来有三种地址，而此时未开启mmu，有MVA = VA(虚拟地址) = PA(物理地址).

要讨论这，就不得不提下内存模型。内存有两个基本属性，地址 + 内容。

围绕地址+内容，衍生了很多东西。 如下表：

编译链接后各变量有其固定的地址，即虚拟地址，运行时变量也有自己的地址，两变量不一定一致。见下图，图中的地址是假定的，实际不一定如此：

?

上图两个内存里的内容必然是一致的，唯一的差别就在于地址。当运行到adr r3, __lookup_processor_type_data时，获得的是运行的地址r3 = 0x8c, 而ldmia????r3, {r4 - r6} 是将0x8c, 0x90, 0x94地址里的内容加载到r4,r5, r6去，因此等效于将0xc000808c, 0x c0008090, 0xc0008094地址里的内容加载到r4,r5, r6去, 0xc000808c地址的内存里面的内容就是他的地址，为0xc000808c。

因此上面r3= 0x8c为实际的物理地址，而0x8c对应的虚拟地址为0xc000808c。

根据PA1 – VA1 = PA2 – VA2 = 0x8c - 0xc000808c, 即PA – VA值确定了，编译后VA的值也确定了，所以可以反推所有的运行时刻代码所在的物理地址。

?

?

src\arch\arm\kernel\head.S: add????pc, r10, #PROCINFO_INITFUNC

跳到src\arch\arm\mm\proc-arm920.S： 执行__arm920_setup

src\arch\arm有\kernel\head-common.S：b start_kernel

进入阶段2：

src\init\main.c: asmlinkage void __init start_kernel(void)

1. 阶段2

start_kernel: 第二阶段启动入口

?

src\include\linux\init.h： __init

后面大部分都能够在source insight中查到

• 检测机器（board）：setup_arch→setup_machine_tags，

.arch.info.init：在MACHINE_START中定义，在具体文件mach-mini2440.c中

__arch_info_begin：vmlinux.lds

1. 解析atags标记列表

setup_arch→setup_machine_tags→parse_tags

1. U-BOOT参数处理

parse_tags： 标记列表处理

src\arch\arm\kernel\vmlinux.lds: __tagtable_begin→ #define __tag __used __attribute__((__section__(".taglist.init")))→ __tagtable(ATAG_CORE, parse_tag_core);

src\arch\arm\kernel\atags_parse.c

?

命令行bootargs处理:

start_kernel→parse_early_param→parse_early_options→parse_args→parse_one→do_early_param

__setup_start在vmlinux.lds中，该段是通过__setup宏定义的__setup("console=", console_setup);

?

Console: start_kernel→console_init 执行由console_initcall宏定义的函数，包括console_setup，s3c24xx_serial_console_init→ register_console(&s3c24xx_serial_console)，s3c24xx_serial_console.name = "ttySAC", 这就是为什么要用ttySAC的原因.