linux 2.6.34 内核启动详细分析(一)-凯发app官方网站

凯发app官方网站-凯发k8官网下载客户端中心 | | 凯发app官方网站-凯发k8官网下载客户端中心

王卫波的chinaunix博客

凯发app官方网站首页　| 　　| 　

王卫波

  • 博客访问： 20300
  • 博文数量： 1
  • 博客积分： 0
  • 博客等级： 民兵
  • 技术积分： 16
  • 用 户 组： 普通用户
  • 注册时间： 2017-06-08 17:38
文章分类

（1）

  • （1）
文章存档

（1）

我的朋友
最近访客
推荐博文
相关博文
  • ·
  • ·
  • ·
  • ·
  • ·
  • ·
  • ·
  • ·
  • ·
  • ·
linux 2.6.34 内核启动详细分析(一)

分类： linux

2021-09-05 19:05:15

原文地址： 作者：

linux 2.6.34 内核启动详细分析(一)

内核编译完成后会生成zimage内核镜像文件。关于bootloader加载zimage到内核，
并且跳转到zimage开始地址运行zimage的过程，相信大家都很容易理解。但对于zimage
是如何解压的过程，就不是那么好理解了。
本文将结合部分关键代码，讲解zimage的解压过程;

先看看zimage的组成吧。在内核编译完成后会在arch/arm/boot/下生成zimage。
在arch/arm/boot/makefile中：
  1. $(obj)/zimage: $(obj)/compressed/vmlinux force
  2. $(call if_changed,objcopy)
  3. $(obj)/compressed/vmlinux: $(obj)/image force
  4. $(q)$(make) $(build)=$(obj)/compressed $@  #make obj=$(obj)/compressed $@

由此可见，zimage的是elf格式的arch/arm/boot/compressed/vmlinux二进制化得到的
在arch/arm/boot/compressed/makefile中：

  1. $(obj)/vmlinux: $(obj)/vmlinux.lds $(obj)/$(head) $(obj)/piggy.$(suffix_y).o \
  2. $(addprefix $(obj)/, $(objs)) $(lib1funcs) force
  3. $(call if_changed,ld)

  5. $(obj)/piggy.$(suffix_y): $(obj)/../image force
  6. $(call if_changed,$(suffix_y))

  8. $(obj)/piggy.$(suffix_y).o: $(obj)/piggy.$(suffix_y) force
其中image是由内核顶层目录下的vmlinux二进制化后得到的。
注意：arch/arm/boot/compressed/vmlinux是位置无关的，这个有助于理解后面的代码。
链接选项中有个 –fpic参数：
extra_cflags := -fpic

pic就是position independent code 
pic使.so文件的代码段变为真正意义上的共享 
如果不加-fpic,则加载.so文件的代码段时,代码段引用的数据对象需要重定位, 重定位会修改代码段的内容,这就造成每个使用这个.so文件代码段的进程在内核里都会生成这个.so文件代码段的copy.每个copy都不一样,取决于 这个.so文件代码段和数据段内存映射的位置.

总结一下zimage的组成，它是由一个压缩后的内核piggy.gzip.o，连接上一段初始化及解压功能的代码（head.o misc.o）,组成的。

下面就要看内核的启动了，那么内核是从什么地方开始运行的呢？这个当然要看lds文件啦。
zimage的生成经历了两次大的链接过程：
一次是顶层vmlinux的生成，由arch/arm/boot/vmlinux.lds（这个lds文件是由arch/arm/kernel/vmlinux.lds.s生成的）决定；
另一次是arch/arm/boot/compressed/vmlinux的生成，是由arch/arm/boot/compressed /vmlinux.lds（这个lds文件是由arch/arm/boot/compressed/vmlinux.lds.in生成的）决定。

因此，zimage的入口点应该由arch/arm/boot/compressed/vmlinux.lds决定。

首先，我们来看内核解压部分,这部分的代码主要存放在
1. arch/arm/boot/compressed/makefile   
2. arch/arm/boot/compressed/vmlinux.lds
3. arch/arm/kernel/vmlinux.lds



linux内核解压流程
arch/arm/boot/compressed/head.s

• 对于各种arm cpu的debug输出设定，通过定义宏来统一操作；
  1. #include
  2. .macro writeb, ch, rb
  3. senduart \ch, \rb
  4. .endm
  5. #defined(config_arch_s3c2410)
  6. .macro loadsp, rb, tmp
  7. mov \rb, #0x50000000
  8. add \rb, \rb, #0x4000 * config_s3c_lowlevel_uart_port
  9. .endm
  10. #endif
  11. .macro kputc,val
  12. mov r0, \val
  13. bl putc
  14. .endm
  15. .macro kphex,val,len
  16. mov r0, \val
  17. mov r1, #\len
  18. bl phex
  19. .endm
  20. .macro debug_reloc_start
  21. kputc #'\n'
  22. kphex r6, 8 /* processor id */
  23. kputc #':'
  24. kphex r7, 8 /* architecture id */
  25. kputc #':'
  26. mrc p15, 0, r0, c1, c0
  27. kphex r0, 8 /* control reg */
  28. kputc #'\n'
  29. kphex r5, 8 /* decompressed kernel start */
  30. kputc #'-'
  31. kphex r9, 8 /* decompressed kernel end */
  32. kputc #'>'
  33. kphex r4, 8 /* kernel execution address */
  34. kputc #'\n'
  35. .macro debug_reloc_end
  36. kphex r5, 8 /* end of kernel */
  37. kputc #'\n'
  38. mov r0, r4
  39. bl memdump /* dump 256 bytes at start of kernel */
  40. .endm
  41. 设置kernel开始和结束地址，保存architecture id；
  42. start:
  43. .type start,#function @.type 符号,类型描述(函数类型或者对象类型)
  44. .rept 8 @.rept 数据定义 .endr 重复协议操作
  45. mov r0, r0
  46. .endr
  47. b 1f
  48. .word 0x016f2818 @ magic numbers to help the loader
  49. .word start @ absolute load/run zimage address
  50. .word _edata @ zimage end address
  51. 1:
  52. mov r7, r1 @ save architecture id
  53. mov r8, r2 @ save atags pointer
  54. 如果在arm2以上的cpu中，如用的是普通用户模式，则升到超级用户模式，然后关中断
  55. 这也标志着u-boot将系统完全的交给了os，bootloader生命终止，系统已经处于svc32模式；而利用
  56. angel进入则处于user模式，还需要额外两条指令。之后是再次确认中断关闭，并完成cpsr写入
  57. mrs r2, cpsr @ get current mode
  58. tst r2, #3 @ not user mode?
  59. bne not_angel
  60. mov r0, #0x17 @ angel_swireason_entersvc
  61. swi 0x123456 @ angel_swi_arm 软中断指令 进入svc模式
  62. not_angel:
  63. mrs r2, cpsr @ turn off interrupts to
  64. orr r2, r2, #0xc0 @ prevent angel from running
  65. msr cpsr_c, r2
  66. 分析lc0结构delta offset，判断是否需要重载内核地址(r0存入偏移量，判断r0是否为零)。在lc0
  67. 地址处将分段信息导入r0-r6、r11、ip、sp等寄存器，并检查代码是否运行在与链接时相同的目标地址，
  68. 以决定是否进行处理。
  69. adr r0, lc0
  70. ldmia r0, {r1, r2, r3, r4, r5, r6, r11, ip, sp})
  71. subs r0, r0, r1 @ calculate the delta offset
  72. @ if delta is zero, we are
  73. beq not_relocated @ running at the address we
  74. @ were linked at.
  75. .align 2
  76. .type lc0, #object
  77. lc0:
  78. .word lc0 @ r1
  79. .word __bss_start @ r2
  80. .word _end @ r3
  81. .word zreladdr @ r4
  82. .word _start @ r5
  83. .word _image_size @ r6
  84. .word _got_start @ r11
  85. .word _got_end @ ip
  86. .word user_stack 4096 @ sp
  87. 由于现在很少有人不使用loader和tags，将zimage烧写到rom直接从0x0位置执行，
  88. 所以这个处理是必须的（但是zimage的头现在也保留了不用 loader也可启动的能力）。
  89. arm架构下自解压头一般是链接在0x0地址而被加载到0x30008000运行，所以要修正这个变化。
  90. 涉及到r5寄存器存放的zimage基地址
  91. r6和r12（即ip寄存器）存放的got（global offset table）
  92. r2和r3存放的bss段起止地址
  93. sp栈指针地址
  94. 很简单，这些寄存器统统被加上一个你也能猜到的偏移地址0x30008000。该地址是s3c2410相关的
  95. 这些操作发生在代码172行开始的地方，下面只粘贴一部分
  96. /*we're running at a different address. we need to fix
  97. * up various pointers:
  98. * r5 - zimage base address ( _start )
  99. * r6 - size of decompressed image
  100. * r11 - got start
  101. * ip - got end*/
  102. add r5, r5, r0
  103. add r11, r11, r0
  104. add ip, ip, r0
  105. 需要重载内核地址，将r0的偏移量加到bss region和got table中的每一项。对于位置无关
  106. 的代码，程序是通过got表访问全局数据目标的，也就是说got表中中记录的是全局数据目标
  107. 的绝对地址，所以其中的每一项也需要重载。
  108. /* if we're running fully pic === config_zboot_rom = n,
  109. * we need to fix up pointers into the bss region.
  110. * r2 - bss start
  111. * r3 - bss end
  112. * sp - stack pointer*/
  113. add r2, r2, r0
  114. add r3, r3, r0
  115. add sp, sp, r0
  116. /*relocate all entries in the got table.*/
  117. 1:
  118. ldr r1, [r11, #0] @ relocate entries in the got
  119. add r1, r1, r0 @ table. this fixes up the
  120. str r1, [r11], #4 @ c references.
  121. cmp r11, ip
  122. blo 1b
  123. 清空bss堆栈空间r2－r3
  124. not_relocated:
  125. mov r0, #0
  126. 1:
  127. str r0, [r2], #4 @ clear bss
  128. str r0, [r2], #4
  129. str r0, [r2], #4
  130. str r0, [r2], #4
  131. cmp r2, r3
  132. blo 1b
  133. 打开cache,建立c程序运行需要的64kb的临时malloc空间
  134. bl cache_on
  135. mov r1, sp @ malloc space above stack
  136. add r2, sp, #0x10000 @ 64k max 接下来238行进行检查，确定内核解压缩后的
  137. @image目标地址是否会覆盖到zimage头，如果是则准备
  138. @将zimage头转移到解压出来的内核后面
  139. 这时r2是缓存的结束地址，r4是kernel的最后执行地址，r5是kernel境象文件的开始地址
  140. /*
  141. * check to see if we will overwrite ourselves.
  142. * r4 = final kernel address
  143. * r5 = start of this image
  144. * r6 = size of decompressed image
  145. * r2 = end of malloc space (and therefore this image)
  146. * we basically want:
  147. * r4 >= r2 -> ok
  148. * r4 image length <= r5 -> ok
  149. */
  150. cmp r4, r2
  151. bhs wont_overwrite
  152. sub r3, sp, r5 @ > compressed kernel size
  153. add r0, r4, r3, lsl #2 @ allow for 4x expansion
  154. cmp r0, r5
  155. bls wont_overwrite
  156. 用文件misc.c的函数decompress_kernel()，解压内核于缓存结束的地方(r2地址之后)。
  157. mov r5, r2 @ decompress after malloc space
  158. mov r0, r5
  159. mov r3, r7
  160. bl decompress_kernel
  161. 可能大家看了上面的文字描述还是不清楚解压的动态过程。还是先用图表的方式描述下
  162. 代码的搬运解压过程。然后再针对中间的一些关键过程阐述。
  163. 真实情况在大多数的应用中，内核编译都会把压缩的zimage和非压缩的image链接到同样的地
  164. 址，s3c2410平台下即是0x30008000。这样做的好处是，人们不用关心内核是image还是zimage，
  165. 放到这个位置执行就ok，所以在解压缩后zimage头必须为真正的内核让路。在250行解压完毕，
  166. 内核长度返回值存放在r0寄存器里。
  167. 在内核末尾空出128字节的栈空间用，并且使其长度128字节对齐。
  168. add r0, r0, #127 128 @ alignment stack
  169. bic r0, r0, #127 @ align the kernel length
  170. 算出搬移代码的参数：计算内核末尾地址并存放于r1寄存器，需要搬移代码原来地址放在r2，需要搬移
  171. 的长度放在r3。然后执行搬移，并设置好sp指针指向新的栈（原来的栈也会被内核覆盖掉）
  172. * r0 = decompressed kernel length
  173. * r1-r3 = unused
  174. * r4 = kernel execution address
  175. * r5 = decompressed kernel start
  176. * r7 = architecture id
  177. * r8 = atags pointer
  178. * r9-r12,r14 = corrupted
  179. add r1, r5, r0 @ end of decompressed kernel
  180. adr r2, reloc_start
  181. ldr r3, lc1
  182. add r3, r2, r3
  183. 1:
  184. ldmia r2!, {r9 - r14} @ copy relocation code
  185. stmia r1!, {r9 - r14}
  186. ldmia r2!, {r9 - r14}
  187. stmia r1!, {r9 - r14}
  188. cmp r2, r3
  189. blo 1b
  190. add sp, r1, #128 @ relocate the stack
  191. 搬移完成后刷新cache，因为代码地址变化了不能让cache再命中被内核覆盖的老地址。
  192. 然后跳转到新的地址继续执行
  193. bl cache_clean_flush
  194. add pc, r5, r0 @ call relocation code(reloc_start:)
  195. 注意:zimage在解压后的搬移和跳转会给gdb调试内核带来麻烦。因为用来调试的符号表是在编译
  196. 生成的，并不知道以后会被搬移到何处去，只有在内核解压缩完成之后，根据计算出来的参数“告诉”
  197. 调试器这个变化。以撰写本文时使用的zimage为例，内核自解压头重定向后，reloc_start地址由0x30008360变为 0x30533e60。故我们要把vmlinux的符号表也相应的从0x30008000后移到0x30533b00开始，这样gdb就可以正确的对应源 代码和机器指令。随着头部代码移动到新的位置，
  198. 不会再和内核的目标地址冲突，可以开始内核自身的搬移了。此时r0寄存器存放的是内核长度（严格
  199. 的说是长度外加128byte的栈），r4存放的是内核的目的地址0x30008000，r5是目前内核存放地
  200. 址，r6是cpu id，r7是machine id，r8是atags地址。
  201. * all code following this line is relocatable. it is relocated by the above code to the
  202. * end of the decompressed kernel image and executed there.
  203. * during this time, we have no stacks.
  204. * r0 = decompressed kernel length
  205. * r1-r3 = unused
  206. * r4 = kernel execution address
  207. * r5 = decompressed kernel start
  208. * r7 = architecture id
  209. * r8 = atags pointer
  210. * r9-r12,r14 = corrupted
  211. reloc_start:
  212. add r9, r5, r0
  213. sub r9, r9, #128 @ do not copy the stack
  214. debug_reloc_start
  215. mov r1, r4
  216. 1:
  217. .rept 4
  218. ldmia r5!, {r0, r2, r3, r10 - r14} @ relocate kernel
  219. stmia r1!, {r0, r2, r3, r10 - r14}
  220. .endr
  221. cmp r5, r9
  222. blo 1b
  223. add sp, r1, #128 @ relocate the stack
  224. 接下来在566行清除并关闭cache，清零r0，将machine id存入r1，atags指针存入r2，
  225. 再跳入0x30008000执行真正的内核image
  226. call_kernel:
  227. bl cache_clean_flush
  228. bl cache_off
  229. mov r0, #0 @ must be zero
  230. mov r1, r7 @ restore architecture number
  231. mov r2, r8 @ restore atags pointer
  232. mov pc, r4 @ call kernel
  233. 至此，开始正式跳到内核代码执行！
  234. 遗留问题解决：
  235. 问题1：zimage是如何知道自己最后的运行地址是0x30008000的？
  236. 这个地址的确定和makefile和链接脚本有关
  237. 在arch/arm/mach-s3c2410/makefile.boot中
  238. zreladdr-y := 0x30008000 这个就是zimage的运行地址了
  239. 在arch/arm/boot/makefile文件中
  240. zreladdr := $(zreladdr-y)
  241. 在arch/arm/boot/compressed/makefile文件中
  242. zreladdr=$(zreladdr)
  243. 在arch/arm/boot/compressed/head.s中有
  244. .word zreladdr @ r4
  245. 内核就是用这种方式让代码知道最终运行的位置的
  246. 问题2：调用decompress_kernel函数时，其4个参数是什么值及物理含义？
  247. decompress_kernel(ulg output_start,
  248. ulg free_mem_ptr_p,
  249. ulg free_mem_ptr_end_p,
  250. int arch_id)
  251. output_start：指解压后内核输出的起始位置，紧接在解压缓冲区后；
  252. free_mem_ptr_p：解压函数需要的内存缓冲开始地址；
  253. free_mem_ptr_end_p：解压函数需要的内存缓冲结束地址，共64k；
  254. arch_id ：architecture id，对于smdk2410这个值为193；
  255. 问题3：解压函数是如何确定代码中压缩内核位置的？
  256. 首先看看piggy.o是如何生成的，在arch/arm/boot/compressed/makefie中
  257. $(obj)/piggy.$(suffix_y): $(obj)/../image force
  258. piggy.gzip.o是由piggy.gzip.s生成的，咱们看看piggy.gzip.s的内容：
  259. .section .piggydata,#alloc
  260. .globl input_data
  261. input_data:
  262. .incbin "arch/arm/boot/compressed/piggy.gzip"
  263. .globl input_data_end
  264. input_data_end:
  265. 再看看misc.c中decompress_kernel函数吧，它将调用gunzip()解压内核。
  266. gunzip()在lib/inflate.c中定义，它将调用nextbyte()，进而调用get_byte()来获取压缩内核代码。
  267. 在misc.c中
  268. #define get_byte() (inptr < insize ? inbuf[inptr ] : fill_inbuf())
  269. 查看fill_inbuf函数
  270. int fill_inbuf(void)
  271. {
  272. if (insize != 0)
  273. error("ran out of input data");
  274. inbuf = input_data;
  275. insize = &input_data_end[0] - &input_data[0];
  276. inptr = 1;
  277. return inbuf[0];
  278. }
发现什么没？这里的input_data不正是piggy.gzip.s里的input_data吗？这个时候应该
明白内核是怎样确定piggy.gz在zimage中的位置了吧。
阅读(11558) | 评论(0) | 转发(0) |
1

上一篇：没有了

下一篇：没有了

给主人留下些什么吧！~~
| | | | |

凯发app官方网站 copyright 2001-2010 chinaunix.net all rights reserved 北京皓辰网域网络信息技术有限公司. 凯发k8官网下载客户端中心的版权所有

感谢所有关心和支持过chinaunix的朋友们
")); function link(t){ var href= $(t).attr('href'); href ="?url=" encodeuricomponent(location.href); $(t).attr('href',href); //setcookie("returnouturl", location.href, 60, "/"); }
网站地图