首页 > 代码库 > Arm Linux Kernel 构建 情景分析
Arm Linux Kernel 构建 情景分析
概述
构建一个内核,一般是先配置,后编译。这里以构建 Nexus5 内核为例,代号为 hammerhead。配置
通常做法是以厂商预置的配置为基础,根据自己需要进行配置。命令:make ARCH=arm hammerhead_defconfig
执行完毕后,"arch/arm/configs/hammerhead_defconfig" 文件会被复制到 ".config" ,作为默认配置。然后运行以下命令根据自己需要进行配置:make ARCH=arm menuconfig
编译
通常,需要生成 zImage 和 内核模块。如果不指定目标,这两个都会默认生成。命令:
# CROSS_COMPILE 的值根据自己情况设定
make ARCH=arm CROSS_COMPILE=arm-linux-androideabi-
这条命令做了什么呢,把 make 输出到控制台的信息贴出来(省略中间相似的信息):make ARCH=arm CROSS_COMPILE=arm-linux-androideabi- CONFIG_DEBUG_SECTION_MISMATCH=yscripts/kconfig/conf --silentoldconfig KconfigWRAP arch/arm/include/generated/asm/auxvec.hWRAP arch/arm/include/generated/asm/bitsperlong.hWRAP arch/arm/include/generated/asm/cputime.h...WRAP arch/arm/include/generated/asm/siginfo.hWRAP arch/arm/include/generated/asm/sizes.hCHK include/linux/version.hUPD include/linux/version.hCHK include/generated/utsrelease.hUPD include/generated/utsrelease.hGenerating include/generated/mach-types.hCC kernel/bounds.sGEN include/generated/bounds.hCC arch/arm/kernel/asm-offsets.sGEN include/generated/asm-offsets.hCALL scripts/checksyscalls.shHOSTCC scripts/dtc/checks.oHOSTCC scripts/dtc/data.o...HOSTCC scripts/conmakehashHOSTCC scripts/recordmcountCC init/main.oCHK include/generated/compile.hUPD include/generated/compile.hCC init/version.oCC init/do_mounts.oCC init/do_mounts_rd.oCC init/do_mounts_initrd.oLD init/mounts.oCC init/initramfs.oCC init/calibrate.oLD init/built-in.o...AR lib/lib.aLD vmlinux.oMODPOST vmlinux.oGEN .versionCHK include/generated/compile.hUPD include/generated/compile.hCC init/version.oLD init/built-in.oLD .tmp_vmlinux1KSYM .tmp_kallsyms1.SAS .tmp_kallsyms1.oLD .tmp_vmlinux2KSYM .tmp_kallsyms2.SAS .tmp_kallsyms2.oLD vmlinuxSYSMAP System.mapSYSMAP .tmp_System.mapOBJCOPY arch/arm/boot/ImageKernel: arch/arm/boot/Image is readyAS arch/arm/boot/compressed/head.oGZIP arch/arm/boot/compressed/piggy.gzipAS arch/arm/boot/compressed/piggy.gzip.oCC arch/arm/boot/compressed/misc.oCC arch/arm/boot/compressed/decompress.oCC arch/arm/boot/compressed/string.oAS arch/arm/boot/compressed/lib1funcs.oAS arch/arm/boot/compressed/ashldi3.oLD arch/arm/boot/compressed/vmlinuxOBJCOPY arch/arm/boot/zImageKernel: arch/arm/boot/zImage is readyDTC arch/arm/boot/msm8974-hammerhead-rev-11.dtbDTC arch/arm/boot/msm8974-hammerhead-rev-11j.dtbDTC arch/arm/boot/msm8974-hammerhead-rev-10.dtbDTC arch/arm/boot/msm8974-hammerhead-rev-c.dtbDTC arch/arm/boot/msm8974-hammerhead-rev-b.dtbDTC arch/arm/boot/msm8974-hammerhead-rev-bn.dtbDTC arch/arm/boot/msm8974-hammerhead-rev-a.dtbDTC arch/arm/boot/msm8974-hammerhead-rev-f.dtbCAT arch/arm/boot/zImage-dtbKernel: arch/arm/boot/zImage-dtb is readymake[1]:没有什么可以做的为`arch/arm/boot/dtbs‘。
简单分析一下,大致做了这么几件事情:而我们最终需要的文件就是 zImage-dtb(注意:这里没有生成内核模块,因为所有的内核功能都被配置为 built-in ,编译进 zImage-dtb 了)。
- 根据配置信息,生成了一些头文件
- 编译了一些小工具
- 根据配置信息,有选择性地编译一些源码,将输出的 obj 链接成对应的 built-in.o
- 生成符号表文件
- 将所有的 built-in.o 和符号表链接成内核 vmlinux
- 使用 BOJCOPY 从 vmlinux 生成 Image
- 生成压缩过的内核 arch/arm/boot/compressed/vmlinux
- 使用 OBJCOPY 从 压缩过的内核 vmlinux 生成 zImage
- 生成 dtb(device tree blob)
- 将 zImage 和 dtb 连接成一个文件:zImage-dtb
要点分析
内核配置和编译,依靠的是 make 和 kbuild 系统。无论是 make 还是 kbuild,都只是工具,我们并不一定要完全弄清其内部工作原理,只需要熟悉和工作相关的部分即可。这里涉及到的有如下几点:之所以要分析 vmlinux 和 arch/arm/boot/compressed/vmlinux ,是因为这个两个文件是最原始的两个可执行文件:Image 由 vmlinux 生成;zImage 由 arch/arm/boot/compressed/vmlinux 生成。分析这连个文件的生成,还有助于分析 linux 内核的启动过程。
- vmlinux 的构建过程
- arch/arm/boot/compressed/vmlinux 的构建过程
- 源码是如何选择性地参与内核的构建的
基础
vmlinux 的构建过程vmlinux 是 makefile 中的一个目标。makefile 中的规则定义了目标和源码的关系,命令则定义了如何由源码生成目标,变量起辅助作用。规则、命令和变量是 makefile 的三大要素。理清 makefile 规则中定义的依赖关系是分析构建过程的关键。涉及到的几个重要文件:Makefilearch/arm/Makefilearch/arm/boot/Makefilearch/arm/mach-msm/Makefile.bootarch/arm/compressed/Makefile
vmlinux 是一个可执行程序,其链接过程必然涉及的链接脚本,链接脚本是做什么的?看看 ld 手册中的描述:通过 lds 文件,我们至少可以知道一个可执行程序的入口在哪里。这里又要涉及到几个重要文件:# 对应 vmlinuxarch/arm/kernel/vmlinux.lds# 对应 /arch/arm/boot/compressed/vmlinuxarch/arm/boot/compressed/vmlinux.lds
vmlinux 是一个可执行程序,由源码编译、链接而来。那么是哪些源码参与了构建过程,又是如何控制这些源码参与的?后面会分析。为了分析 makefile,这里借用了 UML 的概念。用 包 表示 makefile 文件;用 类 表示 目标和文件;用类间依赖表示目标的依赖;用组合表示变量的定义。下面是一个总图,表明了各个目标之间的依赖关系:(红色边框是可执行程序,蓝色边框是对应的链接脚本)
和 lds 文件的关系
?依赖链:_all->all->vmlinux->$(vmlinux-lds)=arch/arm/kernel/vmlinux.lds从 _all 到 all:
PHONY += allifeq ($(KBUILD_EXTMOD),)_all: allelse_all: modulesendifKBUILD_EXTMOD 只有在内核树外编译内核模块的时候才会定义 M 变量,从而给其赋值,否则为空,这里为空。
从 all 到 vmlinux:all: vmlinux
从 vmlinux 到 $(vmlinux-lds):vmlinux: $(vmlinux-lds) $(vmlinux-init) $(vmlinux-main) vmlinux.o $(kallsyms.o) FORCE
$(vmlinux-lds) 定义:vmlinux-lds := arch/$(SRCARCH)/kernel/vmlinux.lds
和源码的关系
?依赖链:_all->all->vmlinux->$(vmlinux-init)+$(vmlinux-main)看看这个:
# vmlinux# ^# |# +-< $(vmlinux-init)# | +--< init/version.o + more# |# +--< $(vmlinux-main)# | +--< driver/built-in.o mm/built-in.o + more# |# +-< kallsyms.o (see description in CONFIG_KALLSYMS section)
关键部分上面已经列出,这里再次列出来:vmlinux: $(vmlinux-lds) $(vmlinux-init) $(vmlinux-main) vmlinux.o $(kallsyms.o) FORCE那么 $(vmlinux-init) 连个变量是什么呢?通过分析,第一次展开后为:“$(head-y) $(init-y)”。没有找到 $(head-y),而 $(init-y) 最终展开为:init/built-in.o。
到这里有点眉目了(回头看看 make 过程输出的信息,里面有大量的 built-in.o)。可以说是众多的 built-in.o构成了vmlinux。所以 vmlinux 和源码的关系转变成了 built-in.o 和源码的关系。还是看 make 的输出信息:CC init/version.oCC init/do_mounts.oCC init/do_mounts_rd.oCC init/do_mounts_initrd.oLD init/mounts.oCC init/initramfs.oCC init/calibrate.oLD init/built-in.o
可以推测:init/built-in.o 是由 init 目录下的 源码编译、链接而成。在 init 目录下发现 Makefile:
obj-y := main.o version.o mounts.oifneq ($(CONFIG_BLK_DEV_INITRD),y)obj-y += noinitramfs.oelseobj-$(CONFIG_BLK_DEV_INITRD)+= initramfs.oendifobj-$(CONFIG_GENERIC_CALIBRATE_DELAY)+= calibrate.omounts-y := do_mounts.omounts-$(CONFIG_BLK_DEV_RAM)+= do_mounts_rd.omounts-$(CONFIG_BLK_DEV_INITRD)+= do_mounts_initrd.omounts-$(CONFIG_BLK_DEV_MD)+= do_mounts_md.o有内核开发经验的开发者应该知道,赋值到 obj-y 的目标会被编译进 vmlinux,至于是如何控制的,推测 kbuild 系统是有参与的,这属于 make 和 kubild 的内部原理,这里不分析了,知道有这么回事,会用就行了。$(CONFIG_BLK_DEV_INITRD) 等变量在 .config(没错,就是保存内核配置的文件) 文件中定义:
CONFIG_RELAY=yCONFIG_BLK_DEV_INITRD=yCONFIG_INITRAMFS_SOURCE=""这里 vmlinux 和源码的关系就搞清了,是由 built-in.o 来当中间人的:
vmlinux<->built-in.o<->*.c
和符号表的关系
略。
arch/arm/boot/comressed/vmlinux 的构建过程
有了分析 vmlinux 的基础,分析压缩过的 vmlinux 就容易了。看 规则:$(obj)/vmlinux: $(obj)/vmlinux.lds $(obj)/$(HEAD) $(obj)/piggy.$(suffix_y).o $(addprefix $(obj)/, $(OBJS)) $(lib1funcs) $(ashldi3) FORCE@$(check_for_multiple_zreladdr)$(call if_changed,ld)@$(check_for_bad_syms)参与压缩过的 vmlinux 的构建过程的主要有三类文件:
因为解压缩功能和内核开发关系不大,就不具体分析了。
- 链接脚本:arch/arm/boot/compressed/vmlinux.lds
- 解压代码:arch/arm/boot/compressed/ 下的源码
- 压缩的数据:压缩的 Image(由未经压缩的 vmlinux 生成)
Arm Linux Kernel 构建 情景分析
声明:以上内容来自用户投稿及互联网公开渠道收集整理发布,本网站不拥有所有权,未作人工编辑处理,也不承担相关法律责任,若内容有误或涉及侵权可进行投诉: 投诉/举报 工作人员会在5个工作日内联系你,一经查实,本站将立刻删除涉嫌侵权内容。