zImage內核鏡像解壓過程詳解

       在華清遠見教學過程當中，發現不少學員對內核鏡像解壓過程比較感興趣，但網上相關的文章每每不能把關鍵問題講清楚，因此寫了這篇文章。

       本文以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決定，位置不固定)

       一、初始狀態

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

         二、head.S調用misc.c中的decompress_kernel剛解壓完內核後

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

        三、此時會將head.S中的部分代碼重定位

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

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

        四、跳轉到重定位後的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 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函數吧，它將調用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中的位置了吧。

       時間關係，可能敘述的不夠詳細，你們能夠集合內核代碼和網上的其它相關文章，理解啓動解壓過程。