|
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的方式進行編譯. 在選擇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) 有關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,<lext.1135> ("static const unsigned short lext" in lib/zlib_inflate/inftrees.c) b,<lbase.1134> ("static const unsigned short lbase" in lib/zlib_inflate/inftrees.c) c,<dext.1137> ("static const unsigned short dext" in lib/zlib_inflate/inftrees.c) d,<dbase.1136> ("static const unsigned short dbase" in lib/zlib_inflate/inftrees.c) e,<lenfix.1621> ("static const code lenfix" in lib/zlib_inflate/inffixed.h) f,<distfix.1622> ("static const code distfix" in lib/zlib_inflate/inffixed.h) ….etc 2,會把壓縮後的Linux Kernel piggy.gzip 放在.text節區中Symbol <input_data> 到 <input_data_end>之間,以筆者驗證的環境來說,大約介於實體記憶體 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 <start>: 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 <not_angel> 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 /* Initialise the page tables, turning on the cacheable and bufferable * bits for the RAM area only. */ 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> /* If ever we are running from Flash, then we surely want the cache * to be enabled also for our execution instance… We map 2MB of it * so there is no map overlap problem for up to 1 MB compressed kernel. * If the execution is in RAM then we would only be duplicating the above. */
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到目標位址 /* * The C runtime environment should now be setup sufficiently. * Set up some pointers, and start decompressing. * r4 = kernel execution address * r7 = architecture ID * r8 = atags pointer */ 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 <stext>: 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 /*r1 = machine no, r2 = atags, * r8 = phys_offset, r9 = cpuid, r10 = procinfo */ 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 <stext+0×40> //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, <Rd>, 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 <v7_flush_dcache_all> 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 <start_kernel> //正式進入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)作為初始化的處理器.
| | 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() |
[tr][/tr]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中,
| 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中,
|
timekeeping_init | 實作在檔案kernel/time/timekeeping.c中,
初始化Generic Timekeeping Subsystem,用以更新系統的流逝時間,會更新xtime,wall_to_monotonic與total_sleep_time,並負責較整誤差(包括從系統Suspend到Resume的時間差),支援getnstimeofday,do_gettimeofday,do_settimeofday…etc函式.
|
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.
| 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);” 也可以參考這網頁的說明
| 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的條件.
| 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對於多核心的初步支援,我們可以預期,未來考量到省電與效能的平衡,多核心肯定會是消費性產品的主流,對有至於從事消費性產品開發的人而言, 這部份的知識建立,也是當務之急.
|
[複製鏈接]
IP卡
發表於 2013-12-6 19:04:39
提升卡
置頂卡(一天)
沉默卡
喧囂卡
變色卡
顯身卡