本文以linux-2.6.14內核在S3C2410平臺上運行為例，講解內核的解壓過程。
內核編譯完成后會生成zImage內核鏡像文件。關于bootloader加載zImage到內核，并且跳轉到zImage開始地址運行zImage的過程，相信大家都很容易理解。但對于zImage是如何解壓的過程，就不是那么好理解了。本文將結合部分關鍵代碼，講解zImage的解壓過程。
先看看zImage的組成吧。在內核編譯完成后會在arch/ARM/boot/下生成zImage。
在arch/armboot/Makefile中：
$(obj)/zImage: $(obj)/compressed/vmlinux FORCE
$(call if_changed,objcopy)
由此可見，zImage的是elf格式的arch/arm/boot/compressed/vmlinux二進制化得到的
在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是由內核頂層目錄下的vmlinux二進制化后得到的。注意：arch/arm/boot/compressed/vmlinux是位置無關的，這個有助于理解后面的代碼。，鏈接選項中有個 –fpic參數(shù)：
EXTRA_CFLAGS := -fpic
總結一下zImage的組成，它是由一個壓縮后的內核piggy.o，連接上一段初始化及解壓功能的代碼(head.o misc.o),組成的。
下面就要看內核的啟動了，那么內核是從什么地方開始運行的呢?這個當然要看lds文件啦。zImage的生成經(jīng)歷了兩次大的鏈接過程：一次是頂層vmlinux的生成，由arch/arm/boot/vmlinux.lds(這個lds文件是由arch/arm/kernel/vmlinux.lds.S生成的)決定;另一次是arch/arm/boot/compressed/vmlinux的生成，是由arch/arm/boot/compressed/vmlinux.lds(這個lds文件是由arch/arm/boot/compressed/vmlinux.lds.in生成的)決定。zImage的入口點應該由arch/arm/boot/compressed/vmlinux.lds決定。從中可以看出入口點為‘_STart’
OUTPUT_ARCH(arm)
ENTRY(_start)
SECTI*
{
. = 0;
_text = .;
.text : {
_start = .;
*(.start)
*(.text)
……
}
在arch/arm/boot/compressed/head.S中找到入口點。
看看head.S會做些什么樣的工作：
• 對于各種Arm CPU的DEBUG輸出設定，通過定義宏來統(tǒng)一操作;
•設置kernel開始和結束地址，保存architecture ID;
• 如果在ARM2以上的CPU中，用的是普通用戶模式，則升到超級用戶模式，然后關中斷
• 分析LC0結構delta offset，判斷是否需要重載內核地址(r0存入偏移量，判斷r0是否為零)。
•需要重載內核地址，將r0的偏移量加到BSS regiON和GOT table中的每一項。
對于位置無關的代碼，程序是通過GOT表訪問全局數(shù)據(jù)目標的，也就是說GOT表中中記錄的是全局數(shù)據(jù)目標的絕對地址，所以其中的每一項也需要重載。
• 清空bss堆?？臻gr2-r3
•建立C程序運行需要的緩存
•這時r2是緩存的結束地址，r4是kernel的最后執(zhí)行地址，r5是kernel境象文件的開始地址
•用文件misc.c的函數(shù)decompress_kernel()，解壓內核于緩存結束的地方(r2地址之后)。
可能大家看了上面的文字描述還是不清楚解壓的動態(tài)過程。還是先用圖表的方式描述下代碼的搬運解壓過程。然后再針對中間的一些關鍵過程闡述。
假定zImage在內存中的初始地址為0x30008000(這個地址由bootloader決定，位置不固定)
1、初始狀態(tài)
2、head.S調用misc.c中的decompress_kernel剛解壓完內核后
3、此時會將head.S中的部分代碼重定位
4、跳轉到重定位后的reloc_start處，由reloc_start至reloc_end的代碼復制解壓后的內核代碼到0x30008000處，并調用call_kernel跳轉到0x30008000處執(zhí)行。
在通過head.S了解了動態(tài)過程后，大家可能會有幾個問題：
問題1：zImage是如何知道自己最后的運行地址是0x30008000的?
問題2：調用decompress_kernel函數(shù)時，其4個參數(shù)是什么值及物理含義?
問題3：解壓函數(shù)是如何確定代碼中壓縮內核位置的?
先回答第1個問題
這個地址的確定和Makefile和鏈接腳本有關，在arch/arm/Makefile文件中的
textaddr-y := 0xC0008000 這個是內核啟動的虛擬地址
TEXTADDR := $(textaddr-y)
在arch/arm/mach-s3c2410/Makefile.boot中
zreladdr-y := 0x30008000 這個就是zImage的運行地址了
在arch/arm/boot/Makefile文件中
ZRELADDR := $(zreladdr-y)
在arch/arm/boot/compressed/Makefile文件中
zreladdr=$(ZRELADDR)
在arch/arm/boot/compressed/Makefile中有
.word zreladdr @ r4
內核就是用這種方式讓代碼知道最終運行的位置的
接下來再回答第2個問題
decompress_kernel(ulg output_start, ulg free_mem_ptr_p, ulg free_mem_ptr_end_p,[!--empirenews.page--]
int arch_id)
l output_start：指解壓后內核輸出的起始位置，此時它的值參考上面的圖表，緊接在解壓緩沖區(qū)后;
l free_mem_ptr_p：解壓函數(shù)需要的內存緩沖開始地址;
l ulg free_mem_ptr_end_p：解壓函數(shù)需要的內存緩沖結束地址，共64K;
l arch_id ：architecture ID，對于SMDK2410這個值為193;
最后回答第3個問題
首先看看piggy.o是如何生成的，在arch/arm/boot/compressed/Makefie中
$(obj)/piggy.o: $(obj)/piggy.gz FORCE
Piggy.o是由piggy.S生成的，咱們看看piggy.S的內容：
.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ù)吧，它將調用gunzip()解壓內核。gunzip()在lib/inflate.c中定義，它將調用NEXTBYTE()，進而調用get_byte()來獲取壓縮內核代碼。
在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嗎?這個時候應該明白內核是怎樣確定piggy.gz在zImage中的位置了吧。
時間關系，可能敘述的不夠詳細，大家可以集合內核代碼和網(wǎng)上的其它相關文章，理解啟動解壓過程。
下載文檔
