{var%20f='http://v.t.sina.com.cn/share/share.php?appkey=1515056452',u=z||d.location,p=['&url=',e(u),'&title=',e(t||d.title),'&source=',e(r),'&sourceUrl=',e(l),'&content=',c||'gb2312','&pic=',e(p||'')].join('');function%20a(){if(!window.open([f,p].join(''),'mb',['toolbar=0,status=0,resizable=1,width=440,height=430,left=',(s.width-440)/2,',top=',(s.height-430)/2].join('')))u.href=[f,p].join('');};if(/Firefox/.test(navigator.userAgent))setTimeout(a,0);else%20a();})(screen,document,encodeURIComponent,'','','https://www.xiaopingtou.cn//data/attach/topic/topicKPo7gB.jpg', '推荐 ddgg888 的文章《arm linux kernel 从入口到start_kernel 的代码分析》','https://www.xiaopingtou.net/article-69711.html','页面编码gb2312|utf-8默认gb2312'));){kind=link}
参考资料：
《ARM体系结构与编程》
《嵌入式Linux应用开发完全手册》
Linux_Memory_Address_Mapping
http://www.chinaunix.net/old_jh/4/1021226.html
更多文档参见：http://pan.baidu.com/s/1mg3DbHQ
本文针对arm linux, 从kernel的第一条指令开始分析,一直分析到进入start_kernel()函数.
我们当前以linux-2.6.19内核版本作为范例来分析,本文中所有的代码,前面都会加上行号以便于和源码进行对照,
例:
在文件init/main.c中:
00478: asmlinkage void __init start_kernel(void)
前面的"00478:" 表示478行,冒号后面的内容就是源码了.
在分析代码的过程中,我们使用缩进来表示各个代码的调用层次.
由于启动部分有一些代码是平台特定的,虽然大部分的平台所实现的功能都比较类似,但是为了更好的对code进行说明,对于平台相关的代码,我们选择at91(ARM926EJS)平台进行分析.
另外,本文是以uncompressed kernel开始讲解的.对于内核解压缩部分的code,在 arch/arm/boot/compressed中,本文不做讨论.
关于boot loader的内容,本文就不做过多介绍.
这里只讨论进入到linux kernel的时候的一些限制条件,这一般是boot loader在最后跳转到kernel之前要完成的:
1. CPU必须处于SVC(supervisor)模式,并且IRQ和FIQ中断都是禁止的;
2. MMU(内存管理单元)必须是关闭的, 此时虚拟地址对物理地址;
3. 数据cache(Data cache)必须是关闭的
4. 指令cache(Instruction cache)可以是打开的,也可以是关闭的,这个没有强制要求;
5. CPU 通用寄存器0 (r0)必须是 0;
6. CPU 通用寄存器1 (r1)必须是 ARM Linux machine type (关于machine type, 我们后面会有讲解)
7. CPU 通用寄存器2 (r2) 必须是 kernel parameter list 的物理地址(parameter list 是由boot loader传递给kernel,用来描述设备信息属性的列表,详细内容可参考"Booting ARM Linux"文档).
宏 位置 默认值 说明
KERNEL_RAM_ADDR arch/arm/kernel/head.S +26 0xc0008000 kernel在RAM中的的虚拟地址
PAGE_OFFSET include/asm-arm/memeory.h +50 0xc0000000 内核空间的起始虚拟地址
TEXT_OFFSET arch/arm/Makefile +137 0x00008000 内核相对于存储空间的偏移
TEXTADDR arch/arm/kernel/head.S +49 0xc0008000 kernel的起始虚拟地址
PHYS_OFFSET include/asm-arm/arch-xxx/memory.h 平台相关 RAM的起始物理地址
内核的入口是stext,这是在arch/arm/kernel/vmlinux.lds.S中定义的:
00011: ENTRY(stext)
对于vmlinux.lds.S,这是ld script文件,此文件的格式和汇编及C程序都不同,本文不对ld script作过多的介绍,只对内核中用到的内容进行讲解,关于ld的详细内容可以参考ld.info
这里的ENTRY(stext) 表示程序的入口是在符号stext.
而符号stext是在arch/arm/kernel/head.S中定义的:
下面我们将arm linux boot的主要代码列出来进行一个概括的介绍,然后,我们会逐个的进行详细的讲解.
在arch/arm/kernel/head.S中 72 - 94 行,是arm linux boot的主代码:
00072: ENTRY(stext)
00073: msr cpsr_c, #PSR_F_BIT | PSR_I_BIT | SVC_MODE @ ensure svc mode
00074: @ and irqs disabled
00075: mrc p15, 0, r9, c0, c0 @ get processor id
00076: bl __lookup_processor_type @ r5=procinfo r9=cpuid
00077: movs r10, r5 @ invalid processor (r5=0)?
00078: beq __error_p @ yes, error 'p'
00079: bl __lookup_machine_type @ r5=machinfo
00080: movs r8, r5 @ invalid machine (r5=0)?
00081: beq __error_a @ yes, error 'a'
00082: bl __create_page_tables
00083:
00084: /*
00085: * The following calls CPU specific code in a position independent
00086: * manner. See arch/arm/mm/proc-*.S for details. r10 = base of
00087: * xxx_proc_info structure selected by __lookup_machine_type
00088: * above. On return, the CPU will be ready for the MMU to be
00089: * turned on, and r0 will hold the CPU control register value.
00090: */
00091: ldr r13, __switch_data @ address to jump to after
00092: @ mmu has been enabled
00093: adr lr, __enable_mmu @ return (PIC) address
00094: add pc, r10, #PROCINFO_INITFUNC
其中,73行是确保kernel运行在SVC模式下,并且IRQ和FIRQ中断已经关闭,这样做是很谨慎的.
arm linux boot的主线可以概括为以下几个步骤:
1. 确定 processor type (75 - 78行)
2. 确定 machine type (79 - 81行)
3. 创建页表 (82行)
4. 调用平台特定的__cpu_flush函数 (在struct proc_info_list中) (94 行)
5. 开启mmu (93行)
6. 切换数据 (91行)
最终跳转到start_kernel (在__switch_data的结束的时候,调用了 b start_kernel)
下面,我们按照这个主线,逐步的分析Code.
00075: mrc p15, 0, r9, c0, c0 @ get processor id
00076: bl __lookup_processor_type @ r5=procinfo r9=cpuid
00077: movs r10, r5 @ invalid processor (r5=0)?
00078: beq __error_p @ yes, error 'p'
75行: 通过cp15协处理器的c0寄存器来获得processor id的指令. 关于cp15的详细内容可参考相关的arm手册
76行: 跳转到__lookup_processor_type.在__lookup_processor_type中,会把processor type 存储在r5中
77,78行: 判断r5中的processor type是否是0,如果是0,说明是无效的processor type,跳转到__error_p(出错)
__lookup_processor_type 函数主要是根据从cpu中获得的processor id和系统中的proc_info进行匹配,将匹配到的proc_info_list的基地址存到r5中, 0表示没有找到对应的processor type.
下面我们分析__lookup_processor_type函数
arch/arm/kernel/head-common.S中:
00145: .type __lookup_processor_type, %function
00146: __lookup_processor_type:
00147: adr r3, 3f
00148: ldmda r3, {r5 - r7}
00149: sub r3, r3, r7 @ get offset between virt&phys
00150: add r5, r5, r3 @ convert virt addresses to
00151: add r6, r6, r3 @ physical address space
00152: 1: ldmia r5, {r3, r4} @ value, mask
00153: and r4, r4, r9 @ mask wanted bits
00154: teq r3, r4
00155: beq 2f
00156: add r5, r5, #PROC_INFO_SZ @ sizeof(proc_info_list)
00157: cmp r5, r6
00158: blo 1b
00159: mov r5, #0 @ unknown processor
00160: 2: mov pc, lr
00161:
00162: /*
00163: * This provides a C-API version of the above function.
00164: */
00165: ENTRY(lookup_processor_type)
00166: stmfd sp!, {r4 - r7, r9, lr}
00167: mov r9, r0
00168: bl __lookup_processor_type
00169: mov r0, r5
00170: ldmfd sp!, {r4 - r7, r9, pc}
00171:
00172: /*
00173: * Look in include/asm-arm/procinfo.h and arch/arm/kernel/arch.[ch] for
00174: * more information about the __proc_info and __arch_info structures.
00175: */
00176: .long __proc_info_begin
00177: .long __proc_info_end
00178: 3: .long .
00179: .long __arch_info_begin
00180: .long __arch_info_end
145, 146行是函数定义
147行: 取地址指令,这里的3f是向前symbol名称是3的位置,即第178行,将该地址存入r3.
这里需要注意的是,adr指令取址,获得的是基于pc的一个地址,要格外注意,这个地址是3f处的"运行时地址", 由于此时MMU还没有打开,也可以理解成物理地址(实地址).(详细内容可参考arm指令手册)
148行: 因为r3中的地址是178行的位置的地址,因而执行完后: (ldmda表示栈指针递减，即r3递减，内存的地址编号较大的对应寄存器编号较大的)
r5存的是176行符号 __proc_info_begin的地址;
r6存的是177行符号 __proc_info_end的地址;
r7存的是3f处的地址.
这里需要注意链接地址和运行时地址的区别. r3存储的是运行时地址(物理地址),而r7中存储的是链接地址(虚拟地址).
__proc_info_begin和__proc_info_end是在arch/arm/kernel/vmlinux.lds.S中:
00031: __proc_info_begin = .;
00032: *(.proc.info.init)
00033: __proc_info_end = .;
这里是声明了两个变量:__proc_info_begin 和 __proc_info_end,其中等号后面的"."是location counter(详细内容请参考ld.info)
这三行的意思是: __proc_info_begin 的位置上,放置所有文件中的 ".proc.info.init" 段的内容,然后紧接着是 __proc_info_end 的位置.
kernel 使用struct proc_info_list来描述processor type.
在 include/asm-arm/procinfo.h 中:
00029: struct proc_info_list {
00030: unsigned int cpu_val;
00031: unsigned int cpu_mask;
00032: unsigned long __cpu_mm_mmu_flags; /* used by head.S */
00033: unsigned long __cpu_io_mmu_flags; /* used by head.S */
00034: unsigned long __cpu_flush; /* used by head.S */
00035: const char *arch_name;
00036: const char *elf_name;
00037: unsigned int elf_hwcap;
00038: const char *cpu_name;
00039: struct processor *proc;
00040: struct cpu_tlb_fns *tlb;
00041: struct cpu_user_fns *user;
00042: struct cpu_cache_fns *cache;
00043: };
我们当前以at91为例,其processor是926的.
在arch/arm/mm/proc-arm926.S 中:
00464: .section ".proc.info.init", #alloc, #execinstr
00465:
00466: .type __arm926_proc_info,#object
00467: __arm926_proc_info:
00468: .long 0x41069260 @ ARM926EJ-S (v5TEJ)
00469: .long 0xff0ffff0
00470: .long PMD_TYPE_SECT |
00471: PMD_SECT_BUFFERABLE |
00472: PMD_SECT_CACHEABLE |
00473: PMD_BIT4 |
00474: PMD_SECT_AP_WRITE |
00475: PMD_SECT_AP_READ
00476: .long PMD_TYPE_SECT |
00477: PMD_BIT4 |
00478: PMD_SECT_AP_WRITE |
00479: PMD_SECT_AP_READ
00480: b __arm926_setup
00481: .long cpu_arch_name
00482: .long cpu_elf_name
00483: .long HWCAP_SWP|HWCAP_HALF|HWCAP_THUMB|HWCAP_FAST_MULT|HWCAP_VFP|HWCAP_EDSP|HWCAP_JAVA
00484: .long cpu_arm926_name
00485: .long arm926_processor_functions
00486: .long v4wbi_tlb_fns
00487: .long v4wb_user_fns
00488: .long arm926_cache_fns
00489: .size __arm926_proc_info, . - __arm926_proc_info
从464行,我们可以看到 __arm926_proc_info 被放到了".proc.info.init"段中.
对照struct proc_info_list,我们可以看到 __cpu_flush的定义是在480行,即__arm926_setup.(我们将在"4. 调用平台特定的__cpu_flush函数"一节中详细分析这部分的内容.)
从以上的内容我们可以看出: r5中的__proc_info_begin是proc_info_list的起始地址, r6中的__proc_info_end是proc_info_list的结束地址.
149行: 从上面的分析我们可以知道r3中存储的是3f处的物理地址,而r7存储的是3f处的虚拟地址,这一行是计算当前程序运行的物理地址和虚拟地址的差值,将其保存到r3中.
150行: 将r5存储的虚拟地址(__proc_info_begin)转换成物理地址
151行: 将r6存储的虚拟地址(__proc_info_end)转换成物理地址
152行: 对照struct proc_info_list,可以得知,这句是将当前proc_info的cpu_val和cpu_mask分别存r3, r4中
153行: r9中存储了processor id(arch/arm/kernel/head.S中的75行),与r4的cpu_mask进行逻辑与操作,得到我们需要的值
154行: 将153行中得到的值与r3中的cpu_val进行比较
155行: 如果相等,说明我们找到了对应的processor type,跳到160行,返回
156行: (如果不相等) , 将r5指向下一个proc_info,
157行: 和r6比较,检查是否到了__proc_info_end.
158行: 如果没有到__proc_info_end,表明还有proc_info配置,返回152行继续查找
159行: 执行到这里,说明所有的proc_info都匹配过了,但是没有找到匹配的,将r5设置成0(unknown processor)
160行: 返回
00079: bl __lookup_machine_type @ r5=machinfo
00080: movs r8, r5 @ invalid machine (r5=0)?
00081: beq __error_a @ yes, error 'a'
79行: 跳转到__lookup_machine_type函数,在__lookup_machine_type中,会把struct machine_desc的基地址(machine type)存储在r5中
80,81行: 将r5中的 machine_desc的基地址存储到r8中,并判断r5是否是0,如果是0,说明是无效的machine type,跳转到__error_a(出错)
__lookup_machine_type 函数
下面我们分析__lookup_machine_type 函数:
arch/arm/kernel/head-common.S中:
00176: .long __proc_info_begin
00177: .long __proc_info_end
00178: 3: .long .
00179: .long __arch_info_begin
00180: .long __arch_info_end
00181:
00182: /*
00183: * Lookup machine architecture in the linker-build list of architectures.
00184: * Note that we can't use the absolute addresses for the __arch_info
00185: * lists since we aren't running with the MMU on (and therefore, we are
00186: * not in the correct address space). We have to calculate the offset.
00187: *
00188: * r1 = machine architecture number
00189: * Returns:
00190: * r3, r4, r6 corrupted
00191: * r5 = mach_info pointer in physical address space
00192: */
00193: .type __lookup_machine_type, %function
00194: __lookup_machine_type:
00195: adr r3, 3b
00196: ldmia r3, {r4, r5, r6}
00197: sub r3, r3, r4 @ get offset between virt&phys
00198: add r5, r5, r3 @ convert virt addresses to
00199: add r6, r6, r3 @ physical address space
00200: 1: ldr r3, [r5, #MACHINFO_TYPE] @ get machine type
00201: teq r3, r1 @ matches loader number?
00202: beq 2f @ found
00203: add r5, r5, #SIZEOF_MACHINE_DESC @ next machine_desc
00204: cmp r5, r6
00205: blo 1b
00206: mov r5, #0 @ unknown machine
00207: 2: mov pc, lr
193, 194行: 函数声明
195行: 取地址指令,这里的3b是向后symbol名称是3的位置,即第178行,将该地址存入r3.
和上面我们对__lookup_processor_type 函数的分析相同,r3中存放的是3b处物理地址.
196行: r3是3b处的地址,因而执行完后:（ldmia 表示栈是递增的，即r3递增，低内存地址对应小号寄存器）
r4存的是 3b处的地址
r5存的是__arch_info_begin 的地址
r6存的是__arch_info_end 的地址
__arch_info_begin 和 __arch_info_end是在 arch/arm/kernel/vmlinux.lds.S中:
00034: __arch_info_begin = .;
00035: *(.arch.info.init)
00036: __arch_info_end = .;
这里是声明了两个变量:__arch_info_begin 和 __arch_info_end,其中等号后面的"."是location counter(详细内容请参考ld.info)
这三行的意思是: __arch_info_begin 的位置上,放置所有文件中的 ".arch.info.init" 段的内容,然后紧接着是 __arch_info_end 的位置.
kernel 使用struct machine_desc 来描述 machine type.
在 include/asm-arm/mach/arch.h 中:
00017: struct machine_desc {
00018: /*
00019: * Note! The first four elements are used
00020: * by assembler code in head-armv.S
00021: */
00022: unsigned int nr; /* architecture number */
00023: unsigned int phys_io; /* start of physical io */
00024: unsigned int io_pg_offst; /* byte offset for io
00025: * page tabe entry */
00026:
00027: const char *name; /* architecture name */
00028: unsigned long boot_params; /* tagged list */
00029:
00030: unsigned int video_start; /* start of video RAM */
00031: unsigned int video_end; /* end of video RAM */
00032:
00033: unsigned int reserve_lp0 :1; /* never has lp0 */
00034: unsigned int reserve_lp1 :1; /* never has lp1 */
00035: unsigned int reserve_lp2 :1; /* never has lp2 */
00036: unsigned int soft_reboot :1; /* soft reboot */
00037: void (*fixup)(struct machine_desc *,
00038: struct tag *, char **,
00039: struct meminfo *);
00040: void (*map_io)(void);/* IO mapping function */
00041: void (*init_irq)(void);
00042: struct sys_timer *timer; /* system tick timer */
00043: void (*init_machine)(void);
00044: };
00045:
00046: /*
00047: * Set of macros to define architecture features. This is built into
00048: * a table by the linker.
00049: */
00050: #define MACHINE_START(_type,_name)
00051: static const struct machine_desc __mach_desc_##_type
00052: __attribute_used__
00053: __attribute__((__section__(".arch.info.init"
)) = {
00054: .nr = MACH_TYPE_##_type,
00055: .name = _name,
00056:
00057: #define MACHINE_END
00058: };
内核中,一般使用宏MACHINE_START来定义machine type.
对于at91, 在 arch/arm/mach-at91rm9200/board-ek.c 中:
00137: MACHINE_START(AT91RM9200EK, "Atmel AT91RM9200-EK"![icon_wink[1]](https://images0.cnblogs.com/blog/480488/201403/291644393751111.gif "icon_wink[1]")
00138: /* Maintainer: SAN People/Atmel */
00139: .phys_io = AT91_BASE_SYS,
00140: .io_pg_offst = (AT91_VA_BASE_SYS >> 1
& 0xfffc,
00141: .boot_params = AT91_SDRAM_BASE + 0x100,
00142: .timer = &at91rm9200_timer,
00143: .map_io = ek_map_io,
00144: .init_irq = ek_init_irq,
00145: .init_machine = ek_board_init,
00146: MACHINE_END
197行: r3中存储的是3b处的物理地址,而r4中存储的是3b处的虚拟地址,这里计算处物理地址和虚拟地址的差值,保存到r3中
198行: 将r5存储的虚拟地址(__arch_info_begin)转换成物理地址
199行: 将r6存储的虚拟地址(__arch_info_end)转换成物理地址
200行: MACHINFO_TYPE 在 arch/arm/kernel/asm-offset.c 101行定义, 这里是取 struct machine_desc中的nr(architecture number) 到r3中
201行: 将r3中取到的machine type 和 r1中的 machine type(见前面的"启动条件"![icon_wink[2]](https://images0.cnblogs.com/blog/480488/201403/291644406563152.gif "icon_wink[2]")
进行比较
202行: 如果相同,说明找到了对应的machine type,跳转到207行的2f处,此时r5中存储了对应的struct machine_desc的基地址
203行: (不相同), 取下一个machine_desc的地址
204行: 和r6进行比较,检查是否到了__arch_info_end.
205行: 如果不相同,说明还有machine_desc,返回200行继续查找.
206行: 执行到这里,说明所有的machind_desc都查找完了,并且没有找到匹配的, 将r5设置成0(unknown machine).
207行: 返回
此时,一些特定寄存器的值如下所示:
r8 = machine info (struct machine_desc的基地址)
r9 = cpu id (通过cp15协处理器获得的cpu id)
r10 = procinfo (struct proc_info_list的基地址)
创建页表是通过函数 __create_page_tables 来实现的.
这里,我们使用的是arm的L1主页表,L1主页表也称为段页表(section page table)
L1 主页表将4 GB 的地址空间分成若干个1 MB的段(section),因此L1页表包含4096个页表项(section entry). 每个页表项是32 bits(4 bytes)
因而L1主页表占用 4096 *4 = 16k的内存空间.
对于ARM926,其L1 section entry的格式为
可参考arm926EJS TRM):
(一级描述符的格式 可以参考《ARM体系结构与编程》P180)
下面我们来分析 __create_page_tables 函数:
在 arch/arm/kernel/head.S 中:
00206: .type __create_page_tables, %function
00207: __create_page_tables:
00208: pgtbl r4 @ page table address
00209:
00210: /*
00211: * Clear the 16K level 1 swapper page table
00212: */
00213: mov r0, r4
00214: mov r3, #0
00215: add r6, r0, #0x4000
00216: 1: str r3, [r0], #4
00217: str r3, [r0], #4
00218: str r3, [r0], #4
00219: str r3, [r0], #4
00220: teq r0, r6
00221: bne 1b
00222:
00223: ldr r7, [r10, #PROCINFO_MM_MMUFLAGS] @ mm_mmuflags
00224:
00225: /*
00226: * Create identity mapping for first MB of kernel to
00227: * cater for the MMU enable. This identity mapping
00228: * will be removed by paging_init(). We use our current program
00229: * counter to determine corresponding section base address.
00230: */
00231: mov r6, pc, lsr #20 @ start of kernel section
00232: orr r3, r7, r6, lsl #20 @ flags + kernel base
00233: str r3, [r4, r6, lsl #2] @ identity mapping
00234:
00235: /*
00236: * Now setup the pagetables for our kernel direct
00237: * mapped region.
00238: */
00239: add r0, r4, #(TEXTADDR & 0xff000000) >> 18 @ start of kernel
00240: str r3, [r0, #(TEXTADDR & 0x00f00000) >> 18]!
00241:
00242: ldr r6, =(_end - PAGE_OFFSET - 1) @ r6 = number of sections
00243: mov r6, r6, lsr #20 @ needed for kernel minus 1
00244:
00245: 1: add r3, r3, #1 << 20
00246: str r3, [r0, #4]!
00247: subs r6, r6, #1
00248: bgt 1b
00249:
00250: /*
00251: * Then map first 1MB of ram in case it contains our boot params.
00252: */
00253: add r0, r4, #PAGE_OFFSET >> 18
00254: orr r6, r7, #PHYS_OFFSET
00255: str r6, [r0]
...
00314: mov pc, lr
00315: .ltorg
206, 207行: 函数声明
208行: 通过宏 pgtbl 将r4设置成页表的基地址(物理地址)
宏pgtbl 在 arch/arm/kernel/head.S 中:
00042: .macro pgtbl, rd
00043: ldr d, =(__virt_to_phys(KERNEL_RAM_ADDR - 0x4000))
00044: .endm
可以看到,页表是位于 KERNEL_RAM_ADDR 下面 16k 的位置
宏 __virt_to_phys 是在incude/asm-arm/memory.h 中:
00125: #ifndef __virt_to_phys
00126: #define __virt_to_phys(x) ((x) - PAGE_OFFSET + PHYS_OFFSET)
00127: #define __phys_to_virt(x) ((x) - PHYS_OFFSET + PAGE_OFFSET)
00128: #endif
下面从213行 - 221行, 是将这16k 的页表清0.
213行: r0 = r4, 将页表基地址存在r0中
214行: 将 r3 置成0
215行: r6 = 页表基地址 + 16k, 可以看到这是页表的尾地址
216 - 221 行: 循环,从 r0 到 r6 将这16k页表用0填充.
223行: 获得proc_info_list的__cpu_mm_mmu_flags的值,并存储到 r7中. (宏PROCINFO_MM_MMUFLAGS是在arch/arm/kernel/asm-offset.c中定义，值为8)（可以参考《嵌入式Linux应用完全开发手册》P118）（r7的值就是设置这个段描述符的权限、域字段，） 在arch/arm/mm/proc-arm926.S 中: 00464: .section ".proc.info.init", #alloc, #execinstr 00465: 00466: .type __arm926_proc_info,#object 00467: __arm926_proc_info: 00468: .long 0x41069260 @ ARM926EJ-S (v5TEJ) 00469: .long 0xff0ffff0 00470: .long PMD_TYPE_SECT | 00471: PMD_SECT_BUFFERABLE | 00472: PMD_SECT_CACHEABLE | 00473: PMD_BIT4 | 00474: PMD_SECT_AP_WRITE | 00475: PMD_SECT_AP_READ 00476: .long PMD_TYPE_SECT | 00477: PMD_BIT4 | 00478: PMD_SECT_AP_WRITE | 00479: PMD_SECT_AP_READ 00480: b __arm926_setup 00481: .long cpu_arch_name 00482: .long cpu_elf_name 00483: .long HWCAP_SWP|HWCAP_HALF|HWCAP_THUMB|HWCAP_FAST_MULT|HWCAP_VFP|HWCAP_EDSP|HWCAP_JAVA 00484: .long cpu_arm926_name 00485: .long arm926_processor_functions 00486: .long v4wbi_tlb_fns 00487: .long v4wb_user_fns 00488: .long arm926_cache_fns 00489: .size __arm926_proc_info, . - __arm926_proc_info
231行: 通过pc值的高12位(右移20位),得到kernel的section,并存储到r6中.因为当前是通过运行时地址得到的kernel的section,因而是物理地址.
232行: r3 = r7 | (r6 << 20); flags + kernel base,得到页表中需要设置的值.
233行: 设置页表: mem[r4 + r6 * 4] = r3
这里,因为页表的每一项是32 bits(4 bytes),所以要乘以4(<<2).
上面这三行,设置了kernel的第一个section(物理地址所在的page entry)的页表项
239, 240行: TEXTADDR是内核的起始虚拟地址(0xc0008000), 这两行是设置kernel起始虚拟地址的页表项(注意,这里设置的页表项和上面的231 - 233行设置的页表项是不同的 )
执行完后,r0指向kernel的第2个section的虚拟地址所在的页表项.
/* TODO: 这两行的code很奇怪,为什么要先取TEXTADDR的高8位(Bit[31:24])0xff000000,然后再取后面的8位 (Bit[23:20])0x00f00000*/
242行: 这一行计算kernel镜像的大小(bytes).
_end 是在vmlinux.lds.S中162行定义的,标记kernel的结束位置(虚拟地址):
00158 .bss : {
00159 __bss_start = .; /* BSS */
00160 *(.bss)
00161 *(COMMON)
00162 _end = .;
00163 }
kernel的size = _end - PAGE_OFFSET -1, 这里 减1的原因是因为 _end 是 location counter,它的地址是kernel镜像后面的一个byte的地址.
243行: 地址右移20位,计算出kernel有多少sections（也就是有多少兆，因为段描述符每个可以映射1MiB的虚拟地址）,并将结果存到r6中
245 - 248行: 这几行用来填充kernel所有section虚拟地址对应的页表项.
253行: 将r0设置为RAM第一兆虚拟地址的页表项地址(page entry)
254行: r7中存储的是mmu flags, 逻辑或上RAM的起始物理地址,得到RAM第一个MB页表项的值.
255行: 设置RAM的第一个MB虚拟地址的页表.
上面这三行是用来设置RAM中第一兆虚拟地址的页表. 之所以要设置这个页表项的原因是RAM的第一兆内存中可能存储着boot params.
这样,kernel所需要的基本的页表我们都设置完了, 如下图所示:
下面是linux-2.6.30.4中的arch/arm/kernel/head.S，代码有一些不同，但是效果一样：
1: /*
2: * linux/arch/arm/kernel/head.S
3: *
4: * Copyright (C) 1994-2002 Russell King
5: * Copyright (c) 2003 ARM Limited
6: * All Rights Reserved
7: *
8: * This program is free software; you can redistribute it and/or modify
9: * it under the terms of the GNU General Public License version 2 as
10: * published by the Free Software Foundation.
11: *
12: * Kernel startup code for all 32-bit CPUs
13: */
14: #include
15: #include
16:
17: #include <asm/assembler.h>
18: #include <asm/domain.h>
19: #include <asm/ptrace.h>
20: #include <asm/asm-offsets.h>
21: #include <asm/memory.h>
22: #include <asm/thread_info.h>
23: #include <asm/system.h>
24:
25: #if (PHYS_OFFSET & 0x001fffff)
26: #error "PHYS_OFFSET must be at an even 2MiB boundary!"
27: #endif
28:
29: #define KERNEL_RAM_VADDR (PAGE_OFFSET + TEXT_OFFSET)
30: #define KERNEL_RAM_PADDR (PHYS_OFFSET + TEXT_OFFSET)
31:
32:
33: /*
34: * swapper_pg_dir is the virtual address of the initial page table.
35: * We place the page tables 16K below KERNEL_RAM_VADDR. Therefore, we must
36: * make sure that KERNEL_RAM_VADDR is correctly set. Currently, we expect
37: * the least significant 16 bits to be 0x8000, but we could probably
38: * relax this restriction to KERNEL_RAM_VADDR >= PAGE_OFFSET + 0x4000.
39: */
40: #if (KERNEL_RAM_VADDR & 0xffff) != 0x8000
41: #error KERNEL_RAM_VADDR must start at 0xXXXX8000
42: #endif
43:
44: .globl swapper_pg_dir
45: .equ swapper_pg_dir, KERNEL_RAM_VADDR - 0x4000
46:
47: .macro pgtbl, rd
48: ldr
d, =(KERNEL_RAM_PADDR - 0x4000)
49: .endm
50:
51: #ifdef CONFIG_XIP_KERNEL
52: #define KERNEL_START XIP_VIRT_ADDR(CONFIG_XIP_PHYS_ADDR)
53: #define KERNEL_END _edata_loc
54: #else
55: #define KERNEL_START KERNEL_RAM_VADDR
56: #define KERNEL_END _end
57: #endif
58:
59: /*
60: * Kernel startup entry point.
61: * ---------------------------
62: *
63: * This is normally called from the decompressor code. The requirements
64: * are: MMU = off, D-cache = off, I-cache = dont care, r0 = 0,
65: * r1 = machine nr, r2 = atags pointer.
66: *
67: * This code is mostly position independent, so if you link the kernel at
68: * 0xc0008000, you call this at __pa(0xc0008000).
69: *
70: * See linux/arch/arm/tools/mach-types for the complete list of machine
71: * numbers for r1.
72: *
73: * We're trying to keep crap to a minimum; DO NOT add any machine specific
74: * crap here - that's what the boot loader (or in extreme, well justified
75: * circumstances, zImage) is for.
76: */
77: .section ".text.head", "ax"
78: ENTRY(stext)
79: msr cpsr_c, #PSR_F_BIT | PSR_I_BIT | SVC_MODE @ ensure svc mode
80: @ and irqs disabled
81: mrc p15, 0, r9, c0, c0 @ get processor id
82: bl __lookup_processor_type @ r5=procinfo r9=cpuid
83: movs r10, r5 @ invalid processor (r5=0)?
84: beq __error_p @ yes, error 'p'
85: bl __lookup_machine_type @ r5=machinfo
86: movs r8, r5 @ invalid machine (r5=0)?
87: beq __error_a @ yes, error 'a'
88: bl __vet_atags
89: bl __create_page_tables
90:
91: /*
92: * The following calls CPU specific code in a position independent
93: * manner. See arch/arm/mm/proc-*.S for details. r10 = base of
94: * xxx_proc_info structure selected by __lookup_machine_type
95: * above. On return, the CPU will be ready for the MMU to be
96: * turned on, and r0 will hold the CPU control register value.
97: */
98: ldr r13, __switch_data @ address to jump to after
99: @ mmu has been enabled
100: adr lr, __enable_mmu @ return (PIC) address
101: add pc, r10, #PROCINFO_INITFUNC
102: ENDPROC(stext)
103:
104: #if defined(CONFIG_SMP)
105: ENTRY(secondary_startup)
106: /*
107: * Common entry point for secondary CPUs.
108: *
109: * Ensure that we're in SVC mode, and IRQs are disabled. Lookup
110: * the processor type - there is no need to check the machine type
111: * as it has already been validated by the primary processor.
112: */
113: msr cpsr_c, #PSR_F_BIT | PSR_I_BIT | SVC_MODE
114: mrc p15, 0, r9, c0, c0 @ get processor id
115: bl __lookup_processor_type
116: movs r10, r5 @ invalid processor?
117: moveq r0, #'p' @ yes, error 'p'
118: beq __error
119:
120: /*
121: * Use the page tables supplied from __cpu_up.
122: */
123: adr r4, __secondary_data
124: ldmia r4, {r5, r7, r13} @ address to jump to after
125: sub r4, r4, r5 @ mmu has been enabled
126: ldr r4, [r7, r4] @ get secondary_data.pgdir
127: adr lr, __enable_mmu @ return address
128: add pc, r10, #PROCINFO_INITFUNC @ initialise processor
129: @ (return control reg)
130: ENDPROC(secondary_startup)
131:
132: /*
133: * r6 = &secondary_data
134: */
135: ENTRY(__secondary_switched)
136: ldr sp, [r7, #4] @ get secondary_data.stack
137: mov fp, #0
138: b secondary_start_kernel
139: ENDPROC(__secondary_switched)
140:
141: .type __secondary_data, %object
142: __secondary_data:
143: .long .
144: .long secondary_data
145: .long __secondary_switched
146: #endif /* defined(CONFIG_SMP) */
147:
148:
149:
150: /*
151: * Setup common bits before finally enabling the MMU. Essentially
我们当前以linux-2.6.19内核版本作为范例来分析,本文中所有的代码,前面都会加上行号以便于和源码进行对照,
例:
在文件init/main.c中:
00478: asmlinkage void __init start_kernel(void)
前面的"00478:" 表示478行,冒号后面的内容就是源码了.
在分析代码的过程中,我们使用缩进来表示各个代码的调用层次.
由于启动部分有一些代码是平台特定的,虽然大部分的平台所实现的功能都比较类似,但是为了更好的对code进行说明,对于平台相关的代码,我们选择at91(ARM926EJS)平台进行分析.
另外,本文是以uncompressed kernel开始讲解的.对于内核解压缩部分的code,在 arch/arm/boot/compressed中,本文不做讨论.
一. 启动条件
通常从系统上电到执行到linux kenel这部分的任务是由boot loader来完成.关于boot loader的内容,本文就不做过多介绍.
这里只讨论进入到linux kernel的时候的一些限制条件,这一般是boot loader在最后跳转到kernel之前要完成的:
1. CPU必须处于SVC(supervisor)模式,并且IRQ和FIQ中断都是禁止的;
2. MMU(内存管理单元)必须是关闭的, 此时虚拟地址对物理地址;
3. 数据cache(Data cache)必须是关闭的
4. 指令cache(Instruction cache)可以是打开的,也可以是关闭的,这个没有强制要求;
5. CPU 通用寄存器0 (r0)必须是 0;
6. CPU 通用寄存器1 (r1)必须是 ARM Linux machine type (关于machine type, 我们后面会有讲解)
7. CPU 通用寄存器2 (r2) 必须是 kernel parameter list 的物理地址(parameter list 是由boot loader传递给kernel,用来描述设备信息属性的列表,详细内容可参考"Booting ARM Linux"文档).
二. starting kernel
首先，我们先对几个重要的宏进行说明(我们针对有MMU的情况)：宏 位置 默认值 说明
KERNEL_RAM_ADDR arch/arm/kernel/head.S +26 0xc0008000 kernel在RAM中的的虚拟地址
PAGE_OFFSET include/asm-arm/memeory.h +50 0xc0000000 内核空间的起始虚拟地址
TEXT_OFFSET arch/arm/Makefile +137 0x00008000 内核相对于存储空间的偏移
TEXTADDR arch/arm/kernel/head.S +49 0xc0008000 kernel的起始虚拟地址
PHYS_OFFSET include/asm-arm/arch-xxx/memory.h 平台相关 RAM的起始物理地址
内核的入口是stext,这是在arch/arm/kernel/vmlinux.lds.S中定义的:
00011: ENTRY(stext)
对于vmlinux.lds.S,这是ld script文件,此文件的格式和汇编及C程序都不同,本文不对ld script作过多的介绍,只对内核中用到的内容进行讲解,关于ld的详细内容可以参考ld.info
这里的ENTRY(stext) 表示程序的入口是在符号stext.
而符号stext是在arch/arm/kernel/head.S中定义的:
下面我们将arm linux boot的主要代码列出来进行一个概括的介绍,然后,我们会逐个的进行详细的讲解.
在arch/arm/kernel/head.S中 72 - 94 行,是arm linux boot的主代码:
00072: ENTRY(stext)
00073: msr cpsr_c, #PSR_F_BIT | PSR_I_BIT | SVC_MODE @ ensure svc mode
00074: @ and irqs disabled
00075: mrc p15, 0, r9, c0, c0 @ get processor id
00076: bl __lookup_processor_type @ r5=procinfo r9=cpuid
00077: movs r10, r5 @ invalid processor (r5=0)?
00078: beq __error_p @ yes, error 'p'
00079: bl __lookup_machine_type @ r5=machinfo
00080: movs r8, r5 @ invalid machine (r5=0)?
00081: beq __error_a @ yes, error 'a'
00082: bl __create_page_tables
00083:
00084: /*
00085: * The following calls CPU specific code in a position independent
00086: * manner. See arch/arm/mm/proc-*.S for details. r10 = base of
00087: * xxx_proc_info structure selected by __lookup_machine_type
00088: * above. On return, the CPU will be ready for the MMU to be
00089: * turned on, and r0 will hold the CPU control register value.
00090: */
00091: ldr r13, __switch_data @ address to jump to after
00092: @ mmu has been enabled
00093: adr lr, __enable_mmu @ return (PIC) address
00094: add pc, r10, #PROCINFO_INITFUNC
其中,73行是确保kernel运行在SVC模式下,并且IRQ和FIRQ中断已经关闭,这样做是很谨慎的.
arm linux boot的主线可以概括为以下几个步骤:
1. 确定 processor type (75 - 78行)
2. 确定 machine type (79 - 81行)
3. 创建页表 (82行)
4. 调用平台特定的__cpu_flush函数 (在struct proc_info_list中) (94 行)
5. 开启mmu (93行)
6. 切换数据 (91行)
最终跳转到start_kernel (在__switch_data的结束的时候,调用了 b start_kernel)
下面,我们按照这个主线,逐步的分析Code.
1. 确定 processor type
arch/arm/kernel/head.S中:00075: mrc p15, 0, r9, c0, c0 @ get processor id
00076: bl __lookup_processor_type @ r5=procinfo r9=cpuid
00077: movs r10, r5 @ invalid processor (r5=0)?
00078: beq __error_p @ yes, error 'p'
75行: 通过cp15协处理器的c0寄存器来获得processor id的指令. 关于cp15的详细内容可参考相关的arm手册
76行: 跳转到__lookup_processor_type.在__lookup_processor_type中,会把processor type 存储在r5中
77,78行: 判断r5中的processor type是否是0,如果是0,说明是无效的processor type,跳转到__error_p(出错)
__lookup_processor_type 函数主要是根据从cpu中获得的processor id和系统中的proc_info进行匹配,将匹配到的proc_info_list的基地址存到r5中, 0表示没有找到对应的processor type.
下面我们分析__lookup_processor_type函数
arch/arm/kernel/head-common.S中:
00145: .type __lookup_processor_type, %function
00146: __lookup_processor_type:
00147: adr r3, 3f
00148: ldmda r3, {r5 - r7}
00149: sub r3, r3, r7 @ get offset between virt&phys
00150: add r5, r5, r3 @ convert virt addresses to
00151: add r6, r6, r3 @ physical address space
00152: 1: ldmia r5, {r3, r4} @ value, mask
00153: and r4, r4, r9 @ mask wanted bits
00154: teq r3, r4
00155: beq 2f
00156: add r5, r5, #PROC_INFO_SZ @ sizeof(proc_info_list)
00157: cmp r5, r6
00158: blo 1b
00159: mov r5, #0 @ unknown processor
00160: 2: mov pc, lr
00161:
00162: /*
00163: * This provides a C-API version of the above function.
00164: */
00165: ENTRY(lookup_processor_type)
00166: stmfd sp!, {r4 - r7, r9, lr}
00167: mov r9, r0
00168: bl __lookup_processor_type
00169: mov r0, r5
00170: ldmfd sp!, {r4 - r7, r9, pc}
00171:
00172: /*
00173: * Look in include/asm-arm/procinfo.h and arch/arm/kernel/arch.[ch] for
00174: * more information about the __proc_info and __arch_info structures.
00175: */
00176: .long __proc_info_begin
00177: .long __proc_info_end
00178: 3: .long .
00179: .long __arch_info_begin
00180: .long __arch_info_end
145, 146行是函数定义
147行: 取地址指令,这里的3f是向前symbol名称是3的位置,即第178行,将该地址存入r3.
这里需要注意的是,adr指令取址,获得的是基于pc的一个地址,要格外注意,这个地址是3f处的"运行时地址", 由于此时MMU还没有打开,也可以理解成物理地址(实地址).(详细内容可参考arm指令手册)
148行: 因为r3中的地址是178行的位置的地址,因而执行完后: (ldmda表示栈指针递减，即r3递减，内存的地址编号较大的对应寄存器编号较大的)
r5存的是176行符号 __proc_info_begin的地址;
r6存的是177行符号 __proc_info_end的地址;
r7存的是3f处的地址.
这里需要注意链接地址和运行时地址的区别. r3存储的是运行时地址(物理地址),而r7中存储的是链接地址(虚拟地址).
__proc_info_begin和__proc_info_end是在arch/arm/kernel/vmlinux.lds.S中:
00031: __proc_info_begin = .;
00032: *(.proc.info.init)
00033: __proc_info_end = .;
这里是声明了两个变量:__proc_info_begin 和 __proc_info_end,其中等号后面的"."是location counter(详细内容请参考ld.info)
这三行的意思是: __proc_info_begin 的位置上,放置所有文件中的 ".proc.info.init" 段的内容,然后紧接着是 __proc_info_end 的位置.
kernel 使用struct proc_info_list来描述processor type.
在 include/asm-arm/procinfo.h 中:
00029: struct proc_info_list {
00030: unsigned int cpu_val;
00031: unsigned int cpu_mask;
00032: unsigned long __cpu_mm_mmu_flags; /* used by head.S */
00033: unsigned long __cpu_io_mmu_flags; /* used by head.S */
00034: unsigned long __cpu_flush; /* used by head.S */
00035: const char *arch_name;
00036: const char *elf_name;
00037: unsigned int elf_hwcap;
00038: const char *cpu_name;
00039: struct processor *proc;
00040: struct cpu_tlb_fns *tlb;
00041: struct cpu_user_fns *user;
00042: struct cpu_cache_fns *cache;
00043: };
我们当前以at91为例,其processor是926的.
在arch/arm/mm/proc-arm926.S 中:
00464: .section ".proc.info.init", #alloc, #execinstr
00465:
00466: .type __arm926_proc_info,#object
00467: __arm926_proc_info:
00468: .long 0x41069260 @ ARM926EJ-S (v5TEJ)
00469: .long 0xff0ffff0
00470: .long PMD_TYPE_SECT |
00471: PMD_SECT_BUFFERABLE |
00472: PMD_SECT_CACHEABLE |
00473: PMD_BIT4 |
00474: PMD_SECT_AP_WRITE |
00475: PMD_SECT_AP_READ
00476: .long PMD_TYPE_SECT |
00477: PMD_BIT4 |
00478: PMD_SECT_AP_WRITE |
00479: PMD_SECT_AP_READ
00480: b __arm926_setup
00481: .long cpu_arch_name
00482: .long cpu_elf_name
00483: .long HWCAP_SWP|HWCAP_HALF|HWCAP_THUMB|HWCAP_FAST_MULT|HWCAP_VFP|HWCAP_EDSP|HWCAP_JAVA
00484: .long cpu_arm926_name
00485: .long arm926_processor_functions
00486: .long v4wbi_tlb_fns
00487: .long v4wb_user_fns
00488: .long arm926_cache_fns
00489: .size __arm926_proc_info, . - __arm926_proc_info
从464行,我们可以看到 __arm926_proc_info 被放到了".proc.info.init"段中.
对照struct proc_info_list,我们可以看到 __cpu_flush的定义是在480行,即__arm926_setup.(我们将在"4. 调用平台特定的__cpu_flush函数"一节中详细分析这部分的内容.)
从以上的内容我们可以看出: r5中的__proc_info_begin是proc_info_list的起始地址, r6中的__proc_info_end是proc_info_list的结束地址.
149行: 从上面的分析我们可以知道r3中存储的是3f处的物理地址,而r7存储的是3f处的虚拟地址,这一行是计算当前程序运行的物理地址和虚拟地址的差值,将其保存到r3中.
150行: 将r5存储的虚拟地址(__proc_info_begin)转换成物理地址
151行: 将r6存储的虚拟地址(__proc_info_end)转换成物理地址
152行: 对照struct proc_info_list,可以得知,这句是将当前proc_info的cpu_val和cpu_mask分别存r3, r4中
153行: r9中存储了processor id(arch/arm/kernel/head.S中的75行),与r4的cpu_mask进行逻辑与操作,得到我们需要的值
154行: 将153行中得到的值与r3中的cpu_val进行比较
155行: 如果相等,说明我们找到了对应的processor type,跳到160行,返回
156行: (如果不相等) , 将r5指向下一个proc_info,
157行: 和r6比较,检查是否到了__proc_info_end.
158行: 如果没有到__proc_info_end,表明还有proc_info配置,返回152行继续查找
159行: 执行到这里,说明所有的proc_info都匹配过了,但是没有找到匹配的,将r5设置成0(unknown processor)
160行: 返回
2. 确定 machine type
arch/arm/kernel/head.S中:00079: bl __lookup_machine_type @ r5=machinfo
00080: movs r8, r5 @ invalid machine (r5=0)?
00081: beq __error_a @ yes, error 'a'
79行: 跳转到__lookup_machine_type函数,在__lookup_machine_type中,会把struct machine_desc的基地址(machine type)存储在r5中
80,81行: 将r5中的 machine_desc的基地址存储到r8中,并判断r5是否是0,如果是0,说明是无效的machine type,跳转到__error_a(出错)
__lookup_machine_type 函数
下面我们分析__lookup_machine_type 函数:
arch/arm/kernel/head-common.S中:
00176: .long __proc_info_begin
00177: .long __proc_info_end
00178: 3: .long .
00179: .long __arch_info_begin
00180: .long __arch_info_end
00181:
00182: /*
00183: * Lookup machine architecture in the linker-build list of architectures.
00184: * Note that we can't use the absolute addresses for the __arch_info
00185: * lists since we aren't running with the MMU on (and therefore, we are
00186: * not in the correct address space). We have to calculate the offset.
00187: *
00188: * r1 = machine architecture number
00189: * Returns:
00190: * r3, r4, r6 corrupted
00191: * r5 = mach_info pointer in physical address space
00192: */
00193: .type __lookup_machine_type, %function
00194: __lookup_machine_type:
00195: adr r3, 3b
00196: ldmia r3, {r4, r5, r6}
00197: sub r3, r3, r4 @ get offset between virt&phys
00198: add r5, r5, r3 @ convert virt addresses to
00199: add r6, r6, r3 @ physical address space
00200: 1: ldr r3, [r5, #MACHINFO_TYPE] @ get machine type
00201: teq r3, r1 @ matches loader number?
00202: beq 2f @ found
00203: add r5, r5, #SIZEOF_MACHINE_DESC @ next machine_desc
00204: cmp r5, r6
00205: blo 1b
00206: mov r5, #0 @ unknown machine
00207: 2: mov pc, lr
193, 194行: 函数声明
195行: 取地址指令,这里的3b是向后symbol名称是3的位置,即第178行,将该地址存入r3.
和上面我们对__lookup_processor_type 函数的分析相同,r3中存放的是3b处物理地址.
196行: r3是3b处的地址,因而执行完后:（ldmia 表示栈是递增的，即r3递增，低内存地址对应小号寄存器）
r4存的是 3b处的地址
r5存的是__arch_info_begin 的地址
r6存的是__arch_info_end 的地址
__arch_info_begin 和 __arch_info_end是在 arch/arm/kernel/vmlinux.lds.S中:
00034: __arch_info_begin = .;
00035: *(.arch.info.init)
00036: __arch_info_end = .;
这里是声明了两个变量:__arch_info_begin 和 __arch_info_end,其中等号后面的"."是location counter(详细内容请参考ld.info)
这三行的意思是: __arch_info_begin 的位置上,放置所有文件中的 ".arch.info.init" 段的内容,然后紧接着是 __arch_info_end 的位置.
kernel 使用struct machine_desc 来描述 machine type.
在 include/asm-arm/mach/arch.h 中:
00017: struct machine_desc {
00018: /*
00019: * Note! The first four elements are used
00020: * by assembler code in head-armv.S
00021: */
00022: unsigned int nr; /* architecture number */
00023: unsigned int phys_io; /* start of physical io */
00024: unsigned int io_pg_offst; /* byte offset for io
00025: * page tabe entry */
00026:
00027: const char *name; /* architecture name */
00028: unsigned long boot_params; /* tagged list */
00029:
00030: unsigned int video_start; /* start of video RAM */
00031: unsigned int video_end; /* end of video RAM */
00032:
00033: unsigned int reserve_lp0 :1; /* never has lp0 */
00034: unsigned int reserve_lp1 :1; /* never has lp1 */
00035: unsigned int reserve_lp2 :1; /* never has lp2 */
00036: unsigned int soft_reboot :1; /* soft reboot */
00037: void (*fixup)(struct machine_desc *,
00038: struct tag *, char **,
00039: struct meminfo *);
00040: void (*map_io)(void);/* IO mapping function */
00041: void (*init_irq)(void);
00042: struct sys_timer *timer; /* system tick timer */
00043: void (*init_machine)(void);
00044: };
00045:
00046: /*
00047: * Set of macros to define architecture features. This is built into
00048: * a table by the linker.
00049: */
00050: #define MACHINE_START(_type,_name)
00051: static const struct machine_desc __mach_desc_##_type
00052: __attribute_used__
00053: __attribute__((__section__(".arch.info.init"
)) = { 00054: .nr = MACH_TYPE_##_type,
00055: .name = _name,
00056:
00057: #define MACHINE_END
00058: };
内核中,一般使用宏MACHINE_START来定义machine type.
对于at91, 在 arch/arm/mach-at91rm9200/board-ek.c 中:
00137: MACHINE_START(AT91RM9200EK, "Atmel AT91RM9200-EK"
![icon_wink[1]](https://images0.cnblogs.com/blog/480488/201403/291644390621140.gif "icon_wink[1]"){kind=small}
00138: /* Maintainer: SAN People/Atmel */
00139: .phys_io = AT91_BASE_SYS,
00140: .io_pg_offst = (AT91_VA_BASE_SYS >> 1
& 0xfffc, 00141: .boot_params = AT91_SDRAM_BASE + 0x100,
00142: .timer = &at91rm9200_timer,
00143: .map_io = ek_map_io,
00144: .init_irq = ek_init_irq,
00145: .init_machine = ek_board_init,
00146: MACHINE_END
197行: r3中存储的是3b处的物理地址,而r4中存储的是3b处的虚拟地址,这里计算处物理地址和虚拟地址的差值,保存到r3中
198行: 将r5存储的虚拟地址(__arch_info_begin)转换成物理地址
199行: 将r6存储的虚拟地址(__arch_info_end)转换成物理地址
200行: MACHINFO_TYPE 在 arch/arm/kernel/asm-offset.c 101行定义, 这里是取 struct machine_desc中的nr(architecture number) 到r3中
201行: 将r3中取到的machine type 和 r1中的 machine type(见前面的"启动条件"
![icon_wink[2]](https://images0.cnblogs.com/blog/480488/201403/291644402502210.gif "icon_wink[2]"){kind=small}
进行比较 202行: 如果相同,说明找到了对应的machine type,跳转到207行的2f处,此时r5中存储了对应的struct machine_desc的基地址
203行: (不相同), 取下一个machine_desc的地址
204行: 和r6进行比较,检查是否到了__arch_info_end.
205行: 如果不相同,说明还有machine_desc,返回200行继续查找.
206行: 执行到这里,说明所有的machind_desc都查找完了,并且没有找到匹配的, 将r5设置成0(unknown machine).
207行: 返回
3. 创建页表
通过前面的两步,我们已经确定了processor type 和 machine type.此时,一些特定寄存器的值如下所示:
r8 = machine info (struct machine_desc的基地址)
r9 = cpu id (通过cp15协处理器获得的cpu id)
r10 = procinfo (struct proc_info_list的基地址)
创建页表是通过函数 __create_page_tables 来实现的.
这里,我们使用的是arm的L1主页表,L1主页表也称为段页表(section page table)
L1 主页表将4 GB 的地址空间分成若干个1 MB的段(section),因此L1页表包含4096个页表项(section entry). 每个页表项是32 bits(4 bytes)
因而L1主页表占用 4096 *4 = 16k的内存空间.
对于ARM926,其L1 section entry的格式为
可参考arm926EJS TRM):
(一级描述符的格式 可以参考《ARM体系结构与编程》P180) 
下面我们来分析 __create_page_tables 函数: 在 arch/arm/kernel/head.S 中:
00206: .type __create_page_tables, %function
00207: __create_page_tables:
00208: pgtbl r4 @ page table address
00209:
00210: /*
00211: * Clear the 16K level 1 swapper page table
00212: */
00213: mov r0, r4
00214: mov r3, #0
00215: add r6, r0, #0x4000
00216: 1: str r3, [r0], #4
00217: str r3, [r0], #4
00218: str r3, [r0], #4
00219: str r3, [r0], #4
00220: teq r0, r6
00221: bne 1b
00222:
00223: ldr r7, [r10, #PROCINFO_MM_MMUFLAGS] @ mm_mmuflags
00224:
00225: /*
00226: * Create identity mapping for first MB of kernel to
00227: * cater for the MMU enable. This identity mapping
00228: * will be removed by paging_init(). We use our current program
00229: * counter to determine corresponding section base address.
00230: */
00231: mov r6, pc, lsr #20 @ start of kernel section
00232: orr r3, r7, r6, lsl #20 @ flags + kernel base
00233: str r3, [r4, r6, lsl #2] @ identity mapping
00234:
00235: /*
00236: * Now setup the pagetables for our kernel direct
00237: * mapped region.
00238: */
00239: add r0, r4, #(TEXTADDR & 0xff000000) >> 18 @ start of kernel
00240: str r3, [r0, #(TEXTADDR & 0x00f00000) >> 18]!
00241:
00242: ldr r6, =(_end - PAGE_OFFSET - 1) @ r6 = number of sections
00243: mov r6, r6, lsr #20 @ needed for kernel minus 1
00244:
00245: 1: add r3, r3, #1 << 20
00246: str r3, [r0, #4]!
00247: subs r6, r6, #1
00248: bgt 1b
00249:
00250: /*
00251: * Then map first 1MB of ram in case it contains our boot params.
00252: */
00253: add r0, r4, #PAGE_OFFSET >> 18
00254: orr r6, r7, #PHYS_OFFSET
00255: str r6, [r0]
...
00314: mov pc, lr
00315: .ltorg
206, 207行: 函数声明
208行: 通过宏 pgtbl 将r4设置成页表的基地址(物理地址)
宏pgtbl 在 arch/arm/kernel/head.S 中:
00042: .macro pgtbl, rd
00043: ldr d, =(__virt_to_phys(KERNEL_RAM_ADDR - 0x4000))
00044: .endm
可以看到,页表是位于 KERNEL_RAM_ADDR 下面 16k 的位置
宏 __virt_to_phys 是在incude/asm-arm/memory.h 中:
00125: #ifndef __virt_to_phys
00126: #define __virt_to_phys(x) ((x) - PAGE_OFFSET + PHYS_OFFSET)
00127: #define __phys_to_virt(x) ((x) - PHYS_OFFSET + PAGE_OFFSET)
00128: #endif
下面从213行 - 221行, 是将这16k 的页表清0.
213行: r0 = r4, 将页表基地址存在r0中
214行: 将 r3 置成0
215行: r6 = 页表基地址 + 16k, 可以看到这是页表的尾地址
216 - 221 行: 循环,从 r0 到 r6 将这16k页表用0填充.
223行: 获得proc_info_list的__cpu_mm_mmu_flags的值,并存储到 r7中. (宏PROCINFO_MM_MMUFLAGS是在arch/arm/kernel/asm-offset.c中定义，值为8)（可以参考《嵌入式Linux应用完全开发手册》P118）（r7的值就是设置这个段描述符的权限、域字段，） 在arch/arm/mm/proc-arm926.S 中: 00464: .section ".proc.info.init", #alloc, #execinstr 00465: 00466: .type __arm926_proc_info,#object 00467: __arm926_proc_info: 00468: .long 0x41069260 @ ARM926EJ-S (v5TEJ) 00469: .long 0xff0ffff0 00470: .long PMD_TYPE_SECT | 00471: PMD_SECT_BUFFERABLE | 00472: PMD_SECT_CACHEABLE | 00473: PMD_BIT4 | 00474: PMD_SECT_AP_WRITE | 00475: PMD_SECT_AP_READ 00476: .long PMD_TYPE_SECT | 00477: PMD_BIT4 | 00478: PMD_SECT_AP_WRITE | 00479: PMD_SECT_AP_READ 00480: b __arm926_setup 00481: .long cpu_arch_name 00482: .long cpu_elf_name 00483: .long HWCAP_SWP|HWCAP_HALF|HWCAP_THUMB|HWCAP_FAST_MULT|HWCAP_VFP|HWCAP_EDSP|HWCAP_JAVA 00484: .long cpu_arm926_name 00485: .long arm926_processor_functions 00486: .long v4wbi_tlb_fns 00487: .long v4wb_user_fns 00488: .long arm926_cache_fns 00489: .size __arm926_proc_info, . - __arm926_proc_info
231行: 通过pc值的高12位(右移20位),得到kernel的section,并存储到r6中.因为当前是通过运行时地址得到的kernel的section,因而是物理地址.
232行: r3 = r7 | (r6 << 20); flags + kernel base,得到页表中需要设置的值.
233行: 设置页表: mem[r4 + r6 * 4] = r3
这里,因为页表的每一项是32 bits(4 bytes),所以要乘以4(<<2).
上面这三行,设置了kernel的第一个section(物理地址所在的page entry)的页表项
239, 240行: TEXTADDR是内核的起始虚拟地址(0xc0008000), 这两行是设置kernel起始虚拟地址的页表项(注意,这里设置的页表项和上面的231 - 233行设置的页表项是不同的 )
执行完后,r0指向kernel的第2个section的虚拟地址所在的页表项.
/* TODO: 这两行的code很奇怪,为什么要先取TEXTADDR的高8位(Bit[31:24])0xff000000,然后再取后面的8位 (Bit[23:20])0x00f00000*/
242行: 这一行计算kernel镜像的大小(bytes).
_end 是在vmlinux.lds.S中162行定义的,标记kernel的结束位置(虚拟地址):
00158 .bss : {
00159 __bss_start = .; /* BSS */
00160 *(.bss)
00161 *(COMMON)
00162 _end = .;
00163 }
kernel的size = _end - PAGE_OFFSET -1, 这里 减1的原因是因为 _end 是 location counter,它的地址是kernel镜像后面的一个byte的地址.
243行: 地址右移20位,计算出kernel有多少sections（也就是有多少兆，因为段描述符每个可以映射1MiB的虚拟地址）,并将结果存到r6中
245 - 248行: 这几行用来填充kernel所有section虚拟地址对应的页表项.
253行: 将r0设置为RAM第一兆虚拟地址的页表项地址(page entry)
254行: r7中存储的是mmu flags, 逻辑或上RAM的起始物理地址,得到RAM第一个MB页表项的值.
255行: 设置RAM的第一个MB虚拟地址的页表.
上面这三行是用来设置RAM中第一兆虚拟地址的页表. 之所以要设置这个页表项的原因是RAM的第一兆内存中可能存储着boot params.
这样,kernel所需要的基本的页表我们都设置完了, 如下图所示:
下面是linux-2.6.30.4中的arch/arm/kernel/head.S，代码有一些不同，但是效果一样：
1: /*
2: * linux/arch/arm/kernel/head.S
3: *
4: * Copyright (C) 1994-2002 Russell King
5: * Copyright (c) 2003 ARM Limited
6: * All Rights Reserved
7: *
8: * This program is free software; you can redistribute it and/or modify
9: * it under the terms of the GNU General Public License version 2 as
10: * published by the Free Software Foundation.
11: *
12: * Kernel startup code for all 32-bit CPUs
13: */
14: #include