轉自：http://www.embedu.org/Column/Column13.htm

作者： 劉洪濤，華清遠見嵌入式培訓中心 講師。

在華清遠見教學過程中，發現很多學員對核心映象解壓過程比較感興趣，但網上相關的文章往往不能把關鍵問題講清楚，所以寫了這篇文章。本文以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引數：EXTRA_CFLAGS := -fpic總結一下zImage的組成，它是由一個壓縮後的核心piggy.o，連線上一段初始化及解壓功能的程式碼（head.o misc.o）,組成的。下面就要看核心的啟動了，那麼核心是從什麼地方開始執行的呢？這個當然要看lds檔案啦。zImage的生成經歷了兩次大的連結過程：一次是頂層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)SECTIONS{        . = 0;       _text = .;       .text : {       _start = .;       *(.start)       *(.text)                            ……}在arch/arm/boot/compressed/head.S中找到入口點。看看head.S會做些什麼樣的工作：? 對於各種Arm CPU的DEBUG輸出設定，通過定義巨集來統一操作；?設定kernel開始和結束地址，儲存architecture ID；? 如果在ARM2以上的CPU中，用的是普通使用者模式，則升到超級使用者模式，然後關中斷? 分析LC0結構delta offset，判斷是否需要過載核心地址(r0存入偏移量，判斷r0是否為零)。?需要過載核心地址，將r0的偏移量加到BSS region和GOT table中的每一項。對於位置無關的程式碼，程式是通過GOT表訪問全域性資料目標的，也就是說GOT表中中記錄的是全域性資料目標的絕對地址，所以其中的每一項也需要過載。? 清空bss堆疊空間r2－r3?建立C程式執行需要的快取?這時r2是快取的結束地址，r4是kernel的最後執行地址，r5是kernel境象檔案的開始地址?用檔案misc.c的函式decompress_kernel()，解壓核心於快取結束的地方(r2地址之後)。可能大家看了上面的文字描述還是不清楚解壓的動態過程。還是先用圖表的方式描述下程式碼的搬運解壓過程。然後再針對中間的一些關鍵過程闡述。假定zImage在記憶體中的初始地址為0x30008000(這個地址由bootloader決定，位置不固定)1、初始狀態

.text	0x30008000開始，包含piggydata段（即壓縮的核心段）
.got	?
.data	?
.bss	?
.stack	4K大小

2、head.S呼叫misc.c中的decompress_kernel剛解壓完核心後

.text	0x30008000開始，包含piggydata段（即壓縮的核心段）
.got	?
.data	?
.bss	?
.stack	4K大小
解壓函式所需緩衝區	64K大小
解壓後的核心程式碼	小於4M

3、此時會將head.S中的部分程式碼重定位

.text	0x30008000開始，包含piggydata段（即壓縮的核心段）
.got	?
.data	?
.bss	?
.stack	4K大小
解壓函式所需緩衝區	64K大小
解壓後的核心程式碼	小於4M
head.S中的部分重定位程式碼程式碼	reloc_start至reloc_end

4、跳轉到重定位後的reloc_start處，由reloc_start至reloc_end的程式碼複製解壓後的核心程式碼到0x30008000處，並呼叫call_kernel跳轉到0x30008000處執行。

解壓後的核心

0x30008000開始

在通過head.S瞭解了動態過程後，大家可能會有幾個問題：問題1：zImage是如何知道自己最後的執行地址是0x30008000的？問題2：呼叫decompress_kernel函式時，其4個引數是什麼值及物理含義？問題3：解壓函式是如何確定程式碼中壓縮核心位置的？先回答第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,int arch_id)l output_start：指解壓後核心輸出的起始位置，此時它的值參考上面的圖表，緊接在解壓緩衝區後；l free_mem_ptr_p：解壓函式需要的記憶體緩衝開始地址；l ulg free_mem_ptr_end_p：解壓函式需要的記憶體緩衝結束地址，共64K；l arch_id ：architecture ID，對於SMDK2410這個值為193；最後回答第3個問題首先看看piggy.o是如何生成的，在arch/arm/boot/compressed/Makefie中$(obj)/piggy.o: $(obj)/piggy.gz FORCEPiggy.o是由piggy.S生成的，咱們看看piggy.S的內容：             .section .piggydata,#alloc             .globl input_datainput_data:             .incbin "arch/arm/boot/compressed/piggy.gz"             .globl input_data_endinput_data_end:再看看misc.c中decompress_kernel函式吧，它將呼叫gunzip()解壓核心。gunzip()在lib/inflate.c中定義，它將呼叫NEXTBYTE()，進而呼叫get_byte()來獲取壓縮核心程式碼。在misc.c中#define get_byte() (inptr < insize ? inbuf[inptr++] : fill_inbuf())檢視fill_inbuf函式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];}發現什麼沒？這裡的input_data不正是piggy.S裡的input_data嗎？這個時候應該明白核心是怎樣確定piggy.gz在zImage中的位置了吧。時間關係，可能敘述的不夠詳細，大家可以集合核心程式碼和網上的其它相關文章，理解啟動解壓過程。