要想分析内核的启动过程，首先得知道内核从哪个函数入口的。那这个入口是谁呢？根据分析uboot启动流程的经验，你会想到lds文件。内核里这么多lds文件，要先分析哪个呢？
在linux下，uboot引导的是uImage，不妨从uImage入口。首先看顶层的Makefile。uImage是怎么生成的：
我们查看顶层的Makefile。没有找uImage。那就分析一下，这个uImage可能会在哪个Makefile。因为我们编译的是arm平台，会不会在arch/arm下的Makefile呢？进去一看发现了uImage的藏身之处。那么顶层的Mafefile会不会包含这个arch/arm/Makefile呢？在最顶层的Makefile中发现了
484 include $(srctree)/arch/$(SRCARCH)/Makefile
这说明我们的分析是正确的，源码根目录下的Makefile确实是包含了arch/arm/Makefile($(SRCARCH)=arm)。接下来可以分析一下arch/arm/Makefile了。继续跟踪我们需要的uImage。
在arch/arm/Makefile中搜搜uImage
303 zImage Image xipImage bootpImage uImage: $(VMLINUX)
304 $(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $(boot)/$@
可以看出uImage依赖
264 # Default target when executing plain make
265 ifeq ($(CONFIG_XIP_KERNEL),y)
266 KBUILD_IMAGE := xipImage
267 else ifeq ($(CONFIG_BUILD_ARM_APPENDED_DTB_IMAGE),y)
268 KBUILD_IMAGE := zImage-dtb.$(CONFIG_BUILD_ARM_APPENDED_DTB_IMAGE_NAME)
269 else
270 KBUILD_IMAGE := zImage
271 endif
272
273 all: $(KBUILD_IMAGE)
274
275 boot := arch/arm/boot
276 comp := $(boot)/compressed
277 VMLINUX := vmlinux vmlinux.bin vmlinux.dump
278 CLEAN_FILES += vmlinux.srec vmlinux.bin vmlinux.dump
279
280 vmlinux.bin: vmlinux
281 $(OBJCOPY) --remove-section=.reginfo -O binary $< $@
282
这个VMLINUX:= vmlinux vmlinux.bin vmlinux.dump，结合zImage Image xipImage bootpImage uImage: $(VMLINUX)
那么就是“”
zImage Image xipImage bootpImage uImage:vmlinux vmlinux.bin vmlinux.dump，还得一点一点的 看。uImage依赖了这么多文件，一个一个看吧。接着你会发现vmlinux.bin: vmlinux 和，vmlinux.dump: vmlinux 即
vmlinux.bin: vmlinux
281 $(OBJCOPY) --remove-section=.reginfo -O binary $< $@
282
283 vmlinux.dump: vmlinux
284 @(\
285 tmp=$@.$$$$;\
286 rm -f $@.[0-9]*;\
287 trap '' SIGHUP SIGINT SIGTTIN SIGTTOU SIGWINCH;\
288 echo Dumping to $$tmp, will move to $@ when done | tee $@;\
289 exec <&- 2>&-;\
290 $(OBJDUMP) -dtr $(objdump-flags-y) $< > $$tmp \
291 && mv $$tmp $@\
292 )& \
293 [ -t 0 ] || wait ;: objdump async only when interactive
294 $(OBJDUMP) -f $<
现在vmlinux.bin vmlinux.dump都依赖于vmlinux，那么我们就只看vmlinux是怎么来的吧！在arch/arm/Makfile中没有找到编译vmlinux的过程。那么看看最顶层的Makefile吧
在顶层的Makefile中
509 init-y := init/
510 drivers-y := drivers/ sound/ firmware/
511 net-y := net/
512 libs-y := lib/
513 core-y := usr/
722 init-y := $(patsubst %/, %/built-in.o, $(init-y))
723 core-y := $(patsubst %/, %/built-in.o, $(core-y))
724 drivers-y := $(patsubst %/, %/built-in.o, $(drivers-y))
725 net-y := $(patsubst %/, %/built-in.o, $(net-y))
726 libs-y1 := $(patsubst %/, %/lib.a, $(libs-y))
727 libs-y2 := $(patsubst %/, %/built-in.o, $(libs-y))
728 libs-y := $(libs-y1) $(libs-y2)
757 vmlinux-init := $(head-y) $(init-y)
758 vmlinux-main := $(core-y) $(libs-y) $(drivers-y) $(net-y)
759 vmlinux-all := $(vmlinux-init) $(vmlinux-main)
760 vmlinux-lds := arch/$(SRCARCH)/kernel/vmlinux.lds
#909 vmlinux image - including updated kernel symbols
910 vmlinux: $(vmlinux-lds) $(vmlinux-init) $(vmlinux-main) vmlinux.o $(kallsym s.o) FORCE
911 ifdef CONFIG_HEADERS_CHECK
912 $(Q)$(MAKE) -f $(srctree)/Makefile headers_check
913 endif
914 ifdef CONFIG_SAMPLES
915 $(Q)$(MAKE) $(build)=samples
916 endif
917 ifdef CONFIG_BUILD_DOCSRC
918 $(Q)$(MAKE) $(build)=Documentation
919 endif
920 $(call vmlinux-modpost)
921 $(call if_changed_rule,vmlinux__)
922 $(Q)rm -f .old_version
923
924 # build vmlinux.o first to catch section mismatch errors early
925 ifdef CONFIG_KALLSYMS
926 .tmp_vmlinux1: vmlinux.o
927 endif
可以看出vmlinux依赖了很多文件，这些文件大多都是dir/built-in.o，如何生成一个built-in.o呢？
不妨随便找一个目录看一下，看看init/built-in.o是怎么生成的吧。如果生成init/built-in.o，肯定要执行init下的Makeifile，在顶层的Makefile中应该有个make -f init/Makefile的过程。
找了一下没找到。却发生有个
那么build的内容是什么呢？
顶层Makeifle include $(srctree)/scripts/Kbuild.include
而Kbuild.include中定义了
build := -f $(if $(KBUILD_SRC),$(srctree)/)scripts/Makefile.build obj
在顶层的Makefile中KBUILD_SRC已经被定义为$(CURDIR)即linux源码的根目录。
$(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $(boot)/$@其实就是
$(Q)$(MAKE) -f $(srctree)/)scripts/Makefile.build obj=$(boot) MACHINE=$(MACHINE) $(boot)/$@
其中 $(boot)就是arch/arm/boot
```
继续看看scripts/Makefile.build,在它里搜关键字"built-in"
发现了`133 ifneq ($(strip $(lib-y) $(lib-m) $(lib-n) $(lib-)),)
134 lib-target := $(obj)/lib.a
135 endif
136
137 ifneq ($(strip $(obj-y) $(obj-m) $(obj-n) $(obj-) $(subdir-m) $(lib-target)) ,)
138 builtin-target := $(obj)/built-in.o
139 endif
`意思很明确，除了lib下的编译成了lib.a外，其他的在obj目录下的*.o都被编进了built-in.o
那么obj是什么呢？由上面的分析可以知道obj就是我们要编译的目录。
原来顶层的Makeifle是这么编译build-in.o的。
用
这个命令展开以后就是
$(Q)$(MAKE) $(build)=(MYDIR)
等价于：
$(Q)$(MAKE) -f $(srctree)/)scripts/Makefile.build obj=(MYDIR)
//根据 scripts下的Makefile.build,可以再次展开为
builtin-target:=(MYDIR/built-in.o)
在顶层的Makefile中执行了多少个
搜索一下有多少个这样的语句
4.y# cat Makefile | grep '$(build)='
$(Q)$(MAKE) $(build)=scripts/basic
$(Q)$(MAKE) $(build)=scripts/kconfig $@
$(Q)$(MAKE) $(build)=scripts/kconfig $@
$(Q)$(MAKE) $(build)=$(@)
$(MAKE) $(build)=init
$(Q)$(MAKE) $(build)=samples
$(Q)$(MAKE) $(build)=Documentation
$(Q)$(MAKE) $(build)=$@
$(Q)$(MAKE) $(build)=.
$(Q)$(MAKE) $(build)=scripts build_unifdef
$(Q)$(MAKE) $(build)=$(package-dir) $@
$(Q)$(MAKE) $(build)=$(package-dir) $@
$(Q)$(MAKE) $(build)=$(package-dir) $@
@$(MAKE) $(build)=$(package-dir) help
$(Q)$(MAKE) $(build)=scripts build_docproc
$(Q)$(MAKE) $(build)=Documentation/DocBook $@
$(Q)$(MAKE) $(build)=$(patsubst _module_%,%,$@)
$(Q)$(MAKE) $(build)=$(build-dir) $(target-dir)$(notdir $@)
$(Q)$(MAKE) $(build)=$(build-dir) $(target-dir)$(notdir $@)
$(Q)$(MAKE) $(build)=$(build-dir) $(target-dir)$(notdir $@)
$(Q)$(MAKE) $(build)=$(build-dir) $(target-dir)$(notdir $@)
$(Q)$(MAKE) $(build)=$(build-dir) $(target-dir)$(notdir $@)
$(Q)$(MAKE) $(build)=$(build-dir) $(target-dir)$(notdir $@)
$(Q)$(MAKE) $(build)=$(build-dir) $(target-dir)$(notdir $@)
$(build)=$(build-dir)
$(build)=$(build-dir)
$(build)=$(build-dir) $(@:.ko=.o)
上面分析的是vmlinux的生成过程，有了vmlinux后，怎么得到uImage呢?
在arch/arm下的Makefile中看一下.
的
300 bzImage: zImage
301
302 #zImage Image xipImage bootpImage uImage: vmlinux
303 zImage Image xipImage bootpImage uImage: $(VMLINUX)
304 $(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $(boot)/$@
305
306 #vmlinux
307 zinstall uinstall install: $(VMLINUX)
308 #zinstall uinstall install: vmlinux
309 $(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $@所有$VMLINUX都已经准备好了，继续看arm/arm/Makefile
47 $(obj)/Image: vmlinux FORCE
48 $(call if_changed,objcopy)
49 @echo ' Kernel: $@ is ready'
50
51 $(obj)/compressed/vmlinux: $(obj)/Image FORCE
52 $(Q)$(MAKE) $(build)=$(obj)/compressed $@
53
54 $(obj)/zImage: $(obj)/compressed/vmlinux FORCE
55 $(call if_changed,objcopy)
56 @echo ' Kernel: $@ is ready'
57
...............
88 $(obj)/uImage: $(obj)/zImage FORCE
89 @$(check_for_multiple_loadaddr)
90 $(call if_changed,uimage)
91 @echo ' Image $@ is ready'
92
93 $(obj)/bootp/bootp: $(obj)/zImage initrd FORCE
94 $(Q)$(MAKE) $(build)=$(obj)/bootp $@
95 @:
96
97 $(obj)/bootpImage: $(obj)/bootp/bootp FORCE
98 $(call if_changed,objcopy)
99 @echo ' Kernel: $@ is ready'
可以看出文件的依赖关系
uImage依赖zImage
zImage 依赖compressed/vmlinux
compressed/vmlinux 依赖Image
Image又依赖于 vmlinux（这个vmlinux就是前面生成的，内核镜像elf文件vmlinux）
显然，我们首先要得到Image。
那么就分析一下怎么得到Image的吧
由
47 $(obj)/Image: vmlinux FORCE
48 $(call if_changed,objcopy)
49 @echo ' Kernel: $@ is ready'
这里可以猜出，大概是vmlinux是经过objcopy后才得到了Image，是不是这样的呢？
我们跟踪一下，if_changed是个函数，这个函数在哪定义呢？
那要看看这个arch/arm/boot下的Makefile本身或者其include的文件中的内容了。
跟踪后发现在arch/arm/boot下的Makeifle中没有定义if_changed这个函数，且其include的文件（只有Makeifle.boot）也没有这个函数。
遇到这种情况，不如直接去分析顶层的Makefile，很可能是顶层的Makefile 的函数，大家都可以使用。
在顶层的Makefile中有一句“”
327 include $(srctree)/scripts/Kbuild.include
//Kbuild.include的内容是什么呢？
199 ifneq ($(KBUILD_NOCMDDEP),1)
200 # Check if both arguments has same arguments. Result is empty string if equal.
201 # User may override this check using make KBUILD_NOCMDDEP=1
202 arg-check = $(strip $(filter-out $(cmd_$(1)), $(cmd_$@)) \
203 $(filter-out $(cmd_$@), $(cmd_$(1))) )
204 else
205 arg-check = $(if $(strip $(cmd_$@)),,1)
206 endif
207
208 # >'< substitution is for echo to work,
209 # >$< substitution to preserve $ when reloading .cmd file
210 # note: when using inline perl scripts [perl -e '...$$t=1;...']
211 # in $(cmd_xxx) double $$ your perl vars
212 make-cmd = $(subst \\,\\\\,$(subst \#,\\\#,$(subst $$,$$$$,$(call escsq,$(cmd_$(1))))))
213
214 # Find any prerequisites that is newer than target or that does not exist.
215 # PHONY targets skipped in both cases.
216 any-prereq = $(filter-out $(PHONY),$?) $(filter-out $(PHONY) $(wildcard $^),$^)
217
218 # Execute command if command has changed or prerequisite(s) are updated.
219 #
220 if_changed = $(if $(strip $(any-prereq) $(arg-check)), \
221 @set -e; \
222 $(echo-cmd) $(cmd_$(1)); \
223 echo 'cmd_$@ := $(make-cmd)' > $(dot-target).cmd)
终于找到if_changed的原形了
这里的any-prereq作用是找到比较新的依赖文件，且过滤伪目标。之后执行了cmd_
我们搜一下cmd_objcopy
root@ubuntu:/home/work2/pdk/Hi3535_SDK/Hi3535_SDK_V2.0.4.0/source/arm11/linux-3.4.y/scripts# grep -nr 'cmd_objcopy'
Makefile.lib:235:quiet_cmd_objcopy = OBJCOPY $@
Makefile.lib:236:cmd_objcopy = $(OBJCOPY) $(OBJCOPYFLAGS) $(OBJCOPYFLAGS_$(@F)) $< $@
//原来在Makefile.lib中定义了其实就是执行了objcopy的命令。其中传递的objcopyflags先不分析，肯定是去除符号信息的。
1. 由内核源码根目录下的elf 文件 vmlinux 经过objcopy 得到了Image.
我们之前分析过“uImage依赖zImage
zImage 依赖compressed/vmlinux
compressed/vmlinux 依赖Image
Image又依赖于 vmlinux（这个vmlinux就是前面生成的，内核镜像elf文件vmlinux）”
得到了Image如何得到compressed/vmlinux 呢？
51 $(obj)/compressed/vmlinux: $(obj)/Image FORCE
52 $(Q)$(MAKE) $(build)=$(obj)/compressed $@
根据这句话，就知道应该分析一下$(obj)/compressed
24 HEAD = head.o
91 suffix_$(CONFIG_KERNEL_GZIP) = gzip
92 suffix_$(CONFIG_KERNEL_LZO) = lzo
93 suffix_$(CONFIG_KERNEL_LZMA) = lzma
94 suffix_$(CONFIG_KERNEL_XZ) = xzkern
95
182 $(obj)/vmlinux: $(obj)/vmlinux.lds $(obj)/$(HEAD) $(obj)/piggy.$(suffix_y).o \
183 $(addprefix $(obj)/, $(OBJS)) $(lib1funcs) $(ashldi3) FORCE
184 @$(check_for_multiple_zreladdr)
185 $(call if_changed,ld)
186 @$(check_for_bad_syms)
187
188 $(obj)/piggy.$(suffix_y): $(obj)/../Image FORCE
189 $(call if_changed,$(suffix_y))
190
191 $(obj)/piggy.$(suffix_y).o: $(obj)/piggy.$(suffix_y) FORCE
这里面的内容告诉我们
要想生成vmlinux，需要准备vmlinux.lds，这里的
这里我们选择的gzip压缩方式，piggy.$(suffix_y).o 对应的就是piggy.gzip.S
看看这个 piggy.gzip.S
1 .section .piggydata,#alloc
2 .globl input_data
3 input_data:
4 .incbin "arch/arm/boot/compressed/piggy.gzip"
5 .globl input_data_end
6 input_data_end:
~
~ incbin了一个二进制文件arch/arm/boot/compressed/piggy.gzip”，它又是怎么来的呢？
arch/arm/boot/compressed下的Makefile写道:
188 $(obj)/piggy.$(suffix_y): $(obj)/../Image FORCE
189 $(call if_changed,$(suffix_y))
190
//piggy.$(suffix_y)就是piggy.gzip这样的话就明白了。需要找到cmd_gzip这个函数。
还在scripts 目录下搜索
4.y/scripts# grep -nr 'cmd_gzip'
Makefile.lib:241:quiet_cmd_gzip = GZIP $@
Makefile.lib:242:cmd_gzip = (cat $(filter-out FORCE,$^) | gzip -n -f -9 > $@) || \
md_gzip = (cat $(filter-out FORCE,$^) | gzip -n -f -9 > $@) || \
243 (rm -f $@ ; false)
244
原来是执行了一条gzip -n -f -9的命令生成了piggy.gzip。
回过头来看一下：
1.源码下的vmlinux经过objcopy得到了Image
2.Image经过了gzip -n -f -9得到了piggy.gzip
3.piggy.gzip.S head.o 和vmlinux.lds共同生成了compressed下的vmlinux。
1. 压缩效率：LZO <GZIP < BZIP2 < LZMA
2. 压缩时间：GZIP <LZO ~= BZIP2 << LZMA
3. 解压缩时间：LZO <GZIP < LZMA<< BZIP2
4.压缩需要的内存：GZIP < LZO < BZIP2 << LZMA
5.解压缩需要的内存：GZIP < LZO < BZIP2 << LZMA
如果FLASH不是问题，启动速度是关键，选LZO。如果是在低成本嵌入式设备上，FLASH和RAM很小，GZIP是不错的选择；如果RAM有限，选BZIP2；如果RAM还够，可以考虑LZMA。
[END]
根据上面分析的。
“uImage依赖zImage
zImage 依赖compressed/vmlinux
compressed/vmlinux 依赖Image
Image又依赖于 vmlinux（这个vmlinux就是前面生成的，内核镜像elf文件vmlinux）”
离目标越来越近了。
看看zImage是怎么生成的吧
在arch/arm/boot下的Makefile中。
54 $(obj)/zImage: $(obj)/compressed/vmlinux FORCE
55 $(call if_changed,objcopy)
56 @echo ' Kernel: $@ is ready'
原来compressed/vmlinux 经过objcopy后得到了zImage。
这个zImage就是经过压缩后的内核镜像。
但是它仍然不能被Uboot引导。因为Uboot引导过程中会解析内核镜像的前64字节。
继续看看zImage怎么得到了uImage。
在arch/arm/boot下的Makefile中。
88 $(obj)/uImage: $(obj)/zImage FORCE
89 @$(check_for_multiple_loadaddr)
90 $(call if_changed,uimage)
91 @echo ' Image $@ is ready'
原来有个命令是cmd_uimage。它是原形是什么呢？
老办法，搜索
grep -nr 'cmd_uimage'
Makefile.lib:324:quiet_cmd_uimage = UIMAGE $(UIMAGE_OUT)
Makefile.lib:325: cmd_uimage = $(CONFIG_SHELL) $(MKIMAGE) -A $(UIMAGE_ARCH) -O linux \
\\Makeifle.lib:
323
324 quiet_cmd_uimage = UIMAGE $(UIMAGE_OUT)
325 cmd_uimage = $(CONFIG_SHELL) $(MKIMAGE) -A $(UIMAGE_ARCH) -O linux \
326 -C $(UIMAGE_COMPRESSION) $(UIMAGE_OPTS-y) \
327 -T $(UIMAGE_TYPE) \
328 -a $(UIMAGE_LOADADDR) -e $(UIMAGE_ENTRYADDR) \
329 -n $(UIMAGE_NAME) -d $(UIMAGE_IN) $(UIMAGE_OUT)
330
331 # XZ
原来是用mkimage工具生成的。
-A 指定了cpu架构是arm
-O 指定了os是linux
-T指定了uImage类型是kernel
-a指定了加载地址
-e指定了入口地址,一般是加载地址减去64字节。
-n指定了uImage头部结构中填充的name
这些参数是uboot能够解析，如果uboot支持这种类型的uImage，就会引导它启动。
到这里，我们可以知道，要分析入口函数，应该先看arch/arm/boot/compressed下的vmlinux.lds文件
OUTPUT_ARCH(arm)
ENTRY(_start)
SECTIONS
{
/DISCARD/ : {
*(.ARM.exidx*)
*(.ARM.extab*)
/*
* Discard any r/w data - this produces a link error if we have any,
* which is required for PIC decompression. Local data generates
* GOTOFF relocations, which prevents it being relocated independently
* of the text/got segments.
*/
*(.data)
}
. = 0;
_text = .;
.text : {
_start = .;
*(.start)
*(.text)
*(.text.*)
*(.fixup)
*(.gnu.warning)
*(.glue_7t)
*(.glue_7)
}
.rodata : {
*(.rodata)
*(.rodata.*)
}
.piggydata : {
*(.piggydata)
}
. = ALIGN(4);
_etext = .;
.got.plt : { *(.got.plt) }
_got_start = .;
.got : { *(.got) }
_got_end = .;
/* ensure the zImage file size is always a multiple of 64 bits */
/* (without a dummy byte, ld just ignores the empty section) */
.pad : { BYTE(0); . = ALIGN(8); }
_edata = .;
. = ALIGN(8);
__bss_start = .;
.bss : { *(.bss) }
_end = .;
. = ALIGN(8); /* the stack must be 64-bit aligned */
.stack : { *(.stack) }
.stab 0 : { *(.stab) }
.stabstr 0 : { *(.stabstr) }
.stab.excl 0 : { *(.stab.excl) }
.stab.exclstr 0 : { *(.stab.exclstr) }
.stab.index 0 : { *(.stab.index) }
.stab.indexstr 0 : { *(.stab.indexstr) }
.comment 0 : { *(.comment) }
}
定义了入口函数_start。它定义在arch/arm/boot/compressed下的head.S
如果要分析内核启动过程的话，当然是先从这个文件入手。
启动过程将在下篇进行分析。
