Analysis of the construction scenario of ARM Linux Kernel

Overview

build a kernel that is typically configured first and then compiled. This is the example of building the NEXUS5 kernel, codenamed Hammerhead. Configuration

The

usual approach is based on the vendor-provisioned configuration, which is configured to suit your needs. Command:

 Make Arch=arm Hammerhead_defconfig

After execution, the "arch/arm/configs/hammerhead_defconfig" file is copied to ". config" as the default configuration. Then run the following command to configure it to suit your needs:

 Make Arch=arm Menuconfig

compiling

Typically, you need to generate zimage and kernel modules. If you do not specify a target, both will be generated by default. Command:

1. # CROSS_COMPILE 的值根据自己情况设定

    Make Arch=arm cross_compile=arm-linux-androideabi-

What does this command do, to post the information that makes output to the console (omitting information similar to the middle):

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]: Nothing can be done for ' Arch/arm/boot/dtbs '.

A brief analysis of a few things is done roughly:

1. Some header files are generated based on the configuration information
2. Compiled a few gadgets
3. According to the configuration information, some source code is selectively compiled, and the output obj is linked to the corresponding BUILT-IN.O
4. Generating symbol table Files
5. Connect all BUILT-IN.O and symbol tables to the kernel Vmlinux
6. Generate an Image from Vmlinux using bojcopy
7. Generate a compressed kernel Arch/arm/boot/compressed/vmlinux
8. Use Objcopy to generate zimage from a compressed kernel vmlinux
9. Build DTB (Device tree blob)
10. Connect Zimage and DTB to a file: ZIMAGE-DTB

And the final file we need is ZIMAGE-DTB (note: There is no kernel module generated because all kernel functions are configured as built-in, compiled into ZIMAGE-DTB).

Essentials Analysis

The kernel is configured and compiled, relying on make and kbuild systems.       Whether make or kbuild is just a tool, we don't have to fully understand how it works internally, just be familiar with the work-related parts. Here are some of the following:

• The construction process of vmlinux
• The construction process of Arch/arm/boot/compressed/vmlinux
• How the source code chooses to participate in the kernel's construction

the reason for analyzing vmlinux and Arch/arm/boot/compressed/vmlinux is that the two files are the most primitive two executables: Image generated by vmlinux; Zimage by arch/arm/ Boot/compressed/vmlinux generation. Analyzing the generation of this even file also helps to analyze the boot process of the Linux kernel. Basic

Vmlinux is a goal in the makefile. The rules in makefile define the relationship between the target and the source code, and the command defines how the target is generated by the source code, and the variables play an auxiliary role. Rules, commands, and variables are the three main elements of makefile. clearing the dependencies defined in the makefile rules is the key to the analysis of the build process. Several important documents are involved:

Makefilearch/arm/makefilearch/arm/boot/makefilearch/arm/mach-msm/makefile.bootarch/arm/compressed/makefile

Vmlinux is an executable program whose linking process necessarily involves a link script, what does a link script do? Take a look at the description in the LD Handbook: With LDS files, we can at least know where an executable program's entry is. There are also several important documents to be involved:

# corresponds to vmlinuxarch/arm/kernel/vmlinux.lds# corresponding/arch/arm/boot/compressed/vmlinuxarch/arm/boot/compressed/vmlinux.lds

Vmlinux is an executable program, compiled and linked by the source code. So what source code to participate in the construction process, but also how to control the participation of these sources?        will be analyzed later.        To analyze makefile, we borrowed the concept of UML.       The makefile file is represented by a package, a class is used to represent a target and a file, a dependency between classes is used to represent a target, and a combination represents the definition of a variable. Here is a general diagram that shows the dependencies between the targets: (Red border is executable, blue border is the corresponding link script)

the construction process of Vmlinux

< Span style= "FONT-SIZE:1.3EM; line-height:1.5; " > ? Dependency chain:

 _all->all->vmlinux->$ (vmlinux-lds) =arch/arm/kernel/vmlinux.lds 

From _all to all:

 phony += Allifeq ($ (kbuild_extmod) ,  

Kbuild_extmod The M variable is defined only when the kernel module is compiled outside the kernel tree, so it is assigned a value, otherwise it is empty.

from all to Vmlinux:

 all:vmlinux 

 

  from Vmlinux to $ (vmlinux-lds):

 vmlinux: $ (vmlinux-lds
 ) $ (vmlinux-init) $ (vmlinux-main) VMLINUX.O $ (KALLSYMS.O) Force 

 

 $ (vmlinux-lds) definition: 

 Vmlinux-lds: = arch/$ (srcarch)/kernel/vmlinux.lds 

 

the relationship with the source code

? Dependency chain:

_all->all->vmlinux->$ (Vmlinux-init) +$ (Vmlinux-main)

Check this out:

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

The key sections are listed above and listed here again:

Vmlinux: $ (vmlinux-lds) $ (vmlinux-init) $ (vmlinux-main) VMLINUX.O $ (KALLSYMS.O) force

So what is a $ (vmlinux-init) variable? Through analysis, the first expansion is: "$ (head-y) $ (init-y)".       $ (head-y) was not found, while $ (init-y) eventually unfolded as: INIT/BUILT-IN.O. Here's a little bit of a look (looking back at the information the make process output, there's a lot of BUILT-IN.O). It can be said that many built-in.o constitute the vmlinux.       Therefore, the relationship between Vmlinux and source becomes the relationship between BUILT-IN.O and source code. Or look at the output information of 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

It can be speculated that the INIT/BUILT-IN.O is compiled and linked by the source code under the Init directory. Makefile found under the init directory:

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

Developers with kernel development experience should know that the assignment to Obj-y Target will be compiled into the vmlinux, as to how to control, speculation Kbuild system is involved, this is the internal principle of make and kubild, here does not analyze, know that there is such a thing, will be used on the line. The $ (CONFIG_BLK_DEV_INITRD) variables are defined in. CONFIG (yes, the file that holds the kernel configuration) in the file:

config_relay=yconfig_blk_dev_initrd=Yconfig_initramfs_source= ""

Here Vmlinux and the source of the relationship is clear, is by the BUILT-IN.O to be a middleman:

Vmlinux<->built-in.o<->*.c

relationship to the symbol table

A

little.

the construction process of Arch/arm/boot/comressed/vmlinux

with the basis of analysis Vmlinux, it is easy to analyze the compressed vmlinux. See the rules:

$ (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)

There are three main types of files involved in the process of building a compressed vmlinux:

• Link script: Arch/arm/boot/compressed/vmlinux.lds
• Decompression code: arch/arm/boot/compressed/under the source
• Compressed data: Compressed Image (generated by uncompressed vmlinux)

because the decompression function and the kernel development relationship is not very small, it is not specifically analyzed.

Analysis of the construction scenario of ARM Linux Kernel