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
在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 開始
問題2：呼叫decompress_kernel函式時，其4個引數是什麼值及物理含義？
問題3：解壓函式是如何確定**中壓縮核心位置的？
先回答第1個問題
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 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)
發現什麼沒？這裡的input_data不正是piggy.s裡的input_data嗎？這個時候應該明白核心是怎樣確定piggy.gz在zimage中的位置了吧。
機器學習之核函式
建議看這個，中文的 這裡面會講解kernel 的基本概念,svm,lda,lr，pca等如何使用kernel版本 本文大致講解核函式的定義，限制，使用等 機器學習中，對於線性可分的情況研究的比較透徹，可以採用svm lr 感知機等成熟的機器學習模型，但是很多情況是我們希望我們的模型學習非線性的模型。...
以Qemu模擬Linux，學習Linux核心
維護日誌 2013 02 21 建立文件 注 文章參考自 是對該篇文章的一些補充和說明。文章內所使用的環境是ubuntu 12.04，如果其中遇到編譯問題，請自行參考錯誤說明，配置依賴環境 0.準備 我們所有的工作都在指定目錄下工作，使用以下變數來代替相關目錄。kernel 核心工作目錄 linux...
Linux核心zImage怎麼來的？
以下內容基於s5pv210硬體進行分析 當我們配置好核心後執行make，在arch arm makefile中有 首先要生成依賴vmlinux，這個過程請參考我的隨筆 linux核心編譯make做了什麼？得到vmlinux後make會執行 q make build boot machine mach...