ARM Linux启动代码分析

时间:2023-03-08 23:20:30
ARM Linux启动代码分析

前言

在学习、分析之前首先要弄明白一个问题:为什么要分析启动代码?

因为启动代码绝大部分都是用汇编语言写的,对于没学过或者不熟悉汇编语言的同学确实有一定难度,但是如果你想真正深入地学习Linux,那么读、分析某一个体系结构(比如ARM)的启动代码或者其他底层代码是必不可少的。当分析之后会发现这是有很多好处的:分析启动代码可以加深对汇编语言的理解;可以学习汇编语言的使用技巧;可以学习如何编写位置无关的代码,可以知道从启动到start_kernel()函数之前内核到底干了什么事情,从而为后续其他内核子系统的学习打下基础。

废话不多说,下面基于s3c6410,以Linux-2.6.36版本为基础进行分析。ARM Linux的启动代码有两处,一处是经过压缩的,一处是没有经过压缩的,压缩的最终还是会调用没有压缩的,没有压缩的入口在arch/arm/kernel/head.S文件中,如下所示:

     __HEAD
ENTRY(stext)
setmode PSR_F_BIT | PSR_I_BIT | SVC_MODE, r9 @ ensure svc mode
@ and irqs disabled
mrc p15, , r9, c0, c0 @ get processor id
bl __lookup_processor_type @ r5=procinfo r9=cpuid
movs r10, r5 @ invalid processor (r5=)?
beq __error_p @ yes, error 'p'
bl __lookup_machine_type @ r5=machinfo
movs r8, r5 @ invalid machine (r5=)?
beq __error_a @ yes, error 'a'
bl __vet_atags
bl __create_page_tables /*
* The following calls CPU specific code in a position independent
* manner. See arch/arm/mm/proc-*.S for details. r10 = base of
* xxx_proc_info structure selected by __lookup_machine_type
* above. On return, the CPU will be ready for the MMU to be
* turned on, and r0 will hold the CPU control register value.
*/
ldr r13, __switch_data @ address to jump to after
@ mmu has been enabled
adr lr, BSYM(__enable_mmu) @ return (PIC) address
ARM( add pc, r10, #PROCINFO_INITFUNC )
THUMB( add r12, r10, #PROCINFO_INITFUNC )
THUMB( mov pc, r12 )
ENDPROC(stext)

79行就是要分析的第一行代码,设置CPU为管理模式,这也是CPU一上电所处的模式,关闭CPU普通中断和CPU快速中断。

81行,读协处理器p15获取CPU ID,结果存在r9寄存器里,待会会用到。

82行,跳转到__lookup_processor_type标号处,在arch/arm/kernel/head-common.S文件里定义:

 __lookup_processor_type:
adr r3, 3f
ldmia r3, {r5 - r7}
add r3, r3, #
sub r3, r3, r7 @ get offset between virt&phys
add r5, r5, r3 @ convert virt addresses to
add r6, r6, r3 @ physical address space
: 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, # @ unknown processor
: mov pc, lr
ENDPROC(__lookup_processor_type)
……
.align
: .long __proc_info_begin
.long __proc_info_end
: .long .
.long __arch_info_begin
.long __arch_info_end

在汇编语言中,标号代表的是地址,准确来说是链接地址。adr和ldr都是伪指令,它们两者的作用都是将标号处所代表的地址存放到寄存器中。但是adr采用基于PC值的相对地址(PC+偏移值),而ldr采用的是绝对地址(直接采用标号的值),另外adr要求指令与标号位于同一个段中。

161行,因此当前PC值是存放的是一个物理地址,为什么是物理地址?为了搞清楚这个问题,下面简单说说上一个“年代”的bootloader是怎么引导、启动内核的,主要的流程如下:

(1)上电

(2)必要的设置

(3)关看门狗

(4)初始化SDRAM、初始化Nand Flash

(5)把bootloader拷贝到SDRAM的高处

(6)清BSS段

(7)跳到SDRAM继续执行

(8)把Nand Flash中的内核Image拷贝到SDRAM(0x50008000)

(9)设置启动参数,r0、r1等寄存器,关闭MMU、cache等

(10)跳到内核Image的起始处(0x50008000)执行,此后,bootloader时代一去不复返,进入Linux新时代。

现在应该知道执行到161行时,PC的值就为0x50000000~0x58000000之间的某一个值(假定内存为128MB,s3c6410物理内存的起始地址为0x50000000),即一物理地址,因此r3的值就为194行的标号3处的物理地址。

162行,分别将r3、r3+4、r3+8地址上的内容存放到r5、r6、r7寄存器中,即r5存放的是__proc_info_begin的值(是一个链接地址,或者说虚拟地址),r6存放的是__proc_info_end的值(是一个链接地址,或者说虚拟地址),因为 . 表示的是当前的链接地址,所以r7存放的是标号4的链接地址,这跟LD链接脚本里的 . 表示的意思是一样的。

163行,将r3的值加8,即现在r3的值为196行的标号4的物理地址。

164行,r3 = r3 – r7,即r3 = 标号4的物理地址 - 标号4的虚拟地址,这样就可以计算出物理地址和虚拟地址的偏移量,显然r3的值为一负数。

165行,结果为r5 = __proc_info_begin的物理地址。

166行,结果为r6 = __proc_info_end的物理地址。

167行,取出struct proc_info_list结构体的前两个成员的值分别放到r3、r4。struct proc_info_list结构体的定义如下:

struct proc_info_list {
unsigned int cpu_val;
unsigned int cpu_mask;
unsigned long __cpu_mm_mmu_flags; /* used by head.S */
unsigned long __cpu_io_mmu_flags; /* used by head.S */
unsigned long __cpu_flush; /* used by head.S */
const char *arch_name;
const char *elf_name;
unsigned int elf_hwcap;
const char *cpu_name;
struct processor *proc;
struct cpu_tlb_fns *tlb;
struct cpu_user_fns *user;
struct cpu_cache_fns *cache;
};

每一种体系结构都有一个这样的结构体变量,对于s3c6410,来说,它属于ARMv6体系结构,它的struct proc_info_list变量在arch/arm/mm/proc-v6.S中定义,在链接的时候所有这些变量都被放在__proc_info_begin和__proc_info_end之间。因此,167行执行后,r3 = cpu_val,r4 = cpu_mask。

168行,将r4的值与r9的值相与,得到的CPU ID存在r4中。

169行,比较r4与r3的值。

170行,如果r4=r3,那么跳到175行处执行,即子程序返回。如果r4不等于r3,那么执行171行,将r5的值加上sizeof(struct proc_info_list),即指向下一个struct proc_info_list变量。

172行,比较r5和r6。

173行,如果r5小于r6,则跳转到167行,重复上面的过程。如果所有struct proc_info_list变量都比较后都没有找到对应的CPU ID,那么执行174行,r5 = 0,然后返回。

至此,__lookup_processor_type分析完毕,回到head.S的83行,把r5的值赋给r10,并影响标志位。

84行,如果r5=0,那么跳转到__error_p标号。这里假设内核是支持当前CPU的,即r5不为0,因此不分析__error_p的内容。

85行,跳到__lookup_machine_type标号处,同样是在arch/arm/kernel/head-common.S中定义:

 :    .long    .
.long __arch_info_begin
.long __arch_info_end __lookup_machine_type:
adr r3, 4b
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
: 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, # @ unknown machine
: mov pc, lr
ENDPROC(__lookup_machine_type)

和前面的__lookup_processor_type非常类似,只不过这里查找的是struct machine_desc结构体变量,比较的是struct machine_desc的成员nr的值,因此不再分析。这里需要提一下的是,比如对于mini6410(tiny6410),struct machine_desc变量的定义在arch/arm/mach-s3c64xx/mach-mini6410.c文件中,如下所示:

 MACHINE_START(MINI6410, "MINI6410")
/* Maintainer: Ben Dooks <ben-linux@fluff.org> */
.phys_io = S3C_PA_UART & 0xfff00000,
.io_pg_offst = (((u32)S3C_VA_UART) >> ) & 0xfffc,
.boot_params = S3C64XX_PA_SDRAM + 0x100, .init_irq = s3c6410_init_irq,
.map_io = mini6410_map_io,
.init_machine = mini6410_machine_init,
.timer = &s3c24xx_timer,
MACHINE_END

回到head.S,86、87行判断是否支持当前的机器号,不支持就跳到__error_a标号处。

88行,跳到__vet_atags,同样是在arch/arm/kernel/head-common.S中定义:

 __vet_atags:
tst r2, #0x3 @ aligned?
bne 1f ldr r5, [r2, #] @ is first tag ATAG_CORE?
cmp r5, #ATAG_CORE_SIZE
cmpne r5, #ATAG_CORE_SIZE_EMPTY
bne 1f
ldr r5, [r2, #]
ldr r6, =ATAG_CORE
cmp r5, r6
bne 1f mov pc, lr @ atag pointer is ok : mov r2, #
mov pc, lr
ENDPROC(__vet_atags)

251行,测试r2的低2位是否为0,也即r2的值是否4字节对齐。

252行,如果r2的低2位不为0,则跳转到265行,将r2的值设为0,然后返回。

下面先看一下bootloader传递参数给内核的结构定义,在arch/arm/include/asm/setup.h文件中:

 struct tag {
struct tag_header hdr;
union {
struct tag_core core;
struct tag_mem32 mem;
struct tag_videotext videotext;
struct tag_ramdisk ramdisk;
struct tag_initrd initrd;
struct tag_serialnr serialnr;
struct tag_revision revision;
struct tag_videolfb videolfb;
struct tag_cmdline cmdline; /*
00000160 * Acorn specific
00000161 */
struct tag_acorn acorn; /*
00000165 * DC21285 specific
00000166 */
struct tag_memclk memclk;
} u;
};

147行,struct tag_header的定义:

 struct tag_header {
__u32 size;
__u32 tag;
};

从struct tag的定义可以知道,bootloader传递的参数有好几种类型的tag,但是内核规定第一个tag必须是ATAG_CORE类型,最后一个必须是ATAG_NONE类型,每一种类型的tag都有一个编号,例如ATAG_CORE为0x54410001,ATAG_NONE为0x00000000。struct tag_header的tag成员就是用来描述tag的类型,而size成员用来描述整个tag的大小。每个tag连续存放。

那么标号__vet_atags的254行的意思就是获取ATAG_CORE类型tag的size成员的值赋给r5。

255行,将r5的值与ATAG_CORE_SIZE比较,ATAG_CORE_SIZE的值为((2*4 + 3*4) >> 2),即5。

256行,如果255行比较的结果不相等,那么将r5与ATAG_CORE_SIZE_EMPTY进行比较,ATAG_CORE_SIZE_EMPTY的值为((2*4) >> 2),即2。

257行,如果还是不相等,那么跳转到265行执行,同样是将r2设为0,然后返回。

258行,获取struct tag_header的tag成员,将它的值赋给r5。

259行,r6 = ATAG_CORE,即0x54410001。

260行,比较r5和r6的值。

261行,如果r5和r6的值不相等则跳转到265行,如果相等则执行263行直接返回。

至此,__vet_atags标号的内容分析完毕。

回到head.S的89行,跳转到__create_page_tables标号处,在head.S里定义:

 __create_page_tables:
pgtbl r4 @ page table address /*
* Clear the 16K level swapper page table
*/
mov r0, r4
mov r3, #
add r6, r0, #0x4000
: str r3, [r0], #
str r3, [r0], #
str r3, [r0], #
str r3, [r0], #
teq r0, r6
bne 1b ldr r7, [r10, #PROCINFO_MM_MMUFLAGS] @ mm_mmuflags /*
* Create identity mapping for first MB of kernel to
* cater for the MMU enable. This identity mapping
* will be removed by paging_init(). We use our current program
* counter to determine corresponding section base address.
*/
mov r6, pc
mov r6, r6, lsr # @ start of kernel section
orr r3, r7, r6, lsl # @ flags + kernel base
str r3, [r4, r6, lsl #] @ identity mapping /*
* Now setup the pagetables for our kernel direct
* mapped region.
*/
add r0, r4, #(KERNEL_START & 0xff000000) >>
str r3, [r0, #(KERNEL_START & 0x00f00000) >> ]!
ldr r6, =(KERNEL_END - )
add r0, r0, #
add r6, r4, r6, lsr #
: cmp r0, r6
add r3, r3, # <<
strls r3, [r0], #
bls 1b #ifdef CONFIG_XIP_KERNEL
/*
* Map some ram to cover our .data and .bss areas.
*/
orr r3, r7, #(KERNEL_RAM_PADDR & 0xff000000)
.if (KERNEL_RAM_PADDR & 0x00f00000)
orr r3, r3, #(KERNEL_RAM_PADDR & 0x00f00000)
.endif
add r0, r4, #(KERNEL_RAM_VADDR & 0xff000000) >>
str r3, [r0, #(KERNEL_RAM_VADDR & 0x00f00000) >> ]!
ldr r6, =(_end - )
add r0, r0, #
add r6, r4, r6, lsr #
: cmp r0, r6
add r3, r3, # <<
strls r3, [r0], #
bls 1b
#endif /*
* Then map first 1MB of ram in case it contains our boot params.
*/
add r0, r4, #PAGE_OFFSET >>
orr r6, r7, #(PHYS_OFFSET & 0xff000000)
.if (PHYS_OFFSET & 0x00f00000)
orr r6, r6, #(PHYS_OFFSET & 0x00f00000)
.endif
str r6, [r0] #ifdef CONFIG_DEBUG_LL
ldr r7, [r10, #PROCINFO_IO_MMUFLAGS] @ io_mmuflags
/*
* Map in IO space for serial debugging.
* This allows debug messages to be output
* via a serial console before paging_init.
*/
ldr r3, [r8, #MACHINFO_PGOFFIO]
add r0, r4, r3
rsb r3, r3, #0x4000 @ PTRS_PER_PGD*sizeof(long)
cmp r3, #0x0800 @ limit to 512MB
movhi r3, #0x0800
add r6, r0, r3
ldr r3, [r8, #MACHINFO_PHYSIO]
orr r3, r3, r7
: str r3, [r0], #
add r3, r3, # <<
teq r0, r6
bne 1b
#if defined(CONFIG_ARCH_NETWINDER) || defined(CONFIG_ARCH_CATS)
/*
* If we're using the NetWinder or CATS, we also need to map
00000313 * in the 16550-type serial port for the debug messages
00000314 */
00000315 add r0, r4, #0xff000000 >> 18
00000316 orr r3, r7, #0x7c000000
00000317 str r3, [r0]
00000318 #endif
00000319 #ifdef CONFIG_ARCH_RPC
00000320 /*
00000321 * Map in screen at 0x02000000 & SCREEN2_BASE
00000322 * Similar reasons here - for debug. This is
00000323 * only for Acorn RiscPC architectures.
00000324 */
00000325 add r0, r4, #0x02000000 >> 18
00000326 orr r3, r7, #0x02000000
00000327 str r3, [r0]
00000328 add r0, r4, #0xd8000000 >> 18
00000329 str r3, [r0]
00000330 #endif
00000331 #endif
00000332 mov pc, lr
00000333 ENDPROC(__create_page_tables)

别看这个定义这么长,其实需要关注的代码并不多。

220行,pgtbl是一个宏,定义如下:

     .macro    pgtbl, rd
ldr \rd, =(KERNEL_RAM_PADDR - 0x4000)
.endm

就是将KERNEL_RAM_PADDR - 0x4000的值赋给r4,现在关键是KERNEL_RAM_PADDR的定义:

#define KERNEL_RAM_PADDR (PHYS_OFFSET + TEXT_OFFSET)

其中PHYS_OFFSET就是SDRAM的起始地址,对于s3c6410,它的值为0x50000000,TEXT_OFFSET在arch/arm/Makefile中定义:

 TEXT_OFFSET := $(textofs-y)
export TEXT_OFFSET GZFLAGS MMUEXT

而textofs-y的定义为:

 textofs-y    := 0x00008000

因此KERNEL_RAM_PADDR的值就为0x50008000,而r4的值就为0x50004000。

225行,r0 = r4。

226行,r3 = 0。

227行,r6 = r0 + 0x4000,即0x50008000。

228到233行,将0x50004000开始到0x50008000这段内存清零。

235行,别忘了r10存的是struct proc_info_list变量的起始地址。这里将其__cpu_mm_mmu_flags成员的值赋给r7。

在分析下面的代码之前,先了解点预备知识。我们知道MMU的主要作用是将虚拟地址转换为物理地址,但是虚拟地址与物理地址的转换关系需要我们预先设置好(就是设置页表项),而转换的过程需要通过页表来完成。对于ARM来说,映射大体分为段映射和二级映射,段映射只需要一级页表,段映射的大小为1MB,二级映射需要两级页表。下面分析的代码都只用到段映射,因此只介绍段映射。

如图1所示(以ARM9为例),根据上面的分析可知,寄存器r4里存放的是一级页表的基地址,当启动MMU后,CPU发出的是虚拟地址(正确来说是修正后的虚拟地址,即MVA),然后MMU利用该地址的最高12位(MVA[31:20])做为索引值,以一级页表基地址作为起始地址索引对应的页表项,当索引到相应的页表项后,根据页表项的内容找到对应的大小为1MB的起始物理地址,然后利用MVA的低20位(MVA[19:0])索引确切的物理地址(精确到1个字节)。

ARM Linux启动代码分析

图1 段映射

具体过程如图2所示,关键看图中的虚线部分,由于页表项的大小为4字节,因此最低两位为0,也即4字节对齐,根据虚线里的值就可以找到相应页表项的起始地址。从图中也可以知道页表基地址是16KB对齐的(最低14位为0)。

ARM Linux启动代码分析

图2 获取一级描述符

有了上面的基础知识后就可以继续分析代码了。

243行,r6 = pc,保存当前PC的值。

244行,r6 = r6 >> 20。

245行,r3 = r7 | (r6 << 20)。此时,r3的值就是一个页表项的内容,也即段描述符。从这就可以知道244行的作用是清零r6的低20位。

246行,mem[r4 + r6 << 2] = r3,刚好与图2中的虚线部分对应。将r3的值存到页表相应的位置里,这样就完成了一个页表项的构建,也即完成了内核前1MB的映射。因为这里直接使用物理地址作为索引,所以虚拟地址与物理地址是直接映射关系,比如说虚拟地址0x50008000对应的物理地址也是0x50008000。后面会看到,这样做是为了开启MMU之后不用考虑太多的事情。

252行,r0 = r4 + (KERNEL_START & 0xff000000) >> 18,KERNEL_START的定义如下:

 #define KERNEL_START   KERNEL_RAM_VADDR

而KERNEL_RAM_VADDR的定义为:

 #define KERNEL_RAM_VADDR  (PAGE_OFFSET + TEXT_OFFSET)

PAGE_OFFSET的值板子对应的config文件里定义,这里为0xC0000000,因此KERNEL_START = 0xC0000000  + 0x00008000。

253行,mem[r0 + (KERNEL_START & 0x00f00000) >> 18] = r3和r0 = r0 + (KERNEL_START & 0x00f00000) >> 18。其实252行253行的意思就是mem[r4 + (0xC0008000 & 0xfff00000) >> 18] = r3,即将内核的前1MB映射到以0xC0008000为起始的虚拟内存处。

254行,r6 = KERNEL_END – 1,KERNEL_END的定义为:

00000056 #define KERNEL_END _end

而_end在arch/arm/kernel/vmlinux.lds.S中定义,表示的是内核Image的结束链接地址。

255行,r0 = r0 + 4,即下一个页表项的起始地址。

256行,r6 = r4 + r6 >> 18。

257行,比较r0,r6的值,并根据结果影响标志位。

258行,r3 = r3 + 1 << 20,即将r3的值加1MB。

259行,如果257行r0 <= r6的值就执行次句,mem[r0] = r3,r0 = r0 + 4。

260行,如果257行r0 <= r6的值就执行此句,跳转到257行。

257到260行的作用就是将整个内核Image映射到以0xC0008000为起始地址的虚拟地址处,如图3所示。

ARM Linux启动代码分析

图3 内核Image映射到虚拟地址

162行,XIP大概就是说在Flash里执行内核,而不必把内核拷贝到内存里再执行,具体没了解过,在此略过,直接到284行。

284行,r0 = r4 + PAGE_OFFSET >> 18。

285行,r6 = r7 |( PHYS_OFFSET & 0xff000000)。

289行,mem[r0] = r6,即将物理内存的前1MB映射到0xC0000000,因为这1MB里存放有bootloader传过来的启动参数,从这可以看到,映射的虚拟地址存在重叠,但并没有关系,一个虚拟地址肯定只对应一个物理地址,但一个物理地址可以对应多个虚拟地址。

291行,看名字就知道是与调试有关的,因此不分析,直接到332行,子程序返回,至此__create_page_tables分析完毕。

98行,r13 = __switch_data的地址,等会再分析__switch_data的内容。

100行,lr = __enable_mmu的物理地址。

101行,pc = r10 + PROCINFO_INITFUNC,跳到struct proc_info_list变量的__cpu_flush成员处,从arch/arm/mm/proc-v6.S文件中可以知道,那里放的是一条跳转指令:b __v6_setup。__v6_setup也是在proc-v6.S中文件中定义:

 __v6_setup:
#ifdef CONFIG_SMP
mrc p15, , r0, c1, c0, @ Enable SMP/nAMP mode
orr r0, r0, #0x20
mcr p15, , r0, c1, c0,
#endif mov r0, #
mcr p15, , r0, c7, c14, @ clean+invalidate D cache
mcr p15, , r0, c7, c5, @ invalidate I cache
mcr p15, , r0, c7, c15, @ clean+invalidate cache
mcr p15, , r0, c7, c10, @ drain write buffer
#ifdef CONFIG_MMU
mcr p15, , r0, c8, c7, @ invalidate I + D TLBs
mcr p15, , r0, c2, c0, @ TTB control register
orr r4, r4, #TTB_FLAGS
mcr p15, , r4, c2, c0, @ load TTB1
#endif /* CONFIG_MMU */
adr r5, v6_crval
ldmia r5, {r5, r6}
#ifdef CONFIG_CPU_ENDIAN_BE8
orr r6, r6, # << @ big-endian page tables
#endif
mrc p15, , r0, c1, c0, @ read control register
bic r0, r0, r5 @ clear bits them
orr r0, r0, r6 @ set them
mov pc, lr @ return to head.S:__ret

158到162行,如果CPU是双核以上的,那么就使能多核模式。

164到168行,失能数据Cache、指令cache和write buffer。

169到174行,如果支持MMU,那么失能数据和指令TLB,将r4或上TTB_FLAGS之后写入到TTB1寄存器。

175行,取得v6_crval标号的物理地址,v6_crval的定义:

     .type    v6_crval, #object
v6_crval:
crval clear=0x01e0fb7f, mmuset=0x00c0387d, ucset=0x00c0187c

其中crval是一个宏,定义如下:

.macro    crval, clear, mmuset, ucset
#ifdef CONFIG_MMU
.word \clear
.word \mmuset
#else
.word \clear
.word \ucset
#endif
.endm

这里假设是支持MMU的,因此v6_crval标号的定义替换为:

v6_crval:
.word 0x01e0fb7f
.word 0x00c0387d

176行,r5 = 0x01e0fb7f,r6 = 0x00c0387d

177到179行,大端模式相关,现在大部分CPU都工作在小端模式。

180行,读控制寄存器的值。

181行,r0 = r0 & (~r5)。

182行,r0 = r0 | r6。

183行,返回,注意,这里lr的值为__enable_mmu标号的物理地址,因为返回到__enable_mmu标号处执行,至此__v6_setup分析完毕,下面看__enable_mmu。

 __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, , r5, c3, c0, @ load domain access register
mcr p15, , r4, c2, c0, @ load page table pointer
b __turn_mmu_on
ENDPROC(__enable_mmu)

161到174行,根据配置设置相应的位,不说了。

175到179行,设置域存取寄存器。

180行,设置TTB寄存器。

181行,跳到__turn_mmu_on标号处。

 __turn_mmu_on:
mov r0, r0
mcr p15, , r0, c1, c0, @ write control reg
mrc p15, , r3, c0, c0, @ read id reg
mov r3, r3
mov r3, r13
mov pc, r3
ENDPROC(__turn_mmu_on)

需要注意的是在执行200行时,MMU已经开启,CPU以后发出的都是虚拟地址。201行,r3 = r13,而r13的值为__switch_data标号的绝对地址(虚拟地址),因此202行就跳到__switch_data标号处。

     .type    __switch_data, %object
__switch_data:
.long __mmap_switched
.long __data_loc @ r4
.long _data @ r5
.long __bss_start @ r6
.long _end @ r7
.long processor_id @ r4
.long __machine_arch_type @ r5
.long __atags_pointer @ r6
.long cr_alignment @ r7
.long init_thread_union + THREAD_START_SP @ sp

取出21行的代码执行,也即跳转到__mmap_switched标号处。

 __mmap_switched:
adr r3, __switch_data + ldmia r3!, {r4, r5, r6, r7}
cmp r4, r5 @ Copy data segment if needed
: cmpne r5, r6
ldrne fp, [r4], #
strne fp, [r5], #
bne 1b mov fp, # @ Clear BSS (and zero fp)
: cmp r6, r7
strcc fp, [r6],#
bcc 1b ARM( ldmia r3, {r4, r5, r6, r7, sp})
THUMB( ldmia r3, {r4, r5, r6, r7} )
THUMB( ldr sp, [r3, #] )
str r9, [r4] @ Save processor ID
str r1, [r5] @ Save machine type
str r2, [r6] @ Save atags pointer
bic r4, r0, #CR_A @ Clear 'A' bit
stmia r7, {r0, r4} @ Save control register values
b start_kernel
ENDPROC(__mmap_switched)

42行,获得__switch_data + 4的地址。

44行,将__data_loc的地址存到r4,_data的地址存到r5,__bss_start的地址存到r6,_end的地址存到r7。

45行,比较r4和r5的值,对于XIP,它们是不相等,这里显然是相等的,因此46到49行都不执行。

51到54行,清BSS段。

56行,r4 = processor_id,r5 = __machine_arch_type,r6 = __atags_pointer,r7 = cr_alignment,sp = init_thread_union + THREAD_START_SP。

57、58行,是对于Thumb状态的,这里啥也没做。

59到61行,将值存到对应的地址上。

62行,清掉r0的’A’位然后存到r4,该位表示数据存取是否需要对齐。

63行,保存r0,r4的值。

64行,start_kernel,欢呼吧……