微波EDA网,见证研发工程师的成长!
首页 > 硬件设计 > 嵌入式设计 > Android arm linux kernel启动流程

Android arm linux kernel启动流程

时间:11-09 来源:互联网 点击:

  1. DRAM_BASE+0x00004000)

#define PHYSICAL_DRAM_BASE 0x00200000 #define KERNEL_ADDR (PHYSICAL_DRAM_BASE + 0x00008000) #define RAMDISK_ADDR (PHYSICAL_DRAM_BASE + 0x01000000) #define TAGS_ADDR (PHYSICAL_DRAM_BASE + 0x00000100) #define NEWTAGS_ADDR (PHYSICAL_DRAM_BASE + 0x00004000)

上面这些值分别和我们开篇时候提到的那几个名词相对应,比如kernel_addr就是ZTEXTADDR,RAMDISK_ADDR就是 INITRD_PHYS,而TAGS_ADDR就是PARAMS_PHYS。bootloader会从boot.img的分区中将kernel和 ramdisk分别读入RAM上面定义的地址中,然后就会跳到ZTEXTADDR开始执行。

基本了解boot.img的内容之后我们来分别看看里面的ramdisk.img和kernel又是如何产生的,以及其包含的内容。从简单的说起,我们先看看ramdisk.img,这里首先要强调一下这个ramdisk.img在arm linux中的作用。它在kernel启动过程中充当着第一阶段的文件系统,是一个CPIO格式打成的包。通俗上来讲他就是我们将生成的root目录,用 CPIO方式进行了打包,然后在kernel启动过程中会被mount作为文件系统,当kernel启动完成以后会执行init,然后将 system.img再mount进来作为Android的文件系统。在这里稍微解释下这个mount的概念,所谓mount实际上就是告诉linux虚拟文件系统它的根目录在哪,就是说我这个虚拟文件系统需要操作的那块区域在哪,比如说ramdisk实际上是我们在内存中的一块区域,把它作为文件系统的意思实际上就是告诉虚拟文件系统你的根目录就在我这里,我的起始地址赋给你,你以后就能对我进行操作了。实际上我们也可以使用rom上的一块区域作为根文件系统,但是rom相对ram慢,所以这里使用ramdisk。然后我们在把system.img mount到ramdisk的system目录,实际上就是将system.img的地址给了虚拟文件系统,然后虚拟文件系统访问system目录的时候会重新定位到对system.img的访问。我们可以看看makefile是如何生成它的:

out/host/linux-x86/bin/mkbootfs out/target/product/msm7627_ffa/root | out/host/linux-x86/bin/minigzip > out/target/product/msm7627_ffa/ramdisk.img

下面我们来看看kernel产生的过程,老方法,从Makefile开始/arch/arm/boot/Makefile ~

view plainprint?

  1. $(obj)/Image:vmlinuxFORCE
  2. $(callif_changed,objcopy)
  3. @echoKernel:$@isready
  4. $(obj)/compressed/vmlinux:$(obj)/ImageFORCE
  5. $(Q)$(MAKE)$(build)=$(obj)/compressed$@
  6. $(obj)/zImage:$(obj)/compressed/vmlinuxFORCE
  7. $(callif_changed,objcopy)
  8. @echoKernel:$@isready

$(obj)/Image: vmlinux FORCE $(call if_changed,objcopy) @echo Kernel: $@ is ready $(obj)/compressed/vmlinux: $(obj)/Image FORCE $(Q)$(MAKE) $(build)=$(obj)/compressed $@ $(obj)/zImage: $(obj)/compressed/vmlinux FORCE $(call if_changed,objcopy) @echo Kernel: $@ is ready

我们分解地来看各个步骤,第一个是将vmlinux经过objcopy后生成一个未经压缩的raw binary(Image 4M左右),这里的vmlinux是我们编译链接以后生成的vmlinx,大概60多M。这里稍微说一下这个objcopy,在启动的时候ELF格式是没法执行的,ELF格式的解析是在kernel启动以后有了操作系统之后才能进行的。因为虽然我们编出的img虽然被编成ELF格式,但要想启动起来必须将其转化成原始的二进制格式,我们可以多照着man objcopy和OBJCOPYFLAGS :=-O binary -R .note -R .note.gnu.build-id -R .comment -S(arch/arm/Makefile)来看看这些objcopy具体做了什么事情 ~

得到Image以后,再将这个Image跟解压代码合成一个vmlinux,具体的我们可以看看arch/arm/boot/compressed/Makefile:

view plainprint?

  1. $(obj)/vmlinux:$(obj)/vmlinux.lds$(obj)/$(HEAD)$(obj)/piggy.o/
  2. $(addprefix$(obj)/,$(OBJS))FORCE
  3. $(callif_changed,ld)
  4. @:
  5. $(obj)/piggy.gz:$(obj)/../ImageFORCE
  6. $(callif_changed,gzip)
  7. $(obj)/piggy.o:$(obj)/piggy.gzFORCE

$(obj)/vmlinux: $(obj)/vmlinux.lds $(obj)/$(HEAD) $(obj)/piggy.o / $(addprefix $(obj)/, $(OBJS)) FORCE $(call if_changed,ld) @: $(obj)/piggy.gz: $(obj)/../Image FORCE $(call if_changed,gzip) $(obj)/piggy.o: $(obj)/piggy.gz FORCE

从这里我们就可以看出来实际上这个vmlinux就是将Image压缩以后根据vmlinux.lds与解压代码head.o和misc.o链接以后生成的一个elf,而且用readelf或者objdump可以很明显地看到解压代码是PIC的,所有的虚

Copyright © 2017-2020 微波EDA网 版权所有

网站地图

Top