- 论坛徽章:
- 0
|
linux内核启动过程——基于S3C2410 （2）Image早期初始化
由 zhoum 于 星期日, 11/09/2008 - 21:11 发表
S3C2410
linux
embedded
嵌入式
从zImage头跳转进来，此时的状态
- MMU为off
- D-cache为off
- I-cache为dont care，on或off没有关系
- r0为0
- r1为machine ID
- r2为atags指针
内核代码入口在linux-2.6.24-moko-linuxbj/arch/arm/kernel/head.S文件的83行。首先进入SVC32模式，并查询CPU ID，检查合法性
msr cpsr_c, #PSR_F_BIT | PSR_I_BIT | SVC_MODE @ ensure svc mode
@ and irqs disabled
mrc p15, 0, r9, c0, c0 @ get processor id
bl __lookup_processor_type @ r5=procinfo r9=cpuid
movs r10, r5 @ invalid processor (r5=0)?
beq __error_p @ yes, error 'p'
接着在87行进一步查询machine ID并检查合法性
bl __lookup_machine_type @ r5=machinfo
movs r8, r5 @ invalid machine (r5=0)?
beq __error_a @ yes, error 'a'
其中__lookup_processor_type在linux-2.6.24-moko-linuxbj/arch/arm
/kernel/head-common.S文件的149行，该函数首将标号3的实际地址加载到r3，然后将编译时生成的
__proc_info_begin虚拟地址载入到r5，__proc_info_end虚拟地址载入到r6，标号3的虚拟地址载入到r7。由于adr伪
指令和标号3的使用，以及__proc_info_begin等符号在linux-2.6.24-moko-linuxbj/arch/arm
/kernel/vmlinux.lds而不是代码中被定义，此处代码不是非常直观，想弄清楚代码缘由的读者请耐心阅读这两个文件和adr伪指令的说明。
r3和r7分别存储的是同一位置标号3的物理地址（由于没有启用mmu，所以当前肯定是物理地址）和虚拟地址，所以儿者相减即得到虚拟地址和物理地址之间的offset。利用此offset，将r5和r6中保存的虚拟地址转变为物理地址
__lookup_processor_type:
adr r3, 3f
ldmda r3, {r5 - r7}
sub r3, r3, r7 @ get offset between virt&phys
add r5, r5, r3 @ convert virt addresses to
add r6, r6, r3 @ physical address space
然后从proc_info中读出内核编译时写入的processor ID和之前从cpsr中读到的processor
ID对比，查看代码和CPU硬件是否匹配（想在arm920t上运行为cortex-a8编译的内核？不让！）。如果编译了多种处理器支持，如
versatile板，则会循环每种type依次检验，如果硬件读出的ID在内核中找不到匹配，则r5置0返回
1: ldmia r5, {r3, r4} @ value, mask
and r4, r4, r9 @ mask wanted bits
teq r3, r4
beq 2f
add r5, r5, #PROC_INFO_SZ @ sizeof(proc_info_list)
cmp r5, r6
blo 1b
mov r5, #0 @ unknown processor
2: mov pc, lr
__lookup_machine_type在linux-2.6.24-moko-linuxbj/arch/arm/kernel/head-common.S文件的197行，编码方法与检查processor ID完全一样，请参考前段
__lookup_machine_type:
adr r3, 3b
ldmia r3, {r4, r5, r6}
sub r3, r3, r4 @ get offset between virt&phys
add r5, r5, r3 @ convert virt addresses to
add r6, r6, r3 @ physical address space
1: ldr r3, [r5, #MACHINFO_TYPE] @ get machine type
teq r3, r1 @ matches loader number?
beq 2f @ found
add r5, r5, #SIZEOF_MACHINE_DESC @ next machine_desc
cmp r5, r6
blo 1b
mov r5, #0 @ unknown machine
2: mov pc, lr
代码回到head.S第92行，检查atags合法性，然后创建初始页表
bl __vet_atags
bl __create_page_tables
创建页表的代码在218行，首先将内核起始地址-0x4000到内核起始地址之间的16K存储器清0
__create_page_tables:
pgtbl r4 @ page table address
/*
* Clear the 16K level 1 swapper page table
*/
mov r0, r4
mov r3, #0
add r6, r0, #0x4000
1: str r3, [r0], #4
str r3, [r0], #4
str r3, [r0], #4
str r3, [r0], #4
teq r0, r6
bne 1b
然后在234行将proc_info中的mmu_flags加载到r7
ldr r7, [r10, #PROCINFO_MM_MMUFLAGS] @ mm_mmuflags
在242行将PC指针右移20位，得到内核第一个1MB空间的段地址存入r6，在s3c2410平台该值是0x300。接着根据此值存入映射标识
mov r6, pc, lsr #20 @ start of kernel section
orr r3, r7, r6, lsl #20 @ flags + kernel base
str r3, [r4, r6, lsl #2] @ identity mapping
完成页表设置后回到102行，为打开虚拟地址映射作准备。设置sp指针，函数返回地址lr指向__enable_mmu，并跳转到
linux-2.6.24-moko-linuxbj/arch/arm/mm/proc-arm920.S的386行，清除I-cache、D-
cache、write buffer和TLB
__arm920_setup:
mov r0, #0
mcr p15, 0, r0, c7, c7 @ invalidate I,D caches on v4
mcr p15, 0, r0, c7, c10, 4 @ drain write buffer on v4
#ifdef CONFIG_MMU
mcr p15, 0, r0, c8, c7 @ invalidate I,D TLBs on v4
#endif
然后返回head.S的158行，加载domain和页表，跳转到__turn_mmu_on
__enable_mmu:
#ifdef CONFIG_ALIGNMENT_TRAP
orr r0, r0, #CR_A
#else
bic r0, r0, #CR_A
#endif
#ifdef CONFIG_CPU_DCACHE_DISABLE
bic r0, r0, #CR_C
#endif
#ifdef CONFIG_CPU_BPREDICT_DISABLE
bic r0, r0, #CR_Z
#endif
#ifdef CONFIG_CPU_ICACHE_DISABLE
bic r0, r0, #CR_I
#endif
mov r5, #(domain_val(DOMAIN_USER, DOMAIN_MANAGER) | \
domain_val(DOMAIN_KERNEL, DOMAIN_MANAGER) | \
domain_val(DOMAIN_TABLE, DOMAIN_MANAGER) | \
domain_val(DOMAIN_IO, DOMAIN_CLIENT))
mcr p15, 0, r5, c3, c0, 0 @ load domain access register
mcr p15, 0, r4, c2, c0, 0 @ load page table pointer
b __turn_mmu_on
在194行把mmu使能位写入mmu，激活虚拟地址。然后将原来保存在sp中的地址载入pc，跳转到head-common.S的__mmap_switched，至此代码进入虚拟地址的世界
mov r0, r0
mcr p15, 0, r0, c1, c0, 0 @ write control reg
mrc p15, 0, r3, c0, c0, 0 @ read id reg
mov r3, r3
mov r3, r3
mov pc, r13
在head-common.S的37行开始清除内核bss段，processor ID保存在r9，machine
ID报存在r1，atags地址保存在r2，并将控制寄存器保存到r7定义的内存地址。接下来跳入linux-2.6.24-moko-
linuxbj/init/main.c的507行，start_kernel函数。这里只粘贴部分代码
__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
在main.c第507行，是硬件无关的C初始化代码
asmlinkage void __init start_kernel(void)
{
char * command_line;
extern struct kernel_param __start___param[], __stop___param[];
smp_setup_processor_id();
s3c2410平台linux-2.6.24内核早期的汇编初始化到这里就结束了
调试技巧：
利用gdb调试内核Image启动流程是一种很好的分析手段，要使用好这种手段有一个问题需要解决——内核地址映射问题
代码执行的早期是处于mmu关闭的状态下，软件直接使用硬件相关的物理地址（s3c2410的ram从0x30000000开始）；后来启用mmu并建立映射之后，软件使用虚拟地址。在3G用户空间配置下（大多数32位嵌入式系统都是此配置），内核使用的PAGE_OFFSET为0xc0000000，与硬件无关，核心虚拟地址变为从0xc0000000开始；
调试器无法自动接受这样的地址转变，需要使用上文介绍的诀窍，手工“告诉”调试器该怎么做。
对内核编译产生的vmlinux文件使用objdump工具
$ /usr/local/linuxbj/eabi-glibc/arm/bin/arm-linuxbj-linux-gnueabi-objdump -t vmlinux|more
vmlinux: file format elf32-littlearm
SYMBOL TABLE:
c0008000 l d .text.head 00000000 .text.head
c0008240 l d .init 00000000 .init
c0027000 l d .text 00000000 .text
c03377ec l d .notes 00000000 .notes
c0338000 l d __ksymtab 00000000 __ksymtab
c033ca40 l d __ksymtab_gpl 00000000 __ksymtab_gpl
c033e2d0 l d __ksymtab_gpl_future 00000000 __ksymtab_gpl_future
c033e2e8 l d __ksymtab_strings 00000000 __ksymtab_strings
c034c9ec l d __param 00000000 __param
c034e000 l d .data 00000000 .data
c0373e20 l d .bss 00000000 .bss
可以看到内核符号表的.text链接虚拟地址是0xc0027000，所以在mmu处于关闭的阶段中，应该将内核符号表在调试器里加载到0x30027000地址。使得head.S入口.text.head正好是0x30008000，与实际的内存一致。
本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u3/100089/showart_2027429.html |
|
免费注册
发表于 2009-08-14 16:27