要想分析内核的启动过程，首先得知道内核从哪个函数入口的。那这个入口是谁呢？根据分析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依赖 ( V M L I N U X ) ，这个 (VMLINUX)，这个 (VMLINUX)，这个(VMLINUX)又是谁呢？继续分析
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的过程。
找了一下没找到。却发生有个$(MAKE) $(build)=init
那么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
)
(Q)
(Q)(MAKE) $(build)=(MYDIR)
等价于：
(
Q
)
(Q)
(Q)(MAKE) -f $(srctree)/)scripts/Makefile.build obj=(MYDIR)
//根据 scripts下的Makefile.build,可以再次展开为
builtin-target:=(MYDIR/built-in.o)
在顶层的Makefile中执行了多少个 $(Q)$(MAKE) $(build)=就有多少个built-in.o(除lib外)
搜索一下有多少个这样的语句
4.y# cat Makefile | grep ‘$(build)=’
(
Q
)
(Q)
(Q)(MAKE) $(build)=scripts/basic
(
Q
)
(Q)
(Q)(MAKE) $(build)=scripts/kconfig $@
(
Q
)
(Q)
(Q)(MAKE) $(build)=scripts/kconfig $@
(
Q
)
(Q)
(Q)(MAKE)
(
b
u
i
l
d
)
=
(build)=
(build)=(@)
$(MAKE) $(build)=init
(
Q
)
(Q)
(Q)(MAKE) $(build)=samples
(
Q
)
(Q)
(Q)(MAKE) $(build)=Documentation
(
Q
)
(Q)
(Q)(MAKE)
(
b
u
i
l
d
)
=
(build)=
(build)=@
(
Q
)
(Q)
(Q)(MAKE) $(build)=.
(
Q
)
(Q)
(Q)(MAKE) $(build)=scripts build_unifdef
(
Q
)
(Q)
(Q)(MAKE)
(
b
u
i
l
d
)
=
(build)=
(build)=(package-dir) $@
(
Q
)
(Q)
(Q)(MAKE)
(
b
u
i
l
d
)
=
(build)=
(build)=(package-dir) $@
(
Q
)
(Q)
(Q)(MAKE)
(
b
u
i
l
d
)
=
(build)=
(build)=(package-dir)
@
@
@ @
@@(MAKE)
(
b
u
i
l
d
)
=
(build)=
(build)=(package-dir) help
(
Q
)
(Q)
(Q)(MAKE) $(build)=scripts build_docproc
(
Q
)
(Q)
(Q)(MAKE) $(build)=Documentation/DocBook $@
(
Q
)
(Q)
(Q)(MAKE)
(
b
u
i
l
d
)
=
(build)=
(build)=(patsubst module%,%,$@)
(
Q
)
(Q)
(Q)(MAKE)
(
b
u
i
l
d
)
=
(build)=
(build)=(build-dir)
(
t
a
r
g
e
t
−
d
i
r
)
(target-dir)
(target−dir)(notdir $@)
(
Q
)
(Q)
(Q)(MAKE)
(
b
u
i
l
d
)
=
(build)=
(build)=(build-dir)
(
t
a
r
g
e
t
−
d
i
r
)
(target-dir)
(target−dir)(notdir $@)
(
Q
)
(Q)
(Q)(MAKE)
(
b
u
i
l
d
)
=
(build)=
(build)=(build-dir)
(
t
a
r
g
e
t
−
d
i
r
)
(target-dir)
(target−dir)(notdir $@)
(
Q
)
(Q)
(Q)(MAKE)
(
b
u
i
l
d
)
=
(build)=
(build)=(build-dir)
(
t
a
r
g
e
t
−
d
i
r
)
(target-dir)
(target−dir)(notdir $@)
(
Q
)
(Q)
(Q)(MAKE)
(
b
u
i
l
d
)
=
(build)=
(build)=(build-dir)
(
t
a
r
g
e
t
−
d
i
r
)
(target-dir)
(target−dir)(notdir $@)
(
Q
)
(Q)
(Q)(MAKE)
(
b
u
i
l
d
)
=
(build)=
(build)=(build-dir)
(
t
a
r
g
e
t
−
d
i
r
)
(target-dir)
(target−dir)(notdir $@)
(
Q
)
(Q)
(Q)(MAKE)
(
b
u
i
l
d
)
=
(build)=
(build)=(build-dir)
(
t
a
r
g
e
t
−
d
i
r
)
(target-dir)
(target−dir)(notdir $@)
(
b
u
i
l
d
)
=
(build)=
(build)=(build-dir)
(
b
u
i
l
d
)
=
(build)=
(build)=(build-dir)
(
b
u
i
l
d
)
=
(build)=
(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
)
(Q)
(Q)(MAKE)
(
b
u
i
l
d
)
=
(build)=
(build)=(boot) MACHINE=$(MACHINE)
(
b
o
o
t
)
/
(boot)/
(boot)/@
305
306 #vmlinux
307 zinstall uinstall install: $(VMLINUX)
308 #zinstall uinstall install: vmlinux
309
(
Q
)
(Q)
(Q)(MAKE)
(
b
u
i
l
d
)
=
(build)=
(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
)
(Q)
(Q)(MAKE)
(
b
u
i
l
d
)
=
(build)=
(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:
(
o
b
j
)
/
z
I
m
a
g
e
F
O
R
C
E
89
@
(obj)/zImage FORCE 89 @
(obj)/zImageFORCE89@(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
)
(Q)
(Q)(MAKE)
(
b
u
i
l
d
)
=
(build)=
(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
(
s
r
c
t
r
e
e
)
/
s
c
r
i
p
t
s
/
K
b
u
i
l
d
.
i
n
c
l
u
d
e
/
/
K
b
u
i
l
d
.
i
n
c
l
u
d
e
的内容是什么呢？
199
i
f
n
e
q
(
(srctree)/scripts/Kbuild.include //Kbuild.include的内容是什么呢？ 199 ifneq (
(srctree)/scripts/Kbuild.include//Kbuild.include的内容是什么呢？199ifneq((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 KaTeX parse error: Expected group after '_' at position 5: (cmd_̲(1)), KaTeX parse error: Expected group after '_' at position 5: (cmd_̲@))
203 $(filter-out KaTeX parse error: Expected group after '_' at position 5: (cmd_̲@), KaTeX parse error: Expected group after '_' at position 5: (cmd_̲(1))) )
204 else
205 arg-check = $(if $(strip KaTeX parse error: Expected group after '_' at position 5: (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 '…KaTeX parse error: Expected 'EOF', got '#' at position 15: t=1;...'] 211 #̲ in $(cmd_xxx) … your perl vars
212 make-cmd =
(
s
u
b
s
t
,
,
(subst \\,\\\\,
(subst,,(subst #,\#,$(subst
,
,
,$
,
,
,(call escsq,KaTeX parse error: Expected group after '_' at position 5: (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
(
P
H
O
N
Y
)
,
(PHONY),
(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) KaTeX parse error: Expected group after '_' at position 5: (cmd_̲(1));
223 echo ‘cmd_$@ := $(make-cmd)’ > $(dot-target).cmd)
终于找到if_changed的原形了
这里的any-prereq作用是找到比较新的依赖文件，且过滤伪目标。之后执行了cmd_$1
对应我们这里的 $(call if_changed,objcopy) 就应该是cmd_objcopy
我们搜一下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) KaTeX parse error: Expected group after '_' at position 14: (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
)
(Q)
(Q)(MAKE)
(
b
u
i
l
d
)
=
(build)=
(build)=(obj)/compressed $@
根据这句话，就知道应该分析一下$(obj)/compressed
24 HEAD = head.o
91 suffix_KaTeX parse error: Expected group after '_' at position 39: …gzip 92 suffix_̲(CONFIG_KERNEL_LZO) = lzo
93 suffix_KaTeX parse error: Expected group after '_' at position 39: …lzma 94 suffix_̲(CONFIG_KERNEL_XZ) = xzkern
95
182 $(obj)/vmlinux: $(obj)/vmlinux.lds
(
o
b
j
)
/
(obj)/
(obj)/(HEAD)
(
o
b
j
)
/
p
i
g
g
y
.
(obj)/piggy.
(obj)/piggy.(suffix_y).o
183 $(addprefix $(obj)/, $(OBJS)) $(lib1funcs)
(
a
s
h
l
d
i
3
)
F
O
R
C
E
184
@
(ashldi3) FORCE 184 @
(ashldi3)FORCE184@(check_for_multiple_zreladdr)
185
(
c
a
l
l
i
f
c
h
a
n
g
e
d
,
l
d
)
186
@
(call if_changed,ld) 186 @
(callifchanged,ld)186@(check_for_bad_syms)
187
188
(
o
b
j
)
/
p
i
g
g
y
.
(obj)/piggy.
(obj)/piggy.(suffix_y): $(obj)/…/Image FORCE
189
(
c
a
l
l
i
f
c
h
a
n
g
e
d
,
(call if_changed,
(callifchanged,(suffix_y))
190
191
(
o
b
j
)
/
p
i
g
g
y
.
(obj)/piggy.
(obj)/piggy.(suffix_y).o:
(
o
b
j
)
/
p
i
g
g
y
.
(obj)/piggy.
(obj)/piggy.(suffix_y) FORCE
这里面的内容告诉我们
要想生成vmlinux，需要准备vmlinux.lds，这里的 $(obj)就是compressed目录本身。
还需要head.o 和 piggy.$(suffix_y).o 。head.o对应compressed下的head.S
这里我们选择的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
(
o
b
j
)
/
p
i
g
g
y
.
(obj)/piggy.
(obj)/piggy.(suffix_y): $(obj)/…/Image FORCE
189
(
c
a
l
l
i
f
c
h
a
n
g
e
d
,
(call if_changed,
(callifchanged,(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
(
f
i
l
t
e
r
−
o
u
t
F
O
R
C
E
,
(filter-out FORCE,
(filter−outFORCE,^) | gzip -n -f -9 > $@) || \
md_gzip = (cat
(
f
i
l
t
e
r
−
o
u
t
F
O
R
C
E
,
(filter-out FORCE,
(filter−outFORCE,^) | 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。
-
压缩效率：LZO <GZIP < BZIP2 < LZMA
-
压缩时间：GZIP <LZO ~= BZIP2 << LZMA
-
解压缩时间：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:
(
o
b
j
)
/
z
I
m
a
g
e
F
O
R
C
E
89
@
(obj)/zImage FORCE 89 @
(obj)/zImageFORCE89@(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
如果要分析内核启动过程的话，当然是先从这个文件入手。
启动过程将在下篇进行分析。
4683
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
