我分析的是
陸續(xù)總結(jié)成文字，今天是第一篇：
內(nèi)核一般是由bootloader來引導(dǎo)的，通過bootloader啟動(dòng)內(nèi)核一般要傳遞三個(gè)參數(shù)，
第一個(gè)參數(shù)放在寄存器0中，一般都為0，r0 = 0；
第二個(gè)參數(shù)放在寄存器1中，是機(jī)器類型id，r1 = Machine Type Number；
第三個(gè)參數(shù)放在寄存器2中，是啟動(dòng)參數(shù)標(biāo)記列表在ram中的起始基地址；
bootloader首先要將ramdisk（如果有）和內(nèi)核拷貝到ram當(dāng)中，然后可以通過c語(yǔ)言的模式啟動(dòng)內(nèi)核：
void (*startkernel)(int zero, int arch, unsigned int params_addr) = (void(*)(int, int, unsigned int))KERNEL_RAM_BASE;
startkernel(0, ARCH_NUMBER, (unsigned int)kernel_params_start);
其中KERNEL_RAM_BASE為內(nèi)核在ram中啟動(dòng)的地址，ARCH_NUMBER是Machine Type Number，kernel_params_start是參數(shù)在ram的偏移地址。
這時(shí)候就將全力交給了內(nèi)核。
內(nèi)核編譯鏈接過程是依靠vmlinux.lds文件，以arm為例vmlinux.lds文件位于kernel/arch/arm/vmlinux.lds，
但是該文件是由vmlinux-armv.lds.in生成的，根據(jù)編譯選項(xiàng)的不同源文件還可以是vmlinux-armo.lds.in，
vmlinux-armv-xip.lds.in。
vmlinux-armv.lds的生成過程在kernel/arch/arm/Makefile中
LDSCRIPT = arch/arm/vmlinux-armv.lds.in
arch/arm/vmlinux.lds: arch/arm/Makefile $(LDSCRIPT) \
$(wildcard include/config/cpu/32.h) \
$(wildcard include/config/cpu/26.h) \
$(wildcard include/config/arch/*.h)
@echo ' Generating $@'
@sed 's/TEXTADDR/$(TEXTADDR)/;s/DATAADDR/$(DATAADDR)/' $(LDSCRIPT) >$@
vmlinux-armv.lds.in文件的內(nèi)容：
OUTPUT_ARCH(arm)
ENTRY(stext)
SECTIONS
{
. = TEXTADDR;
.init : { /* Init code and data */
_stext = .;
__init_begin = .;
*(.text.init)
__proc_info_begin = .;
*(.proc.info)
__proc_info_end = .;
__arch_info_begin = .;
*(.arch.info)
__arch_info_end = .;
__tagtable_begin = .;
*(.taglist)
__tagtable_end = .;
*(.data.init)
. = ALIGN(16);
__setup_start = .;
*(.setup.init)
__setup_end = .;
__initcall_start = .;
*(.initcall.init)
__initcall_end = .;
. = ALIGN(4096);
__init_end = .;
}
其中TEXTADDR就是內(nèi)核啟動(dòng)的虛擬地址，定義在kernel/arch/arm/Makefile中：
ifeq ($(CONFIG_CPU_32),y)
PROCESSOR = armv
TEXTADDR = 0xC0008000
LDSCRIPT = arch/arm/vmlinux-armv.lds.in
endif
需要注意的是這里是虛擬地址而不是物理地址。
一般情況下都在生成vmlinux后，再對(duì)內(nèi)核進(jìn)行壓縮成為zImage，壓縮的目錄是kernel/arch/arm/boot。
下載到flash中的是壓縮后的zImage文件，zImage是由壓縮后的vmlinux和解壓縮程序組成，如下圖所示：
|-----------------|\ |-----------------|
| | \ | |
| | \ | decompress code |
| vmlinux | \ |-----------------| zImage
| | \| |
| | | |
| | | |
| | | |
| | /|-----------------|
| | /
| | /
| | /
|-----------------|/
zImage鏈接腳本也叫做vmlinux.lds，位于kernel/arch/arm/boot/compressed。
是由同一目錄下的vmlinux.lds.in文件生成的，內(nèi)容如下：
OUTPUT_ARCH(arm)
ENTRY(_start)
SECTIONS
{
. = LOAD_ADDR;
_load_addr = .;
. = TEXT_START;
_text = .;
.text : {
_start = .;
其中LOAD_ADDR就是zImage中解壓縮代碼的ram偏移地址，TEXT_START是內(nèi)核ram啟動(dòng)的偏移地址，這個(gè)地址是物理地址。
在kernel/arch/arm/boot/Makefile文件中定義了：
ZTEXTADDR =0
ZRELADDR = 0xa0008000
ZTEXTADDR就是解壓縮代碼的ram偏移地址，ZRELADDR是內(nèi)核ram啟動(dòng)的偏移地址，這里看到指定ZTEXTADDR的地址為0，
明顯是不正確的，因?yàn)槲业钠脚_(tái)上的ram起始地址是0xa0000000，在Makefile文件中看到了對(duì)該地址設(shè)置的幾行注釋：
# We now have a PIC decompressor implementation. Decompressors running
# from RAM should not define ZTEXTADDR. Decompressors running directly
# from ROM or Flash must define ZTEXTADDR (preferably via the config)
他的意識(shí)是如果是在ram中進(jìn)行解壓縮時(shí)，不用指定它在ram中的運(yùn)行地址，如果是在flash中就必須指定他的地址。所以
這里將ZTEXTADDR指定為0，也就是沒有真正指定地址。
在kernel/arch/arm/boot/compressed/Makefile文件有一行腳本：
SEDFLAGS = s/TEXT_START/$(ZTEXTADDR)/;s/LOAD_ADDR/$(ZRELADDR)/;s/BSS_START/$(ZBSSADDR)/
使得TEXT_START = ZTEXTADDR，LOAD_ADDR = ZRELADDR。
這樣vmlinux.lds的生成過程如下：
vmlinux.lds: vmlinux.lds.in Makefile $(TOPDIR)/arch/$(ARCH)/boot/Makefile $(TOPDIR)/.config
@sed "$(SEDFLAGS)" < vmlinux.lds.in > $@
以上就是我對(duì)內(nèi)核啟動(dòng)地址的分析，總結(jié)一下內(nèi)核啟動(dòng)地址的設(shè)置：
1、設(shè)置kernel/arch/arm/Makefile文件中的
TEXTADDR = 0xC0008000
內(nèi)核啟動(dòng)的虛擬地址
2、設(shè)置kernel/arch/arm/boot/Makefile文件中的
ZRELADDR = 0xa0008000
內(nèi)核啟動(dòng)的物理地址
如果需要從flash中啟動(dòng)還需要設(shè)置
ZTEXTADDR地址。
內(nèi)核壓縮和解壓縮代碼都在目錄kernel/arch/arm/boot/compressed，
編譯完成后將產(chǎn)生vmlinux、head.o、misc.o、head-xscale.o、piggy.o這幾個(gè)文件，
head.o是內(nèi)核的頭部文件，負(fù)責(zé)初始設(shè)置；
misc.o將主要負(fù)責(zé)內(nèi)核的解壓工作，它在head.o之后；
head-xscale.o文件主要針對(duì)Xscale的初始化，將在鏈接時(shí)與head.o合并；
piggy.o是一個(gè)中間文件，其實(shí)是一個(gè)壓縮的內(nèi)核(kernel/vmlinux)，只不過沒有和初始化文件及解壓文件鏈接而已；
vmlinux是(沒有－－lw：zImage是壓縮過的內(nèi)核)壓縮過的內(nèi)核，就是由piggy.o、head.o、misc.o、head-xscale.o組成的。
在BootLoader完成系統(tǒng)的引導(dǎo)以后并將Linux內(nèi)核調(diào)入內(nèi)存之后，調(diào)用bootLinux()，
這個(gè)函數(shù)將跳轉(zhuǎn)到kernel的起始位置。如果kernel沒有壓縮，就可以啟動(dòng)了。
如果kernel壓縮過，則要進(jìn)行解壓，在壓縮過的kernel頭部有解壓程序。
壓縮過得kernel入口第一個(gè)文件源碼位置在arch/arm/boot/compressed/head.S。
它將調(diào)用函數(shù)decompress_kernel()，這個(gè)函數(shù)在文件arch/arm/boot/compressed/misc.c中，
decompress_kernel()又調(diào)用proc_decomp_setup(),arch_decomp_setup()進(jìn)行設(shè)置，
然后使用在打印出信息“Uncompressing Linux...”后，調(diào)用gunzip()。將內(nèi)核放于指定的位置。
以下分析head.S文件：
(1)對(duì)于各種Arm CPU的DEBUG輸出設(shè)定，通過定義宏來統(tǒng)一操作。
(2)設(shè)置kernel開始和結(jié)束地址，保存architecture ID。
(3)如果在ARM2以上的CPU中，用的是普通用戶模式，則升到超級(jí)用戶模式，然后關(guān)中斷。
(4)分析LC0結(jié)構(gòu)delta offset，判斷是否需要重載內(nèi)核地址(r0存入偏移量，判斷r0是否為零)。
這里是否需要重載內(nèi)核地址，我以為主要分析arch/arm/boot/Makefile、arch/arm/boot/compressed/Makefile
和arch/arm/boot/compressed/vmlinux.lds.in三個(gè)文件，主要看vmlinux.lds.in鏈接文件的主要段的位置，
LOAD_ADDR(_load_addr)＝0xA0008000，而對(duì)于TEXT_START(_text、_start)的位置只設(shè)為0，BSS_START(__bss_start)＝ALIGN(4)。
對(duì)于這樣的結(jié)果依賴于，對(duì)內(nèi)核解壓的運(yùn)行方式，也就是說，內(nèi)核解壓前是在內(nèi)存(RAM)中還是在FLASH上，
因?yàn)檫@里，我們的BOOTLOADER將壓縮內(nèi)核(zImage)移到了RAM的0xA0008000位置，我們的壓縮內(nèi)核是在內(nèi)存(RAM)從0xA0008000地址開始順序排列，
因此我們的r0獲得的偏移量是載入地址(0xA0008000)。接下來的工作是要把內(nèi)核鏡像的相對(duì)地址轉(zhuǎn)化為內(nèi)存的物理地址，即重載內(nèi)核地址。
(5)需要重載內(nèi)核地址，將r0的偏移量加到BSS region和GOT table中。
(6)清空bss堆棧空間r2－r3。
(7)建立C程序運(yùn)行需要的緩存，并賦于64K的?？臻g。
(8)這時(shí)r2是緩存的結(jié)束地址，r4是kernel的最后執(zhí)行地址，r5是kernel境象文件的開始地址。檢查是否地址有沖突。
將r5等于r2，使decompress后的kernel地址就在64K的棧之后。
(9)調(diào)用文件misc.c的函數(shù)decompress_kernel()，解壓內(nèi)核于緩存結(jié)束的地方(r2地址之后)。此時(shí)各寄存器值有如下變化：
r0為解壓后kernel的大小
r4為kernel執(zhí)行時(shí)的地址
r5為解壓后kernel的起始地址
r6為CPU類型值(processor ID)
r7為系統(tǒng)類型值(architecture ID)
(10)將reloc_start代碼拷貝之kernel之后(r5+r0之后)，首先清除緩存，而后執(zhí)行reloc_start。
(11)reloc_start將r5開始的kernel重載于r4地址處。
(12)清除cache內(nèi)容，關(guān)閉cache，將r7中architecture ID賦于r1，執(zhí)行r4開始的kernel代碼。
下面簡(jiǎn)單介紹一下解壓縮過程，也就是函數(shù)decompress_kernel實(shí)現(xiàn)的功能：
解壓縮代碼位于kernel/lib/inflate.c，inflate.c是從gzip源程序中分離出來的。包含了一些對(duì)全局?jǐn)?shù)據(jù)的直接引用。
在使用時(shí)需要直接嵌入到代碼中。gzip壓縮文件時(shí)總是在前32K字節(jié)的范圍內(nèi)尋找重復(fù)的字符串進(jìn)行編碼，
在解壓時(shí)需要一個(gè)至少為32K字節(jié)的解壓緩沖區(qū)，它定義為window[WSIZE]。inflate.c使用get_byte()讀取輸入文件，
它被定義成宏來提高效率。輸入緩沖區(qū)指針必須定義為inptr，inflate.c中對(duì)之有減量操作。inflate.c調(diào)用flush_window()
來輸出window緩沖區(qū)中的解壓出的字節(jié)串，每次輸出長(zhǎng)度用outcnt變量表示。在flush_window()中，還必
須對(duì)輸出字節(jié)串計(jì)算CRC并且刷新crc變量。在調(diào)用gunzip()開始解壓之前，調(diào)用makecrc()初始化CRC計(jì)算表。
最后gunzip()返回0表示解壓成功。
我們?cè)趦?nèi)核啟動(dòng)的開始都會(huì)看到這樣的輸出：
Uncompressing Linux...done, booting the kernel.
這也是由decompress_kernel函數(shù)內(nèi)部輸出的，它調(diào)用了puts()輸出字符串，
puts是在kernel/include/asm-arm/arch-pxa/uncompress.h中實(shí)現(xiàn)的。
執(zhí)行完解壓過程，再返回到head.S中，啟動(dòng)內(nèi)核：
call_kernel: bl cache_clean_flush
bl cache_off
mov r0, #0
mov r1, r7 @ restore architecture number
mov pc, r4 @ call kernel
下面就開始真正的內(nèi)核了。
在網(wǎng)上參考很多高手的文章，又加入了自己的一點(diǎn)兒內(nèi)容，整理了一下，里面還有很多不明白的地方，而且也會(huì)有理解錯(cuò)誤的地方，望高手指點(diǎn)，自己也會(huì)不斷進(jìn)行修改
當(dāng)進(jìn)入linux內(nèi)核后,arch/arm/kernel/head-armv.S是內(nèi)核最先執(zhí)行的一個(gè)文件，包括從內(nèi)核入口ENTRY(stext)到
start_kernel之間的初始化代碼，下面以我所是用的平臺(tái)intel pxa270為例，說明一下他的匯編代碼：
1 .section ".text.init",#alloc,#execinstr
2 .type stext, #function
/* 內(nèi)核入口點(diǎn) */
3 ENTRY(stext)
4 mov r12, r0
/* 程序狀態(tài)，禁止FIQ、IRQ，設(shè)定SVC模式 */
5 mov r0, #F_BIT | I_BIT | MODE_SVC @ make sure svc mode
6 msr cpsr_c, r0 @ and all irqs disabled
/* 判斷CPU類型，查找運(yùn)行的CPU ID值與Linux編譯支持的ID值是否支持 */
7 bl __lookup_processor_type
/* 判斷如果r10的值為0，則表示函數(shù)執(zhí)行錯(cuò)誤，跳轉(zhuǎn)到出錯(cuò)處理，*/
/* 出錯(cuò)處理函數(shù)__error的實(shí)現(xiàn)代碼定義在debug-armv.S中，這里就不再作過多介紹了 */
8 teq r10, #0 @ invalid processor?
9 moveq r0, #'p' @ yes, error 'p'
10 beq __error
/* 判斷體系類型，查看R1寄存器的Architecture Type值是否支持 */
11 bl __lookup_architecture_type
/* 判斷如果r7的值為0，則表示函數(shù)執(zhí)行錯(cuò)誤，跳轉(zhuǎn)到出錯(cuò)處理，*/
12 teq r7, #0 @ invalid architecture?
13 moveq r0, #'a' @ yes, error 'a'
14 beq __error
/* 創(chuàng)建核心頁(yè)表 */
15 bl __create_page_tables
16 adr lr, __ret @ return address
17 add pc, r10, #12 @ initialise processor
@ (return control reg)
第5行，準(zhǔn)備進(jìn)入SVC工作模式，同時(shí)關(guān)閉中斷(I_BIT)和快速中斷(F_BIT)
第7行，查看處理器類型，主要是為了得到處理器的ID以及頁(yè)表的flags。
第11行，查看一些體系結(jié)構(gòu)的信息。
第15行，建立頁(yè)表。
第17行，跳轉(zhuǎn)到處理器的初始化函數(shù)，其函數(shù)地址是從__lookup_processor_type中得到的，
需要注意的是第16行，當(dāng)處理器初始化完成后，會(huì)直接跳轉(zhuǎn)到__ret去執(zhí)行，
這是由于初始化函數(shù)最后的語(yǔ)句是mov pc, lr。
前面一篇文章，簡(jiǎn)單介紹了內(nèi)核啟動(dòng)的匯編主流程，這篇介紹其中調(diào)用的匯編子函數(shù)__lookup_processor_type
函數(shù)__lookup_processor_type介紹：
內(nèi)核中使用了一個(gè)結(jié)構(gòu)struct proc_info_list，用來記錄處理器相關(guān)的信息，該結(jié)構(gòu)定義在
kernel/include/asm-arm/procinfo.h頭文件中。
/*
* Note! struct processor is always defined if we're
* using MULTI_CPU, otherwise this entry is unused,
* but still exists.
*
* NOTE! The following structure is defined by assembly
* language, NOT C code. For more information, check:
* arch/arm/mm/proc-*.S and arch/arm/kernel/head-armv.S
*/
struct proc_info_list {
unsigned int cpu_val;
unsigned int cpu_mask;
unsigned long __cpu_mmu_flags; /* used by head-armv.S */
unsigned long __cpu_flush; /* used by head-armv.S */
const char *arch_name;
const char *elf_name;
unsigned int elf_hwcap;
struct proc_info_item *info;
struct processor *proc;
};
在arch/arm/mm/proc-xscale.S文件中定義了所有和xscale有關(guān)的proc_info_list，我們使用的pxa270定義如下：
.section ".proc.info", #alloc, #execinstr
.type __bva0_proc_info,#object
__bva0_proc_info:
.long 0x69054110 @ Bulverde A0: 0x69054110, A1 : 0x69054111.
.long 0xfffffff0 @ and this is the CPU id mask.
#if CACHE_WRITE_THROUGH
.long 0x
#else
.long 0x
#endif
b __xscale_setup
.long cpu_arch_name
.long cpu_elf_name
.long HWCAP_SWP|HWCAP_HALF|HWCAP_THUMB|HWCAP_FAST_MULT|HWCAP_EDSP|HWCAP_XSCALE
.long cpu_bva0_info
.long xscale_processor_functions
.size __bva0_proc_info, . - __bva0_proc_info
由于.section指示符，上面定義的__bva0_proc_info信息在編譯的時(shí)候被放到了.proc.info段中，這是由linux的
鏈接腳本文件vmlinux.lds指定的，參考如下：
SECTIONS
{
. = 0xC0008000;
.init : { /* Init code and data */
_stext = .;
__init_begin = .;
*(.text.init)
__proc_info_begin = .;
*(.proc.info)
__proc_info_end = .;
這里的符號(hào)__proc_info_begin指向.proc.info的起始地址，而符號(hào)__proc_info_end指向.proc.info的結(jié)束地址。
后面就會(huì)引用這兩個(gè)符號(hào)，來指向.proc.info這個(gè)段。
下面來來看看函數(shù)的源代碼，為了分析方便將函數(shù)按行進(jìn)行編號(hào)，其中17-18行就是前面提到的對(duì).proc.info的引用，
第2行將17行的地址放到寄存器r5中，adr是小范圍的地址讀取偽指令。第3行將r5所指向的數(shù)據(jù)區(qū)的數(shù)據(jù)讀出到r7，r9
r10，執(zhí)行結(jié)果是r7=__proc_info_end，r9=__proc_info_begin，r10=第19行的地址，第4-6行的結(jié)果應(yīng)該是r10指向
__proc_info_begin的地址，第7行讀取cpu的id，這是一個(gè)協(xié)處理器指令，將processor ID存儲(chǔ)在r9中，第8行將r10指向
的__bva0_proc_info開始的數(shù)據(jù)讀出放到寄存器r5，r6，r8，結(jié)果r5=0x69054110(cpu_val)，r6=0xfffffff0(cpu_mask)，
r8=0x00000c0e(__cpu_mmu_flags)，第9-10行將讀出的id和結(jié)構(gòu)中的id進(jìn)行比較，如果id相同則返回，返回時(shí)r9存儲(chǔ)
processor ID，如果id不匹配，則將指針r10增加36(proc_info_list結(jié)構(gòu)的長(zhǎng)度)，如果r10小于r7指定的地址，也就是
__proc_info_end，則繼續(xù)循環(huán)比較下一個(gè)proc_info_list中的id，如第11-14行的代碼，如果查找到__proc_info_end
仍未找到一個(gè)匹配的id，則將r10清零并返回，如15-16行，也就是說如果函數(shù)執(zhí)行成功則r10指向匹配的proc_info_list
結(jié)構(gòu)地址，如果函數(shù)返回錯(cuò)誤則r10為0。
/*
* Read processor ID register (CP#15, CR0), and look up in the linker-built
* supported processor list. Note that we can't use the absolute addresses
* for the __proc_info lists since we aren't running with the MMU on
* (and therefore, we are not in the correct address space). We have to
* calculate the offset.
*
* Returns:
* r5, r6, r7 corrupted
* r8 = page table flags
* r9 = processor ID
* r10 = pointer to processor structure
*/
1 __lookup_processor_type:
2 adr r5,
3 ldmia r5, {r7, r9, r10}
4 sub r5, r5, r10 @ convert addresses
5 add r7, r7, r5 @ to our address space
6 add r10, r9, r5
7 mrc p15, 0, r9, c0, c0 @ get processor id
8 1: ldmia r10, {r5, r6, r8} @ value, mask, mmuflags
9 and r6, r6, r9 @ mask wanted bits
10 teq r5, r6
11 moveq pc, lr
12 add r10, r10, #36 @ sizeof(proc_info_list)
13 cmp r10, r7
14 blt 1b
15 mov r10, #0 @ unknown processor
16 mov pc, lr
/*
* Look in include/asm-arm/procinfo.h and arch/arm/kernel/arch.[ch] for
* more information about the __proc_info and __arch_info structures.
*/
17 2: .long __proc_info_end
18 .long __proc_info_begin
19 .long 2b
20 .long __arch_info_begin
21 .long __arch_info_end
前一篇介紹了匯編函數(shù)__lookup_processor_type，這一篇介紹__lookup_architecture_type函數(shù)
函數(shù)__lookup_architecture_type介紹：
每個(gè)機(jī)器(一般指的是某一個(gè)電路板)都有自己的特殊結(jié)構(gòu)，如物理內(nèi)存地址，物理I/O地址，顯存起始地址等等，
這個(gè)結(jié)構(gòu)為struct machine_desc，定義在asm-arm/mach/arch.h中:
struct machine_desc {
/*
* Note! The first four elements are used
* by assembler code in head-armv.S
*/
unsigned intnr;/* architecture number*/
unsigned intphys_ram;/* start of physical ram */
unsigned intphys_io;/* start of physical io*/
unsigned intio_pg_offst;/* byte offset for io page table entry*/
const char*name;/* architecture name*/
unsigned intparam_offset;/* parameter page*/
unsigned intvideo_start;/* start of video RAM*/
unsigned intvideo_end;/* end of video RAM*/
unsigned intreserve_lp0 :1;/* never has lp0*/,
unsigned intreserve_lp1 :1;/* never has lp1*/
unsigned intreserve_lp2 :1;/* never has lp2*/
unsigned intsoft_reboot :1;/* soft reboot*/
void(*fixup)(struct machine_desc *,
struct param_struct *, char **,
struct meminfo *);
void(*map_io)(void);/* IO mapping function*/
void(*init_irq)(void);
};
這個(gè)結(jié)構(gòu)一般都定義在(以arm平臺(tái)為例)kernel\arch\arm\mach-xxx\xxx.c中，是用宏來定義的，以mainstone的開發(fā)板為例：
定義在kernel\arch\arm\mach-pxa\mainstone.c文件中，如下所示：
MACHINE_START(MAINSTONE, "Intel DBBVA0 Development Platform")
MAINTAINER("MontaVista Software Inc.")
BOOT_MEM(0xa0000000, 0x40000000, io_p2v(0x40000000))
FIXUP(fixup_mainstone)
MAPIO(mainstone_map_io)
INITIRQ(mainstone_init_irq)
MACHINE_END
這些宏也定義在kernel/include/asm-arm/mach/arch.h中，以MACHINE_START為例：
#define MACHINE_START(_type,_name) \
const struct machine_desc __mach_desc_##_type \
__attribute__((__section__(".arch.info"))) = { \
.nr = MACH_TYPE_##_type, \
.name = _name,
展開之后結(jié)構(gòu)的是：
__mach_desc_MAINSTONE = {
.nr = MACH_TYPE_MAINSTIONE,
.name = "Intel DBBVA0 Development Platform",
中間的1行__attribute__((__section__(".arch.info"))) = {說明將這個(gè)結(jié)構(gòu)放到指定的段.arch.info中，這和前面的
.proc.info是一個(gè)意思，__attribute__((__section__的含義參考GNU手冊(cè)。后面的宏都是類似的含義，這里就不再一一
介紹。下面開始說明源碼：
第1行實(shí)現(xiàn)r4指向2b的地址，2b如__lookup_processor_type介紹的第19行，將machine_desc結(jié)構(gòu)中的數(shù)據(jù)存放到r2, r3, r5, r6, r7。
讀取__mach_desc_MAINSTONE結(jié)構(gòu)中的nr參數(shù)到r5中，如第7行，比較r5和r1中的機(jī)器編號(hào)是否相同，如第8行，
r5中的nr值MACH_TYPE_MAINSTONE定義在kernel\include\asm-arm\mach-types.h中：
#define MACH_TYPE_MAINSTONE 303
r1中的值是由bootloader傳遞過來的，這在<<linux啟動(dòng)流程分析(1)---bootloader啟動(dòng)內(nèi)核過程>>中有說明，
如果機(jī)器編號(hào)相同，跳到15行執(zhí)行，r5=intphys_ram，r6=intphys_io，r7=intio_pg_offst，并返回。如果
不同則將地址指針增加，在跳到7行繼續(xù)查找，如10--12行的代碼，如果檢索完所有的machine_desc仍然沒
有找到則將r7清零并返回。
/*
* Lookup machine architecture in the linker-build list of architectures.
* Note that we can't use the absolute addresses for the __arch_info
* lists since we aren't running with the MMU on (and therefore, we are
* not in the correct address space). We have to calculate the offset.
*
* r1 = machine architecture number
* Returns:
* r2, r3, r4 corrupted
* r5 = physical start address of RAM
* r6 = physical address of IO
* r7 = byte offset into page tables for IO
*/
1 __lookup_architecture_type:
2 adr r4, 2b
3 ldmia r4, {r2, r3, r5, r6, r7} @ throw away r2, r3
4 sub r5, r4, r5 @ convert addresses
5 add r4, r6, r5 @ to our address space
6 add r7, r7, r5
7 1: ldr r5, [r4] @ get machine type
8 teq r5, r1
9 beq
10 add r4, r4, #SIZEOF_MACHINE_DESC
11 cmp r4, r7
12 blt 1b
13 mov r7, #0 @ unknown architecture
14 mov pc, lr
15 2: ldmib r4, {r5, r6, r7} @ found, get results
16 mov pc, lr
函數(shù)__create_page_tables介紹：
假設(shè)內(nèi)核起始物理地址是0xA0008000，虛擬地址是0xC0008000，下面的代碼是建立內(nèi)核起始處4MB空間的映射，
采用了一級(jí)映射方式，即段式(section)映射方式，每段映射范圍為1MB空間。于是需要建立4個(gè)表項(xiàng)，實(shí)現(xiàn)：
虛擬地址0xC0000000~0xC0300000，映射到物理地址0xA0000000~0xA0300000。
.macro pgtbl, reg, rambase
adr \reg, stext
sub \reg, \reg, #0x4000
.endm
.macro krnladr, rd, pgtable, rambase
bic \rd, \pgtable, #0x000ff000
.endm
/*
* Setup the initial page tables. We only setup the barest
* amount which are required to get the kernel running, which
* generally means mapping in the kernel code.
*
* We only map in 4MB of RAM, which should be sufficient in
* all cases.
*
* r5 = physical address of start of RAM
* r6 = physical IO address
* r7 = byte offset into page tables for IO
* r8 = page table flags
*/
1 __create_page_tables:
/* r5中存放著內(nèi)核啟動(dòng)的地址0xa0008000 */
/* pgtbl將啟動(dòng)地址減去0x4000，存放到r4=0xa0004000 */
2 pgtbl r4, r5 @ page table address
/*
* Clear the 16K level 1 swapper page table
*/
/* r0 = 0xa0004000 */
3 mov r0, r4
4 mov r3, #0
/* r2 = 0xa0008000 */
5 add r2, r0, #0x4000
/* 清除16k空間，addr 0xa0004000: 0xa0008000 is page table, total 16K*/
6 1: str r3, [r0], #4
7 str r3, [r0], #4
8 str r3, [r0], #4
9 str r3, [r0], #4
10 teq r0, r2
11 bne 1b
/*
* Create identity mapping for first MB of kernel to
* cater for the MMU enable. This identity mapping
* will be removed by paging_init()
*/
/* r2 = 0xa0040000 & 0x000ff000 = 0xa00000000 */
12 krnladr r2, r4, r5 @ start of kernel
/* r3 = 0xa0000000 + 0x
/* r8 = 0x
13 add r3, r8, r2 @ flags + kernel base
/* value r3=0xa
/* r4 = 0xa0006800 */
14 str r3, [r4, r2, lsr #18] @ identity mapping
/*
* Now setup the pagetables for our kernel direct
* mapped region. We round TEXTADDR down to the
* nearest megabyte boundary.
*/
/* TEXTADDR= 0xC0008000 有關(guān)TEXTADDR參考<<linux啟動(dòng)流程分析(2)---內(nèi)核啟動(dòng)地址的確定>> */
/* start of kernel, r0=0xa0007000 */
15 add r0, r4, #(TEXTADDR & 0xff000000) >> 18 @ start of kernel
/* r2=0xa
16 bic r2, r3, #0x
/* 0xa
17 str r2, [r0] @ PAGE_OFFSET + 0MB
/* r0=0xa0007000, no change */
18 add r0, r0, #(TEXTADDR & 0x
19 str r3, [r0], #4 @ KERNEL + 0MB
20 add r3, r3, #1 << 20
21 str r3, [r0], #4 @ KERNEL + 1MB
22 add r3, r3, #1 << 20
23 str r3, [r0], #4 @ KERNEL + 2MB
24 add r3, r3, #1 << 20
25 str r3, [r0], #4 @ KERNEL + 3MB
/*
* Ensure that the first section of RAM is present.
* we assume that:
* 1. the RAM is aligned to a 32MB boundary
* 2. the kernel is executing in the same 32MB chunk
* as the start of RAM.
*/
26 bic r0, r0, #0x
27 and r2, r5, #0xfe000000 @ round down
28 add r3, r8, r2 @ flags + rambase
29 str r3, [r0]
30 bic r8, r8, #0x
31 mov pc, lr
我已經(jīng)把每一步涉及的地址詳細(xì)列出了，讀者可以自行對(duì)照閱讀。第11～16行，清空頁(yè)表項(xiàng)從0xA0004000到0xA00,8000，共16KB。
第28行，取得__cpu_mmu_flags。第35～45行，填寫頁(yè)表項(xiàng)，共4項(xiàng)。讀者可以對(duì)照XScale的地址映射手冊(cè)，
因?yàn)椴捎玫氖嵌问接成浞绞剑悦?/font>1MB虛擬空間映射到相同的頁(yè)表表項(xiàng)，根據(jù)手冊(cè)說明，段式映射只有一級(jí)表索引，
是虛擬地址的前12位；而頁(yè)式映射的頁(yè)目錄表是前12位，頁(yè)表是接著的8位，最后12位才是頁(yè)內(nèi)偏移，
讀者一定不要和386的10位頁(yè)目錄表，10位頁(yè)表的機(jī)制相混淆。我們舉個(gè)例子說明，對(duì)于虛擬地址0xC00x,xxxxx，
其前12位為C00，頁(yè)表基址為0xA000,4000，所以表項(xiàng)地址為0xA000,4000+0xC00<<2=0xA000,7000，
而這個(gè)地址內(nèi)容為0xA
函數(shù)__mmap_switched介紹：
/*
* The following fragment of code is executed with the MMU on, and uses
* absolute addresses; this is not position independent.
*
* r0 = processor control register
* r1 = machine ID
* r9 = processor ID
*/
/* 下面按4字節(jié)對(duì)齊 */
1 .align 5
2 __mmap_switched:
/* r3 = __bss_start */
3 adr r3, __switch_data + 4
4 ldmia r3, {r4, r5, r6, r7, r8, sp}@ r2 = compat
@ sp = stack pointer
5 mov fp, #0 @ Clear BSS (and zero fp)
6 1: cmp r4, r5
7 strcc fp, [r4],#4
8 bcc 1b
9 str r9, [r6] @ Save processor ID
10 str r1, [r7] @ Save machine type
11 orr r0, r0, #2 @ ...........A.
12 bic r2, r0, #2 @ Clear 'A' bit
13 stmia r8, {r0, r2} @ Save control register values
14 b SYMBOL_NAME(start_kernel)
程序的4行執(zhí)行完成之后的結(jié)果是r4=__bss_start，r5=_end，r6=processor_id，r7=__machine_arch_type，
r8=cr_alignment，sp=init_task_union+8192，第5-8行將__bss_start到_end清零，定義在vmlinux.lds文件中，如下：
.bss : {
__bss_start = .; /* BSS */
*(.bss)
*(COMMON)
_end = . ;
}
第9、10行分別將處理器類型和機(jī)器類型存儲(chǔ)到變量processor_id和__machine_arch_type中，這些變量以后會(huì)
在start_kernel->setup_arch中使用，來得到當(dāng)前處理器的struct proc_info_list結(jié)構(gòu)和當(dāng)前系統(tǒng)的machine_desc結(jié)構(gòu)的數(shù)據(jù)。
第10-13將processor control register保存到cr_alignment中，14行跳轉(zhuǎn)到init/main.c中的start_kernel進(jìn)入內(nèi)核啟動(dòng)的第二階段。
內(nèi)核從現(xiàn)在開始就進(jìn)入了c語(yǔ)言部分，內(nèi)核啟動(dòng)第二階段從init/main.c的start_kernel()函數(shù)開始到函數(shù)結(jié)束。
這一階段對(duì)整個(gè)系統(tǒng)內(nèi)存、cache、信號(hào)、設(shè)備等進(jìn)行初始化，最后產(chǎn)生新的內(nèi)核線程init后，
調(diào)用cpu_idle()完成內(nèi)核第二階段。有很多書籍介紹這一部分的內(nèi)容，我們這里僅僅講述與xscale結(jié)構(gòu)相關(guān)的部分。
首先我們看一下start_kernel開始部分的源代碼
asmlinkage void __init start_kernel(void)
{
char * command_line;
extern char saved_command_line[];
/*
* Interrupts are still disabled. Do necessary setups, then
* enable them
*/
lock_kernel();
printk(linux_banner);
setup_arch(&command_line);
printk("Kernel command line: %s\n", saved_command_line);
parse_options(command_line);
trap_init();
init_IRQ();
sched_init();
softirq_init();
time_init();
.......
.....
...
start_kernel使用了asmlinkage進(jìn)行修飾，該修飾符定義在kernel/include/linux/linkage.h中，如下所示：
#ifdef __cplusplus
#define CPP_ASMLINKAGE extern "C"
#else
#define CPP_ASMLINKAGE
#endif
#if defined __i386__
#define asmlinkage CPP_ASMLINKAGE __attribute__((regparm(0)))
#elif defined __ia64__
#define asmlinkage CPP_ASMLINKAGE __attribute__((syscall_linkage))
#else
#define asmlinkage CPP_ASMLINKAGE
#endif
應(yīng)為我們使用的是arm平臺(tái)，所以這些定義沒有意義，不過還是簡(jiǎn)單介紹一下regparm的意思，察看gcc手冊(cè)，原文
介紹如下：
On the Intel 386, the regparm attribute causes the compiler to pass arguments
number one to number if they are of integral type in registers EAX, EDX,
and ECX instead of on the stack. Functions that take a variable number of
arguments will continue to be passed all of their arguments on the stack.
Beware that on some ELF systems this attribute is unsuitable for global functions
in shared libraries with lazy binding (which is the default). Lazy binding
will send the first call via resolving code in the loader, which might assume
EAX, EDX and ECX can be clobbered, as per the standard calling conventions.
Solaris 8 is affected by this. GNU systems with GLIBC 2.1 or higher,
and FreeBSD, are believed to be safe since the loaders there save all registers.
(Lazy binding can be disabled with the linker or the loader if desired, to avoid
the problem.)
在網(wǎng)上還看到一個(gè)比較好的英文說明：
The asmlinkage tag is one other thing that we should observe about this simple function.
This is a #define for some gcc magic that tells the compiler that the function should not
expect to find any of its arguments in registers (a common optimization),
but only on the CPU's stack. Recall our earlier assertion that system_call consumes its
first argument, the system call number, and allows up to four more arguments that are
passed along to the real system call. system_call achieves this feat simply by leaving
its other arguments (which were passed to it in registers) on the stack. All system calls
are marked with the asmlinkage tag, so they all look to the stack for arguments. Of course,
in sys_ni_syscall's case, this doesn't make any difference, because sys_ni_syscall doesn't
take any arguments, but it's an issue for most other system calls. And, because you'll be
seeing asmlinkage in front of many other functions, I thought you should know what it was about.
簡(jiǎn)單描述一下他的功能：
asmlinkage是個(gè)宏，使用它是為了保持參數(shù)在stack中。因?yàn)閺膮R編語(yǔ)言到C語(yǔ)言代碼參數(shù)
的傳遞是通過stack的，它也可能從stack中得到一些不需要的參數(shù)。Asmlinkage將要
解析那些參數(shù)。regparm(0)表示不從寄存器傳遞參數(shù)。如果是__attribute__((regparm(3)))，
那么調(diào)用函數(shù)的時(shí)候參數(shù)不是通過棧傳遞，而是直接放到寄存器里，被調(diào)用函數(shù)直接從寄存器取參數(shù)。
這一點(diǎn)可以從下面的定義可以看出：
#define fastcall __attribute__((regparm(3)))
這些都必須是在i386平臺(tái)下才有意義。
說完asmlinkage，開始看源代碼，第一個(gè)函數(shù)：lock_kernel()，
這是為了在SMP系統(tǒng)下設(shè)計(jì)的，它定義在kernel/include/linux/smp_lock.h，如果是SMP系統(tǒng)，則會(huì)
定義CONFIG_SMP，否則lock_kernel()將是空函數(shù)，如果定義CONFIG_SMP的話，則會(huì)包含kernel/include/
asm/smplock.h頭文件，lock_kernel()就定一在該文件中，首先我們來看一下smp_lock.h文件：
#ifndef CONFIG_SMP
#define lock_kernel() do { } while(0)
#define unlock_kernel() do { } while(0)
#define release_kernel_lock(task, cpu) do { } while(0)
#define reacquire_kernel_lock(task) do { } while(0)
#define kernel_locked() 1
#else
#include <asm/smplock.h>
#endif /* CONFIG_SMP */
我們的平臺(tái)是單cpu的(沒有定義CONFIG_SMP)，所以lock_kernel是空函數(shù)，不過仍然對(duì)它進(jìn)行一下說明，
如果定義了CONFIG_SMP，則include kernel/include/asm-arm/smplock.h文件，看一下該文件：
static inline void lock_kernel(void)
{
if (!++current->lock_depth)
spin_lock(&kernel_flag);
}
static inline void unlock_kernel(void)
{
if (--current->lock_depth < 0)
spin_unlock(&kernel_flag);
}
找到兩個(gè)比較好的說明如下
1
kernel_flag是一個(gè)內(nèi)核大自旋鎖，所有進(jìn)程都通過這個(gè)大鎖來實(shí)現(xiàn)向內(nèi)核態(tài)的遷移。只有
獲得這個(gè)大自旋鎖的處理器可以進(jìn)入內(nèi)核，如中斷處理程序等。在任何一對(duì)lock_kernel／
unlock_kernel函數(shù)里至多可以有一個(gè)程序占用CPU。 進(jìn)程的lock_depth成員初始化為-1，
在kerenl/fork.c文件中設(shè)置。在它小于0時(shí)（恒為 -1），進(jìn)程不擁有內(nèi)核鎖；當(dāng)大于或等
于0時(shí)，進(jìn)程得到內(nèi)核鎖。
2
kernel_flag，定義為自旋鎖，因?yàn)楹芏嗪诵牟僮鳎ɡ珧?qū)動(dòng)中）需要保證當(dāng)前僅由一個(gè)進(jìn)程執(zhí)行，
所以需要調(diào)用lock_kernel()/release_kernel()對(duì)核心鎖進(jìn)行操作，它在鎖定/解鎖kernel_flag的
同時(shí)還在task_struct::lock_depth上設(shè)置了標(biāo)志，lock_depth小于0表示未加鎖。當(dāng)發(fā)生進(jìn)程切換的時(shí)候，
不允許被切換走的進(jìn)程握有kernel_flag鎖，所以必須調(diào)用release_kernel_lock()強(qiáng)制釋放，同時(shí)，
新進(jìn)程投入運(yùn)行時(shí)如果lock_depth>0，即表明該進(jìn)程被切換走之前握有核心鎖，
必須調(diào)用reacquire_kernel_lock()再次鎖定；
代碼printk(linux_banner)將linux的一些標(biāo)語(yǔ)打印在內(nèi)核啟動(dòng)的開始部分，需要說明的是雖然這是
在內(nèi)核一開始運(yùn)行時(shí)就打印了，但是它沒有馬上輸出到控制臺(tái)上，它只是將liunx_banner存儲(chǔ)到printk
的內(nèi)部緩沖中，因?yàn)檫@時(shí)printk的輸出設(shè)備，一般都是串口還沒有初始化，只有到輸出設(shè)備初始化完畢
在緩沖中的數(shù)據(jù)才被輸出，后面會(huì)看到在哪個(gè)位置linux_banner才真正輸出到終端。linux_banner定義在
kernel/init/version.c中：
const char *linux_banner =
"Linux version " UTS_RELEASE " (" LINUX_COMPILE_BY "@"
LINUX_COMPILE_HOST ") (" LINUX_COMPILER ") " UTS_VERSION "\n";
這里面的字符串定義在文件kernel/include/linux/compile.h和kernel/include/linux/version.h中，
compile.h中的內(nèi)容：
#define UTS_VERSION "#1 Thu, 01 Feb 2007 13:32:14 +0800"
#define LINUX_COMPILE_TIME "13:32:14"
#define LINUX_COMPILE_BY "taoyue"
#define LINUX_COMPILE_HOST "swlinux.cecwireless.com.cn"
#define LINUX_COMPILE_DOMAIN "cecwireless.com.cn"
#define LINUX_COMPILER "gcc version
version.h中的內(nèi)容：
#define UTS_RELEASE "
#define LINUX_VERSION_CODE 132115
#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))
這兩個(gè)文件都是在編譯時(shí)候生成的，看一下kernel/Makefile文件：
include/linux/compile.h: $(CONFIGURATION) include/linux/version.h newversion
@echo -n \#`cat .version` > .ver1
@if [ -n "$(CONFIG_SMP)" ] ; then echo -n " SMP" >> .ver1; fi
@if [ -f .name ]; then echo -n \-`cat .name` >> .ver1; fi
@LANG=C echo ' '`date -R` >> .ver1
@echo \#define UTS_VERSION \"`cat .ver1 | $(uts_truncate)`\" > .ver
@LANG=C echo \#define LINUX_COMPILE_TIME \"`date +%T`\" >> .ver
@echo \#define LINUX_COMPILE_BY \"`whoami`\" >> .ver
@echo \#define LINUX_COMPILE_HOST \"`hostname | $(uts_truncate)`\" >> .ver
@([ -x /bin/dnsdomainname ] && /bin/dnsdomainname > .ver1) || \
([ -x /bin/domainname ] && /bin/domainname > .ver1) || \
echo > .ver1
@echo \#define LINUX_COMPILE_DOMAIN \"`cat .ver1 | $(uts_truncate)`\" >> .ver
@echo \#define LINUX_COMPILER \"`$(CC) $(CFLAGS) -v 2>&1 | tail -1`\" >> .ver
@mv -f .ver $@
@rm -f .ver1
include/linux/version.h: ./Makefile
@expr length "$(KERNELRELEASE)" \<= $(uts_len) > /dev/null || \
(echo KERNELRELEASE \"$(KERNELRELEASE)\" exceeds $(uts_len) characters >&2; false)
@echo \#define UTS_RELEASE \"$(KERNELRELEASE)\" > .ver
@echo \#define LINUX_VERSION_CODE `expr $(VERSION) \\* 65536 + $(PATCHLEVEL) \\* 256 + $(SUBLEVEL)` >> .ver
@echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))' >>.ver
@mv -f .ver $@
可以修改的參數(shù)是:
VERSION = 2
PATCHLEVEL = 4
SUBLEVEL = 19
EXTRAVERSION = -rmk7-pxa2
聯(lián)系客服
