ARM linux解析之壓縮內核zImage的啟動(dòng)過(guò)程

下面以arch/arm/boot/compressed/head.s為主線(xiàn)進(jìn)行啟動(dòng)過(guò)程解析。

1.head.s的debug宏定義部分

最開(kāi)始的一段都是head.s的debug宏定義部分，這部分可以方便我們調試時(shí)使用。

如下：

如果開(kāi)啟DEBUGging宏的話(huà)，這部分代碼分兩段CONFIG_DEBUG_ICEDCC是用ARMv6以上的加構支持的ICEDCC技術(shù)進(jìn)行調試，DCC（Debug Communications Channel）是ARM的一個(gè)調試通信通道，在串口無(wú)法使用的時(shí)候可以使用這個(gè)通道進(jìn)行數據的通信，具體的技術(shù)參前ARM公司文檔《ARM Architecture Reference Manual》。

第二部分首先#include ，這個(gè)文件定義位于arch/arm/mach-xxxx/include/mach/debug-macro.S里面，所以這個(gè)是和平臺相關(guān)的，里面定義了每個(gè)平臺的相關(guān)的串口操作，因這個(gè)時(shí)候系統還沒(méi)有起來(lái)，所以它所用的串口配置參數是依賴(lài)于前一級bootloader所設置好的，如我們使用的u-boot設置好所有的參數。如我們的EVB板ARM的實(shí)現如下：

主要實(shí)現addruart，senduart，waituart，busyuart這四個(gè)函數的具體實(shí)施。這個(gè)是調試函數打印的基礎。

下面是調試打印用到的kputc和kphex

它所調用的putc和phex是在head.s最后的一段定義的，如下

上面是分配打印hex的buffer，下面是具體的實(shí)現：

嘿嘿，還有memdump這個(gè)函數可以用，不錯。

好了，言歸正傳，再往下看，代碼如下：

debug_reloc_start

用來(lái)打印出一些代碼重定位后的信息，關(guān)于重定位，后面會(huì )說(shuō)，debug_reloc_end

用來(lái)把解壓后的內核的256字節的數據dump出來(lái)，查看是否正確。很不幸的是，這個(gè)不是必須調用的，調試的時(shí)候，這些都是要自己把這些調試函數加上去的。好debug部分到這里就完了。

2.head.s的.start部分，進(jìn)入或保持在svc模式，并關(guān)中斷

繼續向下分析，下面是定義.start段，這段在鏈接時(shí)被鏈接到代碼的最開(kāi)頭，那么zImage啟動(dòng)時(shí)，最先執行的代碼也就是下面這段代碼start開(kāi)始的，如下：

為何這個(gè)會(huì )先執行呢？問(wèn)的好。那么來(lái)個(gè)中斷吧：這個(gè)是由arch/arm/boot/compressed/vmlinux.lds的鏈接腳本決定的，如下：

怎么樣，看到?jīng)]，.text段最開(kāi)始的一部分就是.start段，所以這就注定了它就是最先執行的代碼。

好了，中斷結束，再回到先前面的代碼，這段代碼的最開(kāi)始是會(huì )被編譯器編譯成8個(gè)nop，這個(gè)是為了留給ARM的中斷向量表的，但是整個(gè)head.s都沒(méi)有用到中斷啊，誰(shuí)知道告訴我一下，謝了。

然后呢，把u-boot傳過(guò)來(lái)的放在r1,r2的值，存在r7,r8中，r1存是的evb板的ID號，而r2存的是內核要用的參數地址，這兩個(gè)參數在解壓內核的時(shí)候不要用到，所以暫時(shí)保存一下，解壓內枋完了，再傳給linux內核。

再然后是幾個(gè)宏定義的解釋?zhuān)珹RM()，BSYM()，THUMB()，再加上W()吧，這幾個(gè)個(gè)宏定義都是在arch/arm/include/asm/unified.h里面定義的，好了，這里也算個(gè)中斷吧，如下：

好的看到上面的定義你就會(huì )明白了，這里是為了兼容THUMB2指令的內核。

關(guān)于#defineARM(x...)里面的“...”，沒(méi)有見(jiàn)過(guò)吧，這個(gè)是C語(yǔ)言的C99的新標準，變參宏，就是在x里，你可以隨便你輸入多少個(gè)參數。別急還沒(méi)有完，因為沒(méi)有看見(jiàn)文件里有什么方包含這個(gè)頭文件。是的文件中確實(shí)沒(méi)有包含，它的定義是在：arch/arm/makefile中加上的：

KBUILD_AFLAGS+= -include asm/unified.h

行，這些宏解釋到此，下面再出現，我就無(wú)視它了。

好了，再回來(lái)，讀取cpsr并判斷是否處理器處于supervisor模式——從u-boot進(jìn)入kernel，系統已經(jīng)處于SVC32模式；而利用angel進(jìn)入則處于user模式，還需要額外兩條指令。之后是再次確認中斷關(guān)閉，并完成cpsr寫(xiě)入。

注：Angel是ARM公司的一種調試方法，它本身就是一個(gè)調試監控程序，是一組運行在目標機上的程序，可以接收主機上調試器發(fā)送的命令，執行諸如設置斷點(diǎn)、單步執行目標程序、觀(guān)察或修改寄存器、存儲器內容之類(lèi)的操作。與基于jtag的調試代理不同，Angel調試監控程序需要占用一定的系統資源，如內存、串行端口等。使用angel調試監控程序可以調試在目標系統運行的arm程序或thumb程序。

好了，里面有一句：teqppc, #0x0c003@ turn off interrupts

是否很奇怪，不過(guò)大家千萬(wàn)不要糾結它，因為它是ARMv2架構以前的匯編方法，用于模式變換，和中斷關(guān)閉的，看不明白也沒(méi)關(guān)系，因為我們以后也用不到。這里知道一下有這個(gè)事就行了。

行，到這里.start段就完了，代碼那么多，其實(shí)就是做一件事，保證運行下面的代碼時(shí)已經(jīng)進(jìn)入了SVC模式，并保證中斷是關(guān)的，完了.start部分結束。

3.。text段開(kāi)始，先是內核解壓地址的確定

再往下看，代碼如下：

額~~~~不要小這一段代碼，東西好多啊。如哪入手呢？好吧，先從linux基本參數入手吧，見(jiàn)表.1，里面我寫(xiě)的很詳細，因為表格我要放一頁(yè)，解釋我就寫(xiě)在上面了。TEXT_OFFSET是代碼相對于物理內存的偏移，通常選為32k=0x8。這個(gè)是有原因的，具體的原因后面會(huì )說(shuō)。先看CONFIG_AUTO_ZRELADDR這個(gè)宏所含的內容，它的意思是如果你不知道ZRELADDR地址要定在內存什么地方，那么這段代碼就可以幫你?？吹?xf8了吧，那么后面有多少個(gè)0呢？答案是27個(gè)，那么2的27次方就是128M，這就明白了，只要你把解壓程序放在你最后解壓完成后的內核空間的128M之內的偏移的話(huà)，就可以自動(dòng)設定好解壓后內核要運行的地址ZRELADDR。

如果你沒(méi)有定義的話(huà)，那么，就會(huì )去取zreladdr作為最后解壓的內核運行地。那么這個(gè)zreladdr是從哪里來(lái)的呢？答案是在：arch/arm/boot/compressed/Makefile中定義的

ZRELADDR這又是哪里定義的呢？答案是在：arch/arm/boot/Makefile中定義的

而里面的幾個(gè)參數是在每個(gè)arch/arm/Mach-xxx/ Makefile.boot里面定義的，內容如下：

這下知道了，繞了一大圈，終于知道r4存的是什么了，就是最后內核解壓的起址，也是最后解壓后的內核的運行地址，記住，這個(gè)地址很重要。

表.1內核參數解釋

4.打開(kāi)ARM系統的cache，為加快內核解壓做好準備

可以看到，打開(kāi)cache的就一個(gè)函數，如下：

看起來(lái)很少，其實(shí)展開(kāi)后內容還是很多的。我們來(lái)看看這個(gè)cache_on在哪里，可以找到代碼如下：

這里設計的很精妙的，只可意會(huì )，注意movr3, #8，不多解釋?zhuān)M(jìn)去call_cache_fn：

首先看一下proc_types是什么，定義如下：

可以看到這是一個(gè)以proc_types為起始地址的表，上面我列出了第一個(gè)表項，和最后一個(gè)表項，如果查表不成功，則走最后一個(gè)表項返回。它實(shí)現的功能就是存兩個(gè)數據，三條跳轉指令，我們可以第一條是它的值，第二條是它的mask值，三條跳轉分別是：cache_on,cache_off,cache_flush。

我想從ARMv4指令向下都是有CP15協(xié)處理器的吧，故：CONFIG_CPU_CP15是定義的，那下面我們來(lái)分析指令吧。

這個(gè)意思是取得ARM處理器的ID，這個(gè)又要看《ARM Architecture Reference Manual》了，這里我找了arm1176jzfs的架構手冊，也是我用的ARM所用的架構。里面的解釋如下：

這里我們主要關(guān)心Architecture這項，我們的ARM這個(gè)值是: 0x410FB767，說(shuō)明用的是r0p7的release。

好了讀取了這個(gè)值存入r9寄存器，然后使用算法(real ^ match) & mask，程序中：

( r9 ^r1)&r2，這里r1存是是表中的第一個(gè)CPU的ID值，r2是mask值，對于我們的ARM，結果如下：

0x410FB767 ^ 0xf0 = 0x4100B767

0x4100B767 & 0xf0 = 0

故match上了，這個(gè)時(shí)候就會(huì )如下：

我們知道r3的值是0x8，那么r12表項的基址加上0x8就正好是表中的第一條跳轉指令：

明白了，為何r3要等于0x8了吧，如果要調用cache_off，那么只要把r3設為0xC就可以了。精妙吧。行接著(zhù)往下看__armv7_mmu_cache_on，如下：

首先是保存lr寄存器到r12中，因為我們馬上就要調用__setup_mmu了，最后返回也只要用r12就可以了。然后再查看cp15的c7,c10,4看是否支持VMSA，具體的見(jiàn)注解。我們在這里我們的ARM肯定是支持的，所以就要建立頁(yè)表，準備打開(kāi)MMU，從而可以使能cache。

好了下面，就是跳到__setup_mmu進(jìn)行建產(chǎn)頁(yè)表的過(guò)程，代碼如下：

關(guān)于MMU的知識又有好多啊，同樣可以參看《ARM Architecture Reference Manual》，還可以看《ARM體系架構與編程》關(guān)于MMU的部分，我這里只簡(jiǎn)單介紹一下我們這里用到MMU。這里只使用到了MMU的段映，故我只介紹與此相關(guān)的部分。

對于段頁(yè)的大小ARM中為1M大小，對于32位的ARM，可尋址空間為4G=4096M，故每一個(gè)頁(yè)表項表示1M空間的話(huà)，需要4096個(gè)頁(yè)表項，也就是4K大小，而每一個(gè)頁(yè)表項的大小是4字節，這就是說(shuō)我們進(jìn)行段映射的話(huà)，需要16K的大小存儲段頁(yè)表。

下面來(lái)看一下段頁(yè)表的格式，如下：

圖.1段頁(yè)表項的具體內容

可以知道對于進(jìn)行mmu段映射這種方式，一共有4K個(gè)這樣的頁(yè)表項，點(diǎn)大小16K字節。在這里我們的16k頁(yè)表放哪呢？看程序第一句：

我們知道r4存內核解壓后的基址，那么這句就是把頁(yè)表放在解壓后的內核地址的前面16K空間如下圖所示：

圖.2 linux內核地址空間

（里面地址是用的是以我用的ARM為例的）

好了，再回到MMU，從MMU_PAGE_BASE (0x24)建立好頁(yè)表后，ARM的cpu如何知道呢？這個(gè)就是要用到CP15的C2寄存器了，頁(yè)表基址就是存在這里面的，其中[31:14]為內存中頁(yè)表的基址，[13:0]應為0如下圖：

圖.3 CP15的C2寄存器中的頁(yè)表項基址格式

所以我們初始化完段頁(yè)表后，就要把頁(yè)表基址MMU_PAGE_BASE (0x24)存入CP15的C2寄存器，這樣ARM就知道到哪里去找那些頁(yè)表項了。下面我們來(lái)看一下整個(gè)MMU的虛擬地址的尋址過(guò)程，如圖4所示。

簡(jiǎn)單解釋一下。首先，ARM的CPU從CP15的C2寄存器中找取出頁(yè)表基地址，然后把虛擬地址的最高12位左移兩位變?yōu)?4位放到頁(yè)表基址的低14位，組合成對應1M空間的頁(yè)表項在MMU頁(yè)表中的地址。然后，再取出頁(yè)表項的值，檢查AP位，域，判斷是否有讀寫(xiě)的權限，如果沒(méi)有權限測會(huì )拋出數據或指令異常，如果有權限，就把最高12位取出加上虛擬地址的低20位段內偏移地址組合成最終的物理地址。到這里整個(gè)MMU從虛擬地址到物理地址的轉換過(guò)程就完成了。

這段代碼里，只會(huì )開(kāi)啟頁(yè)表所在代碼的開(kāi)始的256K對齊的一個(gè)0x10（256M）空間的大?。ㄟ@個(gè)空間必然包含解壓后的內核），使能cache和write buffer，其他的4G-256M的空間不開(kāi)啟。這里使用的是1：1的映射。到這里也很容易明白MMU和cache和write buffer的關(guān)系了，為什么不開(kāi)MMU無(wú)法使用cache了。

圖.4 MMU的段頁(yè)表的虛擬地址與物理地址的轉換過(guò)程

這里的4G空間全部映射完成之后，還會(huì )做一個(gè)映射，代碼如下：

通過(guò)注釋就可以知道把當前PC所在地址１M對齊的地方的2M空間開(kāi)啟cache和write buffer為了加快代碼在nor flash中運行的速度。然后反回，到這里16K的MMU頁(yè)表就完全建立好了。

然后再反回到建立頁(yè)表后的代碼，如下：

這段代碼就不具體解釋了，多數是關(guān)于CP15的控制寄存器的操作，主要是flush I-cache,D-cache, TLBS，write buffer，然后存頁(yè)表基址啊，最后打開(kāi)MMU這個(gè)是最后一步，前面所有東西都設好之后再使用MMU，否則系統就會(huì )掛掉。最后用保存在r12中的地址，反回到BL cache_on的下一句代碼。如下：

好了，先來(lái)看一下LC0是什么東西吧。

好吧，要理解它，再把arch/arm/boot/vmlinux.lds.in搬出來(lái)吧：

再加上最后一段代碼，關(guān)于stack的空間的大小分配：

這里不僅可以看到各個(gè)寄存器里所存的值的意思，還可以看到. = BSS_START;在這里的作用

arch/arm/boot/compressed/Makefile里面：

對應到這里的話(huà)，就是BSS_START =ALIGN(8)，這個(gè)替換過(guò)程會(huì )在vmlinux.lds.in到vmlinux.lds的過(guò)程中完成，這個(gè)過(guò)程主要是為了有些內核在nor flash中運行而設置的。

好了，再次言歸正傳，從vmlinux.lds文件，可以看到鏈接后各個(gè)段的位置，如下。

圖.5 zImage各個(gè)段的位置

從這里可以看到，zImage在RAM中運行和在NorFlash中直接運行是有些區別的，這就是為何前面要區分ZTEXTADDR和ZBSSADDR的原因了。

好了，再看下面這兩句的區別，如果這個(gè)地方弄明白了，那么，下面的內容就會(huì )變得很簡(jiǎn)單，往下看：

故可知，當zImage加到0x28運行時(shí)，PC值為：0x28070，這個(gè)時(shí)候r0=0x2817C

而通過(guò)ldmiar0, {r1, r2, r3, r6, r10, r11, r12}加載內存值后，r1=0x17C

那么我們看一看這句：sub r0, r0, r1@ calculate the delta offset的值是多少？如下：

see~~~看出來(lái)什么沒(méi)有，這個(gè)就是我們的加載zImage運行的內存起始地址，這個(gè)很重要，后面就要靠它知道我們當前的代碼在哪里，搬移到哪里。然后再下一條指令把堆棧指針設置好。然后再把實(shí)際代碼偏移量加在r6=_edata和(r10=input_data_end-4)上面，這就是實(shí)際的內存中的地址。好繼續往下看：

壓縮的工具會(huì )把所壓縮后的文件的最后加上用小端格式表示的4個(gè)字節的尾，用來(lái)存儲所壓內容的原始大小，這個(gè)信息很要，是我們后面分配空間，代碼重定位的重要依據。這里為何要一個(gè)字節，一個(gè)字節地取，只因為要兼容ARM代碼使用大端編譯的情況，保證讀取的正確無(wú)誤。好了，再往下：

我們這里在RAM中運行，所以加上重定位SP的指針，加上偏移里，變成實(shí)際所在內存的堆棧指針地址。這里主要是為了后面的檢查代碼是否要進(jìn)行重定位的時(shí)候所提前設置的，因為如果代碼不重定位，就不會(huì )再設堆棧指針了，重定位的話(huà)，則還要重設一次。然后再在堆棧指針的上面開(kāi)辟一塊64K大小的空間，用于解壓內核時(shí)的臨時(shí)buffer。

再往下看：

這段的檢測有點(diǎn)繞人，兩種情況都畫(huà)個(gè)圖看一下，如圖.6所示，下面我們來(lái)看分析兩種不會(huì )覆蓋的情況：

第一種情況是加載運行的zImage在下，解壓后內核運行地址zreladdr在上，這種情況如果最上面的64k的解壓buffer不會(huì )覆蓋到內核前的16k頁(yè)表的話(huà)，就不用重定位代碼跳到wont_overwrite執行。

第二種情況是加載運行的zImage在上，而解壓的內核運行地址zreladdr在下面，只要最后解壓后的內核的大小加上zreladdr不會(huì )到當前pc值，則也不會(huì )出現代碼覆蓋的情況，這種情況下，也不用重位代碼，直接跳到wont_overwrite執行就可以了。

圖.6內核的兩種解壓不要重定位的情況

可以我們一般加載的zImage的地址，和最后解壓的zreladdr的地址是相同的，那么，就必然會(huì )發(fā)生代碼覆蓋的問(wèn)題，這時(shí)候就要進(jìn)行代碼的自搬移和重定位。具體實(shí)現如下：

這段代碼就是實(shí)現代碼的自搬移，最開(kāi)始兩句是取得所要搬移代碼的大小，進(jìn)行了256字節的對齊，注釋上說(shuō)了，為了避免偏移很小時(shí)產(chǎn)生自我覆蓋（這個(gè)地方暫沒(méi)有想明白，不過(guò)不影響下面分析）。這里還是再畫(huà)個(gè)圖表示一下整個(gè)搬移過(guò)程吧，以zImage加載地下和zreladdr都為0x28為例，其他的類(lèi)似。

圖.7 zImage的代碼自搬移和內核解壓的全程圖解

圖.7中我已經(jīng)標好了序號，代碼的自搬移和內核解的整個(gè)過(guò)程都在這里面下面一步步來(lái)分解：

①．首先計算要搬移的代碼的.text段代碼的大小，從restart開(kāi)始，到reloc_code_end結束，這個(gè)就是剩下的.text段的內容，這段內容是接在打開(kāi)cache的函數之后的。然后把這段代碼搬到核實(shí)際解壓后256字節對齊的邊界，然后進(jìn)行搬移，搬移時(shí)一次搬運32個(gè)字節，故存有搬移大小的r9寄存器進(jìn)行了一下32字節對齊的擴展。

②．搬移完成后，會(huì )保存一下新舊代碼間的offset值，存于r6中。再重新設置一下新的堆棧的地址，位置如圖所示，代碼如下：

③．然后進(jìn)行cache的flush，因為馬上要進(jìn)行代碼的跳轉了，接著(zhù)就計算新的restart在哪里，接著(zhù)跳過(guò)去執行新的重定位后的代碼。

這個(gè)時(shí)候就又會(huì )到restart處執行，會(huì )把前面的代碼再執行一次，不過(guò)這次在執行時(shí)，會(huì )進(jìn)入圖.6所示的代碼不用重定位的情況，意料之后的事，接著(zhù)跳到wont_overwirte執行，如下：

這兩行代碼的意思是，看一下只什么時(shí)候跳過(guò)來(lái)的，如果r0的值為0，說(shuō)明沒(méi)有進(jìn)行代碼的重定位，那這個(gè)時(shí)候跳到no_relocated處執行，這段就會(huì )跳過(guò).got符號表的搬移，因為位置沒(méi)有變啊。代碼寫(xiě)得好嚴謹啊，佩服。

④．我們這種經(jīng)過(guò)代碼重定位的情況下，r0的值一定不會(huì )零，那么這個(gè)時(shí)候就要進(jìn)行.got表的重搬移，如圖中所示，代碼如下：

⑤．下面就來(lái)初始化我們一直沒(méi)有進(jìn)行初始化的.bss段，其實(shí)就是清零，位置如圖所示。我雖畫(huà)了一個(gè)箭頭，但是其實(shí)并沒(méi)有進(jìn)行任何搬移動(dòng)作，僅僅清零，代碼如下：

這里看到我們可愛(ài)的not_relocated標號了吧，這個(gè)標號就是前面所見(jiàn)到的如果沒(méi)有進(jìn)行重定位，就直接跳過(guò)來(lái)進(jìn)行bss的初始化。

⑥．設置好64K的解壓緩沖區在堆棧之后，代碼如下：

⑦．進(jìn)行內核的解壓過(guò)程

這個(gè)函數是C下面的函數，那些堆棧的設置啊，.got表啊，64k的解壓緩沖啊，都是為它準備的。第一個(gè)參數是內核解壓后所存放的地址，第二，第三參數是64k解壓緩沖起始地址和結束地址，最后一個(gè)參數ID號，這個(gè)由u-boot傳入。

⑧．這是最后一步了，終于到最后一步了。代碼如下：

這里先進(jìn)行cache的flush，然后關(guān)掉cache，再準備好linux內核要啟動(dòng)的幾個(gè)參數，最后跳到zreladdr處，進(jìn)入解壓后的內核，到這里壓縮內核的使命就完成了。但是它的功勞可不小啊。下面就是真真正正的linux內核的啟動(dòng)過(guò)程了，這里會(huì )進(jìn)入到arch/arm/kernel/head.s這個(gè)文件的stext這個(gè)地址開(kāi)始執行第一行代碼。