Home IT Linux Windows Database Network Programming Server Mobile  
  Home \ Programming \ Do you know how to build the Linux kernel     - 10 Codes of good practice PHP (Programming)

- Spring JDBC Comments (Programming)

- Ubuntu 14.10 Install Ubuntu Touch Music App 2.0 (Linux)

- Mount NFS network file system (Linux)

- Mac Docker deploy development environment (Server)

- Ubuntu 12.04 installation OpenCV2.4.1 and compile test (Linux)

- After CentOS configure SSH password Free, still prompted for a password (Linux)

- Oracle database file path changes (Database)

- Apache Mina framework Practice (Programming)

- MySQL migration tool used in the production environment (Database)

- How to add a new hard disk without restarting the CentOS 7 / RHEL 7 virtual machine (Linux)

- Detailed use Zabbix monitoring Nginx (Server)

- CentOS 6.5 installation and simple configuration Nginx (Server)

- Notebook computer forget password solution (Linux)

- Linux Samba server-side structures and the use of the client (Server)

- Use read command to read user input (Programming)

- Java class HashSet (Programming)

- Volatile keyword in C language understanding (Programming)

- Ubuntu 15.10 15.04 14.10 14.04 Install Ubuntu Tweak (Linux)

- Linux Platform Oracle 11g Single Instance Installation Deployment Configuration Quick Reference (Database)

  Do you know how to build the Linux kernel
  Add Date : 2018-11-21      

I will not tell you how to build up in your computer, install a customized Linux kernel, such as too much information, they will help you. This article will tell you when you make Qiaoxia in the kernel source path in what happens.

When I just started learning kernel code, Makefile is the first file I open this file looks really scary :). At that time the Makefile also contains only 1591 lines of code, when I started writing this article, the kernel is the third release candidate of the 4.2.0.

This is the root makefile makefile Linux kernel code, the kernel build starts right here. Yes, it's a lot of content, but if you've read the kernel source code, you will find that each directory contains the code has its own makefile. Of course, we are not going to describe how each code file is compiled and linked, so we will only select some common examples to illustrate the problem. And you will not find here building the kernel documentation, how to clean the kernel code, tags generation and cross-compile the description, and so on. We will make the start, using the standard kernel configuration files to generate the kernel image bzImage end.

If you already understand it is the best tool to make, but I will describe the relevant code in this article appears.

let's start!

Ready to compile the kernel before

Before starting to build a lot of preparatory work to be carried out. The most important is to find and configure profiles, make the command you want to use to obtain these parameters require configuration files. Let us now deeply rooted kernel makefile

Kernel root Makefile is responsible for building two main documents: vmlinux (kernel image executable) files and modules. Kernel Makefile variables are defined as follows from the start:

NAME = Hurr durr I'ma sheep
These variables determine the current version of the kernel, and is used in many different places, such as with a Makefile in KERNELVERSION:

Next we will see a lot ifeq conditional statements, they are responsible for checking the parameters passed to make. Kernel Makefile provides a special compiler option to make help, this option can generate all the available target, and some can be passed to make a valid command line parameters. For example, make V = 1 outputs detailed information compiled in the build process is to check first ifeq passed to make the V = n option.

ifeq ( "$ (origin V)", "command line")
ifeq ($ (KBUILD_VERBOSE), 1)
quiet =
Q =
quiet = quiet_
Q = @
export quiet Q KBUILD_VERBOSE
If V = n This option is passed to make, the system will be attached to the variable V KBUILD_VERBOSE option value, otherwise KBUILD_VERBOSE will be zero. The system then checks the value KBUILD_VERBOSE, in order to determine the quiet and Q values. The @ symbol control command output, if it is placed before a command, the output of this command will be CC scripts / mod / empty.o, instead Compiling .... scripts / mod / empty.o (LCTT Annotation : CC in the makefile are generally compile command). During this last system to export all of the variables.

The next statement checks ifeq was passed to make the option O = / dir, this option allows the output of all the result files in the specified directory dir:

ifeq ($ (KBUILD_SRC),)
ifeq ( "$ (origin O)", "command line")
ifneq ($ (KBUILD_OUTPUT),)
saved-output: = $ (KBUILD_OUTPUT)
KBUILD_OUTPUT: = $ (shell mkdir-p $ (KBUILD_OUTPUT) && cd $ (KBUILD_OUTPUT) \
&& / Bin / pwd)
$ (If $ (KBUILD_OUTPUT) ,, \
$ (Error failed to create output directory "$ (saved-output)"))
sub-make: FORCE
-f $ (CURDIR) / Makefile $ (filter-out _all sub-make, $ (MAKECMDGOALS))
skip-makefile: = 1
endif # ifneq ($ (KBUILD_OUTPUT),)
endif # ifeq ($ (KBUILD_SRC),)
The system checks the variable KBUILD_SRC, which represents the top-level directory of the kernel code, if it is empty (the first execution makefile always empty), we will set the variable passed to KBUILD_OUTPUT option O value (if this option is transferred He came in). The next step will be to examine variables KBUILD_OUTPUT, if you have set up, then the next will do the following things:

Save the value of the variable to a temporary variable KBUILD_OUTPUT saved-output;
Try to create a given output directory;
Check the output directory is created, if it fails to printing errors;
Successfully creating an output directory, then re-execute the make command (see option -C) in a new directory.
The next statement checks ifeq passed to make the option C and M:

ifeq ( "$ (origin C)", "command line")
ifeq ( "$ (origin M)", "command line")
The first option C would tell makefile need to use the environment variable $ tools provided CHECK to check all the c code used by default sparse case. The second option M will be used to build external modules (not discussed).

The system also checks variables KBUILD_SRC, if KBUILD_SRC is not set, the system sets the variable srctree as follows:

ifeq ($ (KBUILD_SRC),)
srctree: =.
objtree: =.
src: = $ (srctree)
obj: = $ (objtree)
export srctree objtree VPATH
This will tell the Makefile in the kernel source tree directory execute make command, and then want to set objtree and other variables for the directory, and export these variables. Next is to get the value SUBARCH. This variable represents the current system architecture (LCTT Annotation: generally refers to the CPU architecture):

SUBARCH: = $ (shell uname-m | sed-e s / i.86 / x86 / -e s / x86_64 / x86 / \
-e s / sun4u / sparc64 / \
-e s / arm. * / arm / -e s / sa110 / arm / \
-e s / s390x / s390 / -e s / parisc64 / parisc / \
-e s / ppc. * / powerpc / -e s / mips. * / mips / \
-e s / sh [234]. * / sh / -e s / aarch64. * / arm64 /)
As you can see, the system performs uname get the machine operating system and architecture information. Because we get uname output, so we need to do some processing and then assigned to the variable SUBARCH. After obtaining the necessary settings SRCARCH SUBARCH and hfr-arch, SRCARCH provides hardware architecture-related code directory, hfr-arch provides a directory-related header files:

ifeq ($ (ARCH), i386)
SRCARCH: = x86
ifeq ($ (ARCH), x86_64)
SRCARCH: = x86
hdr-arch: = $ (SRCARCH)
Note: ARCH is SUBARCH alias. If not set representative of the kernel configuration file path variable KCONFIG_CONFIG, the next step will be to set it up, by default is .config:

And the process of compiling the kernel to be used in shell

CONFIG_SHELL: = $ (shell if [-x "$$ BASH"]; thenecho $$ BASH; \
elseif [-x / bin / bash]; thenecho / bin / bash; \
elseecho sh; fi; fi)
Next step is to set up a group to compile the kernel and compiler-related variables. We will set up a host of C and C ++ compilers and related configuration items:

HOSTCC = gcc
HOSTCXX = g ++
HOSTCFLAGS = -Wall-Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer -std = gnu89
Then the adapter will go on behalf of the compiler variable CC, then why HOST * these variables? This is because the CC is the target architecture to compile the kernel to use during the compiler, but HOSTCC is to be used to compile a set of host application (we will see below).

Then we see the definition of variables and KBUILD_BUILTIN KBUILD_MODULES, these two variables we decided to compile anything (kernel module, or both):

ifeq ($ (MAKECMDGOALS), modules)
Here we can see the definition of these variables, and if they only passed modules to make, variable KBUILD_BUILTIN will depend on the kernel configuration options CONFIG_MODVERSIONS.

The next step is the introduction of the following documents:

include scripts / Kbuild.include
File Kbuild or also called Kernel Build System is used to manage a special framework to build the kernel and its modules. kbuild file syntax and makefile the same. File scripts / Kbuild.include provides general defined as kbuild system. Because we included this kbuild file, we can see the definition and different tools associated with these variables, these tools will be in the process of compiling the kernel and modules to be used (for example, linker, compiler, binary tools from the binutils package, etc. Wait):

CPP = $ (CC) -E
AWK = awk
Behind the defined variables, we define two variables: USERINCLUDE and LINUXINCLUDE. They contain the path of the header file (the first one is used to the user, the second is to use the kernel):

-I $ (Srctree) / arch / $ (hdr-arch) / include / uapi \
-Iarch / $ (Hdr-arch) / include / generated / uapi \
-I $ (Srctree) / include / uapi \
-Iinclude / Generated / uapi \
-include $ (srctree) /include/linux/kconfig.h
-I $ (Srctree) / arch / $ (hdr-arch) / include \
As well as to the standard C compiler flags:

KBUILD_CFLAGS: = - Wall-Wundef-Wstrict-prototypes -Wno-trigraphs \
-fno-strict-aliasing -fno-common \
-Werror-Implicit-function-declaration \
-Wno-Format-security \
-std = gnu89
This is not finalized compiler flags, they can also update (such as arch / inside kbuild) in other makefile inside. After complete variable definition, all are exported makefile for other use.

The following two variables RCS_FIND_IGNORE and RCS_TAR_IGNORE contain ignored file version control system:

export RCS_FIND_IGNORE: = \ (-name SCCS -o -name BitKeeper-o -name .svn -o \
-name CVS -o -name .pc -o -name .hg -o -name .git \) \
-prune -o
export RCS_TAR_IGNORE: = - exclude SCCS --exclude BitKeeper - exclude .svn \
--exclude CVS --exclude .pc --exclude .hg --exclude .git
That's all, we have completed all of the preparatory work, the next point is that if you build vmlinux.


Facing a kernel build

Now that we have completed all the preparations, the root makefile (Note: the kernel root directory of the makefile) the next step is to compile the kernel and the relevant. Prior to this, we will not see anything make command output at the terminal. But the first step now compiled began, where we need to start from the kernel root makefile 598 rows, where you can see the target vmlinux:

all: vmlinux
include arch / $ (SRCARCH) / Makefile
Do not worry we skip from export RCS_FIND_IGNORE ..... to all: vmlinux ..... this part of the makefile code, they are only responsible for generating different targets according to various kernel configuration file (make * .config), because before I say this section we discuss only common way to build the kernel.

Target all: at the time of the command line without specifying a target using the default target. You can see here it contains the schema associated makefile (here it refers to the arch / x86 / Makefile). From that moment, we will from this makefile continue. As we have seen, all dependent on the root makefile target later declared vmlinux:

vmlinux: scripts / link-vmlinux.sh $ (vmlinux-deps) FORCE
vmlinux is a statically linked linux kernel executable file format. Script scripts / link-vmlinux.sh the different sub-compiled modules are linked together to form a vmlinux.

The second objective is vmlinux-deps, which is defined as follows:

It is a built-in.o each top-level directory of the kernel code under the component. Then we will check all the kernel directory, kbuild under each directory compiles all correspondence $ (obj-y) source files. Then call $ (LD) -r these files into a build-in.o file. At this point we have not vmlinux-deps, so the target will not be built now vmlinux. For me vmlinux-deps contains the following files:

arch / x86 / kernel / vmlinux.lds arch / x86 / kernel / head_64.o
arch / x86 / kernel / head64.o arch / x86 / kernel / head.o
init / built-in.o usr / built-in.o
arch / x86 / built-in.o kernel / built-in.o
mm / built-in.o fs / built-in.o
ipc / built-in.o security / built-in.o
crypto / built-in.o block / built-in.o
lib / lib.a arch / x86 / lib / lib.a
lib / built-in.o arch / x86 / lib / built-in.o
drivers / built-in.o sound / built-in.o
firmware / built-in.o arch / x86 / pci / built-in.o
arch / x86 / power / built-in.o arch / x86 / video / built-in.o
net / built-in.o
The next target may be executed as follows:

$ (Sort $ (vmlinux-deps)): $ (vmlinux-dirs);
$ (Vmlinux-dirs): prepare scripts
$ (Q) $ (MAKE) $ (build) = $ @
As we can see, vmlinux-dir relies on two parts: prepare and scripts. First prepare the root makefile defined in the kernel, the preparation is divided into three stages:

prepare: prepare0
prepare0: archprepare FORCE
$ (Q) $ (MAKE) $ (build) =.
archprepare: archheaders archscripts prepare1 scripts_basic
prepare1: prepare2 $ (version_h) include / generated / utsrelease.h \
include / config / auto.conf
$ (Cmd_crmodverdir)
prepare2: prepare3 outputmakefile asm-generic
The first prepare0 expand to archprepare, which in turn expands to archheader and archscripts, these two variables are defined in the x86_64 related Makefile. Let's look at this document. x86_64 specific makefile from the variable definition, these variables are specific architecture and configuration files (defconfig, etc.) are associated. After defining the compile 16-bit code compiler options, according to the value of the variable BITS, if it is 32, the assembly code, the linker, and many other things (all definitions in arch / x86 / Makefile found) corresponding parameter is the i386, which corresponds to 64 on x86_84.

The first objective is to generate makefile list of system call (syscall table) in archheaders:

$ (Q) $ (MAKE) $ (build) = arch / x86 / entry / syscalls all
The second objective is makefile Lane archscripts:

archscripts: scripts_basic
$ (Q) $ (MAKE) $ (build) = arch / x86 / tools relocs
We can see archscripts be dependent on the root Makefile Lane scripts_basic. First of all we can see is the implementation scripts_basic make according to scripts / basic of makefile:

$ (Q) $ (MAKE) $ (build) = scripts / basic
scripts / basic / Makefile contains two compiled host program fixdep and bin2 goal:

hostprogs-y: = fixdep
hostprogs - $ (CONFIG_BUILD_BIN2C) + = bin2c
always: = $ (hostprogs-y)
$ (Addprefix $ (obj) /, $ (filter-out fixdep, $ (always))): $ (obj) / fixdep
The first tool is fixdep: gcc used to optimize the generated dependency list, and then recompile the source file tells make. The second tool is bin2c, it depends on the kernel configuration options CONFIG_BUILD_BIN2C, and it is used to a standard input interface (LCTT translation: stdin) received binary stream output via standard interfaces (ie: stdout) into C head file is very small C program. You may have noticed some strange symbol here, as hostprogs-y like. This flag is used for all kbuild files, you can get more information from the documentation. Us, hostprogs-y told kbuild there is a program called fixed, fixdep.c through this program and Makefile compiled from the same directory.

After executing make, the first output terminal kbuild result of:

$ Make
HOSTCC scripts / basic / fixdep
When the target script_basic executed, makefile goals and objectives relocs archscripts will make arch / x86 / tools under:

$ (Q) $ (MAKE) $ (build) = arch / x86 / tools relocs
Contains the code relocs_32.c relocation information will be compiled and relocs_64.c, which can be seen in the output of make:

HOSTCC arch / x86 / tools / relocs_32.o
HOSTCC arch / x86 / tools / relocs_64.o
HOSTCC arch / x86 / tools / relocs_common.o
HOSTLD arch / x86 / tools / relocs
After compiling relocs.c checks version.h:

$ (Version_h): $ (srctree) / Makefile FORCE
$ (Call filechk, version.h)
$ (Q) rm-f $ (old_version_h)
We can see it in the output:

CHK include / config / kernel.release
And the use of arch / x86 / include / generated / asm goal asm-generic root Makefiel generic kernel to build the assembly header files. After the target asm-generic, archprepare is complete, the target prepare0 will then be executed, as I wrote above:

prepare0: archprepare FORCE
$ (Q) $ (MAKE) $ (build) =.
Note that build, it is defined in the file scripts / Kbuild.include, the content is this:

build: = - f $ (srctree) /scripts/Makefile.build obj
Or, in our case, it is the current source directory path::

$ (Q) $ (MAKE) -f $ (srctree) /scripts/Makefile.build obj =.
Script scripts / Makefile.build find Kbuild file directory given by the parameter obj, then introduced kbuild file:

include $ (kbuild-file)
And in accordance with this build target. We here contains the generated kernel / bounds.s and arch / x86 / kernel / asm-offsets.s of Kbuild file. After that, prepare the target to complete its work. vmlinux-dirs also depends on the second goal scripts, it will compile next several procedures: filealias, mk_elfconfig, modpost like. After, scripts / host-programs can begin to compile our goal vmlinux-dirs up.

First, let's understand what vmlinux-dirs contain those things. In our example, it includes the following kernel directory path:

init usr arch / x86 kernel mm fs ipc security crypto block
drivers sound firmware arch / x86 / pci arch / x86 / power
arch / x86 / video net lib arch / x86 / lib

We can find the definition vmlinux-dirs in the root Makefile in the kernel:

vmlinux-dirs: = $ (patsubst% /,%, $ (filter% /, $ (init-y) $ (init-m) \
$ (Core-y) $ (core-m) $ (drivers-y) $ (drivers-m) \
$ (Net-y) $ (net-m) $ (libs-y) $ (libs-m)))
init-y: = init /
drivers-y: = drivers / sound / firmware /
net-y: = net /
libs-y: = lib /
Here we use function patsubst and filter to remove each directory path where the symbol /, and put the result vmlinux-dirs inside. So we have vmlinux-dirs in a directory listing, as well as the following code:

$ (Vmlinux-dirs): prepare scripts
$ (Q) $ (MAKE) $ (build) = $ @
$ @ Symbol here represents vmlinux-dirs, which shows that the program will recursively traverse from vmlinux-dirs directory and all within it (depending on configuration), and execute make command in the corresponding directory. We can see the result in the output:

CC init / main.o
CHK include / generated / compile.h
CC init / version.o
CC init / do_mounts.o
CC arch / x86 / crypto / glue_helper.o
AS arch / x86 / crypto / aes-x86_64-asm_64.o
CC arch / x86 / crypto / aes_glue.o
AS arch / x86 / entry / entry_64.o
AS arch / x86 / entry / thunk_64.o
CC arch / x86 / entry / syscall_64.o
Source code for each directory will be compiled and linked to the built-io.o in:

$ Find.-name built-in.o
Well, all of the built-in.o are built over, and now we are back on target vmlinux. You should also remember that the goal is at the root makefile vmlinux kernel inside. Before linking vmlinux, the system will build samples, Documentation, etc., but as mentioned above, I will not describe them in this article.

vmlinux: scripts / link-vmlinux.sh $ (vmlinux-deps) FORCE
+ $ (Call if_changed, link-vmlinux)
As you can see, the main purpose of calling the script scripts / link-vmlinux.sh is all the built-in.o link into a static executable file, and generate System.map. Finally, we take a look at the following output:

LINK vmlinux
LD vmlinux.o
MODPOST vmlinux.o
GEN .version
CHK include / generated / compile.h
UPD include / generated / compile.h
CC init / version.o
LD init / built-in.o
KSYM .tmp_kallsyms1.o
KSYM .tmp_kallsyms2.o
LD vmlinux
SORTEX vmlinux
SYSMAP System.map
vmlinux System.map and the kernel source code is generated under the root directory.

$ Ls vmlinux System.map
System.map vmlinux
That was all, vmlinux constructed well, the next step is to create a bzImage.


Make bzImage

bzImage is the compressed linux kernel images. After that we can build vmlinux obtained by performing bzImage make bzImage. Meanwhile, we can only make the implementation without any parameters can also be generated bzImage, because it is in arch / x86 / kernel / Makefile in predefined default generated image:

all: bzImage
Let's look at this, it helps us understand how this image is constructed. I've said bzImage is defined in arch / x86 / kernel / Makefile, defined as follows:

bzImage: vmlinux
$ (Q) $ (MAKE) $ (build) = $ (boot) $ (KBUILD_IMAGE)
$ (Q) mkdir-p $ (objtree) / arch / $ (UTS_MACHINE) / boot
$ (Q) ln-fsn ../../x86/boot/bzImage $ (objtree) / arch / $ (UTS_MACHINE) / boot / $ @
Here we can see the first performance make the boot directory, in our example is as follows:

boot: = arch / x86 / boot
Now the main goal is to compile the directory arch / x86 / boot and arch / x86 / boot / compressed code, and build setup.bin vmlinux.bin, finally generated bzImage with these two files. The first objective is defined in arch / x86 / boot / Makefile in $ (obj) /setup.elf:

$ (Obj) /setup.elf: $ (src) /setup.ld $ (SETUP_OBJS) FORCE
$ (Call if_changed, ld)
We have in the directory arch / x86 / boot script with links setup.ld, and extended to the boot directory of all the source code variable SETUP_OBJS. We can look at the first output:

AS arch / x86 / boot / bioscall.o
CC arch / x86 / boot / cmdline.o
AS arch / x86 / boot / copy.o
HOSTCC arch / x86 / boot / mkcpustr
CPUSTR arch / x86 / boot / cpustr.h
CC arch / x86 / boot / cpu.o
CC arch / x86 / boot / cpuflags.o
CC arch / x86 / boot / cpucheck.o
CC arch / x86 / boot / early_serial_console.o
CC arch / x86 / boot / edd.o
The next source file is the arch / x86 / boot / header.S, but we can not build it now, because this goal depends on the following two headers:

$ (Obj) /header.o: $ (obj) /voffset.h $ (obj) /zoffset.h
The first is to use the header file voffset.h sed script generated by the nm tool contains two addresses obtained from vmlinux:

#define VO__end 0xffffffff82ab0000
#define VO__text 0xffffffff81000000
These two addresses are kernel start and end addresses. Zoffset.h second header file in arch / x86 / boot / compressed / Makefile can be seen to depend on the target vmlinux:

$ (Obj) /zoffset.h: $ (obj) / compressed / vmlinux FORCE
$ (Call if_changed, zoffset)
Target $ (obj) / compressed / vmlinux dependent on vmlinux-objs-y - explained need to compile the source code directory arch / x86 / boot / compressed under, and then generate vmlinux.bin, vmlinux.bin.bz2, and compiler tools mkpiggy . We can see in the following output:

LDS arch / x86 / boot / compressed / vmlinux.lds
AS arch / x86 / boot / compressed / head_64.o
CC arch / x86 / boot / compressed / misc.o
CC arch / x86 / boot / compressed / string.o
CC arch / x86 / boot / compressed / cmdline.o
OBJCOPY arch / x86 / boot / compressed / vmlinux.bin
BZIP2 arch / x86 / boot / compressed / vmlinux.bin.bz2
HOSTCC arch / x86 / boot / compressed / mkpiggy
vmlinux.bin is to remove debugging information and comments vmlinux binary file, add the occupied u32: is vmlinux.bin.bz2 after vmlinux.bin.all (LCTT Annotation namely 4-Byte) length information compression. Vmlinux.bin.all which contains vmlinux.bin and vmlinux.relocs (LCTT Annotation: vmlinux relocations), after which vmlinux.relocs is vmlinux vmlinux image processing program relocs (supra). We now have to get these files, assembler files piggy.S mkpiggy will be generated, and then compile:

MKPIGGY arch / x86 / boot / compressed / piggy.S
AS arch / x86 / boot / compressed / piggy.o
This document contains a compilation calculated come compressed kernel offset information. Processing this compilation of documents, we can see zoffset generated:

ZOFFSET arch / x86 / boot / zoffset.h
Now zoffset.h and voffset.h has been generated, arch / x86 / boot where the source files can continue to compile:

AS arch / x86 / boot / header.o
CC arch / x86 / boot / main.o
CC arch / x86 / boot / mca.o
CC arch / x86 / boot / memory.o
CC arch / x86 / boot / pm.o
AS arch / x86 / boot / pmjump.o
CC arch / x86 / boot / printf.o
CC arch / x86 / boot / regs.o
CC arch / x86 / boot / string.o
CC arch / x86 / boot / tty.o
CC arch / x86 / boot / video.o
CC arch / x86 / boot / video-mode.o
CC arch / x86 / boot / video-vga.o
CC arch / x86 / boot / video-vesa.o
CC arch / x86 / boot / video-bios.o
All source code is compiled, they will eventually be linked to setup.elf:

LD arch / x86 / boot / setup.elf

ld-m elf_x86_64 -T arch / x86 / boot / setup.ld arch / x86 / boot / a20.o arch / x86 / boot / bioscall.o arch / x86 / boot / cmdline.o arch / x86 / boot / copy. o arch / x86 / boot / cpu.o arch / x86 / boot / cpuflags.o arch / x86 / boot / cpucheck.o arch / x86 / boot / early_serial_console.o arch / x86 / boot / edd.o arch / x86 / boot / header.o arch / x86 / boot / main.o arch / x86 / boot / mca.o arch / x86 / boot / memory.o arch / x86 / boot / pm.o arch / x86 / boot / pmjump.o arch / x86 / boot / printf.o arch / x86 / boot / regs.o arch / x86 / boot / string.o arch / x86 / boot / tty.o arch / x86 / boot / video.o arch / x86 / boot /video-mode.o arch / x86 / boot / version.o arch / x86 / boot / video-vga.o arch / x86 / boot / video-vesa.o arch / x86 / boot / video-bios.o -o arch / x86 / boot / setup.elf
The last two things is created that contains the directory arch / x86 / boot / * compiled code under setup.bin:

objcopy -O binary arch / x86 / boot / setup.elf arch / x86 / boot / setup.bin
And generating vmlinux.bin from vmlinux:

objcopy -O binary -R .note -R .comment -S arch / x86 / boot / compressed / vmlinux arch / x86 / boot / vmlinux.bin
Most Finally, we have compiled the host program arch / x86 / boot / tools / build.c, it will be used to setup.bin and vmlinux.bin packaged into bzImage:

arch / x86 / boot / tools / build arch / x86 / boot / setup.bin arch / x86 / boot / vmlinux.bin arch / x86 / boot / zoffset.h arch / x86 / boot / bzImage
In fact bzImage is to setup.bin and vmlinux.bin connected together. Eventually we will see the output result, and the results of those compiled with the kernel source counterparts like:

Setupis16268 bytes (padded to 16384 bytes).
Systemis4704 kB
CRC 94a88f9a
Kernel: arch / x86 / boot / bzImage is ready (# 5)
All over.


in conclusion

This is the end of this article. In this paper, we know all the steps to compile the kernel: make command from the beginning to the last generation bzImage. I know, linux linux kernel makefile and build process might seem confusing at first glance, but this is not difficult. I hope this article will help you understand the entire process to build linux kernel.
- Linux kernel modules related to the management Comments (Linux)
- Atlassian Linux Shell Scripting the confluence remote backup methods (Linux)
- VPS xen openvz kvm (Server)
- SendMail version of Java implementation with attachments (Programming)
- IO reference Docker container (Server)
- ElasticSearch - Basic Concepts (Server)
- MySQL management partition table (Database)
- CentOS 5.3 under broadcom NIC dual activation issues (Linux)
- JBoss7 configuration - Supports IPv4 and IPv6 dual-stack environment (Server)
- Ubuntu 12.04 kernel configuration automatically restart and crash dump (Linux)
- Linux system security audit tools scan nessus installation tutorial (Linux)
- Introduction to Linux Shell (Programming)
- Java reflection Introduction (Programming)
- Python closure and function objects (Programming)
- Linux RPM (Linux)
- Linux modify environment variables method (Linux)
- AngularJS - Getting Started with Routing (Programming)
- Installation and deployment of MariaDB under CentOS (Database)
- grep command Series: grep command to search for multiple words (Linux)
- Django url () function Detailed (Programming)
  CopyRight 2002-2016 newfreesoft.com, All Rights Reserved.