昨天分析了一下SEP4020 LINUX的zImage的加载引导过程,zImage其实主要就是在重定位代码,然后就是将我们的Image镜像搬运到0x30008000位置,然后 向Image传递r0=0,r1=体系架构号,r2=参数列表基址,然后就跳到了Image去执行系统启动了,不过这中间在解压缩内核和搬运过程中是要开 MMU和CACHE的,所以其中有相当的篇幅是开这两个玩意的,下面就代码一句一句来介绍分析吧,代码位置在/arch/arm/boot /compressed/head.S中:
.section ".start", #alloc, #execinstr
/*
* sort out different calling conventions
*/
.align
start:
.type
start,#function
.rept
8
/*重复定义8次下面的指令,也就是空出中断向量表的位置*/
mov
r0, r0
/*就是nop指令*/
.endr
b
1f
.word
0x016f2818
@ 辅助引导程序的幻数
.word
start
@ 加载运行zImage的绝对地址,start表示赋的初值
.word
_edata
@ zImage end address zImage结尾地址,_edata是在vmlinux.lds.S中定义的,表示init,text,data三个段的结束位置(155行)
1:
mov
r7, r1
@ save architecture ID 保存体系结构ID 用r1保存
mov
r8, r2
@ save atags pointer 保存r2寄存器 参数列表,r0始终为0
/*
* Booting from Angel - need to enter SVC mode and disable
* FIQs/IRQs (numeric definitions from angel arm.h source).
* We only do this if we were in user mode on entry.
*/
mrs
r2, cpsr
@ get current mode
tst
r2, #3
@ not user?,tst实际上是相与
bne
not_angel
mov
r0, #0x17
@ angel_SWIreason_EnterSVC,向SWI中传递参数
swi
0x123456
@ angel_SWI_ARM这个是让用户空间调到SVC空间,这个会从前面0x0008处重新执行
not_angel:/*表示非用户模式,可以直接关闭中断*/
mrs
r2, cpsr
@ turn off interrupts to
orr
r2, r2, #0xc0
@ prevent angel from running关闭中断
msr
cpsr_c, r2
/* 注意这里可能需要做cache刷新和其他工作 */
/* 链接的时候,这里可以插入一些体系结构相关的代码,但是应该保留r7 r8 */
/*读入地址表。因为我们的代码可以在任何地址执行,也就是位置无关代码(PIC),所以我们需要加上一个偏移量。
下面有每一个列表项的具体意义。
LC0是表的首项,它本身就是在此head.s中定义的
.type
LC0, #object
LC0:
.word
LC0
@ r1 LC0表的起始位置
.word
__bss_start
@ r2 bss段的起始地址
.word
_end
@ r3 zImage(bss)连接的结束地址在vmlinux.lds.S中定义
.word
zreladdr
@ r4 zImage的连接地址,我们在mach-sep4020/makefile.boot中定义的
.word
_start
@ r5 zImage的基地址,bootp/init.S中的_start函数,主要起传递参数作用
.word
_got_start
@ r6 GOT(全局偏移表)起始地址,_got_start是在compressed/vmlinux.lds.in中定义的
.word
_got_end
@ ip GOT结束地址
.word
user_stack+4096
@ sp 用户栈底 user_stack是紧跟在bss段的后面的,在compressed/vmlinux.lds.in中定义的
在本head.S的末尾定义了zImag的临时栈空间,在这里分配了4K的空间用来做堆栈。
.section ".stack", "w"
user_stack:
.space
4096
GOT表的初值是连接器指定的,当时程序并不知道代码在哪个地址执行。如果当前运行的地址已经和表上的地址不一样,还要修正GOT表。*/
.text
adr
r0, LC0
ldmia
r0, {r1, r2, r3, r4, r5, r6, ip, sp}
@r0是运行时地址,而r1则是链接时地址,而它们两都是表示LC0表的起始位置,这样他们两的差则是运行和链接的偏移量,纠正了这个偏移量才可以运行与”地址相关的代码“
subs
r0, r0, r1
@ calculate the delta offset
@ if delta is zero, we are
beq
not_relocated
@ running at the address we
@ were linked at.若相等则不用重定位了。
/*
* 偏移量不为零,说明运行在不同的地址,那么需要修正几个指针
* r5 – zImage基地址
* r6 – GOT(全局偏移表)起始地址
* ip – GOT结束地址
*/
add
r5, r5, r0 /*加上偏移量*/
add
r6, r6, r0
add
ip, ip, r0 /*ip即是r12*/
/*
* If we're running fully PIC === CONFIG_ZBOOT_ROM = n,
* we need to fix up pointers into the BSS region.
* 这时需要修正BSS区域的指针,我们平台适用。
* r2 – BSS 起始地址
* r3 – BSS 结束地址
* sp – 堆栈指针
*/
add
r2, r2, r0
add
r3, r3, r0
add
sp, sp, r0
/*
* 重新定位GOT表中所有的项.
*/
1:
ldr
r1, [r6, #0]
@ relocate entries in the GOT
add
r1, r1, r0
@ table. This fixes up the
str
r1, [r6], #4
@ C references.
cmp
r6, ip
blo
1b
not_relocated:
mov
r0, #0
/*清除bss段*/
1:
str
r0, [r2], #4
@ clear bss
str
r0, [r2], #4
str
r0, [r2], #4
str
r0, [r2], #4
cmp
r2, r3
blo
1b
@ @ 正如下面的注释所说,C环境我们已经设置好了。下面我们要打开cache和mmu。为什么要这样做呢?
@ 这只是一个解压程序呀?为了速度。那为什么要开mmu呢,而且只是做一个平板式的映射?还是为了速度。
@ 如果不开mmu的话,就只能打开icache。因为不开mmu的话就无法实现内存管理,而io区是决不能开dcache的。
/* 这时C运行环境应该已经配置好了。
* 打开cache,设置一些指针,开始解压vmlinux
*/
bl
cache_on
/************************************进入cache_on函数******************************************************/
/*
* Turn on the cache. We need to setup some page tables so that we
* can have both the I and D caches on.
*
* We place the page tables 16k down from the kernel execution address,
* and we hope that nothing else is using it. If we're using it, we
* will go pop!
*
* On entry,
* r4 = kernel execution address
* r6 = processor ID
* r7 = architecture number
* r8 = atags pointer
* r9 = run-time address of "start" (???)
* On exit,
* r1, r2, r3, r9, r10, r12 corrupted
* This routine must preserve:
* r4, r5, r6, r7, r8
*/
.align
5
cache_on:
mov
r3, #8
@ cache_on function
b
call_cache_fn
call_cache_fn:
adr
r12, proc_types
mrc
p15, 0, r6, c0, c0
@ get processor ID
1:
ldr
r1, [r12, #0]
@ get value
ldr
r2, [r12, #4]
@ get mask
eor
r1, r1, r6
@ (real ^ match)将从c0中读出的cpu id与下面的proc_types表中的cpu系列进行比较可得到其属于哪个系列的
tst
r1, r2
@ & mask
addeq
pc, r12, r3
@ 如果是这个系列的cpu调用其cache打开函数
add
r12, r12, #4*5
b
1b
.type
proc_types,#object
proc_types:
.word
0x41560600
@ ARM6/610
.word
0xffffffe0
b
__arm6_cache_off
@ works, but slow
b
__arm6_cache_off
mov
pc, lr
.word
0x00000000
@ old ARM ID
.word
0x0000f000
mov
pc, lr
mov
pc, lr
mov
pc, lr
.word
0x41007000
@ ARM7/710
.word
0xfff8fe00
b
__arm7_cache_off
b
__arm7_cache_off
mov
pc, lr
.word
0x41807200
@ ARM720T (writethrough)
.word
0xffffff00
b
__armv4_cache_on
b
__armv4_cache_off
mov
pc, lr
.size
proc_types, . - proc_types
__armv4_cache_on:
mov
r12, lr /*在后面的cache_on函数返回的时候会用到的*/
bl
__setup_mmu
/************************************进入__setup_mmu函数******************************************************/
__setup_mmu:
sub
r3, r4, #16384
@ Page directory size(16k),r4是zImage的起始位置,再减16k即是0x30004000
bic
r3, r3, #0xff
@ Align the pointer
bic
r3, r3, #0x3f00
/*
* Initialise the page tables, turning on the cacheable and bufferable
* bits for the RAM area only.
* 在这里只建立了一级虚实映射,是虚实一一映射的,映射的大小为4GB
*/
mov
r0, r3
mov
r9, r0, lsr #18
mov
r9, r9, lsl #18
@ start of RAM,当前可用sdram的起始地址(以256k为边界)
add
r10, r9, #0x10000000
@ a reasonable RAM size,这里假设的可用ram大小为256M
mov
r1, #0x12
/*填充段描述符的第五位*/
orr
r1, r1, #3 << 10
/*段描述符的AP为11b*/
add
r2, r3, #16384
/*段描述符的空间大小为16k*/
1:
cmp
r1, r9
@ if virt > start of RAM只有虚空间在sdram中才是可cache和可buffer
orrhs
r1, r1, #0x0c
@ set cacheable, bufferable
cmp
r1, r10
@ if virt > end of RAM
bichs
r1, r1, #0x0c
@ clear cacheable, bufferable
str
r1, [r0], #4
@ 1:1 mapping
add
r1, r1, #1048576
/*每次描述符的地址内容是自加0x100000*/
teq
r0, r2
bne
1b
/*
* 在这里如果我们是从flash上直接启动,我们也可以将flash这快空间映射为可cache和可buffer的,这样可以加快这段代码的运行速度
*/
mov
r1, #0x1e
orr
r1, r1, #3 << 10
mov
r2, pc, lsr #20
orr
r1, r1, r2, lsl #20
add
r0, r3, r2, lsl #2
str
r1, [r0], #4
add
r1, r1, #1048576
str
r1, [r0]
mov
pc, lr
/************************************从__setup_mmu函数返回****************************************************/
mov
r0, #0
mcr
p15, 0, r0, c7, c10, 4
@ 济干write buffer
mcr
p15, 0, r0, c8, c7, 0
@ 失效I/D TLBs
mrc
p15, 0, r0, c1, c0, 0
@ read control reg
orr
r0, r0, #0x5000
@ I-cache enable, RR cache replacement
orr
r0, r0, #0x0030
bl
__common_cache_on
/************************************进入__common_cache_on函数********************************************/
__common_cache_on:
mov
r1, #-1
mcr
p15, 0, r3, c2, c0, 0
@ load page table pointer
mcr
p15, 0, r1, c3, c0, 0
@ load domain access control所有域都是可读可写
mcr
p15, 0, r0, c1, c0, 0
@ load control register赋值cp15的控制寄存器,这时候开MMU,cache
mov
pc, lr
/******************************从__common_cache_on函数返回***************************************************/
mov
r0, #0
mcr
p15, 0, r0, c8, c7, 0
@ 失效I/D TLBs
mov
pc, r12
/******************************从cache_on函数返回*************************************************************/
mov
r1, sp
@ malloc space above stack
add
r2, sp, #0x10000
@ 64k max解压缩的缓冲区
下面是接着第二节往下的:
@ 对下面这些地址的理解其实还是很麻烦,但有篇文档写得很清楚《About TEXTADDR, ZTEXTADDR,
@ PAGE_OFFSET etc...》。下面程序的意义就是保证解压地址和当前程序的地址不重叠。上面分配了64KB的空间来做解压时的数据缓存。
/*
检查是否会覆盖内核映像本身
* r4 = 最后我们的Image内核执行的最终实地址
* r5 = 本映像zImage的起始地址
* r2 = 分配空间的结束地址(并且处于本映像的前面)
* 基本要求:r4 >= r2 或者 r4 + 映像长度 <= r5
在实际的调试中我们的SEP4020的各个寄存器:
r0 = 0;
r1 = 0x30180358;
r2 = 0x30190358;
r3 = 0x30004000;
r4 = 0x30008000;
r5 = 0x30008000;
r6 = 0x41807202;
r7 = 0x000000c2
*/
cmp
r4, r2
bhs
wont_overwrite
/*如果大于或等于的话*/
add
r0, r4, #4096*1024
@ 4MB largest kernel size
cmp
r0, r5
bls
wont_overwrite
/*如果r4 + 映像长度 <= r5 的话*/
@ 如果空间不够了,只好解压到缓冲区地址后面。调用decompress_kernel进行解压缩,这段代码是用c实现的,和架构无关。
mov
r5, r2
@ decompress after malloc space
mov
r0, r5
/*解压程序从分配空间后面存放 */
mov
r3, r7
bl
decompress_kernel
/******************************进入decompress_kernel***************************************************/
@ decompress_kernel共有4个参数,解压的内核地址、缓存区首地址、缓存区尾地址、和芯片ID,返回解压缩代码的长度。注意r5会在其中改变的
ulg
decompress_kernel(ulg output_start, ulg free_mem_ptr_p, ulg free_mem_ptr_end_p,
int arch_id)
{
output_data
= (uch *)output_start;
/* Points to kernel start */
free_mem_ptr
= free_mem_ptr_p;
free_mem_ptr_end
= free_mem_ptr_end_p;
__machine_arch_type
= arch_id;
arch_decomp_setup(); /*在sep4020中什么都没作*/
makecrc();
/*镜像校验*/
putstr("Uncompressing Linux...");
gunzip();
/*通过free_mem_ptr来解压缩*/
putstr(" done, booting the kernel./n");
return output_ptr;
/*返回镜像的大小*/
}
/******************************从decompress_kernel函数返回*************************************************/
add
r0, r0, #127
bic
r0, r0, #127
@ align the kernel length对齐内核长度
/*
* r0 = 解压后内核长度
0x002ec480
* r1-r3 = 未使用
* r4 = 真正内核执行地址
0x30008000
* r5 = 临时解压内核Image的起始地址
0x3019149c
* r6 = 处理器ID
0x41807202
* r7 = 体系结构ID
0x000000c2
* r8 = 参数列表
0x30000100
* r9-r14 = 未使用
*/
@ 完成了解压缩之后,由于空间不够,内核也没有解压到正确的地址,最后必须通过代码搬移来搬到指定的地址0x30008000。搬运过程中有
@ 可能会覆盖掉现在运行的这段代码,所以必须将有可能会执行到的代码搬运到安全的地方,
@ 这里帮运到的地址是解压缩了的代码的后面r5+r0=0x3047d91c的位置。
add
r1, r5, r0
@ end of decompressed kernel
adr
r2, reloc_start
ldr
r3, LC1
@ LC1:
.word
reloc_end - reloc_start 表示reloc_start段代码的大小
add
r3, r2, r3
1:
ldmia
r2!, {r9 - r14}
@ copy relocation code
stmia
r1!, {r9 - r14}
ldmia
r2!, {r9 - r14}
stmia
r1!, {r9 - r14}
cmp
r2, r3
blo
1b
bl
cache_clean_flush
add
pc, r5, r0
@ call relocation code
@ 在此处会调用重定位代码reloc_start来将Image 的代码从缓冲区r5帮运到最终的目的地r4:0x30008000处
/*
* All code following this line is relocatable. It is relocated by
* the above code to the end of the decompressed kernel image and
* executed there. During this time, we have no stacks.
*
* r0 = decompressed kernel length 0x002ec480
* r1-r3 = unused
* r4 = kernel execution address
0x30008000
* r5 = decompressed kernel start
0x3019149c
* r6 = processor ID
0x41807202
* r7 = architecture ID
0x000000c2
* r8 = atags pointer
0x30000100
* r9-r14 = corrupted
*/
.align
5
reloc_start:
add
r9, r5, r0
debug_reloc_start
mov
r1, r4
1:
.rept
4
ldmia
r5!, {r0, r2, r3, r10 - r14}
@ relocate kernel
stmia
r1!, {r0, r2, r3, r10 - r14}
/*重新帮运内核Image的过程*/
.endr
cmp
r5, r9
blo
1b
debug_reloc_end
call_kernel:
bl
cache_clean_flush
bl
cache_off
mov
r0, #0
@ must be zero
mov
r1, r7
@ restore architecture number
mov
r2, r8
@ restore atags pointer
@ 这个地方就是最终我们从zImage跳转到Image的伟大一跳了,跳之前准备好r0,r1,r2
mov
pc, r4
@ call kernel