Linux學習之zImage核心鏡像解壓過程詳解

 
zImage核心鏡像解壓過程詳解
收藏

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

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 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中的位置了吧。

時間關係，可能敘述的不夠詳細，大家可以集合核心代碼和網上的其它相關文章，理解啟動解壓過程。