Question

一  分析

电子版下载地址：进入我的资源就能找到

http://download.csdn.net/detail/innost/4834459

本节介绍Kernel启动。此时Piggy已经将vimlinux解压，BL将执行权限传给了Kernel。

代码在arch/arm/kernel/head.S中。相关代码如下：

//将采用C/C++注释语句

/*

   .section是GNU ASM的语法。格式如下：

    .section name[,"flags"[,@type]]   其中，name是必须的，flags是可选。

    "ax"表示：a为section is allocatable,x为executable。

*/

   .section ".text.head", "ax"

 

//这个ENTRY(stext)有相当的含义。在kernel/vmlinux.ld.S中，也定义了一个ENTRY。在ld

//语法中，ENTRY是一个command，用来定义入口点。所以，这里就是kernel执行的入口点函数。

ENTRY(stext)

   /*

     MSR:是ARM汇编指令，用来将数据copy到status register寄存器中。cpsr_c表示要操作

     CPSR寄存器的Control标志。

   */

  

    msr    cpsr_c, #PSR_F_BIT | PSR_I_BIT | SVC_MODE @ ensure svc mode

                        @ and irqs disabled

1.1  MSR设置I/F和CPU Mode

CPSR全称是Current Process Status Register，用来表示当前CPU的状态，也可用于控制。相关控制位如图1所示：

图1 CPSR控制位

由图1可知：

q  N/Z/C/V控制位用来表示负/零/进位/溢出，属于User Flags，即可在UserMode下操作。A

q  I/F表示Interrupt和Fast Interrupt使能位。

q  Mode用来控制CPU当前的模式。ARM CPU一共有7种模式。

根据上面的代码，首先将禁止I/F中断，并进入Supervisor模式，也就是OS运行的模式。图2为ARM CPU支持的CPU模式。

图2  ARM CPU支持的运行模式

另外，MSR指令操作的格式如下：

图3  MSR指令格式

其中最重要的是fields，目前支持：

q  c：设置control bit。对应位为16。

q  x：设置extension bit。对应位为17。

q  s：设置status bit。对应位为18。

q  f：设置flags field。对应位为19。

图4 MSR二进制格式

直接看上面的解释，还不是很清楚，因为设置的是MSR指令本身的内容，具体对应到CPSR呢，则可通过下面的伪语句得到：

图5 MSR 设置说明

从代码可知：

msr    cpsr_c, #PSR_F_BIT | PSR_I_BIT | SVC_MODE

//上面代码将设置CPSR的0到第7位，刚好是控制I/F和设置CPU模式的。

1.2  ARM CP15协处理器控制

设置好CPU模式后，下面的工作就是获取CPU的信息。在ARM中，协处理（coprocessor）15中用于管理CPU信息和MMU相关的工作。CP15也是ARM中最重要的处理器，以后会经常碰到。

先看下面这条语句：

    mrc    p15, 0, r9, c0, c0        @ get processor id

MRC是ARM指令，用来从协处理对应的寄存器读取信息到CPU的寄存器，对应写协处理寄存器的指令是MCR。二者的语法格式（注意，是操作CP15的时候）如图6所示：

图6  MRC操作CP15的格式说明

q  Rd：本指令用得是R9，也就是协处理的信息会保存到R9中。

q  CRn：MRC中协处理器的主要寄存器。此处用得是C0。标准写法是C0，C1一直到C15。

q  CRm：附属信息。如果没有附属信息，则使用C0。

q  opcode2，类似附属信息。根据CRn来决定是否需要。如果不指定，则使用0。

CP15有很重要的作用，可通过操作CP15的寄存器来控制它。如图7所示：

图7  CP15各个寄存器的作用

先来看此处操作的C0寄存器。

opcode2在指令中默认是0，所以将取出Main ID register的信息。

得到的结果将怎么使用呢？来看下一句指令：

bl    __lookup_processor_type        @ r5=procinfo r9=cpuid

BL是ARM中的跳转指令，相当于调用函数吧。__lookup_processor_type用来得到CPU信息。注意，这个函数调用的参数是R9，R9的值是从CP15 C0寄存器读取出来的，而是是Main ID。下面看看此函数如何处理R9。

1.3  __lookup_procesoor_type分析

该函数在head-Common.S中定义。下面逐行分析它，这里会碰到几个重要的指令及其用法。

__lookup_processor_type:

    //adr是一条伪指令，其作用是将3f标签的地址赋给R3。这个伪指令其实是可拆分成多条指令

   //由于后面的3f是相对当前PC位置而言，所以R3实际上存储的是3f的物理地址。

    adr    r3, 3f//f是forward之意。标志3在此代码之后声明

    /*

   ldm是load multiple register的意思，它的作用是将[r3]对应的内存内容存储到r5,r6,

    r7寄存器中。DA是Decrease After的意思。ARM汇编在这里有4种模式,DA,IA,DB,IB等

    此处的ldmda，将把3F所在的内容依序传递给R7，R6，R5。每传递一次，R3递减4个字节。

    */

    ldmda    r3, {r5 - r7}

上面语句执行完后：

q  R5=__proc_info_begin，这个值是虚地址。

q  R6=__proc_info_end。

q  R7=.。

以上几个值都是虚地址。__proc_info_begin/end是ld在链接时候指定的信息。

图8  arc/arm/kernel/vmlinx.lds.S文件

从中可以看出，__proc_info_begin/end包含了代码中定义在.proc.info.init段的内容。如图9所示。

图9  proc-V7.s定义的proc.info.init的内容

为什么是proc -v7.S文件呢，因为goldfish编译的就是这个文件。从图9可以看出，其实也就是定义了一个数据结构罢了。

接着来看代码

    //r3指向3f的物理地址，r7指向虚拟地址，而现在只能访问物理地址，所以需要找到一个offset

    sub    r3, r3, r7        @ get offset between virt&phys

    add    r5, r5, r3        @ convert virt addresses to

    add    r6, r6, r3        @ physical address space

经过上面的换算，r5,r6现在都指向__proc_info_begin/end的物理地址了。

    //ldmia将[r5]的内存信息存储到r3，r4中，每完成一次传输，r5自动加4.

1:  ldmia  r5, {r3, r4}        @ value, mask

    //下面将测试R9和mask之后的值是否是我们想要的r3的值。根据图9。应该是0x000f0000。

   //在Main ID register中，这表明[16-19]位是都是1.

    and    r4, r4, r9        @ mask wanted bits

    teq    r3, r4

    beq    2f   //如果是我们想要的数据，则跳转到2f

    //否则跳过一个PROC_INFO_SIZE，继续找，一般只有一个PROC_INFO结构体。

    add    r5, r5, #PROC_INFO_SZ    @ sizeof(proc_info_list)

    cmp    r5, r6

    blo    1b

   //如果没找到，则设置R5寄存器为0

    mov    r5, #0            @ unknown processor

2:  mov    pc, lr   //从函数返回

ENDPROC(__lookup_processor_type)

 

/*

 * 提供一个C接口的lookup_process_type函数

 */

ENTRY(lookup_processor_type)

    stmfd    sp!, {r4 - r7, r9, lr}

    mov    r9, r0

    bl    __lookup_processor_type

    mov    r0, r5

    ldmfd    sp!, {r4 - r7, r9, pc}

ENDPROC(lookup_processor_type)

 

    .long    __proc_info_begin

    .long    __proc_info_end

3:    .long    .

    .long    __arch_info_begin

    .long    __arch_info_end

lookup_process_type其实比较简单，这里就不再多说。但图9的内容以后还要回过头来继续介绍。那里将初始化CPU MMU相关的内容。

    //如果r5为空，则表示CPU信息获取是否，调用__error_p，退出整个启动

    movs    r10, r5                @ invalid processor (r5=0)?

    beq    __error_p            @ yes, error 'p'

 

否则，将调用__lookup_machine_type获取机器信息。

1.4  __lookup_machine_type分析

该函数也是在head-comm.S中定义的。

__lookup_machine_type:

    adr    r3, 3b  //b是backward的意思。标志3在此代码之前声明。

    //r4,r5,r6分别指向 label 3，__arch_info_begin和__arch_info_end

    ldmia    r3, {r4, r5, r6} 

    sub    r3, r3, r4

    add    r5, r5, r3

    add    r6, r6, r3

   //以上将得到__arch_info_begin/end的物理地址

 

1:  ldr    r3, [r5, #MACHINFO_TYPE]

    //比较r1和MACHINFO_TYPE是不是一致。注意，r1的值是BL传递给它的

    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)

这里涉及到另一个关键数据结构，也就是定义在.arch.info.init段中的。如图10所示：

图10  .arch.info.init段

从图10可知，这个段其实对应了一个数据结构，即machine_desc.在我们的goldfish平台中，它是这么定义的：

[arch/arm/mach-goldfish/board-goldfish.c]

//还需要加上：

   nr = MACH_TYPE_GOLDFISH

   name = "Goldfish"

MACHINE_START(GOLDFISH, "Goldfish")

    .phys_io    = IO_START,

    .io_pg_offst    = ((IO_BASE) >> 18) & 0xfffc,

    .boot_params    = 0x00000100,

    .map_io        = goldfish_map_io,

    .init_irq    = goldfish_init_irq,

    .init_machine    = goldfish_init,

    .timer        = &goldfish_timer,

MACHINE_END

完整的machine_desc定义如图11所示：

图11 machine_desc定义

在Goldfish中，nr为1441。详情可参考arch/arm/tools/machine-types.h。

另外，在BootLoader调用kernel之前，传递参数情况如图12所示：

图12  arch/arm/boot/head.S调用kernel前传递参数

从图12可知：

q  r1保存的是machine nr。

这部分代码属于BootLoader，相当复杂。以后再细说。

假设__lookup_machine_type一切正常

    bl    __lookup_machine_type        @ r5=machinfo

    movs    r8, r5                @ invalid machine (r5=0)?

    beq    __error_a            @ yes, error 'a'

1.5  __vet_atags分析

接下来的任务就是Kernel校验BL传递的启动参数了。这部分内容和BootLoader有较大关系。

    bl    __vet_atags

此处的核心概念就是ATAG_CORE/END之类的，由BootLoader往Kernel传递参数，主要是tag结构体

在arch/arm/include/asm/setup.h中。BL传递的是struct tag的链表，该链表以ATAG_CORE开头，以ATAG_NONE结尾。

#define ATAG_CORE    0x54410001

#define ATAG_NONE    0x00000000

struct tag_header {

    __u32 size;

    __u32 tag;

};

struct tag {

  struct tag_header hdr;  //首先是一个头，根据头部的tag来判断下面的union是哪个

  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;

    struct tag_acorn    acorn;

    struct tag_memclk    memclk;

  } u;

};

你可以根据上面的信息自行分析__vet_atags函数。

1.6  __create_page_tables分析

下面的任务就是调用__create_page_tables创建page table。

    bl    __create_page_tables  //调用__create_page_tables函数

此函数就在head.S中定义，代码如下：

__create_page_tables:

    /*

       pgtbl是head.S中定义的一个宏，见下面的分析

    */

     pgtbl    r4

pgtbl定义了一个宏，相关代码如下：

//TEXT_OFFSET是kernel镜像在内存中的偏移量。一般定义为0X8000，即32KB处

//PHYS_OFFSET：是内核镜像在内存中的起始物理地址。上面二者之和就是内核镜像在机器上的

//物理地址。Goldfish平台中，PHYS_OFFSET为0。

//PAGE_OFFSET是Kernel镜像在虚拟内存的起始地址，一般是3G处

#define KERNEL_RAM_VADDR    (PAGE_OFFSET + TEXT_OFFSET)

#define KERNEL_RAM_PADDR    (PHYS_OFFSET + TEXT_OFFSET)

.macro    pgtbl, rd //此宏调用完毕后，r4的值就是0x4000，即16KB

    ldr    \rd, =(KERNEL_RAM_PADDR - 0x4000)

    .endm

接着看代码。

    mov    r0, r4

    mov    r3, #0

    add    r6, r0, #0x4000

    //STR将寄存器的值往内存中传送。r3为0，故内存的值被设置为0.每调用一次str，r0递增4

    //r0是base address，其值可自动增减。由arm address mode格式控制

1:  str    r3, [r0], #4

    str    r3, [r0], #4

    str    r3, [r0], #4

    str    r3, [r0], #4

    teq    r0, r6

    bne    1b //此循环调用完毕后，0x4000-0x8000的内存都被设置为0。此时r0=32KB

 

    //r10存储的是图9中proc_info的第三个long，也就是mmuflas，用于设置MMU参数

    ldr    r7, [r10, #PROCINFO_MM_MMUFLAGS] @ mm_mmuflags

1.6.1  ARM MMU设置介绍

虽然上面最后一条语句是一个简单的ldr，但背后的内容却相当丰富，不把它搞清楚，后面的内容将解释不清。来看proc-V7中mm_mmuflags对应的值是什么

.long   PMD_TYPE_SECT | \   // #define PMD_TYPE_SECT (2 << 0)

        PMD_SECT_BUFFERABLE | \ //#define PMD_SECT_BUFFERABLE (1 << 2)

        PMD_SECT_CACHEABLE | \//#define PMD_SECT_CACHEABLE (1 << 3)

        PMD_SECT_AP_WRITE | \//#define PMD_SECT_AP_WRITE (1 << 10)

        PMD_SECT_AP_READ //#define PMD_SECT_AP_READ (1 << 11)

上面代码中把对应PMD_SECT_XXX的值显示出来，可知它无非是定义了一个32位的常量，某些位置的值为1，某些位置的值为0。为什么要怎么做呢？先来看ARM MMU所支持的虚实地址转换机制。

图13  ARM MMU虚实地址转换

由图13可知：

q  虚地址VA的[20-31]位和CP15 CR2的[14-31]位共同构成First Level地址。

q  从First Level地址将得到一个First Level Descripter，也就是图13中标明memory access的内容。

q  FLD中不同字段表明其内容是段寻址还是页寻址。主要是根据前2位来判断。如果前2位是0b10则是段寻址。

结合图13和前面的代码：

q  PMD_TYPE_SECT = 2<<0，刚好就是0b10

q  C|B控制Cachable和Buffable的，对应为[2,3]位

q  AP对应为Access Point，对应为[10,11]位。

另外，Domain是ARM CPU的一个重要概念，主要和权限有关。以后碰到再说。

至此，当ldr r7 xx执行完后，r7的值包含了section base address对应的[0-12]位的值。而section base address本身却还没有赋值。

接下来的代码就是为了构造一个FLD的值。根据图13，section base address应该是[20-31]位

   //r6的值为当前PC值右移20位

    mov    r6, pc, lsr #20

    orr    r3, r7, r6, lsl #20        @ flags + kernel base

    //此时，r3的值就是一个基于段寻址的FLD。把它存起来。位置是r4+r6<<2

    str    r3, [r4, r6, lsl #2]      

现在r6存储的是段寻址的基地址，需要把这个值存储到对应表的位置，由于在表中，每一项是4个字节，所以这里需要乘以4，也就是lsl #2。

稍微解释下这里左移4的原因：

1 r4存储的是表的起始地址

2 r6存储的是offset

3 r3存储的是往r4[offset]的值

4 由于1个offset实际上是4个字节，所以真实存储的位置就是r4[4*offset] = r3

1.6.2  设置页表

当理解上面代码后，下面就是把kernel虚拟地址的位置存储到r4表中了

继续看代码

   //立即数的计算比较难理解，网上也没有相关说法。不过，只要知道下面这段代码就是存储kernel

  //虚拟地址到对应页表位置即可

   add    r0, r4,  #(KERNEL_START & 0xff000000) >> 18

   str    r3, [r0, #(KERNEL_START & 0x00f00000) >> 18]!

    ldr    r6, =(KERNEL_END - 1)

    add    r0, r0, #4  //r0 = ro+4

    add    r6, r4, r6, lsr #18 //r6=r4+r6>>18

1:    cmp    r0, r6

    add    r3, r3, #1 << 20 //r3 += 1<<20，每次递增1M

    //ls是condition code，表示小于等于，即只要r0<=r6,strls就会执行

    strls    r3, [r0], #4

    bls    1b

 

   //map物理地址前1M到对应位置

   add    r0, r4, #PAGE_OFFSET >> 18

    orr    r6, r7, #(PHYS_OFFSET & 0xff000000)

    .if    (PHYS_OFFSET & 0x00f00000)

    orr    r6, r6, #(PHYS_OFFSET & 0x00f00000)

    .endif

    str    r6, [r0]

 

    mov    pc, lr

ENDPROC(__create_page_tables)

    .ltorg

1.6.3 总结

建议大家仔细体会create_page_tables这段内容。虽然以后不太可能会使用它们，但把这段代码搞清楚还是一个比较有意思的过程。

1.7  剩余工作

回到head.S，最后还剩下几句代码：

//将__switch_data的位置存储到r13

 ldr r13, __switch_data 

 //获取__enable_mmu标签的地址，并保存到lr中

 adr lr, __enable_mmu 

 //r10存储的是__v7_proc_info的地址，#PROCINFO_INITFUNC是一个偏移量

 //执行完下条语句后，pc指向__v7_proc_info的b __v7_setup，故下面这条语句就是

 //执行__v7_setup函数

 add pc, r10, #PROCINFO_INITFUNC

ENDPROC(stext)

1.7.1  __switch_data说明

__switch_data标签如下，主要存储了一些数据。

[head-common.S]

 .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

以后再讨论具体作用。

1.7.2  __v7_setup

先来看

add pc, r10, #PROCINFO_INITFUNC

实际上就是执行__v7_setup函数。代码在mm/proc-v7.S中。

adr r12, __v7_setup_stack  @ the local stack

 stmia r12, {r0-r5, r7, r9, r11, lr}

 bl v7_flush_dcache_all

 ldmia r12, {r0-r5, r7, r9, r11, lr}

 mov r10, #0

dsb

#ifdef CONFIG_MMU  //goldfish定义了这个配置项

 mcr p15, 0, r10, c8, c7, 0  @ invalidate I + D TLBs

 mcr p15, 0, r10, c2, c0, 2  @ TTB control register

 orr r4, r4, #TTB_FLAGS

 mcr p15, 0, r4, c2, c0, 1  @ load TTB1

 mov r10, #0x1f   @ domains 0, 1 = manager

 mcr p15, 0, r10, c3, c0, 0  @ load domain access register

#endif

 ldr r5, =0xff0aa1a8

 ldr r6, =0x40e040e0

 mcr p15, 0, r5, c10, c2, 0  @ write PRRR

 mcr p15, 0, r6, c10, c2, 1  @ write NMRR

 adr r5, v7_crval

 ldmia r5, {r5, r6}

    mrc p15, 0, r0, c1, c0, 0  @ read control register

 bic r0, r0, r5   @ clear bits them

 orr r0, r0, r6   @ set them

//最后一句，将lr赋值给pc。执行完后，将跳到__enable_mmu函数。

 mov pc, lr    @ return to head.S:__ret

ENDPROC(__v7_setup)

上面代码大多是执行ARM v7 CPU的MMU相关设置的，而其中的汇编语句到比较简单。这也是ARM MMU设置的核心内容。下面我们将结合ARM CPU Rerference简单介绍下这些设置的内容。

请务必从ARM官方网页上下载下面两个文档：

q  DDI0344D_cortex_a8_r2p1_trm.pdf：介绍CORTEX A8相关内容

q  DDI0406B_arm_architecture_reference_manual_errata_markup_10_0：最新的ARM架构参考手册

1.     如何看懂MMU设置并掌握理论知识

以下面这个设置为例：

mcr p15, 0, r10, c8, c7, 0

打开参考文档DDI0344D_cortex_a8_r2p1_trm.pdf的第112页。从这一页开始，C15协处理器的各个寄存器的配置都有详细的说明。如图14所示

图14 C8寄存器的设置

上图中，左边空白区域对应的是C8。可知，c8,c7,0的组合对应的是Invalidate unified TLB unlocked entries.详细说明在page3-99。

如果在此文档中碰到有不理解的内容，就需要参考DDI0406B_arm_architecture_reference_manual_errata_markup_10_0。该文档会介绍一些理论知识。

篇幅原因，我就不在这里啰嗦。已经告诉大家如何钓鱼了，请大家自己尝试！

1.7.3  __enable_mmu介绍

__v7_setup最后已经的mov pc, lr将使得CPU跳转到__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

//设置domain的权限，请参考前面的书籍了解DOMAIN在ARM MMU中的意义

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 //跳转到__turn_mmu_on

ENDPROC(__enable_mmu)

简单看看__turn_mmu_on：

__turn_mmu_on:

 mov r0, r0 //类似nop的空指令，浪费一点CPU时间，怕引起race condition发生

//c1,c0这两个控制MMU的设置

 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

//此时，MMU就正式启动了

 mov pc, r13 //r13指向__switch_data

ENDPROC(__turn_mmu_on)

MMU启动后，我们也无需管什么物理地址还是虚拟地址，直接去看对应地址的代码即可。如果您非对这个转换过程很感兴趣，建议您把那两个参考书好好瞅瞅。

1.7.4  __mmaped_switched介绍

__switch_data第一个定义的就是__mmaped_switched，PC将执行这里的指令：

__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

 

 mov fp, #0    @ Clear BSS (and zero fp)

1: cmp r6, r7

 strcc fp, [r6],#4

 bcc 1b

 

 ldmia r3, {r4, r5, r6, r7, sp}

 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

//上面我就懒得废话了，下面这句代码相信各位都很了解。执行start_kernel函数。

 b start_kernel

ENDPROC(__mmap_switched)

 

二总结

我觉得需要说明下为什么写这篇文章：

早在2010年7月的时候，我就看了那本鼎鼎大名的《ARM体系结构与编程》，这应该是第一本系统介绍ARM体系结构和编程的书。但是没看懂，全是枯燥的ARM CPU设置，纯教科书。

最近因为工作的原因，想把ARM这块重新捡起来，想起2年的痛苦，觉得应该换个思路。ARM也好，汇编也好，我们应该关注它的目的，而不是具体它是怎么实现的。即了解What to do比了解How to do更重要（仅我个人目的而言，前者重要。不过在某些追求细节的时候，后者重要。需要你自己去判断）。根据这个思路，我选择以Linux Kernel启动为分析对象，大致研究流程如下：

q  先花几天时间了解下ARM汇编的大概语句。

q  直接上代码分析。不过你得对Kernel启动的流程稍有了解。还好我在《深入理解Android卷I》写完后，花了点时间把这块整理了下。请参考http://blog.csdn.net/innost/article/details/6693731

q  碰到不懂的汇编语句，就查参考手册。这些还只是针对一些没有背景知识的语句。

q  当碰到类似CP15操作的语句时，其背后往往包含了较多的CPU相关的知识，这时候就需要查阅前面提到的两本参考书籍，去真真正正了解ARM CPU运行的相关原理。

大概经过2周先痛苦挣扎，到后面豁然开朗的过程，后续的研究就非常非常流畅了。