-Linux Kernel SMP&nbsp…

Android 筆記-Linux Kernel SMP (Symmetric
Multi-Processors) 開機流程解析 Part(2) Linux Kernel SMP
zImage到start_kernel流程.

hlchou@mail2000.com.tw

by loda.

Mmmmmm,必須承認,我把這篇文章寫的有點囉嗦,以前在Linux
Kernel上的工作,沒有留下太多的筆記,抽象的概念,容易隨著下一個產品或是技術的開發,成為過往記憶的一部分,這次重新整理,希望以後回來看時,可以很快Pick-up所有的細節,所以在一些枝微末節上,會比較嘮叨.

也因此,如果你原本就對ARM與Linux Kernel原始碼有一定的基礎,可能讀起本文來會比較輕鬆些.
若是有些部分,筆者探究的太過細節,還請各位見諒.

Linux Kernel對於SMP的支援有三種組合,

1,不支援SMP的Linux Kernel

2,支援SMP的Linux
Kernel (關閉SMP對於單核心UniProcessor的支援,SMP_ON_UP=n)

3,支援SMP/UP的Linux
Kernel (開啟SMP對於單核心UniProcessor的支援,SMP_ON_UP=y),並在啟動時,如果偵測到為UniProcessor時,會自我修正不能在non-SMP運作的指令.

目前SMP_ON_UP選項只在ARM處理器上有.

其實,整個Linux Kernel中包括PageSet,Process ID
Map與相關的資料結構,都會參考目前系統中的處理器個數,來做出對應的配置,也就是說Linux
Kernel對於支援多核心的架構,已經是相當的內化(骨子裡…就是會考慮到多核心的情況.),並蘊含在許多核心模組的設計上.
也因此,在整理本文的過程中,收獲最大的也是筆者自己對於SMP架構與Linux Kernel模組的藍圖.
並希望對閱讀本文的人也能有所助益.

本文主要從zImage開始到start_kernel完畢(rest_init除外),並以Tegra平台為主要參考,由於並非所有函式都在筆者平台上被參考到,在說明中也會略過,只選擇在這平台上比較重要的部份.

由於筆者時間受限,本系列文章會分次刊登,還請見諒.

Linux Kernel Image

依據開發的需求,Linux Kernel Image可以編譯為 zImage (Compressed kernel
image),Image (Uncompressed kernel image),xipImage(XIP(eXecution In
Place) kernel image),uImage(U-Boot wrapped zImage)與 bootpImage(
Combined zImage and initial RAM disk).

若對Linux Kernel編譯過程有興趣,可在編譯時加上
KBUILD_VERBOSE=1,讓quiet參數為空白,可把編譯過程吐到Console中,便於觀察.

不只是ARMv32,還支援Thumb2的Linux
Kernel Image

如果所選擇的處理器是ARMv7 (也就是Cortex的架構),可以透過勾選Experimental程式碼的選項,就可把Linux
Kernel以Thumb2的方式進行編譯.

有關ARMv32與Thumb2效能的比較可以參考這篇在ARM工作的Richard Phelan所寫的文章Improving ARM
Code Density and Performance
(http://www.cs.uiuc.edu/class/fa05/cs433ug/PROCESSORS/Thumb2.pdf),
以C
Code實作同樣的功能來說,編譯為Thumb2最高可以達到98%的ARM指令及效能,程式碼本身所需的記憶體空間只佔原本ARM程式碼的74%.
對記憶體受限的嵌入式裝置,以Thumb2 16/32 bits混合的程式碼可以得到較佳的 Performance/Code
Size的C/P值.

在選擇Linux Kernel選單時,只要進行如下勾選即可,

General setup —>Prompt for development and/or
incomplete code/drivers

與

Kernel Features —>Compile the kernel in
Thumb-2 mode

目前筆者並未驗證過這部份的代碼,僅作為有興趣的開發者參考資訊.

Linux
Kernel編譯時所產生的Relocatable Object
File.

當一個編譯系統比較龐大時,如果是一次要Link大量的.o或.a檔時,要解決這些Symbol
Resolve會需要的記憶體與運算成本,也會對應的提高,Linux Kernel有使用GCC
relocatable output的機制,讓個別模組可以先進行 Symbol Resolve,節省最後Kernel
Image產生的運算資源. 簡要說明如下

1, 編譯過程中,會透過arm-eabi-ld (GCC Linker) 搭配 “-r” 產生”relocatable
output”,例如:

arm-eabi-ld
-EL -r -o
drivers/tty/vt/built-in.o drivers/tty/vt/vt_ioctl.o
drivers/tty/vt/vc_screen.o drivers/tty/vt/selection.o
drivers/tty/vt/keyboard.o drivers/tty/vt/consolemap.o
drivers/tty/vt/consolemap_deftbl.o drivers/tty/vt/vt.o
drivers/tty/vt/defkeymap.o

會把 drivers/tty/vt下的.o檔案,產生出一個在內部已經做過Symbol Resolved動作的集合Object檔案
built-in.o,透過objdump我們先檢視在目錄下的vt.o檔案中呼叫外部函式vt_ioctl,

arm-eabi-objdump -t vt.o|grep "vt_ioctl"

00000000
*UND* 00000000 vt_ioctl

由於該函式的實作不在vt.c中,因此在編譯後,.o檔案中的Symbol會被標示為
“Undefined”,再來檢視實作該函式的vt_ioctl.c產生的Object檔案,如下所示

arm-eabi-objdump -t vt_ioctl.o|grep "vt_ioctl"

vt_ioctl.o:
file format elf32-littlearm

00000000 l df
*ABS* 00000000 vt_ioctl.c

00000558
g
F .text 00001ccc vt_ioctl

可以看到該函式在vt_ioctl.c編譯後,是在text節區中,且屬性為 global,可供外部的.o檔案連結.

最後我們檢視drivers/tty/vt目錄下產生的built-in.o,

arm-eabi-objdump -t built-in.o|grep "vt_ioctl"

00000000 l df
*ABS* 00000000 vt_ioctl.c

00000558
g
F .text 00001ccc vt_ioctl

可以看到,最後產生的集合檔案built-in.o,包含了vt.o與vt_ioctl.o,且在其中這些.o之間的Symbol交互參考的問題,都已經在編譯階段被解決.

想像一下,如果一次有5000個Object檔案或是.a檔案(.a檔案,等於是Object檔案的Archive,可以分辨.o檔案的集合性,但其中所包含的.o並沒有彼此先進行Symbol
Resolved,因此,所花的時間成本跟.o是一樣的.),要去做Symbol
Resolved,這要建立的對應表格複雜度,跟我先把這5000檔案所在的20個目錄,針對這20個目錄先把其中包含的Object檔案做內部的Symbol
Resolved,減少要解決的Symbol個數與要建立的查表範圍,就可以顯著的加速最後要連結成Image的運算時間與記憶體成本.

參考平台Tegra2的記憶體配置

筆者以Linux Kernel 2.6.39並選擇ARM Tegra2的平台為例 (NVIDIA Tegra
(ARCH_TEGRA)),關於這處理器的基本資訊為

1,兩個Cortex A9處理器

2,一個Audio/Video ARM7處理器

3,實體記憶體SDRAM定址在 0×00000000 (
AP20_BASE_PA_SDRAM)

4,OnChip 256KB SRAM定址在0×40000000 (AP20_BASE_PA_SRAM)

5,NOR Flash的定址在0xD0000000 ( AP20_BASE_PA_NOR_FLASH)

有關NVidia Tegra2的資訊可以參考http://developer.nvidia.com/tegra/taxonomy/term/36/0

有關ALT_UP對SMP到UP程式碼的修正

由於Linux Kernel SMP的實作,在ARM的架構下會有SMP與單核心共用函式實作程式碼的差異,在檔案
arch/arm/include/asm/assembler.h中,有實現ALT_SMP與ALT_UP兩個巨集,例如在程式碼中使用ALT_UP,該指令就會被加入Section
.alt.smp.init 如下所示.

#define
ALT_UP(instr…)
\

.pushsection ".alt.smp.init",
"a"
;\

.long
9998b
;\

9997:
instr
;\

.if . – 9997b !=
4
;\

.error "ALT_UP() content must assemble to exactly 4 bytes";\

.endif
;\

.popsection

藉此我們可以在同樣的函式中,根據單核心與SMP實作的差異,透過ALT_SMP與ALT_UP來把兩種版本的程式碼置入,以開啟SMP與SMP_ON_UP的實作來說,屬於SMP的實作,會被編譯在原本執行函式的內容中,而屬於單核心版本的實作,則會被編譯到Section
.alt.smp.init下,參考如下程式碼的例子

在檔案arch/arm/mm/proc-v7.S中,

ALT_SMP(orr
r0, r0, #TTB_FLAGS_SMP)

ALT_UP(orr
r0, r0, #TTB_FLAGS_UP)

…..

cpu_resume_l1_flags:

ALT_SMP(.long PMD_TYPE_SECT | PMD_SECT_AP_WRITE |
PMD_FLAGS_SMP)

ALT_UP(.long PMD_TYPE_SECT | PMD_SECT_AP_WRITE |
PMD_FLAGS_UP)

或檔案arch/arm/mm/tlb-v7.S中,

ALT_SMP(mcr
p15, 0, r0, c8, c3, 1) @ TLB invalidate U MVA
(shareable)

ALT_UP(mcr
p15, 0, r0, c8, c7, 1) @ TLB invalidate U MVA

我們可以看到依據SMP與單核心版本的差異,實作上會在同一處程式碼中同時實現兩種版本的程式碼,並透過ALT_UP把單核心的版本在編譯階段放到Section
.alt.smp.init中,並且會在每4bytes程式碼位址後,記錄對應4bytes單核心版本指令集,以便修正時參考,如下例子

0xc001858c <__smpalt_begin>:

…..

0xc0018634: c0029fd8
.word
0xc0029fd8 //4
bytes 要取代的目標記憶體位址

0xc0018638: ee080f37

mcr 15, 0,
r0, cr8, cr7, {1} //4bytes
UniProcessor版本指令

0xc001863c: c0029fec
.word
0xc0029fec

0xc0018640: ee07cfd5

mcr 15, 0,
ip, cr7, cr5, {6}

0xc0018644: c002a00c .word
0xc002a00c

0xc0018648: ee080f37

mcr 15, 0,
r0, cr8, cr7, {1}

…..

在最後的Link階段,會把Section .alt.smp.init放在Symbol
__smpalt_begin與__smpalt_end之中,因此在程式碼執行階段,就可以透過這兩個Symbol取得 Section
.alt.smp.init中所包含單核心程式碼的內容與記憶體範圍.

在Linux
Kernel啟動後會呼叫函式__fixup_smp,如果判斷目前是在單核心平台上,就會把在__smpalt_begin到__smpalt_end記憶體範圍的單核心程式碼依據其對應的記憶體位址,進行修正動作.

運作概念如下圖所示



從zImage開始,啟動Linux
Kernel

接下來,以Linux Kernel zImage為例,簡要說明執行流程,也借此對產生的Linux Kernel
Image有一個概念,有關SMP的部份,會在流程走到時,著重說明

編譯完成後,在根目錄下的vmlinux會透過如下的命令產生出來,其中有關記憶體位置與節區的配置參考檔案為
arch/arm/kernel/vmlinux.lds

arm-eabi-ld -EL -p –no-undefined -X –build-id
-o vmlinux -T
arch/arm/kernel/vmlinux.lds arch/arm/kernel/head.o
arch/arm/kernel/init_task.o init/built-in.o
–start-group usr/built-in.o
arch/arm/kernel/built-in.o
arch/arm/mm/built-in.o
arch/arm/common/built-in.o
arch/arm/mach-tegra/built-in.o
kernel/built-in.o mm/built-in.o
fs/built-in.o ipc/built-in.o
security/built-in.o
crypto/built-in.o
block/built-in.o
arch/arm/lib/lib.a lib/lib.a
arch/arm/lib/built-in.o
lib/built-in.o
drivers/built-in.o
sound/built-in.o
firmware/built-in.o net/built-in.o –end-group
.tmp_kallsyms2.o

(關於.tmp_vmlinux1 與.tmp_vmlinux2的產生,在此先略過)

之後,執行如下命令把ELF格式的vmlinux轉為 Binary 格式的Image

arm-eabi-objcopy -O binary -R .comment -S vmlinux
arch/arm/boot/Image

並執行如下命令把 Linux Kernel Binary Image轉為壓縮檔案

cat arch/arm/boot/compressed/../Image | gzip -f -9 >
arch/arm/boot/compressed/piggy.gzip

參考arch/arm/boot/compressed/piggy.gzip.S原始碼

.section .piggydata,#alloc

.globl input_data

input_data:

.incbin "arch/arm/boot/compressed/piggy.gzip"

.globl input_data_end

input_data_end:

可以知道在編譯arch/arm/boot/compressed/piggy.gzip.S產生arch/arm/boot/compressed/piggy.gzip.o時,就會把壓縮後的Linux
Kernel Image "
arch/arm/boot/compressed/piggy.gzip",一併產生在piggy.gzip.o中的Symbol
input_data與input_data_end之間.

然後,把壓縮檔跟解壓縮的部份,連結產生
compressed目錄下的vmlinux (記憶體起點為0×00000000,也就是對應到Tegra2外部記憶體的起點),執行的Link指令如下所示

arm-eabi-ld
-EL –defsym
_image_size=1602596 –defsym zreladdr=0×00008000 -p –no-undefined -X
-T arch/arm/boot/compressed/vmlinux.lds
arch/arm/boot/compressed/head.o
arch/arm/boot/compressed/piggy.gzip.o
arch/arm/boot/compressed/misc.o
arch/arm/boot/compressed/decompress.o
arch/arm/boot/compressed/lib1funcs.o -o
arch/arm/boot/compressed/vmlinux

然後,執行如下命令把帶有壓縮後的vmlinux與解壓縮程式的ELF格式vmlinux轉為 Binary 格式的zImage

arm-eabi-objcopy -O binary -R .comment -S
arch/arm/boot/compressed/vmlinux arch/arm/boot/zImage

如此,就完成Linux Kernel Image的產生.

其中有關zImage執行的實體記憶體位址可以透過CONFIG_ZBOOT_ROM_TEXT與CONFIG_ZBOOT_ROM_BSS設定.

而Linux Kernel解壓縮的位址會在 CONFIG_ZBOOT_ROM_TEXT + 16kbytes的位址,以這例子來說就是
0×00008000. 這是在最後產生arch/arm/boot/compressd/vmlinux時,透過 “–defsym
zreladdr=0×00008000” 產生zreladdr Syombol傳遞給zImage.

可以參考 boot/compressed/Makefile中

LDFLAGS_vmlinux += –defsym zreladdr=$(ZRELADDR)

而 ZRELADDR是在arch/arm/boot/Makefile 中設定的

ZRELADDR :=
$(zreladdr-y)

其中,zreladdr-y會是在每個Machine對應的目錄下的Makefile.boot被定義,例如Tegra2是在檔案
arch/arm/mach-tegra/Makefile.boot中,以如下方式定義zreladdr-y

zreladdr-$(CONFIG_ARCH_TEGRA_2x_SOC)
:= 0×00008000

同時,對解壓縮的Kernel Image執行的虛擬與實體記憶體對應,必須滿足如下條件

ZRELADDR == virt_to_phys(PAGE_OFFSET + TEXT_OFFSET)

因為如此,解壓縮的Linux Kernel在虛擬記憶體中的位址就必須是0xc0008000 對應到實體記憶體中的位址會是
0×00008000. 如果Kernel Space的虛擬記憶體空間有調整的話(例如從
0xc0000000調整為0×80000000,就會變成 0×80008000 ↔ 0×00008000).

Linux Kernel Image在虛擬記憶體的運作位置可以透過 xx訂定,一般而言都是給User-Space
3GB的範圍,Kernel Space為1GB的範圍.

CONFIG_PAGE_OFFSET=0xC0000000

要進一步探討Linux
Kernel啟動流程,我們可以透arch/arm/boot/compressed/vmlinux.lds了解zImage的啟動流程,

1,節區.text產生的Binary Symbol有

a, ("static const unsigned short lext" in
lib/zlib_inflate/inftrees.c)

b, ("static const unsigned short lbase" in
lib/zlib_inflate/inftrees.c)

c, ("static const unsigned short dext" in
lib/zlib_inflate/inftrees.c)

d, ("static const unsigned short dbase" in
lib/zlib_inflate/inftrees.c)

e, ("static const code lenfix" in lib/zlib_inflate/inffixed.h)

f, ("static const code distfix" in lib/zlib_inflate/inffixed.h)

….etc

2,會把壓縮後的Linux Kernel piggy.gzip 放在.text節區中Symbol 到
之間,以筆者驗證的環境來說,大約介於實體記憶體 0x00003fde-0x000bdcbe之間.
(約761kbytes)=>要看總共編譯多少核心模組與程式碼範圍.

如下圖所示



3,編譯後的zImage,在會檔頭 offset: 0×00000024
bytes位置存放32-bits 的 “0x016f2818” 作為
BootLoader載入zImage時,確認zImage檔案正確與否的Magic Number. 緊接著offset:
0×00000028位置存放32-bits
zImage在實體記憶體的起始位址 (以筆者編譯Tegra2
Seaboard環境而言該值為0×00000000.) 再來的offset:
0x0000002c位置存放32-bits
zImage在實體記憶體的結束位置 (以筆者編譯Tegra2
Seaboard環境而言該值為0x000bdcf4).
透過上述的三個值,就可以讓BootLoader驗證Linux Kernel Magic Number,並且知道要把該Kernel
Image擺放到哪一段記憶體位址執行與大小.

4,啟動後,會執行arch/arm/boot/compressed/head.S 中的函式start
,可以參考UBoot中呼叫Linux Kernel Entry 的函式原型為

void
(*kernel_entry)(int zero, int arch, uint params);

也就是說, UBoot/BootLoader
呼叫zImage時,第一個參數固定為0(r0),第二個參數為處理器平台ID(r1),第三個參數為Linux Kernel啟動的Boot
Argument(r2)

00000000 :

0×00000000:
nop
(mov r0,r0)

0×00000004:
nop
(mov r0,r0)

0×00000008:
nop
(mov r0,r0)

0x0000000c:
nop
(mov r0,r0)

0×00000010:
nop
(mov r0,r0)

0×00000014:
nop
(mov r0,r0)

0×00000018:
nop
(mov r0,r0)

0x0000001c:
nop
(mov r0,r0)

0×00000020:
b
30 <_text+0×30>

0×00000024:
.word
0x016f2818

0×00000028:
.word
0×00000000

0x0000002c:
.word
0x000bdcf4

0×00000030: mov r7, r1

0×00000034: mov r8, r2

0×00000038: mrs r2, CPSR

0x0000003c:
tst r2, #3 ;
0×3 (確認是否為Supervisor
Mode,User Mode=b10000(0×0010) and Supervisor
Mode=b10011(0×0013)).

0×00000040: bne 4c

0×00000044: mov r0,
#23
;
0×17 (如果在SVC
Mode就執行這部份的程式碼).

0×00000048: svc
0×00123456 (ARM
semihosting 會傳遞參數0×17給JTAG除錯器,並讓ARM
Core停止執行,可用於ICE除錯啟動流程)

如果zImage在編譯時是載入到記憶體0×00000000的位址,則zImage的進入點為
0×00000030. (從0×00000000開始執行,也會執行連續的mov
r0,r0 直到0×00000020再Branch到正式的函式入口.).

5,之後呼叫函式__armv7_mmu_cache_on,並透過函式setup_mmu以1MB
Section方式配置TLB (MMU虛擬記憶體機制在這並沒有作用,所設定的TLB虛擬記憶體是直接對應到4GB的範圍,所以TLB虛擬位址0xc0000000就會直接對應到實體記憶體的0xc0000000.)

000002bc <__armv7_mmu_cache_on>:

0x000002bc: mov ip, lr

0x000002c0:
mrc 15, 0,
fp, cr0, cr1,
{4} //read
ID_MMFR0

0x000002c4:
tst
fp,
#15
;
0xf //VMSA

0x000002c8: blne 21c
<__setup_mmu>

0x000002cc: mov r0, #0 ;
0×0

0x000002d0:
mcr 15, 0,
r0, cr7, cr10,
{4} //drain write
buffer

0x000002d4:
tst
fp,
#15
;
0xf //VMSA

0x000002d8:
mcrne
15, 0, r0, cr8, cr7,
{0} //flush
I,D TLBs

0x000002dc:
mrc 15, 0,
r0, cr1, cr0,
{0} //read
control reg

0x000002e0:
orr
r0, r0,
#20480
;
0×5000 //I-cache
enable, RR cache replacement

0x000002e4:
orr
r0, r0, #60 ;
0x3c //write
buffer

0x000002e8: orrne r0, r0,
#1
;
0×1 //MMU
enabled

0x000002ec:
mvnne
r1, #0 ; 0×0

0x000002f0:
mcrne
15, 0, r3, cr2, cr0,
{0} //load
page table pointer //r3 from setup_mmu = page table
entry.

0x000002f4:
mcrne
15, 0, r1, cr3, cr0,
{0} //load
domain access control

0x000002f8:
mcr
15, 0, r0, cr1, cr0,
{0} //load
control register

0x000002fc:
mrc
15, 0, r0, cr1, cr0,
{0} //and
read it back

0×00000300: mov r0, #0 ;
0×0

0×00000304:
mcr 15, 0,
r0, cr7, cr5,
{4} //ISB

0×00000308: mov pc, ip

0000021c <__setup_mmu>:

0x0000021c:
sub r3, r4,
#16384
;
0×4000 //Page
directory size //(r4=Linux
Kernel 解壓縮後記憶體位址=0×00008000,
r3=0×00004000)

0×00000220:
bic
r3, r3, #255 ;
0xff //Align
the pointer

0×00000224:
bic
r3, r3,
#16128
; 0x3f00

0×00000228: mov r0, r3

0x0000022c:
lsr
r9, r0, #18

0×00000230:
lsl
r9, r9,
#18 //start
of RAM

0×00000234:
add sl, r9,
#268435456 ;
0×10000000 //
a reasonable RAM size

0×00000238: mov r1,
#18
; 0×12

0x0000023c:
orr
r1, r1,
#3072
; 0xc00

0×00000240:
add r2, r3,
#16384
; 0×4000

0×00000244: cmp r1,
r9 //if
virt > start of RAM

0×00000248: orrcs r1, r1,
#12 ;
0xc //set
cacheable, bufferable

0x0000024c: cmp r1,
sl //if
virt > end of RAM

0×00000250: biccs r1, r1,
#12 ;
0xc //clear
cacheable, bufferable

0×00000254:
str
r1, [r0],
#4 //1:1
mapping

0×00000258:
add r1, r1,
#1048576
; 0×100000 //Use Section Size=1MB//Page
Table從0×4000-0×8000,每個Entry值為4
bytes,所以會有0×1000筆Entry,也就是說0×1000
* 1MB=4GB Range=32bits處理器訂址的上限

0x0000025c:
teq
r0, r2

0×00000260:
bne 244
<__setup_mmu+0×28>

0×00000264: mov r1,
#30
; 0x1e

0×00000268:
orr
r1, r1,
#3072
; 0xc00

0x0000026c: mov r2, pc

0×00000270:
lsr
r2, r2, #20

0×00000274:
orr
r1, r1, r2, lsl #20

0×00000278:
add r0, r3,
r2, lsl #2

0x0000027c:
str
r1, [r0], #4

0×00000280:
add r1, r1,
#1048576
; 0×100000

0×00000284:
str
r1, [r0]

0×00000288: mov pc, lr

有關TLB 1MB Section Settings如下示意圖



以配置在0×00004000-0×00008000之間TLB 1MB Section的虛擬記憶體設定來說,Linux Kernel
Base Address 0xc0008000,透過TLB查尋0xc0000000對應到的實體記憶體位址,首先取虛擬記憶體bits
31-20 值0xc00 作為Table Index,得到的Translation Table Base Address為
0×00004000 + 0xc00*4 = 0×00007000,該記憶體位址的1st Level
Descriptor內容為0xc0000c12,屬性欄位為 1100 0001 0010
也就是AP[2:0]=011(Privileged/User permissions 都是可讀可寫的Full Access
Right.),XN=1,

用虛擬記憶體0xc0008000轉換為實體記憶體時,1st Level Descriptor的bit 31-20
為0xc0000000+Offset
0×00008000=實體記憶體0xc0008000. (這是只有經過zImage前面setup_mmu設定的結果,並非正式Linux
Kernel MMU
TLB的配置結果喔!!!)

雖然setup_mmu已經對MMU TLB進行配置,但還不是最後的運作狀態,會在後續執行中設定完成.

6, 之後透過ARM r4暫存器 (r4 = kernel execution address
)儲存Linux Kernel所要解壓縮的目標記憶體位置,如下程式碼

#ifdef CONFIG_AUTO_ZRELADDR

@ determine final kernel image address

mov
r4, pc

and
r4, r4, #0xf8000000

add
r4, r4, #TEXT_OFFSET

#else

ldr
r4, =zreladdr

#endif

bl
cache_on

呼叫函式decompress_kernel,解壓縮Linux到目標位址

mov
r0, r4

mov
r1,
sp
@ malloc space above stack

add
r2, sp,
#0×10000
@ 64k max

mov
r3, r7

bl
decompress_kernel

bl
cache_clean_flush

bl
cache_off

mov
r0,
#0
@
must be zero

mov
r1,
r7
@ restore architecture number

mov
r2,
r8
@ restore atags pointer

mov
pc,
r4
@ call kernel

函式decompress_kernel 第一個參數為Linux
Kernel要解壓縮的目標記憶體位置(from r4),第二個參數為目前的Stack
Point,第三個參數為目前Stack加上64kbytes,第四個參數為目前的處理器平台識別碼,之後Flush
Cache並關閉Cache.

最後,從Linux Kernel解壓縮後的記憶體位置的起點(也就是r4的記憶體位置)開始執行Linux
Kernel (第一個參數為0, 第二個參數為目前的處理器平台識別碼,第三個參數為BootLoader要傳遞給Linux
Kernel的Boot
Argument.)

整個ARM從Boot Rom到UBoot BootLoader ,到 zImage解壓縮,到啟動解壓縮後Linux
Kernel的流程,簡要描述如下圖所示



結束了zImage到解壓縮後的vmlinux Kernel Image流程,接下來我們以開啟SMP選項的Linux Kernel
Image為例,進一步說明啟動的流程.

繼續vmlinux Linux Kernel
Image執行流程

最原始的ELF格式Linux Kernel在編譯後所在的位置為/vmlinux,透過objcopy產生的Binary檔案為
arch/arm/boot/Image.

根目錄的vmlinux執行時,會從arch/arm/kernel/head.S中的函式stext開始,stext函式會帶入三個函式參數,第一個參數固定為0,第二個參數為architecture
number,第三個參數為要帶給Kernel參數在記憶體中的位址.

如下為反組譯vmlinux執行時最前端的程式碼,

0×00008000 :

0×00008000:
msr CPSR_c,
#211
; 0xd3 //ensure svc mode and irqs
disabled

0×00008004:
mrc 15, 0,
r9, cr0, cr0, {0} //get processor
id

0×00008008:
bl
0×00156878
<__lookup_processor_type> //r5=procinfo
r9=cpuid

0x0000800c:
movs sl, r5 //invalid processor
(r5=0)?

0×00008010:
beq c01568bc
<__error> //yes, error
‘p’

0×00008014:
add r3, pc,
#40 ; 0×28

0×00008018:
ldm r3, {r4,
r8}

0x0000801c:
sub r4, r3,
r4 //(PHYS_OFFSET
– PAGE_OFFSET)

0×00008020:
add r8, r8,
r4 //PHYS_OFFSET

0×00008024:
bl
0x0000810c <__vet_atags>

0×00008028:
bl
0×00008144
<__fixup_smp>//用以修正SMP
Linux Kernel在單核心處理器運作的機制

0x0000802c:
bl
0x0000804c <__create_page_tables>
//設定BootStrap處理器的MMU
TLB分頁表

0×00008030:
ldr
sp, [pc, #8] ; 0×00008040
//address to jump to after mmu has been
enabled

0×00008034:
add lr, pc,
#0
; 0×0 //return (PIC)
address

0×00008038:
add pc, sl,
#16 ;
0×10 //Go to function __v7_proc_info
(0x0019abf8+0×10 = 0x0019ac08)

0x0000803c:
b
0x0015684c <__enable_mmu>

0×00008040:
.word 0xc00081a0

0×00008044:
.word 0xc0008044

0×00008048:
.word 0xc0000000

在前面的內容有提到,透過setup_mmu所配置的MMU TLB並不是一個真正適應於Linux
Kernel最終在高位址執行設定的虛擬記憶體配置,而在這階段透過函式__create_page_tables,就會把MMU
TLB從下圖左側原本的配置方式,改為如右側適應於Linux Kernel配置在高位址,並且針對不存在的記憶體分頁,設定為0.



如果我們所編譯的Linux Kernel為支援SMP的版本,並且有開啟編譯選項SMP_ON_UP,在函式 __fixup_smp中
(fixup = Fix UniProcessor),會進行確認是否為SMP的核心運作在單核心處理器上,並執行必要的修正.

在ARMv7 Cortex處理器下,會進入函式__v7_proc_info + 0×10 也就是函式__v7_setup中

0x0019abf8 <__v7_proc_info>: (in
arch/arm/mm/proc-v7.S)

0x0019abf8:

.word 0x000f0000

0x0019abfc:

.word 0x000f0000

0x0019ac00:

.word 0x00011c0e

0x0019ac04:

.word 0x00000c12

0x0019ac08:

b
0x001570bc <__v7_setup>

在函式__v7_setup中會初始化TLB,Caches與MMU. 並透過CP15取得Main ID Register,
簡要說明如下

透過"MRC p15, 0, , c0, c0, 0″ 讀取處理器Main ID Register

Cortex A8 單核心 Main

Cortex A9 單核心 Main

Cortex A9 Dual-Core Main ID= 0x412FC090 (for
r2p0) ,0x412FC091 (for r2p1) or 0x412FC092 (for
r2p2)

Main ID Register格式如下所示

31	30	29	28	27	26	25	24	23	22	21	20	19	18	17	16	15	14	13	12	11	10	9	8	7	6	5	4	3	2	1	0
Implementor	Variant	Architecture	Primary Part Number	Revision

欄位	說明
Implementor	ARM處理器為0×41
Variant	可用以表示Major Revision Indicates the variant number, or major revision, of the processor: 0×3.
Architecture	Indicates that the architecture is given in the feature registers: 0xF.
Primary Part Number	Indicates the part number, Cortex-A8: 0xC08.
Revision	Indicates the revision number, or minor revision, of the processor: 0×2.

函式__v7_setup運作如下所示

0x001570bc <__v7_setup>: (in arch/arm/mm/proc-v7.S)

0x001570bc:

add ip, pc,
#140 ; 0x8c //the local stack

0x001570c0:

stm ip, {r0,
r1, r2, r3, r4, r5, r7, r9, fp, lr}

0x001570c4:

bl
0x000297ec

0x001570c8:

ldm ip, {r0,
r1, r2, r3, r4, r5, r7, r9, fp, lr}

0x001570cc:

mrc 15, 0,
r0, cr0, cr0, {0} //read main ID
register

0x001570d0:

and sl, r0,
#-16777216 ; 0xff000000 //ARM?

0x001570d4:

teq
sl,
#1090519040
; 0×41000000

0x001570d8:

bne
0×00157108 <__v7_setup+0x4c>

0x001570dc:

and r5, r0,
#15728640 ;
0xf00000 //variant

0x001570e0:

and r6, r0,
#15 ;
0xf //revision

0x001570e4:

orr
r6, r6, r5, lsr #16 //combine variant and
revision

0x001570e8:

ubfx r0, r0, #4,
#12 //primary part number

0x001570ec:

ldr
sl, [pc,
#136]
; 0x0015717c
<__v7_setup_stack+0x2c> //Cortex-A8
primary part number

0x001570f0:

teq
r0, sl

0x001570f4:

bne
0x001570fc <__v7_setup+0×40>

0x001570f8:

b
0×00157108 <__v7_setup+0x4c>

0x001570fc:

ldr
sl, [pc,
#124]
; 0×00157180 <__v7_setup_stack+0×30>//Cortex-A9
primary part number

0×00157100:

teq
r0, sl

0×00157104:

bne
0×00157108 <__v7_setup+0x4c>

0×00157108:

mov sl, #0 ; 0×0

0x0015710c:

dsb sy

0×00157110:

mcr 15, 0,
sl, cr8, cr7, {0} //invalidate I + D
TLBs

0×00157114:

mcr 15, 0,
sl, cr2, cr0, {2} //TTB
control register

0×00157118:

orr
r4, r4, #106 ; 0x6a

0x0015711c:

mcr 15, 0,
r4, cr2, cr0, {1} //load
TTB1

0×00157120:

ldr
r5, [pc, #92] ; 0×00157184
<__v7_setup_stack+0×34> //PRRR

0×00157124:

ldr
r6, [pc, #92] ; 0×00157188
<__v7_setup_stack+0×38> //NMRR

0×00157128:

mcr 15, 0,
r5, cr10, cr2, {0} //write
PRRR

0x0015712c:

mcr 15, 0,
r6, cr10, cr2, {1} //write
NMRR

0×00157130:

add r5, pc,
#16 ; 0×10

0×00157134:

ldm r5, {r5,
r6}

0×00157138:

mrc 15, 0,
r0, cr1, cr0, {0} //read control
register

0x0015713c:

bic
r0, r0, r5 //clear bits them

0×00157140:

orr
r0, r0, r6 //set them

0×00157144:

mov pc,
lr //pc=0x0000803c,之後進入函式__enable_mmu

回到stext函式

0x0000803c:

b
0x0015684c <__enable_mmu>

進入函式 __enable_mmu

0x0015684c <__enable_mmu>:

0x0015684c:

orr
r0, r0,
#2
; 0×2

0×00156850:

mov r5,
#21
; 0×15

0×00156854:

mcr 15, 0,
r5, cr3, cr0, {0}

0×00156858:

mcr 15, 0,
r4, cr2, cr0, {0}

0x0015685c:

b
0×00156860 <__turn_mmu_on>

進入函式 __turn_mmu_on

0×00156860 <__turn_mmu_on>:

0×00156860:

nop
(mov r0,r0)

0×00156864:

mcr 15, 0,
r0, cr1, cr0, {0}

0×00156868:

mrc 15, 0,
r3, cr0, cr0, {0}

0x0015686c:

mov r3, r3

0×00156870:

mov r3, sp

0×00156874:

mov pc,
r3 //會呼叫0xc00081a0 //到這就是第一次執行到虛擬記憶體的位址0xc00081a0

進入函式__mmap_switched

0xc00081a0 <__mmap_switched>:

0xc00081a0:
add r3, pc,
#64 ; 0×40

0xc00081a4:
ldm r3!, {r4,
r5, r6, r7}

0xc00081a8:
cmp r4,
r5 //Copy data segment
if needed

0xc00081ac:
cmpne
r5, r6

0xc00081b0:
ldrne fp, [r4], #4

0xc00081b4:
strne fp, [r5], #4

0xc00081b8:
bne c00081ac
<__mmap_switched+0xc>

0xc00081bc:
mov fp, #0 ;
0×0 //Clear BSS (and zero fp)

0xc00081c0:
cmp r6, r7

0xc00081c4:
strcc fp, [r6], #4

0xc00081c8:
bcc c00081c0
<__mmap_switched+0×20>

0xc00081cc:
ldm r3, {r4,
r5, r6, r7, sp}

0xc00081d0:
str
r9, [r4] //Save processor ID

0xc00081d4:
str
r1, [r5] //Save machine
type

0xc00081d8:
str
r2, [r6] //Save atags
pointer

0xc00081dc:
bic
r4, r0,
#2
; 0×2 //Clear ‘A’ bit

0xc00081e0:
stm r7, {r0,
r4} //Save control register
values

0xc00081e4:
b
0xc00088ac
//正式進入Linux
Kernel Starting.

函式start_kernel實作在
init/main.c中,並且start_kernel啟動主要Linux核心的初始化與包括Kernel SMP機制的初始化,
有關從Linux Kernel stext到start_kernel 執行的流程示意圖,如下所示



start_kernel的流程

在init/main.c中的start_kernel函式為整個Linux核心啟動的主體,接下來我們針對流程簡要說明,在有關SMP部分,會特別強調它的運作行為.

其實探究每一個步驟的細節,是做技術的人最快樂的事情,但如果每個步驟都挖到最深入,就真的像是老太婆的裹腳布一樣又臭又長(雖然本文已經快要又臭又長了…),所以會選擇筆者自己覺得值得深入的動作加以說明,如果我覺得那不必要成為文章中的一部分,就會主動跳過,不另外提及.
有興趣的讀者,也可自行參閱Linux Kernel原碼.

整理後的內容如下所示

start_kernel 初始化函式的流程	說明
smp_setup_processor_id	Do nothing in ARM.
此時中斷是關閉的,直到下述必要的程序走完,才會重新開啟中斷
tick_init	In kernel/time/tick-common.c 呼叫clockevents_register_notifier註冊 Clock Event.
boot_cpu_init	會初始化第一個處理器, include/linux/smp.h:# define smp_processor_id() raw_smp_processor_id() define smp_processor_id() raw_smp_processor_id() 在沒有設定SMP的Kernel中raw_smp_processor_id定義為0,所以處理器ID會固定為0. 而在有設定SMP的Kernel中,smp_processor_id (=raw_smp_processor_id)會傳回目前正在執行該程序的處理器ID. arch/arm/include/asm/smp.h:#define raw_smp_processor_id() (current_thread_info()->cpu) 呼叫函式set_cpu_online,set_cpu_active,set_cpu_present與set_cpu_possible, 讓目前使用的處理器設定為Online,Active,Present與Prosible,在SMP的架構下,通常會用第一個處理器(CPU)作為初始化的處理器.
顯示字串 "Linux version 2.6.39 (root@localhost.localdomain) (gcc version 4.4.0(GCC) ) #11 SMP Thu Jul xx aa:bb:cc EDT 2011″
setup_arch	函式實作在arch/arm/kernel/setup.c, 1,呼叫unwind_init,初始化基於ARM EABI的Backtrace Unwind機制 (in arch/arm/kernel/unwind.c). 處理BootLoader傳遞給Linux Kernel(in __atags_pointer)的參數. 設定code(_text,_etext),data(_sdata,_end),System Ram,Video Ram,I/O記憶體資源 2,呼叫is_smp (in arch/arm/include/asm/smp_plat.h)判斷目前是否運作在SMP Kernel下,總共可以有三種組合 a,沒有設定CONFIG_SMP,會直接返回 false. b,有設定CONFIG_SMP_ON_UP,表示可以支援SMP Kernel運作在UniProcessor(單核心)的處理器上,這時會以smp_on_up的值判斷SMP Kernel是否有運作在單核心處理器上.若是則會返回false. c,反之則返回 true,表明目前是在SMP Kernel運作下 3,承上,如果確認是在SMP下,會呼叫smp_init_cpus (in mach-tegra/platsmp.c), 並透過函式scu_get_core_count(in arch/arm/kernel/smp_scu.c)取得處理器個數, 與透過cpu_set(in include/linux/cpumask.h)設定Cpumasks (為一個bitmap,每個bit代表系統中對應存在的一個處理器), 會透過NR_CPUS決定Cpumasks bitmap的大小,以ARM平台為例,代表SMP支援處理器個數的NR_CPUS範圍可以為2到32. 4,預留記憶體給Linux Kernel崩潰時使用,配置IRQ/Abort/Undefined Instruction Mode的Stack,並回到SVC Mode.(此時IRQ/FIQ中斷都還是維持關閉的狀態) 5,呼叫tcm_init,根據arch/arm/kernel/vmlinux.lds.S中Linker Section的配置, 從外部記憶體__dtcm_start,把DTCM資料搬到__sdtcm_data到__edtcm_data中, 從外部記憶體__itcm_start,把ITCM程式碼搬到__sitcm_text到__eitcm_text中. 6,呼叫early_trap_init (in arch/arm/kernel/traps.c), 根據CONFIG_VECTORS_BASE (在ARM上通常為0xffff0000,可以避免設定Vector在0×00000000時,變成無法對0×00000000設定不可讀/不可寫與不可執行的動作,用以抓出系統可能對0位址的讀寫或是Function Null Pointer的錯誤偵測=>這招在產品開發上很好用!!). 7,參考arch/arm/kernel/entry-armv.S.會在0xffff0000配置Vector Table(複製來源為__vectors_start到__vectors_end).在0xffff0200之後配置Vector Stubs(複製來源為__stubs_start到__stubs_end),在中斷觸發後Branch這,之後Branch到對應CPU Mode的對應Vector處理Handlers. 在(0xffff0000+0×1000-(__kuser_helper_end – __kuser_helper_start) )之後配置User Helpers(複製來源為__kuser_helper_start到__kuser_helper_end),每個User Helpers的Segment為32bytes alignment,主要用以由Kernel這提供給User Mode運作的操作,以提高處理的效率,支援的函式包括__kernel_cmpxchg,__kernel_get_tls,__kernel_helper_version. 因此,觸發中斷的流程為,先到0xffff0000對應的中斷,透過Branch到Vector Stubs,再由Vector Strubs到對應的User Mode/SVC Mode的中斷處理函式,例如IRQ中斷觸發後,透過0×00000018到vector_irq再到__irq_usr或__irq_svc中斷處理函式. 8,執行Machine Descriptor 的init_early
setup_nr_cpu_ids	實作在檔案kernel/smp.c中, 會呼叫find_last_bit去尋找Cpumaks中最後設定的bits,用以決定在SMP中支援的處理器個數. 結果會儲存在變數nr_cpu_ids.
setup_per_cpu_areas	實作在檔案mm/percpu.c中, 針對單核心與SMP有不同的實作,用以配置每個處理器在記憶體中的變數區域.
smp_prepare_boot_cpu	//arch-specific boot-cpu hooks 實作在檔案arch/arm/kernel/smp.c中, 設定目前處理器的idle為目前的Process ID.
呼叫函式build_all_zonelists,page_alloc_init,parse_early_param..etc
These use large bootmem allocations and must precede kmem_cache_init()
pidhash_init	實作在檔案kernel/pid.c中, 產生搭配O(1) Scheduling的PID Hash Table,
vfs_caches_init_early	實作在檔案fs/dcache.c中, 會再呼叫dcache_init_early與inode_init_early
sort_main_extable	實作在檔案kernel/extable.c中, 呼叫sort_extable(in sort_extable)對Linux Kernel中的built-in exception table進行排序
mm_init	配置Linux Kernel memory allocators
Set up the scheduler prior starting any interrupts (such as the timer interrupt). Full topology setup happens at smp_init() time – but meanwhile we still have a functioning scheduler.
sched_init	實作在檔案kernel/sched.c中. 初始化支援多核心的排程機制. 後續還會在kernel_init中呼叫函式sched_init_smp
Disable preemption – early bootup scheduling is extremely fragile until we cpu_idle() for the first time.
呼叫函式preempt_disable與irqs_disabled關閉Preemptive Scheduling與IRQ.
idr_init_cache	實作在檔案lib/idr.c中, for “Small id to pointer translation service.”
rcu_init	實作在檔案kernel/rcutree.c中 用以初始化Read Copy Update機制.這是Linux Kernel在2.5版本後所支援的同步(synchronization)機制,可用以確保當有多個Reader讀取同一個資料時,在同一個Grace週期中,所有Reader讀取到的內容都是一致的.參考Linux Kernel Documentation的內容,RCU讀取的範例如下 rcu_read_lock(); p = rcu_dereference(head.next); y = p->data; rcu_read_unlock(); 尤其是在有多核心(SMP)的架構下,當透過RCU機制保護的資料結構被更動時,有RCU保護的內容,在rcu_read_lock/rcu_read_unlock之間,可以確保每個處理器上在這狀態下每個Process所讀取的同一個資料結構內容都是一致的. RCU是一個在多核心下,很值得善用的資料同步機制,筆者會在後續有專文討論.
radix_tree_init	實作在檔案lib/radix-tree.c中, 用以初始化Radix Tree,作為快速查找的搜尋樹.在Linux Kernel中包括Cache機制,也有採用這資料結構加速效能.
init some links before init_ISA_irqs()
early_irq_init	實作在檔案kernel/irq/irqdesc.c中, 會初始化IRQ Descriptor,這機制主要用以抽象化Device Driver處理的Interrupt Handler,讓Device Driver不需要因為平台的差異,而去因應對於中斷的處理行為. (可以透過一致的函式去request, enable, disable 與 free interrupts),可以參考文件http://www.kernel.org/doc/htmldocs/genericirq.html .
init_IRQ	實作在檔案arch/arm/kernel/irq.c中, 用以呼叫每個平台差異下,各自實作的函式 “init_irq”,以Tegra而言會進入函式tegra_init_irq中.(in arch/arm/mach-tegra/irq.c)
prio_tree_init	實作在檔案lib/prio_tree.c中, 初始化priority search tree.
init_timers	實作在檔案kernel/timer.c中, 初始化支援SMP架構的 per-CPU timer.
hrtimers_init	實作在檔案kernel/hrtimer.c中, 初始化High-resolution kernel timers (相對於kernel/timers中支援的milliseconds sleep,在這機制下可以支援nanoseconds sleep)
softirq_init	實作在檔案kernel/softirq.c中, 初始化Soft IRQ,這是在Linux Kernel中支援Soft IRQ Thread的機制,用以執行基於Kernel Thread的 Interrupt Bottom Halves (也就是一般RTOS下的HISR機制.)(參考網頁 http://elinux.org/Soft_IRQ_Threads )
timekeeping_init	實作在檔案kernel/time/timekeeping.c中, 初始化Generic Timekeeping Subsystem,用以更新系統的流逝時間,會更新xtime,wall_to_monotonic與total_sleep_time,並負責較整誤差(包括從系統Suspend到Resume的時間差),支援getnstimeofday,do_gettimeofday,do_settimeofday…etc函式. (參考網頁http://book.opensourceproject.org.cn/kernel/kernel3rd/opensource/0596005652/understandlk-chp-6-sect-2.html )
time_init	實作在檔案arch/arm/kernel/time.c中, 會初始化平台上的System Timer,以Tegra為例,會依據每個平台的實作,透過machine_desc->timer進入函式tegra_init_timer (in arch/arm/mach-tegra/timer.c)
local_irq_enable	在這會透過CPSR確認IRQ是否有被提前Enable,與指令"cpsie i” 開啟Local IRQ. (可以參考arch/arm/include/asm/irqflags.h中arch_local_irq_enable的實作.) CPSIE i (Enable irq) CPSID i (Disable irq) CPSIE f (Enable fiq) CPSID f (Disable fiq)
console_init	實作在檔案drivers/tty/tty_io.c中, Initialize the console device early.
setup_per_cpu_pageset	實作在檔案mm/page_alloc.c中, 在這會幫每個處理器配置Page Table. 原本只有啟動時,在Bootstrap處理器TLB針對Linux Kernel的Page 1MB Section配置. (Page Table的配置會抽空進一步說明)
sched_clock_init	實作在檔案kernel/sched_clock.c中, 初始化每個處理器的Schedule Clock Data,並支援sched_clock傳回系統開機到目前經過的nanoseconds時間值.(透過 jiffies (每一次Timer-Interrupr加一),與 HZ(HZ為每一秒的Timer Interrupt次數 (以Tegra而言定義為CONFIG_HZ=100))計算.)
calibrate_delay	實作在檔案init/calibrate.c中, 這函式就是著名的BogoMIPS(Bogo Millions Instructions Per Second)計算函式,會產生loops_per_jiffy值,並用以算出最後的BogoMIPS. 開機過程會顯示 ”Calibrating delay loop (skipped), value calculated using timer frequency.. AAA. BB BogoMIPS (lpj=CCCCC)”. 可以透過這網頁http://www.clifton.nl/bogo-list.html 知道不同處理器所對應的BogoMIPS.
pidmap_init	實作在檔案kernel/pid.c中, Generic pidhash and scalable, time-bounded PID allocator. 會參考處理器的數量,訂定PID數量範圍,並配置PID Map記憶體.
anon_vma_init	實作在檔案mm/rmap.c中, 初始化Anonymous VMA(Virtual Memory Area)機制. 簡要來說記憶體的Page Mapping可以分為 1,Anonymous Page: 只要不是屬於以檔案內容進行的記憶體Mapping,就屬此類.例如: “mmap(NULL, Size, PROT_READ|PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);” 2,File-Mapped Page: 以檔案為記憶體Mapping的分頁. 例如: “mmap(NULL, Size, PROT_READ|PROT_WRITE, MAP_PRIVATE, vFile, 0);” 也可以參考這網頁的說明 http://linuxkernelpanic.blogspot.com/2010/05/while-getting-in-touch-recently-with-ex.html
cred_init	實作在檔案kernel/cred.c中, 初始化Credentials,這是在Linux Kernel中用來管控權限的機制,包括在User Mode的Task要去執行系統呼叫(System Call)時,Task Capability的安全稽核機制,會呼叫current_cred取得目前Task的Credentials,並確認該Task是否具備可以執行該系統呼叫的權限,確保系統的安全性. 防止沒有經過授權的使用者Task,去進行屬於特權等級使用者的動作.
fork_init	實作在檔案kernel/fork.c中, 初始化fork機制,會參考totalram_pages決定可以fork的行程數量max_threads.(最低不小於20個),
proc_caches_init	實作在檔案kernel/fork.c中, 配置行程Process所需的Slab Cache,包括sighand/signal/files/fs/mm_struct/vm_area_struct cache,並執行函式mmap_init
buffer_init	實作在檔案fs/buffer.c中, 初始化FileSystem Buffer,會呼叫nr_free_buffer_pages取得目前系統Free的空間值,並定義最大不超過該值的10%,作為FileSystem Buffer的空間.
vfs_caches_init	實作在檔案fs/dcache.c中, 初始化VFS的 dcache跟inode Cache.
signals_init	實作在檔案kernel/signal.c中, 初始化Signal Queue
rootfs populating might need page-writeback
page_writeback_init	實作在檔案mm/page-writeback.c中, 用來初始化檔案系統中用來作為Cache的記憶體Writeback回儲存媒體的機制,會產生pdflush Kernel Thread執行Dirty Page Writeback的流程. 一般來說,有兩種情況會觸發pdflush流程 1,當系統Free Memory過低,進行Shrink Page時,可透過pdflush回寫到磁碟釋放出記憶體. 2,當Dirty Page數量達到一個值或是相對比例時. 參考Linux Kernel 2.6.39文件Documentation/sysctl/vm.txt,透過檔案/proc/sys/vm/nr_pdflush_threads可知道目前啟動的pdflush daemon數量(這要視系統Runtime Dirty Pages的情況而定). 此外,透過設定/proc/sys/vm/dirty_background_ratio (以相對System Memory的百分比)或/proc/sys/vm/dirty_background_bytes (以Dirty Memory數量)二則一,可設定觸發pdflush daemon進行Page Writeback的條件. (可以參考網頁http://www.westnet.com/~gsmith/content/linux-pdflush.htm或http://www.debian.org.tw/index.php/PageCache_writeback)
proc_root_init	實作在檔案fs/proc/root.c中, 初始化 proc 檔案系統.
check_bugs	實作在檔案arch/arm/mm/fault-armv.c中, check_bugs 會被define為 “check_writebuffer_bugs”,用以Check處理器平台Bugs的狀況. 而在筆者所編譯的ARM環境中, check_writebuffer_bugs會透過vmap(實作在mm/vmalloc.c中),把同一個屬性為Bufferable的Page對應到兩個Linux Kernel虛擬記憶體中,再透過設計好 check_writebuffer函式,對剛才得到的兩個虛擬記憶體位置寫入資料,並在每個動作後,加入ARM DSB(Data Synchronization Barrier)指令,透過 “dsb sy” 同步Cache, Branch Predictor 與TLB內容. 如果說,兩個對應到同一個實體記憶體的Bufferable虛擬記憶體寫入動作,最後內容不是一致的,這個ARM平台就可能有Write Buffer Coherency的Bug存在.
rest_init	實作在檔案init/main.c中, 這是start_kernel最後的函式. 有關這函式與後續kernel_init的介紹,會放在下一次的文章中.

結語

Linux Kernel是一個經過長期累積的知識庫,並且由於眾人的幫助,Linux
Kernel也支援最新的ARMv7指令集,並支援處理器Bugs確認的機制,對於一般開發者而言,只要善用Linux
Kernel所提供的成果,便可以在最快的時間內,進行核心的移植與系統的調教.

隨著多核心SMP架構在Intel與ARM平台的普及,我們可以看到Linux對於SMP
多核心原生架構的支援也非常的充分,相關的核心模塊都會考慮到多核心並取得處理器的數量,做出對應資料結構與行為的因應,對於開發者在新架構的適應來說,可以很幸福的基於這些成果來發展.
尤其,隨著Android的普及,以及在Android 3.0
Framework對於多核心的初步支援,我們可以預期,未來考量到省電與效能的平衡,多核心肯定會是消費性產品的主流,對有至於從事消費性產品開發的人而言,
這部份的知識建立,也是當務之急.