Linux学习之zImage内核镜像解压过程详解
? zImage內(nèi)核鏡像解壓過程詳解 收藏
zImage內(nèi)核鏡像解壓過程詳解
作者： 劉洪濤，華清遠(yuǎn)見嵌入式培訓(xùn)中心 講師。
本文以linux-2.6.14內(nèi)核在S3C2410平臺(tái)上運(yùn)行為例，講解內(nèi)核的解壓過程。
內(nèi)核編譯完成后會(huì)生成zImage內(nèi)核鏡像文件。關(guān)于bootloader加載zImage到內(nèi)核，并且 跳轉(zhuǎn)到zImage開始地址運(yùn)行zImage的過程，相信大家都很容易理解。但對(duì)于zImage是如何解壓的過程，就不是那么好理解了。本文將結(jié)合部分關(guān) 鍵代碼，講解zImage的解壓過程。
先看看zImage的組成吧。在內(nèi)核編譯完成后會(huì)在arch/arm/boot/下生成zImage。
在arch/armboot/Makefile中：
$(obj)/zImage: $(obj)/compressed/vmlinux FORCE
????????????????????$(call if_changed,objcopy)
由此可見，zImage的是elf格式的arch/arm/boot/compressed/vmlinux二進(jìn)制化得到的
在arch/armboot/compressed/Makefile中：
$(obj)/vmlinux: $(obj)/vmlinux.lds $(obj)/$(HEAD) $(obj)/piggy.o /
????????????????????????????????????????????????????????????$(addprefix $(obj)/, $(OBJS)) FORCE
????????????????????$(call if_changed,ld)
$(obj)/piggy.gz: $(obj)/../Image FORCE
????????????????????$(call if_changed,gzip)
$(obj)/piggy.o: $(obj)/piggy.gz FORCE
其中Image是由內(nèi)核頂層目錄下的vmlinux二進(jìn)制化后得到的。注意：arch/arm/boot/compressed/vmlinux是位置無關(guān)的，這個(gè)有助于理解后面的代碼。，鏈接選項(xiàng)中有個(gè) –fpic參數(shù)：
EXTRA_CFLAGS := -fpic
總結(jié)一下zImage的組成，它是由一個(gè)壓縮后的內(nèi)核piggy.o，連接上一段初始化及解壓功能的代碼（head.o misc.o）,組成的。
下面就要看內(nèi)核的啟動(dòng)了，那么內(nèi)核是從什么地方開始運(yùn)行的呢？這個(gè)當(dāng)然要看lds文件啦。zImage的 生成經(jīng)歷了兩次大的鏈接過程：一次是頂層vmlinux的生成，由arch/arm/boot/vmlinux.lds（這個(gè)lds文件是由arch /arm/kernel/vmlinux.lds.S生成的）決定；另一次是arch/arm/boot/compressed/vmlinux的生成， 是由arch/arm/boot/compressed/vmlinux.lds（這個(gè)lds文件是由arch/arm/boot/compressed /vmlinux.lds.in生成的）決定。zImage的入口點(diǎn)應(yīng)該由arch/arm/boot/compressed/vmlinux.lds決 定。從中可以看出入口點(diǎn)為‘_start’
OUTPUT_ARCH(arm)
ENTRY(_start)
SECTIONS
{
????????. = 0;
???????_text = .;
???????.text : {
???????_start = .;
???????*(.start)
???????*(.text)
????????????????????????????……
}
在arch/arm/boot/compressed/head.S中找到入口點(diǎn)。
看看head.S會(huì)做些什么樣的工作：
? 對(duì)于各種Arm CPU的DEBUG輸出設(shè)定，通過定義宏來統(tǒng)一操作；
?設(shè)置kernel開始和結(jié)束地址，保存architecture ID；
? 如果在ARM2以上的CPU中，用的是普通用戶模式，則升到超級(jí)用戶模式，然后關(guān)中斷
? 分析LC0結(jié)構(gòu)delta offset，判斷是否需要重載內(nèi)核地址(r0存入偏移量，判斷r0是否為零)。
?需要重載內(nèi)核地址，將r0的偏移量加到BSS region和GOT table中的每一項(xiàng)。
對(duì)于位置無關(guān)的代碼，程序是通過GOT表訪問全局?jǐn)?shù)據(jù)目標(biāo)的，也就是說GOT表中中記錄的是全局?jǐn)?shù)據(jù)目標(biāo)的絕對(duì)地址，所以其中的每一項(xiàng)也需要重載。
? 清空bss堆棧空間r2－r3
?建立C程序運(yùn)行需要的緩存
?這時(shí)r2是緩存的結(jié)束地址，r4是kernel的最后執(zhí)行地址，r5是kernel境象文件的開始地址
?用文件misc.c的函數(shù)decompress_kernel()，解壓內(nèi)核于緩存結(jié)束的地方(r2地址之后)。
可能大家看了上面的文字描述還是不清楚解壓的動(dòng)態(tài)過程。還是先用圖表的方式描述下代碼的搬運(yùn)解壓過程。然后再針對(duì)中間的一些關(guān)鍵過程闡述。
假定zImage在內(nèi)存中的初始地址為0x30008000(這個(gè)地址由bootloader決定，位置不固定)
1、初始狀態(tài)
| .text | 0x30008000 開始，包含piggydata 段（即壓縮的內(nèi)核段） |
| . got | ? |
| . data | ? |
| .bss | ? |
| .stack | 4K 大小 |
2、head.S調(diào)用misc.c中的decompress_kernel剛解壓完內(nèi)核后
| .text | 0x30008000 開始，包含piggydata 段（即壓縮的內(nèi)核段） |
| . got | ? |
| . data | ? |
| .bss | ? |
| .stack | 4K 大小 |
| 解壓函數(shù)所需緩沖區(qū) | 64K 大小 |
| 解壓后的內(nèi)核代碼 | 小于4M |
3、此時(shí)會(huì)將head.S中的部分代碼重定位
| .text | 0x30008000 開始，包含piggydata 段（即壓縮的內(nèi)核段） |
| . got | ? |
| . data | ? |
| .bss | ? |
| .stack | 4K 大小 |
| 解壓函數(shù)所需緩沖區(qū) | 64K 大小 |
| 解壓后的內(nèi)核代碼 | 小于4M |
| head.S 中的部分重定位代碼代碼 | reloc_start 至reloc_end |
4、跳轉(zhuǎn)到重定位后的reloc_start處，由reloc_start至reloc_end的代碼復(fù)制解壓后的內(nèi)核代碼到0x30008000處，并調(diào)用call_kernel跳轉(zhuǎn)到0x30008000處執(zhí)行。
| 解壓后的內(nèi)核 | 0x30008000 開始 |
在通過head.S了解了動(dòng)態(tài)過程后，大家可能會(huì)有幾個(gè)問題：
問題1：zImage是如何知道自己最后的運(yùn)行地址是0x30008000的？
問題2：調(diào)用decompress_kernel函數(shù)時(shí)，其4個(gè)參數(shù)是什么值及物理含義？
問題3：解壓函數(shù)是如何確定代碼中壓縮內(nèi)核位置的？
先回答第1個(gè)問題
這個(gè)地址的確定和Makefile和鏈接腳本有關(guān)，在arch/arm/Makefile文件中的
textaddr-y := 0xC0008000 這個(gè)是內(nèi)核啟動(dòng)的虛擬地址
TEXTADDR := $(textaddr-y)
在arch/arm/mach-s3c2410/Makefile.boot中
zreladdr-y := 0x30008000 這個(gè)就是zImage的運(yùn)行地址了
在arch/arm/boot/Makefile文件中
ZRELADDR := $(zreladdr-y)
在arch/arm/boot/compressed/Makefile文件中
zreladdr=$(ZRELADDR)
在arch/arm/boot/compressed/Makefile中有
???????????????????????????.word zreladdr @ r4
內(nèi)核就是用這種方式讓代碼知道最終運(yùn)行的位置的
接下來再回答第2個(gè)問題
decompress_kernel(ulg output_start, ulg free_mem_ptr_p, ulg free_mem_ptr_end_p,
int arch_id)
l output_start：指解壓后內(nèi)核輸出的起始位置，此時(shí)它的值參考上面的圖表，緊接在解壓緩沖區(qū)后；
l free_mem_ptr_p：解壓函數(shù)需要的內(nèi)存緩沖開始地址；
l ulg free_mem_ptr_end_p：解壓函數(shù)需要的內(nèi)存緩沖結(jié)束地址，共64K；
l arch_id ：architecture ID，對(duì)于SMDK2410這個(gè)值為193；
最后回答第3個(gè)問題
首先看看piggy.o是如何生成的，在arch/arm/boot/compressed/Makefie中
$(obj)/piggy.o: $(obj)/piggy.gz FORCE
Piggy.o是由piggy.S生成的，咱們看看piggy.S的內(nèi)容：
?????????????.section .piggydata,#alloc
?????????????.globl input_data
input_data:
?????????????.incbin "arch/arm/boot/compressed/piggy.gz"
?????????????.globl input_data_end
input_data_end:
再看看misc.c中decompress_kernel函數(shù)吧，它將調(diào)用gunzip()解壓內(nèi)核。gunzip()在lib/inflate.c中定義，它將調(diào)用NEXTBYTE()，進(jìn)而調(diào)用get_byte()來獲取壓縮內(nèi)核代碼。
在misc.c中
#define get_byte() (inptr < insize ? inbuf[inptr++] : fill_inbuf())
查看fill_inbuf函數(shù)
int fill_inbuf(void)
{
?????????????if (insize != 0)
?????????????error("ran out of input data");
?????????????inbuf = input_data;
?????????????insize = &input_data_end[0] - &input_data[0];
?????????????inptr = 1;
?????????????return inbuf[0];
}
發(fā)現(xiàn)什么沒？這里的input_data不正是piggy.S里的input_data嗎？這個(gè)時(shí)候應(yīng)該明白內(nèi)核是怎樣確定piggy.gz在zImage中的位置了吧。
時(shí)間關(guān)系，可能敘述的不夠詳細(xì)，大家可以集合內(nèi)核代碼和網(wǎng)上的其它相關(guān)文章，理解啟動(dòng)解壓過程。
總結(jié)
以上是生活随笔為你收集整理的Linux学习之zImage内核镜像解压过程详解的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 更新目录没有只更新页码选项怎么办(wor
- 下一篇： Linux-Android系统启动之IN