装载ARM Linux内核启动过程

t91为例,其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 cant use the absolute addresses for the __arch_info
00185: * lists since we arent 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