2019年12月26日 | arm-linux启动过程

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

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

     1在分析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代码以后均不会被移动。

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

     1以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.

     代码如下：

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

2. 
   

3. (stext) 

4. 
   

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

6. 
   

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

8. 
   

9.                                      @ and irqs disabled 

10. 
    

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

12. 
    

13.   bl    __lookup_processor_type         @ r5=procinfo r9=cupid 

14. 
    

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

16. 
    

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

18. 
    

19.   beq __error_p                    @ yes, error 'p' 

20. 
    

21.   bl    __lookup_machine_type            @ r5=machinfo 

22. 
    

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

24. 
    

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

26. 
    

27.   beq __error_a                    @ yes, error 'a' 

28. 
    

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

30. 
    

31.   bl    __vet_atags 

32. 
    

33. /*  创建临时页表 */ 

34. 
    

35.   bl    __create_page_tables 

36. 
    

37. 
    

38. 
    

39.   /*

40. 
    

41.    * The following calls CPU specific code in a position independent

42. 
    

43.    * manner.  See arch/arm/mm/proc-*.S for details.  r10 = base of

44. 
    

45.    * xxx_proc_info structure selected by __lookup_machine_type

46. 
    

47.    * above.  On return, the CPU will be ready for the MMU to be

48. 
    

49.    * turned on, and r0 will hold the CPU control register value.

50. 
    

51.    */ 

52. 
    

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

54. 
    

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

56. 
    

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

58.    */ 

59. 
    

60.   ldr   r13, __switch_data             @ address to jump to after 

61. 
    

62.                                      @ mmu has been enabled 

63. 
    

64.   adr  lr, __enable_mmu        @ return (PIC) address 

65. 
    

66.   add pc, r10, #PROCINFO_INITFUNC 

67. 
    

68. OC(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开发板上，那么函数返回下面的定义：

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

2. 
   

3. 
   

4. 
   

5.        .type       __arm920_proc_info,#object 

6. 
   

7. __arm920_proc_info: 

8. 
   

9.        .long       0x41009200 

10. 
    

11.        .long       0xff00fff0 

12. 
    

13.        .long   PMD_TYPE_SECT |  

14. 
    

15.               PMD_SECT_BUFFERABLE |  

16. 
    

17.               PMD_SECT_CACHEABLE |  

18. 
    

19.               PMD_BIT4 |  

20. 
    

21.               PMD_SECT_AP_WRITE |  

22. 
    

23.               PMD_SECT_AP_READ 

24. 
    

25.        .long   PMD_TYPE_SECT |  

26. 
    

27.               PMD_BIT4 |  

28. 
    

29.               PMD_SECT_AP_WRITE |  

30. 
    

31.               PMD_SECT_AP_READ 

32. 
    

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

34. 
    

35.        b     __arm920_setup 

36. 
    

37.        .long       cpu_arch_name 

38. 
    

39.        .long       cpu_elf_name 

40. 
    

41.        .long       HWCAP_SWP | HWCAP_HALF | HWCAP_THUMB 

42. 
    

43.        .long       cpu_arm920_name 

44. 
    

45.        .long       arm920_processor_functions 

46. 
    

47.        .long       v4wbi_tlb_fns 

48. 
    

49.        .long       v4wb_user_fns 

50. 
    

51. #ifndef CONFIG_CPU_DCACHE_WRITETHROUGH 

52. 
    

53.        .long       arm920_cache_fns 

54. 
    

55. #else 

56. 
    

57.        .long       v4wt_cache_fns 

58. 
    

59. #endif 

60. 
    

61.        .size __arm920_proc_info, . - __arm920_proc_info 

1. /*

2. * Read processor ID register (CP#15, CR0), and look up in the linker-built

3. * supported processor list.  Note that we can't use the absolute addresses

4. * for the __proc_info lists since we aren't running with the MMU on

5. * (and therefore, we are not in the correct address space).  We have to

6. * calculate the offset.

7. *

8. *   r9 = cpuid

9. * Returns:

10. *   r3, r4, r6 corrupted

11. *   r5 = proc_info pointer in physical address space

12. *   r9 = cpuid (preserved)

13. */  

14. __lookup_processor_type: 

15.       /* adr 是相对寻址，它的寻计算结果是将当前PC值加上3f符号与PC的偏移量，

16.        * 而PC是物理地址，因此r3的结果也是3f符号的物理地址 */ 

17. 
    

18.        adr  r3, 3f 

19. 
    

20.       /* r5值为__proc_info_bein, r6值为__proc_ino_end，而r7值为.，

21.        * 也即3f符号的链接地址。请注意，在链接期间，__proc_info_begin和

22.        * __proc_info_end以及.均是链接地址，也即虚执地址。

23.        */ 

24. 
    

25.        ldmda     r3, {r5 - r7} 

26. 
    

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

28. 
    

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

30. 
    

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

32. 
    

33.        add r5, r5, r3                     @ convert virt addresses to 

34. 
    

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

36. 
    

37.        add r6, r6, r3                     @ physical address space 

38. 
    

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

40. 
    

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

42. 
    

43.      /* 将当前CPUID和mask相与，并与数组元素中的CPUID比较是否相同

44.       * 若相同，则找到当前CPU的__proc_info定义，r5指向访元素并返回。

45.       */ 

46. 
    

47.        and  r4, r4, r9                     @ mask wanted bits