写这个总结的时分咱的心境是沉重的，由于还有许多东西没弄了解。。。感叹自己的常识仍是浅陋得很，出路钱途漫漫阿～～不过底子头绪是清楚的，详细的细节只能留在今后有时刻再啃了。这儿的第二部分发动流程指的是解压后kernel开端履行的一部分代码，这部分代码和ARM体系结构是紧密联系在一起的，所以最好是将ARM ARCHITECTURE REFERENCE MANUL细心读读，特别里边关于操控寄存器啊，MMU方面的内容～
前面说过解压今后，代码会跳到解压完结今后的vmlinux开端履行，详细从什么地方开端履行咱们能够看看生成的vmlinux.lds(arch/arm/kernel/)这个文件：
view plaincopy to clipboardprint?
OUTPUT_ARCH(arm)
ENTRY(stext)
jiffies = jiffies_64;
SECTIONS
{
. = 0x80000000 + 0x00008000;
.text.head : {
_stext = .;
_sinittext = .;
*(.text.h
OUTPUT_ARCH(arm)
ENTRY(stext)
jiffies = jiffies_64;
SECTIONS
{
. = 0x80000000 + 0x00008000;
.text.head : {
_stext = .;
_sinittext = .;
*(.text.h
很明显咱们的vmlinx最最初的section是.text.head，这儿咱们不能看ENTRY的内容，认为这时分咱们没有操作系统，底子不知道如何来解析这儿的进口地址，咱们只能来剖析他的section(不过一般来说这儿的ENTRY和咱们从seciton剖析的结果是相同的)，这儿的.text.head section咱们很简略就能在arch/arm/kernel/head.S里边找到，并且它里边的第一个符号便是咱们的stext：
view plaincopy to clipboardprint?
.section “.text.head”, “ax”
Y(stext)
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
.section “.text.head”, “ax”
ENTRY(stext)
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
这儿的ENTRY这个宏实践咱们能够在include/linux/linkage.h里边找到，能够看到他实践上便是声明一个GLOBAL Symbol，后边的ENDPROC和END仅有的区别是前面的声明晰一个函数，能够在c里边被调用。
view plaincopy to clipboardprint?
#ifndef ENTRY
#define ENTRY(name) /
.globl name; /
ALIGN; /
name:
#endif
#ifndef WEAK
#define WEAK(name) /
.weak name; /
name:
#endif
#ifndef END
#define END(name) /
.size name, .-name
#endif
/* If symbol name is treated as a subroutine (gets called, and returns)
* then please use ENDPROC to mark name as STT_FUNC for the benefit of
* static analysis tools such as stack depth analyzer.
*/
#ifndef ENDPROC
#define ENDPROC(name) /
.type name, @function; /
END(name)
#endif
#ifndef ENTRY
#define ENTRY(name) /
.globl name; /
ALIGN; /
name:
#endif
#ifndef WEAK
#define WEAK(name) /
.weak name; /
name:
#endif
#ifndef END
#define END(name) /
.size name, .-name
#endif
/* If symbol name is treated as a subroutine (gets called, and returns)
* then please use ENDPROC to mark name as STT_FUNC for the benefit of
* static analysis tools such as stack depth analyzer.
*/
#ifndef ENDPROC
#define ENDPROC(name) /
.type name, @function; /
END(name)
#endif
找到了vmlinux的开端代码咱们就来进行剖析了，先整体归纳一下这部分代码所完结的功用，head.S会首要查看proc和arch以及atag的有效性，然后会树立初始化页表，并进行CPU必要的处理今后翻开MMU，并跳转到start_kernel这个symbol开端履行后边的C代码。这儿有许多变量都是咱们进行kernel移植时需求特别注意的，下面会逐个讲到。
在这儿咱们首要看看这段汇编开端跑的时分的寄存器信息，这儿的寄存器内容实践上是同bootloader跳转到解压代码是相同的，便是r1=arch r2=atag addr。下面咱们就详细来看看这个head.S跑的进程：
view plaincopy to clipboardprint?
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
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
首要进入SVC形式并封闭一切中止，并从arm协处理器里边读到CPU ID，这儿的CPU首要是指arm架构相关的CPU类型，比方ARM9，ARM11等等。
view plaincopy to clipboardprint?
然后跳转到__lookup_processor_type，这个函数界说在head-common.S里边，这儿的bl指令会保存当时的pc在lr里边，最终__lookup_processor_type会从这个函数回来，咱们详细看看这个函数：
view plaincopy to clipboardprint?
__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
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
ENDPROC(__lookup_processor_type)
__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
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
ENDPROC(__lookup_processor_type)
他这儿的履行进程其实比较简略便是在__proc_info_begin和__proc_info_end这个段里边里边去读取咱们注册在里边的proc_info_list这个结构体，这个结构体的界说在arch/arm/include/asm/procinfo.h，详细完结依据你运用的cpu的架构在arch/arm/mm/里边找到详细的完结，这儿咱们运用的ARM11是proc-v6.S，咱们能够看看这个结构体：
view plaincopy to clipboardprint?
.section “.proc.info.init”, #alloc, #execinstr
/*
* Match any ARMv6 processor core.
*/
.type __v6_proc_info, #object
_proc_info:
.long 0x0007b000
.long 0x0007f000
.long PMD_TYPE_SECT | /
PMD_SECT_BUFFERABLE | /
PMD_SECT_CACHEABLE | /
PMD_SECT_AP_WRITE | /
PMD_SECT_AP_READ
.long PMD_TYPE_SECT | /
PMD_SECT_XN | /
PMD_SECT_AP_WRITE | /
PMD_SECT_AP_READ
b __v6_setup
.long cpu_arch_name
.long cpu_elf_name
.long HWCAP_SWP|HWCAP_HALF|HWCAP_THUMB|HWCAP_FAST_MULT|HWCAP_EDSP|HWCAP_JAVA
.long cpu_v6_name
.long v6_processor_functions
.long v6wbi_tlb_fns
.long v6_user_fns
.long v6_cache_fns
.size __v6_proc_info, . – __v6_proc_info
.section “.proc.info.init”, #alloc, #execinstr
/*
* Match any ARMv6 processor core.
*/
.type __v6_proc_info, #object
__v6_proc_info:
.long 0x0007b000
.long 0x0007f000
.long PMD_TYPE_SECT | /
PMD_SECT_BUFFERABLE | /
PMD_SECT_CACHEABLE | /
PMD_SECT_AP_WRITE | /
PMD_SECT_AP_READ
.long PMD_TYPE_SECT | /
PMD_SECT_XN | /
PMD_SECT_AP_WRITE | /
PMD_SECT_AP_READ
b __v6_setup
.long cpu_arch_name
.long cpu_elf_name
.long HWCAP_SWP|HWCAP_HALF|HWCAP_THUMB|HWCAP_FAST_MULT|HWCAP_EDSP|HWCAP_JAVA
.long cpu_v6_name
.long v6_processor_functions
.long v6wbi_tlb_fns
.long v6_user_fns
.long v6_cache_fns
.size __v6_proc_info, . – __v6_proc_info
对着.h咱们就知道各个成员变量的意义了，他这儿lookup的进程实践上是先求出这个proc_info_list的实践物理地址，并将其内容读出，然后将其间的mask也便是咱们这儿的0x007f000与寄存器与之后与0x007b00进行比较，假如相同的话呢就校验成功了，假如不相同呢就会读下一个proc_info的信息，由于proc一般都是只要一个的，所以这儿一般不会循环，假如检测正确寄存器就会将正确的proc_info_list的物理地址赋给寄存器，假如检测不到就会将寄存器值赋0，然后经过LR回来。
view plaincopy to clipboardprint?
bl __lookup_machine_type @ r5=machinfo
movs r8, r5 @ invalid machine (r5=0)?
beq __error_a @ yes, error a
bl __lookup_machine_type @ r5=machinfo
movs r8, r5 @ invalid machine (r5=0)?
beq __error_a @ yes, error a
检测完proc_info_list今后就开端检测machine_type了，这个函数的完结也在head－common.S里边，咱们看看它详细的完结：
view plaincopy to clipboardprint?
__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
ENDPROC(__lookup_machine_type)
__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
ENDPROC(__lookup_machine_type)
这儿的进程底子上是同proc的查看是相同的，这儿首要查看芯片的类型，比方咱们现在的芯片是MSM7X27FFA，这也是一个结构体，它的头文件在arch/arm/include/asm/arch/arch.h里边(machine_desc)，它详细的完结依据你对芯片类型的挑选而不同，这儿咱们运用的是高通的7×27,详细完结在arch/arm/mach-msm/board-msm7x27.c里边，这些结构体最终都会注册到_arch_info_begin和_arch_info_end段里边，详细的咱们能够看看vmlinux.lds或许system.map，这儿的lookup会依据bootloader传过来的nr来在__arch_info里边的相匹配的类型，没有的话就寻觅下一个machin_desk结构体，直到找到相应的结构体，并会将结构体的地址赋值给寄存器，假如没有的话就会赋值为0的。一般来说这儿的machine_type会有好几个，由于不同的芯片类型或许运用的都是同一个cpu架构。
对processor和machine的查看完今后就会查看atags parameter的有效性，关于这个atag详细的界说咱们能够在./include/asm/setup.h里边看到，它实践是一个结构体和一个联合体构成的结合体，里边的size都是以字来核算的。这儿的atags param是bootloader创立的，里边包含了ramdisk以及其他memory分配的一些信息，存储在boot.img头部结构体界说的地址中，详细的咱们能够看咱今后对bootloader的剖析～
view plaincopy to clipboardprint?
__vet_atags:
tst r2, #0x3 @ aligned?
bne 1f
ldr r5, [r2, #0] @ is first tag ATAG_CORE?
cmp r5, #ATAG_CORE_SIZE
cmpne r5, #ATAG_CORE_SIZE_EMPTY
bne 1f
ldr r5, [r2, #4]
ldr r6, =ATAG_CORE
cmp r5, r6
bne 1f
mov pc, lr @ atag pointer is ok
1: mov r2, #0
mov pc, lr
ENDPROC(__vet_atags)
__vet_atags:
tst r2, #0x3 @ aligned?
bne 1f
ldr r5, [r2, #0] @ is first tag ATAG_CORE?
cmp r5, #ATAG_CORE_SIZE
cmpne r5, #ATAG_CORE_SIZE_EMPTY
bne 1f
ldr r5, [r2, #4]
ldr r6, =ATAG_CORE
cmp r5, r6
bne 1f
mov pc, lr @ atag pointer is ok
1: mov r2, #0
mov pc, lr
ENDPROC(__vet_atags)
这儿对atag的查看首要查看其是不是以ATAG_CORE最初，size对不对，底子没什么好剖析的，代码也比较美观～ 下面咱们来看后边一个重头戏，便是创立初始化页表，说实话这段内容我没弄清楚，它需求对ARM VIRT MMU具有适当的了解，这儿我没有太多的时刻去剖析spec，仅仅大略了翻了ARM V7的manu，知道这儿树立的页表是arm的secition页表，完结内存开端1m内存的映射，这个页表树立在kernel和atag paramert之间，一般是4000-8000之间～详细的代码和进程我这儿就不贴了，咱们能够看看参阅的链接，看看其他大虾的剖析，我还没怎么看了解，等今后细心研讨ARM MMU的时分再回头来细心研讨了，不过代码尽管不剖析，这儿有几个重要的地址需求特别剖析下～
这几个地址都界说在arch/arm/include/asm/memory.h，咱们来稍微分析下这个头文件，首要它包含了arch/memory.h，咱们来看看arch/arm/mach-msm/include/mach/memory.h，在这个里边界说了#define PHYS_OFFSET UL(0x00200000) 这个实践上是memory的物理内存初始地址，这个地址和咱们曾经在boardconfig.h里边界说的是共同的。然后咱们再看asm/memory.h，他里边界说了咱们的memory虚拟地址的首地址#define PAGE_OFFSET UL(CONFIG_PAGE_OFFSET)。
别的咱们在head.S里边看到kernel的物理或许虚拟地址的界说都有一个偏移，这个偏移又是从哪来的呢，实践咱们能够从arch/arm/Makefile里边找到：textofs-y := 0x00008000 TEXT_OFFSET := $(textofs-y) 这样咱们再看kernel发动时分的物理地址和链接地址，实践上它和咱们前面在boardconfig.h和Makefile.boot里边界说的都是共同的～
树立初始化页表今后，会首要将__switch_data这个symbol的链接地址放在sp里边，然后获得__enable_mmu的物理地址，然后会跳到__proc_info_list里边的INITFUNC履行，这个偏移是界说在arch/arm/kernel/asm-offset.c里边，实践上便是获得__proc_info_list里边的__cpu_flush这个函数履行。
view plaincopy to clipboardprint?
ldr r13, __switch_data @ address to jump to after
@ mmu has been enabled
adr lr, __enable_mmu @ return (PIC) address
add pc, r10, #PROCINFO_INITFUNC
ldr r13, __switch_data @ address to jump to after
@ mmu has been enabled
adr lr, __enable_mmu @ return (PIC) address
add pc, r10, #PROCINFO_INITFUNC
这个__cpu_flush在这儿便是咱们proc-v6.S里边的__v6_setup函数了，详细它的完结我就不剖析了，都是对arm操控寄存器的操作，这儿转一下它对这部分操作的注释，看完之后就底子知道它完结的功用了。
/*
* __v6_setup
*
* Initialise TLB, Caches, and MMU state ready to switch the MMU
* on. Return in r0 the new CP15 C1 control register setting.
*
* We automatically detect if we have a Harvard cache, and use the
* Harvard cache control instructions insead of the unified cache
* control instructions.
*
* This should be able to cover all ARMv6 cores.
*
* It is assumed that:
* – cache type register is implemented
*/
完结这部分关于CPU的操作今后，下面便是翻开MMU了，这部分内容也没什么好说的，也是对arm操控寄存器的操作，翻开MMU今后咱们就能够运用虚拟地址了，而不需求咱们自己来进行地址的重定位，ARM硬件会完结这部分的作业。翻开MMU今后，会将SP的值赋给PC，这样代码就会跳到__switch_data来运转，这个__switch_data是一个界说在head-common.S里边的结构体，咱们实践上是跳到它地一个函数指针__mmap_switched处履行的。
这个switch的履行进程咱们仅仅简略看一下，前面的copy data_loc段以及清空.bss段就不用说了，它后边会将proc的信息和machine的信息保存在__switch_data这个结构体里边，而这个结构体将来会在start_kernel的setup_arch里边被运用到。这个在后边的对start_kernel的详细剖析中会讲到。别的这个switch还涉及到操控寄存器的一些操作，这儿我不没细心研讨spec，不明白也就不说了～
好啦，switch操作完结今后就会b start_kernel了～ 这样就进入了c代码的运转了，下一篇文章细心研讨这个start_kernel的函数～～
