arm 启动 grafana arm启动过程

arm-linux启动过程

 

1. kernel运行的史前时期和内存布局

 

在arm平台下，zImage.bin压缩镜像是由bootloader加载到物理内存，然后跳到zImage.bin里一段程序，它专门于将被压缩的kernel解压缩到KERNEL_RAM_PADDR开始的一段内存中，接着跳进真正的kernel去执行。该kernel的执行起点是stext函数，定义于arch/arm/kernel/head.S。

 

在分析stext函数前，先介绍此时内存的布局如下图所示

 

 

在开发板tqs3c2440中，SDRAM连接到内存控制器的Bank6中，它的开始内存地址是0x30000000，大小为64M，即0x20000000。 ARM Linux kernel将SDRAM的开始地址定义为PHYS_OFFSET。经bootloader加载kernel并由自解压部分代码运行后，最终kernel被放置到KERNEL_RAM_PADDR（=PHYS_OFFSET + TEXT_OFFSET，即0x30008000）地址上的一段内存，经此放置后，kernel代码以后均不会被移动。

 

在进入kernel代码前，即bootloader和自解压缩阶段，ARM未开启MMU功能。因此kernel启动代码一个重要功能是设置好相应的页表，并开启MMU功能。为了支持MMU功能，kernel镜像中的所有符号，包括代码段和数据段的符号，在链接时都生成了它在开启MMU时，所在物理内存地址映射到的虚拟内存地址。

 

以arm kernel第一个符号（函数）stext为例，在编译链接，它生成的虚拟地址是0xc0008000，而放置它的物理地址为0x30008000（还记得这是PHYS_OFFSET+TEXT_OFFSET吗？）。实际上这个变换可以利用简单的公式进行表示：va = pa – PHYS_OFFSET + PAGE_OFFSET。Arm linux最终的kernel空间的页表，就是按照这个关系来建立。

 

之所以较早提及arm linux 的内存映射，原因是在进入kernel代码，里面所有符号地址值为清一色的0xCXXXXXXX地址，而此时ARM未开启MMU功能，故在执行stext函数第一条执行时，它的PC值就是stext所在的内存地址（即物理地址，0x30008000）。因此，下面有些代码，需要使用地址无关技术。

 

2．一览stext函数

 

stext函数定义在Arch/arm/kernel/head.S，它的功能是获取处理器类型和机器类型信息，并创建临时的页表，然后开启MMU功能，并跳进第一个C语言函数start_kernel。

 

stext函数的在前置条件是：MMU, D-cache, 关闭; r0 = 0, r1 = machine nr, r2 = atags prointer.

 

代码如下：

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

ENTRY(stext)

      /* 设置CPU运行模式为SVC，并关中断 */

       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=cupid

     /* r10指向cpu对应的proc_info记录 */

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

       beq __error_p                    @ yes, error 'p'

       bl    __lookup_machine_type            @ r5=machinfo

     /* r8 指向开发板对应的arch_info记录 */

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

       beq __error_a                    @ yes, error 'a'

     /* __vet_atags函数涉及bootloader造知kernel物理内存的情况，我们暂时不分析它。 */

       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.

        */

      /* 这里的逻辑关系相当复杂，先是从proc_info结构中的中跳进__arm920_setup函数，

       * 然后执__enable_mmu 函数。最后在__enable_mmu函数通过mov pc, r13来执行__switch_data，

       * __switch_data函数在最后一条语句，鱼跃龙门，跳进第一个C语言函数start_kernel。
        */

       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

ENDPROC(stext)

3 __lookup_processor_type 函数

__lookup_processor_type 函数是一个非常讲究技巧的函数，如果你将它领会，也将领会kernel了一些魔法。

Kernel代码将所有CPU信息的定义都放到.proc.info.init段中，因此可以认为.proc.info.init段就是一个数组，每个元素都定义了一个或一种CPU的信息。目前__lookup_processor_type使用该元素的前两个字段cpuid和mask来匹配当前CPUID，如果满足CPUID & mask == cpuid，则找到当前cpu的定义并返回。

下面是tqs3c2440开发板，CPU的定义信息，cpuid = 0x41009200，mask = 0xff00fff0。如果是码是运行在tqs3c2440开发板上，那么函数返回下面的定义：

 

.section ".proc.info.init", #alloc, #execinstr

 

       .type       __arm920_proc_info,#object

__arm920_proc_info:

       .long       0x41009200

       .long       0xff00fff0

       .long   PMD_TYPE_SECT | \

              PMD_SECT_BUFFERABLE | \

              PMD_SECT_CACHEABLE | \

              PMD_BIT4 | \

              PMD_SECT_AP_WRITE | \

              PMD_SECT_AP_READ

       .long   PMD_TYPE_SECT | \

              PMD_BIT4 | \

              PMD_SECT_AP_WRITE | \

              PMD_SECT_AP_READ

      /* __arm920_setup函数在stext的未尾被调用，请往回看。*/

       b     __arm920_setup

       .long       cpu_arch_name

       .long       cpu_elf_name

       .long       HWCAP_SWP | HWCAP_HALF | HWCAP_THUMB

       .long       cpu_arm920_name

       .long       arm920_processor_functions

       .long       v4wbi_tlb_fns

       .long       v4wb_user_fns

#ifndef CONFIG_CPU_DCACHE_WRITETHROUGH

       .long       arm920_cache_fns

#else

       .long       v4wt_cache_fns

#endif

       .size __arm920_proc_info, . - __arm920_proc_info

 

/*
 * Read processor ID register (CP#15, CR0), and look up in the linker-built
 * supported processor list.  Note that we can't use the absolute addresses
 * for the __proc_info lists since we aren't running with the MMU on
 * (and therefore, we are not in the correct address space).  We have to
 * calculate the offset.
 *
 *   r9 = cpuid
 * Returns:
 *   r3, r4, r6 corrupted
 *   r5 = proc_info pointer in physical address space
 *   r9 = cpuid (preserved)
 */ 
__lookup_processor_type:
      /* adr 是相对寻址，它的寻计算结果是将当前PC值加上3f符号与PC的偏移量，
       * 而PC是物理地址，因此r3的结果也是3f符号的物理地址 */

       adr  r3, 3f

      /* r5值为__proc_info_bein, r6值为__proc_ino_end，而r7值为.，
       * 也即3f符号的链接地址。请注意，在链接期间，__proc_info_begin和
       * __proc_info_end以及.均是链接地址，也即虚执地址。
       */

       ldmda     r3, {r5 - r7}

     /* r3为3f的物理地址，而r7为3f的虚拟地址。结果是r3为虚拟地址与物理地址的差值，即PHYS_OFFSET - PAGE_OFFSET。*/

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

     /* r5为__proc_info_begin的物理地址, 即r5指针__proc_info数组的首地址 */

       add r5, r5, r3                     @ convert virt addresses to

     /* r6为__proc_info_end的物理地址 */

       add r6, r6, r3                     @ physical address space

     /* 读取r5指向的__proc_info数组元素的CPUID和mask值 */

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

     /* 将当前CPUID和mask相与，并与数组元素中的CPUID比较是否相同
      * 若相同，则找到当前CPU的__proc_info定义，r5指向访元素并返回。
      */

       and  r4, r4, r9                     @ mask wanted bits

       teq  r3, r4

       beq 2f

     /* r5指向下一个__proc_info元素 */

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

     /* 是否遍历完所有__proc_info元素 */

       cmp r5, r6

       blo  1b

     /* 找不到则返回NULL */

       mov r5, #0                          @ unknown processor

2:    mov pc, lr

ENDPROC(__lookup_processor_type)

       .long       __proc_info_begin
       .long       __proc_info_end
3:    .long       .
       .long       __arch_info_begin
       .long       __arch_info_end

4 __lookup_machine_type 函数

__lookup_machine_type 和__lookup_processor_type像对孪生兄弟，它们的行为都是很类似的：__lookup_machine_type根据r1寄存器的机器编号到.arch.info.init段的数组中依次查找机器编号与r1相同的记录。它使了与它孪生兄弟同样的手法进行虚拟地址到物理地址的转换计算。

 

在介绍函数，我们先分析tqs3c2440开发板的机器信息的定义：

Arch/arm/include/asm/mach/arch.h 

#define MACHINE_START(_type,_name)                  \

static const struct machine_desc __mach_desc_##_type      \

 __used                                           \

 __attribute__((__section__(".arch.info.init"))) = { \

       .nr          = MACH_TYPE_##_type,              \

       .name            = _name,

 

#define MACHINE_END                       \

};

 

MACHINE_START宏用于定义一个.arch.info.init段的数组元素。.nr元素就是函数要比较的变量。Tqs3c2440开发板相应的定义如下：

 

MACHINE_START(S3C2440, "TQ2440")

       .phys_io = S3C2410_PA_UART,

       .io_pg_offst   = (((u32)S3C24XX_VA_UART) >> 18) & 0xfffc,

       .boot_params       = S3C2410_SDRAM_PA + 0x100,

 

       .init_irq   = s3c24xx_init_irq,

       .map_io         = tq2440_map_io,

       .init_machine  = tq2440_machine_init,

       .timer             = &s3c24xx_timer,

MACHINE_END

 

这是一个struct machine_desc结构，在后面的C代码（start_kernel开始执行的代码）会使用该变量对象。在tqs3c2440开发中的__lookup_machine_type函数就是返回该对象指针。

这里涉及很多函数指针，它们都是在start_kernel函数里在各种阶段进行初始化的回函数。如map_io指向的tq2440_map_io就是在建立好内核页表后，再调用它来针对开发板的各种IO端口来建立相关的映射和页表。

至于__loopup_machine_type的代码就不作详细分析，请对比__lookup_processor_type来自行分析。代码如下：

 

/*

 * Lookup machine architecture in the linker-build list of architectures.

 * Note that we can't use the absolute addresses for the __arch_info

 * lists since we aren't running with the MMU on (and therefore, we are

 * not in the correct address space).  We have to calculate the offset.

 *

 *  r1 = machine architecture number

 * Returns:

 *  r3, r4, r6 corrupted

 *  r5 = mach_info pointer in physical address space

 */

__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)

 

5. 为kernel建立临时页表

前面提及到，kernel里面的所有符号在链接时，都使用了虚拟地址值。在完成基本的初始化后，kernel代码将跳到第一个C语言函数start_kernl来执行，在哪个时候，这些虚拟地址必须能够对它所存放在真正内存位置，否则运行将为出错。为此，CPU必须开启MMU，但在开启MMU前，必须为虚拟地址到物理地址的映射建立相应的面表。在开启MMU后，kernel指并不马上将PC值指向start_kernl，而是要做一些C语言运行期的设置，如堆栈，重定义等工作后才跳到start_kernel去执行。在此过程中，PC值还是物理地址，因此还需要为这段内存空间建立va = pa的内存映射关系。当然，本函数建立的所有页表都会在将来paging_init销毁再重建，这是临时过度性的映射关系和页表。

 

在介绍__create_table_pages前，先认识一个macro pgtbl，它将KERNL_RAM_PADDR – 0x4000的值赋给rd寄存器，从下面的使用中可以看它，该值是页表在物理内存的基础，也即页表放在kernel开始地址下的16K的地方。

.macro    pgtbl, rd

       ldr   \rd, =(KERNEL_RAM_PADDR - 0x4000)

.endm

 

/*
 * Setup the initial page tables.  We only setup the barest
 * amount which are required to get the kernel running, which
 * generally means mapping in the kernel code.
 *
 * r8  = machinfo
 * r9  = cpuid
 * r10 = procinfo
 *
 * Returns:
 *  r0, r3, r6, r7 corrupted
 *  r4 = physical page table address
 */
__create_page_tables:
  /* r4 = KERNEL_RAM_PADDR – 0x4000 = 0x30004000
   * 后面的C代码中的swapper_pg_dir变量，它的值也指向0x30004000
   * 内存地址，不过它的值是虚拟内存地址，即0xc0004000
   */
       pgtbl       r4                         @ page table address

   /* 将从r4到KERNEL_RAP_PADDR的16K页表空间清空。 */

       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

 
     /* 还记得r10指向开发板相应的proc_info元素吗？这里它将的mm_mmuflags值读到r7中。
      * PROCINFO_MM_MMUFLAGS值为8，可对应上面列出来的__arm920_proc_info结构或你相应开发板结构的值来查看该mmu_flags值。
      * 这里的flags就是用于设置目录项的flags。查看该mmu_flags的定义，发现它是要求一级页表是section。
      */

       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.
        */

       /* r3 = ((pc >> 20) << 20) | r7， 即取PC以1M向下对齐的地址。R6 = pc >> 20也即r6 = 0x300(pgd_idx)，
        * 即PC对所有1M内存空间，在页表中的下标。                                    
        * R7值表明该目录项是section，即它映射的大小是1M。故刚好一个目录项就可以映射kernel上的1M空间。
        * 这个暂时的va = pa映射只建立1M大小内存的，而不需要建立整个kernel镜像范围的映射。
        * 因为这个va = pa的映射只有当前汇编语言才使用，一量跳进start_kernl后，这将不会用到了。而汇编代码在链接时，
        * 已将它安排到代码段的最前面了。
 
        mov r6, pc, lsr #20                     @ start of kernel section
        orr   r3, r7, r6, lsl #20         @ flags + kernel base

       /* 将目录内空写到页表相应位置，即((uint32_t *)r4)[pgd_idx] = r3 */
 
       str   r3, [r4, r6, lsl #2]         @ identity mapping

 
       /* 上面代码段为[pc &(~0xfffff), (pc + 0xfffff) &(~0xfffff)]的物理内存空间建立了va = pa的映射关系。*/

       /* 下面为kernel镜像所占有空间，即KERNL_START到KERNEL_END建立内存映射，
        * 映射关系为：va = pa – PHYS + PAGR_OFFSET。注意，这里的KENEL_START是kernel空间开始的虚拟地址。
        * 这里的目录表项同样是section，即一个项映射1M的内存。
        */


       /* KERNEL_START = PAGE_OFFSET + TEXT_OFFSET，
        * r0 = ((uint32_t *)(r4))[ (KERNEL_START & 0xff000000) >> 20]，
        * 即r0指向KERNEL_START& 0xff000000(即kernel以16M向下对齐的)虚拟地址，所在项表目录中的位置。

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

      /* r0 = ((uint32_t *)r0)[(KERNEL_START & 0x00f00000) >> 20]
       * 执行前r0指向kernel以16M向下对齐的虚执地址，而这里再加上KERNEL_START未以16M向对齐部分的偏移量。
       * 将原来r3的值写到页表目录中。R3的值就是之前已建立好va=pa映射的那个PA值。
       */

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

      /* r6为kernel镜像的尾部虚拟地址。*/

       ldr   r6, =(KERNEL_END - 1)

      /* 指向下一个即将要填写的目录项 */

       add r0, r0, #4

      /* r6指向KERNEL_END- 1虚拟地址所在的目录表项的位置 */

      add r6, r4, r6, lsr #18
1:    cmp       r0, r6

      /* 每填一个目录项，后一个比前一个所指向的物理地址大1M。*/
      add r3, r3, #1 << 20
      strls r3, [r0], #4
      bls   1b

 #ifdef CONFIG_XIP_KERNEL
       /* 忽略，不分析这种情况 */
#endif

    /* 通常kernel的启动参数由bootloader放到了物理内存的第1个M上，所以需要为RAM上的第1个M建立映射。
     * 上面已为PHYS_OFFSET + TEXT_OFFSET建立了映射，如果TEXT_OFFSET小于0x00100000的话，
     * 上面代码应该也为SDRAM的第一个M建立了映射，但如果大于0x0010000则不会。
     * 所以这里无论如何均为SDRAM的第一个M建立映射（不知分析对否，还请指正）。
     */
       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]

#ifdef CONFIG_DEBUG_LL
       /*略去 */
#if defined(CONFIG_ARCH_NETWINDER) || defined(CONFIG_ARCH_CATS)
       /* 略去 */
#endif

#ifdef CONFIG_ARCH_RPC
 /* 略去 */
#endif

#endif

       mov pc, lr
ENDPROC(__create_page_tables)

一口气将__create_pages_table分析完，但里涉及的代码还是需要细细品读。尤其是右移20位和18位两个地方与页表目录项的地址关系比较复杂。执行完该函数后，虚拟内存和物理内存的映射关系如下图所示：

 

 

6. 开启MMU

 

看完页表的建立，想必开启MMU的代码也是小菜一碟吧。此函数的主要功能是将页表的基址加到cp15中的面表指针寄存器，同时设置域访问(domain access)寄存器。

 

/*
 * Setup common bits before finally enabling the MMU.  Essentially
 * this is just loading the page table pointer and domain access
 * registers.
 */
__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
 /* 是否禁用CPU_BPREDICT ?，不是很清楚此选项 */
#ifdef CONFIG_CPU_BPREDICT_DISABLE
       bic   r0, r0, #CR_Z
#endif
 /* 是否禁用指令缓存功能 */
#ifdef CONFIG_CPU_ICACHE_DISABLE
       bic   r0, r0, #CR_I
#endif

      /* 设置域访问寄存器的值。这里设置每个domain的属性是否上面建立的页表中，
       * 每个目录项的damon值一起进行访问控制检查。具体情况请参考ARM处理器手册。
       */

       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
ENDPROC(__enable_mmu)

/*
 * Enable the MMU.  This completely changes the structure of the visible
 * memory space.  You will not be able to trace execution through this.
 * If you have an enquiry about this, *please* check the linux-arm-kernel
 * mailing list archives BEFORE sending another post to the list.
 *
 *  r0  = cp#15 control register
 *  r13 = *virtual* address to jump to upon completion
 *
 * other registers depend on the function called upon completion
 */

       .align      5
__turn_mmu_on:
       mov r0, r0

      /* 将r0的值写到控制寄存器中。这里，终于开启MMU功能了。
       * 查阅手册说控制寄存器的0位置1表示开启MMU，但这里r0的第0是多少呢（还请大家指正）
       */

       mcr p15, 0, r0, c1, c0, 0           @ write control reg
       mrc p15, 0, r3, c0, c0, 0           @ read id reg

     /* 这里的两个mov似乎是否流水线有关的，开启MMU语句后面几条是不能进行内存寻址的。但仍未搞明白具体东西的。*/
       mov r3, r3
       mov r3, r3

     /* 转跳到r13的函数中去，r13为__mmap_switched函数的虚拟地址，
      * 从stext函数的未尾可以找到它的赋值。故从此开始pc的值就真正在内存的虚拟地址空间了。
      */

       mov pc, r13
ENDPROC(__turn_mmu_on)

7．__mmap_switched函数

__mmap_switched函数专用来设置C语言的执行环境，比如重定位工作，堆栈，以及BSS段的清零。 

__switch_data变量先定义了一系里面处量的数据，如重定位和数据段的地址，BSS段的地址，pocessor_id和__mach_arch_type变量的地址等。

 

.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
 
/*
 * The following fragment of code is executed with the MMU on in MMU mode,
 * and uses absolute addresses; this is not position independent.
 *
 *  r0  = cp#15 control register
 *  r1  = machine ID
 *  r2  = atags pointer
 *  r9  = processor ID
 */
__mmap_switched:
       adr  r3, __switch_data + 4
       /* r4 = __data_loc, r5 = _data, r6 = _bss_start, r7 = _end */
       ldmia      r3!, {r4, r5, r6, r7}

      /* 下面这段代码类似于这段C代码, 即将整个数据段从__data_loc拷贝到_data段。
       * if (__data_loc  == _data || _data != _bass_start)
       *    memcpy(_data, __data_loc, _bss_start - _data);
       */

       cmp      r4, r5                           @ Copy data segment if needed
1:     cmpne    r5, r6
       ldrne       fp, [r4], #4
       strne       fp, [r5], #4
       bne  1b

       /* 将BSS段，也即从_bss_start到_end的内存清零。 */

       mov fp, #0                          @ Clear BSS (and zero fp)
1:     cmp     r6, r7
       strcc       fp, [r6],#4
       bcc  1b

   /* r4 = processor_id,
    * r5 = __machine_arch_type
    * r6 = __atags_pointer
    * r7 = cr_alignment
    * sp = init_thread_union + THREAD_START_SP
    * 为什么将栈顶指针设置为init_thread_union + THREAD_START_SP
    * init_head_union 变量是一个大小为THREAD_SIZE的union，它在编译时，放到数据段的前面。
    * 初步估计这块空间是内核堆栈。故在跳入C语言代码时，它SP的值设置为init_thread_union + THREAD_START_SP。
    * 注意THREAD_START_SP定义为THREAD_SIZE – 8，中间为什么留出8个字节呢？是与ARM的堆栈操作有关吗？ 还有用专向start_kernel函数传递参数？
    */
 
       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

    /* cr_alignment变量的后面接着放置cr_no_alignment, 
     * r0为打开alignment检测时，控制寄存器的值，而r4为关闭时的值,
     * 这里分将将打开和关闭alignment检查的控制寄存器的值写到
     * cr_alignment和cr_no_alignement变量中。
     */

       stmia      r7, {r0, r4}                  @ Save control register values

     /* 跳到start_kernel函数，此函数代码用纯C来实现，它会调用各个平台的相关初始化函数，
      * 来实现不同平台的初始化工作。至此，arm linux的启动工作完成。
      */

       b     start_kernel
ENDPROC(__mmap_switched)

 

全文完