arm linux kernel 從入口到start_kernel 的代碼分析

xpl

最近研究了一下arm linux的入口部分的代碼, code不是太多,所以寫了個(gè)筆記,詳細(xì)的分析了每一條語句.

大家看看, 交流一下.


下面使正文. 由于內(nèi)容比較多,分幾層樓發(fā)吧

____________________________________________________________________________________


本文針對arm linux, 從kernel的第一條指令開始分析,一直分析到進(jìn)入start_kernel()函數(shù).
我們當(dāng)前以linux-2.6.19內(nèi)核版本作為范例來分析,本文中所有的代碼,前面都會加上行號以便于和源碼進(jìn)行對照,
例:
在文件init/main.c中:
00478: asmlinkage void __init start_kernel(void)
前面的"00478:" 表示478行,冒號后面的內(nèi)容就是源碼了.

在分析代碼的過程中,我們使用縮進(jìn)來表示各個(gè)代碼的調(diào)用層次.

由于啟動部分有一些代碼是平臺特定的,雖然大部分的平臺所實(shí)現(xiàn)的功能都比較類似,但是為了更好的對code進(jìn)行說明,對于平臺相關(guān)的代碼,我們選擇at91(ARM926EJS)平臺進(jìn)行分析.

另外,本文是以uncompressed kernel開始講解的.對于內(nèi)核解壓縮部分的code,在 arch/arm/boot/compressed中,本文不做討論.

xpl

一. 啟動條件
        通常從系統(tǒng)上電到執(zhí)行到linux kenel這部分的任務(wù)是由boot loader來完成.
        關(guān)于boot loader的內(nèi)容,本文就不做過多介紹.
        這里只討論進(jìn)入到linux kernel的時(shí)候的一些限制條件,這一般是boot loader在最后跳轉(zhuǎn)到kernel之前要完成的:
        1. CPU必須處于SVC(supervisor)模式,并且IRQ和FIQ中斷都是禁止的;
        2. MMU(內(nèi)存管理單元)必須是關(guān)閉的, 此時(shí)虛擬地址對物理地址;
        3. 數(shù)據(jù)cache(Data cache)必須是關(guān)閉的
        4. 指令cache(Instruction cache)可以是打開的,也可以是關(guān)閉的,這個(gè)沒有強(qiáng)制要求;
        5. CPU 通用寄存器0 (r0)必須是 0;
        6. CPU 通用寄存器1 (r1)必須是 ARM Linux machine type (關(guān)于machine type, 我們后面會有講解)
        7. CPU 通用寄存器2 (r2) 必須是 kernel parameter list 的物理地址(parameter list 是由boot loader傳遞給kernel,用來描述設(shè)備信息屬性的列表,詳細(xì)內(nèi)容可參考"Booting ARM Linux"文檔).

xpl

二. starting kernel

首先，我們先對幾個(gè)重要的宏進(jìn)行說明(我們針對有MMU的情況)：

     宏                 位置                           默認(rèn)值          說明
KERNEL_RAM_ADDR  arch/arm/kernel/head.S +26          0xc0008000      kernel在RAM中的的虛擬地址
PAGE_OFFSET      include/asm-arm/memeory.h +50       0xc0000000      內(nèi)核空間的起始虛擬地址
TEXT_OFFSET      arch/arm/Makefile +137              0x00008000      內(nèi)核相對于存儲空間的偏移
TEXTADDR         arch/arm/kernel/head.S +49          0xc0008000      kernel的起始虛擬地址
PHYS_OFFSET      include/asm-arm/arch-xxx/memory.h   平臺相關(guān)        RAM的起始物理地址


        內(nèi)核的入口是stext,這是在arch/arm/kernel/vmlinux.lds.S中定義的:
        00011: ENTRY(stext)
        對于vmlinux.lds.S,這是ld script文件,此文件的格式和匯編及C程序都不同,本文不對ld script作過多的介紹,只對內(nèi)核中用到的內(nèi)容進(jìn)行講解,關(guān)于ld的詳細(xì)內(nèi)容可以參考ld.info
        這里的ENTRY(stext) 表示程序的入口是在符號stext.
        而符號stext是在arch/arm/kernel/head.S中定義的:
        下面我們將arm linux boot的主要代碼列出來進(jìn)行一個(gè)概括的介紹,然后,我們會逐個(gè)的進(jìn)行詳細(xì)的講解.
       
        在arch/arm/kernel/head.S中 72 - 94 行,是arm linux boot的主代碼:

00072: ENTRY(stext)                                                        
00073:         msr        cpsr_c, #PSR_F_BIT | PSR_I_BIT | SVC_MODE @ ensure svc mode
00074:                                                 @ and irqs disabled        
00075:         mrc        p15, 0, r9, c0, c0                @ get processor id         
00076:         bl        __lookup_processor_type                @ r5=procinfo r9=cpuid     
00077:         movs        r10, r5                                @ invalid processor (r5=0)?
00078:         beq        __error_p                        @ yes, error 'p'           
00079:         bl        __lookup_machine_type                @ r5=machinfo              
00080:         movs        r8, r5                                @ invalid machine (r5=0)?  
00081:         beq        __error_a                        @ yes, error 'a'           
00082:         bl        __create_page_tables                                       
00083:                                                                     
00084:         /*                                                                 
00085:          * The following calls CPU specific code in a position independent
00086:          * manner.  See arch/arm/mm/proc-*.S for details.  r10 = base of   
00087:          * xxx_proc_info structure selected by __lookup_machine_type      
00088:          * above.  On return, the CPU will be ready for the MMU to be      
00089:          * turned on, and r0 will hold the CPU control register value.     
00090:          */                                                               
00091:         ldr        r13, __switch_data                @ address to jump to after
00092:                                                 @ mmu has been enabled     
00093:         adr        lr, __enable_mmu                @ return (PIC) address     
00094:         add        pc, r10, #PROCINFO_INITFUNC                                


其中,73行是確保kernel運(yùn)行在SVC模式下,并且IRQ和FIRQ中斷已經(jīng)關(guān)閉,這樣做是很謹(jǐn)慎的.

arm linux boot的主線可以概括為以下幾個(gè)步驟:
        1. 確定 processor type                        (75 - 78行)
        2. 確定 machine type                        (79 - 81行)
        3. 創(chuàng)建頁表                                (82行)     
        4. 調(diào)用平臺特定的__cpu_flush函數(shù)        (在struct proc_info_list中)        (94 行)                           
        5. 開啟mmu                                (93行)
        6. 切換數(shù)據(jù)                                 (91行)
       
        最終跳轉(zhuǎn)到start_kernel                        (在__switch_data的結(jié)束的時(shí)候,調(diào)用了 b        start_kernel)

下面,我們按照這個(gè)主線,逐步的分析Code.

xpl

1. 確定 processor type
       

    arch/arm/kernel/head.S中:
00075:         mrc        p15, 0, r9, c0, c0                @ get processor id         
00076:         bl        __lookup_processor_type                @ r5=procinfo r9=cpuid     
00077:         movs        r10, r5                                @ invalid processor (r5=0)?
00078:         beq        __error_p                        @ yes, error 'p'           

75行: 通過cp15協(xié)處理器的c0寄存器來獲得processor id的指令. 關(guān)于cp15的詳細(xì)內(nèi)容可參考相關(guān)的arm手冊

76行: 跳轉(zhuǎn)到__lookup_processor_type.在__lookup_processor_type中,會把processor type 存儲在r5中
77,78行: 判斷r5中的processor type是否是0,如果是0,說明是無效的processor type,跳轉(zhuǎn)到__error_p(出錯(cuò))

__lookup_processor_type 函數(shù)主要是根據(jù)從cpu中獲得的processor id和系統(tǒng)中的proc_info進(jìn)行匹配,將匹配到的proc_info_list的基地址存到r5中, 0表示沒有找到對應(yīng)的processor type.

下面我們分析__lookup_processor_type函數(shù)
        arch/arm/kernel/head-common.S中:
       
00145:         .type        __lookup_processor_type, %function
00146: __lookup_processor_type:
00147:         adr        r3, 3f
00148:         ldmda        r3, {r5 - r7}
00149:         sub        r3, r3, r7                        @ get offset between virt&phys
00150:         add        r5, r5, r3                        @ convert virt addresses to
00151:         add        r6, r6, r3                        @ physical address space
00152: 1:        ldmia        r5, {r3, r4}                        @ value, mask
00153:         and        r4, r4, r9                        @ mask wanted bits
00154:         teq        r3, r4
00155:         beq        2f
00156:         add        r5, r5, #PROC_INFO_SZ                @ sizeof(proc_info_list)
00157:         cmp        r5, r6
00158:         blo        1b
00159:         mov        r5, #0                                @ unknown processor
00160: 2:        mov        pc, lr
00161:
00162: /*
00163:  * This provides a C-API version of the above function.
00164:  */
00165: ENTRY(lookup_processor_type)
00166:         stmfd        sp!, {r4 - r7, r9, lr}
00167:         mov        r9, r0
00168:         bl        __lookup_processor_type
00169:         mov        r0, r5
00170:         ldmfd        sp!, {r4 - r7, r9, pc}
00171:
00172: /*
00173:  * Look in include/asm-arm/procinfo.h and arch/arm/kernel/arch.[ch] for
00174:  * more information about the __proc_info and __arch_info structures.
00175:  */
00176:         .long        __proc_info_begin
00177:         .long        __proc_info_end
00178: 3:        .long        .
00179:         .long        __arch_info_begin
00180:         .long        __arch_info_end
       
   
145, 146行是函數(shù)定義
147行: 取地址指令,這里的3f是向前symbol名稱是3的位置,即第178行,將該地址存入r3.
        這里需要注意的是,adr指令取址,獲得的是基于pc的一個(gè)地址,要格外注意,這個(gè)地址是3f處的"運(yùn)行時(shí)地址",由于此時(shí)MMU還沒有打開,也可以理解成物理地址(實(shí)地址).(詳細(xì)內(nèi)容可參考arm指令手冊)
        
148行: 因?yàn)閞3中的地址是178行的位置的地址,因而執(zhí)行完后:
        r5存的是176行符號 __proc_info_begin的地址;
        r6存的是177行符號 __proc_info_end的地址;
        r7存的是3f處的地址.
        這里需要注意鏈接地址和運(yùn)行時(shí)地址的區(qū)別. r3存儲的是運(yùn)行時(shí)地址(物理地址),而r7中存儲的是鏈接地址(虛擬地址).
        
                __proc_info_begin和__proc_info_end是在arch/arm/kernel/vmlinux.lds.S中:
        00031:                __proc_info_begin = .;
        00032:                        *(.proc.info.init)
        00033:                __proc_info_end = .;

        這里是聲明了兩個(gè)變量:__proc_info_begin 和 __proc_info_end,其中等號后面的"."是location counter(詳細(xì)內(nèi)容請參考ld.info)
        這三行的意思是: __proc_info_begin 的位置上,放置所有文件中的 ".proc.info.init" 段的內(nèi)容,然后緊接著是 __proc_info_end 的位置.

        kernel 使用struct proc_info_list來描述processor type.
                在 include/asm-arm/procinfo.h 中:
        00029: struct proc_info_list {
        00030:         unsigned int                cpu_val;
        00031:         unsigned int                cpu_mask;
        00032:         unsigned long                __cpu_mm_mmu_flags;        /* used by head.S */
        00033:         unsigned long                __cpu_io_mmu_flags;        /* used by head.S */
        00034:         unsigned long                __cpu_flush;                /* used by head.S */
        00035:         const char                *arch_name;
        00036:         const char                *elf_name;
        00037:         unsigned int                elf_hwcap;
        00038:         const char                *cpu_name;
        00039:         struct processor        *proc;
        00040:         struct cpu_tlb_fns        *tlb;
        00041:         struct cpu_user_fns        *user;
        00042:         struct cpu_cache_fns        *cache;
        00043: };
        
        我們當(dāng)前以at91為例,其processor是926的.
                在arch/arm/mm/proc-arm926.S 中:
        00464:         .section ".proc.info.init", #alloc, #execinstr
        00465:
        00466:         .type        __arm926_proc_info,#object
        00467: __arm926_proc_info:
        00468:         .long        0x41069260                        @ ARM926EJ-S (v5TEJ)
        00469:         .long        0xff0ffff0
        00470:         .long   PMD_TYPE_SECT | \
        00471:                 PMD_SECT_BUFFERABLE | \
        00472:                 PMD_SECT_CACHEABLE | \
        00473:                 PMD_BIT4 | \
        00474:                 PMD_SECT_AP_WRITE | \
        00475:                 PMD_SECT_AP_READ
        00476:         .long   PMD_TYPE_SECT | \
        00477:                 PMD_BIT4 | \
        00478:                 PMD_SECT_AP_WRITE | \
        00479:                 PMD_SECT_AP_READ
        00480:         b        __arm926_setup
        00481:         .long        cpu_arch_name
        00482:         .long        cpu_elf_name
        00483:         .long        HWCAP_SWP|HWCAP_HALF|HWCAP_THUMB|HWCAP_FAST_MULT|HWCAP_VFP|HWCAP_EDSP|HWCAP_JAVA
        00484:         .long        cpu_arm926_name
        00485:         .long        arm926_processor_functions
        00486:         .long        v4wbi_tlb_fns
        00487:         .long        v4wb_user_fns
        00488:         .long        arm926_cache_fns
        00489:         .size        __arm926_proc_info, . - __arm926_proc_info
        
        從464行,我們可以看到 __arm926_proc_info 被放到了".proc.info.init"段中.
        對照struct proc_info_list,我們可以看到 __cpu_flush的定義是在480行,即__arm926_setup.(我們將在"4. 調(diào)用平臺特定的__cpu_flush函數(shù)"一節(jié)中詳細(xì)分析這部分的內(nèi)容.)
        
從以上的內(nèi)容我們可以看出: r5中的__proc_info_begin是proc_info_list的起始地址, r6中的__proc_info_end是proc_info_list的結(jié)束地址.

149行: 從上面的分析我們可以知道r3中存儲的是3f處的物理地址,而r7存儲的是3f處的虛擬地址,這一行是計(jì)算當(dāng)前程序運(yùn)行的物理地址和虛擬地址的差值,將其保存到r3中.

150行: 將r5存儲的虛擬地址(__proc_info_begin)轉(zhuǎn)換成物理地址
151行: 將r6存儲的虛擬地址(__proc_info_end)轉(zhuǎn)換成物理地址
152行: 對照struct proc_info_list,可以得知,這句是將當(dāng)前proc_info的cpu_val和cpu_mask分別存r3, r4中
153行: r9中存儲了processor id(arch/arm/kernel/head.S中的75行),與r4的cpu_mask進(jìn)行邏輯與操作,得到我們需要的值
154行: 將153行中得到的值與r3中的cpu_val進(jìn)行比較
155行: 如果相等,說明我們找到了對應(yīng)的processor type,跳到160行,返回
156行: (如果不相等) , 將r5指向下一個(gè)proc_info,
157行: 和r6比較,檢查是否到了__proc_info_end.
158行: 如果沒有到__proc_info_end,表明還有proc_info配置,返回152行繼續(xù)查找
159行: 執(zhí)行到這里,說明所有的proc_info都匹配過了,但是沒有找到匹配的,將r5設(shè)置成0(unknown processor)
160行: 返回

xpl

2. 確定 machine type

    arch/arm/kernel/head.S中:
00079:         bl        __lookup_machine_type                @ r5=machinfo              
00080:         movs        r8, r5                                @ invalid machine (r5=0)?  
00081:         beq        __error_a                        @ yes, error 'a'  

79行: 跳轉(zhuǎn)到__lookup_machine_type函數(shù),在__lookup_machine_type中,會把struct machine_desc的基地址(machine type)存儲在r5中
80,81行: 將r5中的 machine_desc的基地址存儲到r8中,并判斷r5是否是0,如果是0,說明是無效的machine type,跳轉(zhuǎn)到__error_a(出錯(cuò))

__lookup_machine_type 函數(shù)
下面我們分析__lookup_machine_type 函數(shù):

        arch/arm/kernel/head-common.S中:
        
00176:         .long        __proc_info_begin
00177:         .long        __proc_info_end
00178: 3:        .long        .
00179:         .long        __arch_info_begin
00180:         .long        __arch_info_end
00181:
00182: /*
00183:  * Lookup machine architecture in the linker-build list of architectures.
00184:  * Note that we can't use the absolute addresses for the __arch_info
00185:  * lists since we aren't running with the MMU on (and therefore, we are
00186:  * not in the correct address space).  We have to calculate the offset.
00187:  *
00188:  *  r1 = machine architecture number
00189:  * Returns:
00190:  *  r3, r4, r6 corrupted
00191:  *  r5 = mach_info pointer in physical address space
00192:  */       
00193:         .type        __lookup_machine_type, %function
00194: __lookup_machine_type:
00195:         adr        r3, 3b
00196:         ldmia        r3, {r4, r5, r6}
00197:         sub        r3, r3, r4                        @ get offset between virt&phys
00198:         add        r5, r5, r3                        @ convert virt addresses to
00199:         add        r6, r6, r3                        @ physical address space
00200: 1:        ldr        r3, [r5, #MACHINFO_TYPE]        @ get machine type
00201:         teq        r3, r1                                @ matches loader number?
00202:         beq        2f                                @ found
00203:         add        r5, r5, #SIZEOF_MACHINE_DESC        @ next machine_desc
00204:         cmp        r5, r6
00205:         blo        1b
00206:         mov        r5, #0                                @ unknown machine
00207: 2:        mov        pc, lr

193, 194行: 函數(shù)聲明
195行: 取地址指令,這里的3b是向后symbol名稱是3的位置,即第178行,將該地址存入r3.
        和上面我們對__lookup_processor_type 函數(shù)的分析相同,r3中存放的是3b處物理地址.
196行: r3是3b處的地址,因而執(zhí)行完后:
        r4存的是 3b處的地址
        r5存的是__arch_info_begin 的地址
        r6存的是__arch_info_end 的地址

        __arch_info_begin 和 __arch_info_end是在 arch/arm/kernel/vmlinux.lds.S中:

        00034:                __arch_info_begin = .;
        00035:                        *(.arch.info.init)
        00036:                __arch_info_end = .;
     

        這里是聲明了兩個(gè)變量:__arch_info_begin 和 __arch_info_end,其中等號后面的"."是location counter(詳細(xì)內(nèi)容請參考ld.info)
        這三行的意思是: __arch_info_begin 的位置上,放置所有文件中的 ".arch.info.init" 段的內(nèi)容,然后緊接著是 __arch_info_end 的位置.

        kernel 使用struct machine_desc 來描述 machine type.
        在 include/asm-arm/mach/arch.h 中:

        00017: struct machine_desc {
        00018:         /*
        00019:          * Note! The first four elements are used
        00020:          * by assembler code in head-armv.S
        00021:          */
        00022:         unsigned int                nr;                /* architecture number        */
        00023:         unsigned int                phys_io;        /* start of physical io        */
        00024:         unsigned int                io_pg_offst;        /* byte offset for io
        00025:                                                  * page tabe entry        */
        00026:
        00027:         const char                *name;                /* architecture name        */
        00028:         unsigned long                boot_params;        /* tagged list                */
        00029:
        00030:         unsigned int                video_start;        /* start of video RAM        */
        00031:         unsigned int                video_end;        /* end of video RAM        */
        00032:
        00033:         unsigned int                reserve_lp0 :1;        /* never has lp0        */
        00034:         unsigned int                reserve_lp1 :1;        /* never has lp1        */
        00035:         unsigned int                reserve_lp2 :1;        /* never has lp2        */
        00036:         unsigned int                soft_reboot :1;        /* soft reboot                */
        00037:         void                        (*fixup)(struct machine_desc *,
        00038:                                          struct tag *, char **,
        00039:                                          struct meminfo *);
        00040:         void                        (*map_io)(void);/* IO mapping function        */
        00041:         void                        (*init_irq)(void);
        00042:         struct sys_timer        *timer;                /* system tick timer        */
        00043:         void                        (*init_machine)(void);
        00044: };
        00045:
        00046: /*
        00047:  * Set of macros to define architecture features.  This is built into
        00048:  * a table by the linker.
        00049:  */
        00050: #define MACHINE_START(_type,_name)                        \
        00051: static const struct machine_desc __mach_desc_##_type        \
        00052:  __attribute_used__                                        \
        00053:  __attribute__((__section__(".arch.info.init")) = {        \
        00054:         .nr                = MACH_TYPE_##_type,                \
        00055:         .name                = _name,
        00056:
        00057: #define MACHINE_END                                \
        00058: };        
        
        內(nèi)核中,一般使用宏MACHINE_START來定義machine type.
        對于at91, 在 arch/arm/mach-at91rm9200/board-ek.c 中:
        00137: MACHINE_START(AT91RM9200EK, "Atmel AT91RM9200-EK"
        00138:         /* Maintainer: SAN People/Atmel */
        00139:         .phys_io        = AT91_BASE_SYS,
        00140:         .io_pg_offst        = (AT91_VA_BASE_SYS >> 1 & 0xfffc,
        00141:         .boot_params        = AT91_SDRAM_BASE + 0x100,
        00142:         .timer                = &at91rm9200_timer,
        00143:         .map_io                = ek_map_io,
        00144:         .init_irq        = ek_init_irq,
        00145:         .init_machine        = ek_board_init,
        00146: MACHINE_END


197行: r3中存儲的是3b處的物理地址,而r4中存儲的是3b處的虛擬地址,這里計(jì)算處物理地址和虛擬地址的差值,保存到r3中
198行: 將r5存儲的虛擬地址(__arch_info_begin)轉(zhuǎn)換成物理地址            
199行: 將r6存儲的虛擬地址(__arch_info_end)轉(zhuǎn)換成物理地址            
200行: MACHINFO_TYPE 在 arch/arm/kernel/asm-offset.c 101行定義, 這里是取 struct machine_desc中的nr(architecture number) 到r3中
201行: 將r3中取到的machine type 和 r1中的 machine type(見前面的"啟動條件"進(jìn)行比較
202行: 如果相同,說明找到了對應(yīng)的machine type,跳轉(zhuǎn)到207行的2f處,此時(shí)r5中存儲了對應(yīng)的struct machine_desc的基地址
203行: (不相同), 取下一個(gè)machine_desc的地址
204行: 和r6進(jìn)行比較,檢查是否到了__arch_info_end.
205行: 如果不相同,說明還有machine_desc,返回200行繼續(xù)查找.
206行: 執(zhí)行到這里,說明所有的machind_desc都查找完了,并且沒有找到匹配的, 將r5設(shè)置成0(unknown machine).
207行: 返回

Godbach

為LZ的辛勤勞動頂一下。

xpl

3. 創(chuàng)建頁表

通過前面的兩步,我們已經(jīng)確定了processor type 和 machine type.
此時(shí),一些特定寄存器的值如下所示:
r8 = machine info       (struct machine_desc的基地址)
r9 = cpu id             (通過cp15協(xié)處理器獲得的cpu id)
r10 = procinfo          (struct proc_info_list的基地址)

創(chuàng)建頁表是通過函數(shù) __create_page_tables 來實(shí)現(xiàn)的.
這里,我們使用的是arm的L1主頁表,L1主頁表也稱為段頁表(section page table)
L1 主頁表將4 GB 的地址空間分成若干個(gè)1 MB的段(section),因此L1頁表包含4096個(gè)頁表項(xiàng)(section entry). 每個(gè)頁表項(xiàng)是32 bits(4 bytes)
因而L1主頁表占用 4096 *4 = 16k的內(nèi)存空間.

        對于ARM926,其L1 section entry的格式為可參考arm926EJS TRM):




下面我們來分析 __create_page_tables 函數(shù):

         在 arch/arm/kernel/head.S 中:

00206:         .type        __create_page_tables, %function
00207: __create_page_tables:
00208:         pgtbl        r4                                @ page table address
00209:
00210:         /*
00211:          * Clear the 16K level 1 swapper page table
00212:          */
00213:         mov        r0, r4
00214:         mov        r3, #0
00215:         add        r6, r0, #0x4000
00216: 1:        str        r3, [r0], #4
00217:         str        r3, [r0], #4
00218:         str        r3, [r0], #4
00219:         str        r3, [r0], #4
00220:         teq        r0, r6
00221:         bne        1b
00222:
00223:         ldr        r7, [r10, #PROCINFO_MM_MMUFLAGS] @ mm_mmuflags
00224:
00225:         /*
00226:          * Create identity mapping for first MB of kernel to
00227:          * cater for the MMU enable.  This identity mapping
00228:          * will be removed by paging_init().  We use our current program
00229:          * counter to determine corresponding section base address.
00230:          */
00231:         mov        r6, pc, lsr #20                        @ start of kernel section
00232:         orr        r3, r7, r6, lsl #20                @ flags + kernel base
00233:         str        r3, [r4, r6, lsl #2]                @ identity mapping
00234:
00235:         /*
00236:          * Now setup the pagetables for our kernel direct
00237:          * mapped region.
00238:          */
00239:         add        r0, r4,  #(TEXTADDR & 0xff000000) >> 18        @ start of kernel
00240:         str        r3, [r0, #(TEXTADDR & 0x00f00000) >> 18]!
00241:
00242:         ldr        r6, =(_end - PAGE_OFFSET - 1)        @ r6 = number of sections
00243:         mov        r6, r6, lsr #20                        @ needed for kernel minus 1
00244:
00245: 1:        add        r3, r3, #1 << 20
00246:         str        r3, [r0, #4]!
00247:         subs        r6, r6, #1
00248:         bgt        1b
00249:
00250:         /*
00251:          * Then map first 1MB of ram in case it contains our boot params.
00252:          */
00253:         add        r0, r4, #PAGE_OFFSET >> 18
00254:         orr        r6, r7, #PHYS_OFFSET
00255:         str        r6, [r0]
        
        ...
        
00314:        mov        pc, lr
00315:        .ltorg         

206, 207行: 函數(shù)聲明
208行: 通過宏 pgtbl 將r4設(shè)置成頁表的基地址(物理地址)
        宏pgtbl 在 arch/arm/kernel/head.S 中:
        
        00042:        .macro        pgtbl, rd
        00043:        ldr        \rd, =(__virt_to_phys(KERNEL_RAM_ADDR - 0x4000))
        00044:        .endm

        可以看到,頁表是位于 KERNEL_RAM_ADDR 下面 16k 的位置
        宏 __virt_to_phys 是在incude/asm-arm/memory.h 中:
        
        00125: #ifndef __virt_to_phys
        00126: #define __virt_to_phys(x)        ((x) - PAGE_OFFSET + PHYS_OFFSET)
        00127: #define __phys_to_virt(x)        ((x) - PHYS_OFFSET + PAGE_OFFSET)
        00128: #endif        
        
        
下面從213行 - 221行, 是將這16k 的頁表清0.
213行: r0 = r4, 將頁表基地址存在r0中
214行: 將 r3 置成0
215行: r6  = 頁表基地址 + 16k, 可以看到這是頁表的尾地址
216 - 221 行: 循環(huán),從 r0 到 r6 將這16k頁表用0填充.
      
223行: 獲得proc_info_list的__cpu_mm_mmu_flags的值,并存儲到 r7中. (宏P(guān)ROCINFO_MM_MMUFLAGS是在arch/arm/kernel/asm-offset.c中定義)


231行: 通過pc值的高12位(右移20位),得到kernel的section,并存儲到r6中.因?yàn)楫?dāng)前是通過運(yùn)行時(shí)地址得到的kernel的section,因而是物理地址.
232行: r3 = r7 | (r6 << 20); flags + kernel base,得到頁表中需要設(shè)置的值.
233行: 設(shè)置頁表: mem[r4 + r6 * 4] = r3
        這里,因?yàn)轫摫淼拿恳豁?xiàng)是32 bits(4 bytes),所以要乘以4(<<2).
上面這三行,設(shè)置了kernel的第一個(gè)section(物理地址所在的page entry)的頁表項(xiàng)

239, 240行: TEXTADDR是內(nèi)核的起始虛擬地址(0xc0008000), 這兩行是設(shè)置kernel起始虛擬地址的頁表項(xiàng)(注意,這里設(shè)置的頁表項(xiàng)和上面的231 - 233行設(shè)置的頁表項(xiàng)是不同的 )
        執(zhí)行完后,r0指向kernel的第2個(gè)section的虛擬地址所在的頁表項(xiàng).
        /* TODO: 這兩行的code很奇怪,為什么要先取TEXTADDR的高8位(Bit[31:24])0xff000000,然后再取后面的8位(Bit[23:20])0x00f00000*/           
        
242行: 這一行計(jì)算kernel鏡像的大小(bytes).
        _end 是在vmlinux.lds.S中162行定義的,標(biāo)記kernel的結(jié)束位置(虛擬地址):
        00158                .bss : {
        00159                __bss_start = .;        /* BSS                                */
        00160                *(.bss)
        00161                *(COMMON)
        00162                _end = .;
        00163        }
       
        kernel的size =  _end - PAGE_OFFSET -1, 這里 減1的原因是因?yàn)?_end 是 location counter,它的地址是kernel鏡像后面的一個(gè)byte的地址.

243行: 地址右移20位,計(jì)算出kernel有多少sections,并將結(jié)果存到r6中

245 - 248行: 這幾行用來填充kernel所有section虛擬地址對應(yīng)的頁表項(xiàng).

253行: 將r0設(shè)置為RAM第一兆虛擬地址的頁表項(xiàng)地址(page entry)
254行: r7中存儲的是mmu flags, 邏輯或上RAM的起始物理地址,得到RAM第一個(gè)MB頁表項(xiàng)的值.
255行:　設(shè)置RAM的第一個(gè)MB虛擬地址的頁表.
上面這三行是用來設(shè)置RAM中第一兆虛擬地址的頁表. 之所以要設(shè)置這個(gè)頁表項(xiàng)的原因是RAM的第一兆內(nèi)存中可能存儲著boot params.

這樣,kernel所需要的基本的頁表我們都設(shè)置完了, 如下圖所示:

xpl

4. 調(diào)用平臺特定的 __cpu_flush 函數(shù)

當(dāng) __create_page_tables 返回之后

此時(shí),一些特定寄存器的值如下所示:
r4 = pgtbl              (page table 的物理基地址)
r8 = machine info       (struct machine_desc的基地址)
r9 = cpu id             (通過cp15協(xié)處理器獲得的cpu id)
r10 = procinfo          (struct proc_info_list的基地址)


在我們需要在開啟mmu之前,做一些必須的工作:清除ICache, 清除 DCache, 清除 Writebuffer, 清除TLB等.
這些一般是通過cp15協(xié)處理器來實(shí)現(xiàn)的,并且是平臺相關(guān)的. 這就是 __cpu_flush 需要做的工作.
        
        在 arch/arm/kernel/head.S中
00091:         ldr        r13, __switch_data                @ address to jump to after
00092:                                                 @ mmu has been enabled     
00093:         adr        lr, __enable_mmu                @ return (PIC) address     
00094:         add        pc, r10, #PROCINFO_INITFUNC            

第91行: 將r13設(shè)置為 __switch_data 的地址
第92行: 將lr設(shè)置為 __enable_mmu 的地址
第93行: r10存儲的是procinfo的基地址, PROCINFO_INITFUNC是在 arch/arm/kernel/asm-offset.c 中107行定義.
        則該行將pc設(shè)為 proc_info_list的 __cpu_flush 函數(shù)的地址, 即下面跳轉(zhuǎn)到該函數(shù).
        在分析 __lookup_processor_type 的時(shí)候,我們已經(jīng)知道,對于 ARM926EJS 來說,其__cpu_flush指向的是函數(shù) __arm926_setup

        
        下面我們來分析函數(shù) __arm926_setup
        
        在 arch/arm/mm/proc-arm926.S 中:
00391:         .type        __arm926_setup, #function
00392: __arm926_setup:
00393:         mov        r0, #0
00394:         mcr        p15, 0, r0, c7, c7                @ invalidate I,D caches on v4
00395:         mcr        p15, 0, r0, c7, c10, 4                @ drain write buffer on v4
00396: #ifdef CONFIG_MMU
00397:         mcr        p15, 0, r0, c8, c7                @ invalidate I,D TLBs on v4
00398: #endif
00399:
00400:
00401: #ifdef CONFIG_CPU_DCACHE_WRITETHROUGH
00402:         mov        r0, #4                                @ disable write-back on caches explicitly
00403:         mcr        p15, 7, r0, c15, c0, 0
00404: #endif
00405:
00406:         adr        r5, arm926_crval
00407:         ldmia        r5, {r5, r6}
00408:         mrc        p15, 0, r0, c1, c0                @ get control register v4
00409:         bic        r0, r0, r5
00410:         orr        r0, r0, r6
00411: #ifdef CONFIG_CPU_CACHE_ROUND_ROBIN
00412:         orr        r0, r0, #0x4000                        @ .1.. .... .... ....
00413: #endif
00414:         mov        pc, lr        
00415:         .size        __arm926_setup, . - __arm926_setup
00416:
00417:         /*
00418:          *  R
00419:          * .RVI ZFRS BLDP WCAM
00420:          * .011 0001 ..11 0101
00421:          *
00422:          */
00423:         .type        arm926_crval, #object
00424: arm926_crval:
00425:         crval        clear=0x00007f3f, mmuset=0x00003135, ucset=0x00001134



第391, 392行: 是函數(shù)聲明
第393行: 將r0設(shè)置為0
第394行: 清除(invalidate)Instruction Cache 和 Data Cache.
第395行: 清除(drain) Write Buffer.
第396 - 398行: 如果有配置了MMU,則需要清除(invalidate)Instruction TLB 和Data TLB

接下來,是對控制寄存器c1進(jìn)行配置,請參考 ARM926 TRM.

第401 - 404行: 如果配置了Data Cache使用writethrough方式, 需要關(guān)掉write-back.
                 
第406行:　取arm926_crval的地址到r5中, arm926_crval 在第424行
   
第407行:　這里我們需要看一下424和425行,其中用到了宏crval,crval是在 arch/arm/mm/proc-macro.S 中:

        00053:         .macro        crval, clear, mmuset, ucset
        00054: #ifdef CONFIG_MMU
        00055:         .word        \clear
        00056:         .word        \mmuset
        00057: #else
        00058:         .word        \clear
        00059:         .word        \ucset
        00060: #endif
        00061:         .endm

        配合425行,我們可以看出,首先在arm926_crval的地址處存放了clear的值,然后接下來的地址存放了mmuset的值(對于配置了MMU的情況)               
        
所以,在407行中,我們將clear和mmuset的值分別存到了r5, r6中

第408行:　獲得控制寄存器c1的值
第409行:  將r0中的 clear (r5) 對應(yīng)的位都清除掉
第410行:　設(shè)置r0中 mmuset (r6) 對應(yīng)的位

第411 - 413行:　如果配置了使用 round robin方式,需要設(shè)置控制寄存器c1的 Bit[16]
第412行: 取lr的值到pc中.
而lr中的值存放的是 __enable_mmu 的地址(arch/arm/kernel/head.S 93行),所以,接下來就是跳轉(zhuǎn)到函數(shù) __enable_mmu

xpl

5. 開啟mmu
        開啟mmu是又函數(shù) __enable_mmu 實(shí)現(xiàn)的.
        
        在進(jìn)入 __enable_mmu 的時(shí)候, r0中已經(jīng)存放了控制寄存器c1的一些配置(在上一步中進(jìn)行的設(shè)置), 但是并沒有真正的打開mmu,
        在 __enable_mmu 中,我們將打開mmu.
        
        此時(shí),一些特定寄存器的值如下所示:
r0 = c1 parameters      (用來配置控制寄存器的參數(shù))        
r4 = pgtbl              (page table 的物理基地址)
r8 = machine info       (struct machine_desc的基地址)
r9 = cpu id             (通過cp15協(xié)處理器獲得的cpu id)
r10 = procinfo          (struct proc_info_list的基地址)
        
        在 arch/arm/kernel/head.S 中:

00146:         .type        __enable_mmu, %function
00147: __enable_mmu:
00148: #ifdef CONFIG_ALIGNMENT_TRAP
00149:         orr        r0, r0, #CR_A
00150: #else
00151:         bic        r0, r0, #CR_A
00152: #endif
00153: #ifdef CONFIG_CPU_DCACHE_DISABLE
00154:         bic        r0, r0, #CR_C
00155: #endif
00156: #ifdef CONFIG_CPU_BPREDICT_DISABLE
00157:         bic        r0, r0, #CR_Z
00158: #endif
00159: #ifdef CONFIG_CPU_ICACHE_DISABLE
00160:         bic        r0, r0, #CR_I
00161: #endif
00162:         mov        r5, #(domain_val(DOMAIN_USER, DOMAIN_MANAGER) | \
00163:                       domain_val(DOMAIN_KERNEL, DOMAIN_MANAGER) | \
00164:                       domain_val(DOMAIN_TABLE, DOMAIN_MANAGER) | \
00165:                       domain_val(DOMAIN_IO, DOMAIN_CLIENT))
00166:         mcr        p15, 0, r5, c3, c0, 0                @ load domain access register
00167:         mcr        p15, 0, r4, c2, c0, 0                @ load page table pointer
00168:         b        __turn_mmu_on
00169:
00170: /*
00171:  * Enable the MMU.  This completely changes the structure of the visible
00172:  * memory space.  You will not be able to trace execution through this.
00173:  * If you have an enquiry about this, *please* check the linux-arm-kernel
00174:  * mailing list archives BEFORE sending another post to the list.
00175:  *
00176:  *  r0  = cp#15 control register
00177:  *  r13 = *virtual* address to jump to upon completion
00178:  *
00179:  * other registers depend on the function called upon completion
00180:  */
00181:         .align        5
00182:         .type        __turn_mmu_on, %function
00183: __turn_mmu_on:
00184:         mov        r0, r0
00185:         mcr        p15, 0, r0, c1, c0, 0                @ write control reg
00186:         mrc        p15, 0, r3, c0, c0, 0                @ read id reg
00187:         mov        r3, r3
00188:         mov        r3, r3
00189:         mov        pc, r13
        
第146, 147行: 函數(shù)聲明
第148 - 161行:  根據(jù)相應(yīng)的配置,設(shè)置r0中的相應(yīng)的Bit. (r0 將用來配置控制寄存器c1)
第162 - 165行: 設(shè)置 domain 參數(shù)r5.(r5 將用來配置domain)
第166行: 配置 domain (詳細(xì)信息清參考arm相關(guān)手冊)
第167行: 配置頁表在存儲器中的位置(set ttb).這里頁表的基地址是r4, 通過寫cp15的c2寄存器來設(shè)置頁表基地址.

第168行: 跳轉(zhuǎn)到 __turn_mmu_on. 從名稱我們可以猜到,下面是要真正打開mmu了.
        (繼續(xù)向下看,我們會發(fā)現(xiàn),__turn_mmu_on就下當(dāng)前代碼的下方,為什么要跳轉(zhuǎn)一下呢? 這是有原因的. go on)
第169 - 180行: 空行和注釋. 這里的注釋我們可以看到, r0是cp15控制寄存器的內(nèi)容, r13存儲了完成后需要跳轉(zhuǎn)的虛擬地址(因?yàn)橥瓿珊髆mu已經(jīng)打開了,都是虛擬地址了).

第181行: .algin 5 這句是cache line對齊. 我們可以看到下面一行就是 __turn_mmu_on, 之所以
第182 - 183行:  __turn_mmu_on 的函數(shù)聲明. 這里我們可以看到, __turn_mmu_on 是緊接著上面第168行的跳轉(zhuǎn)指令的,只是中間在第181行多了一個(gè)cache line對齊.
        這么做的原因是: 下面我們要進(jìn)行真正的打開mmu操作了, 我們要把打開mmu的操作放到一個(gè)單獨(dú)的cache line上. 而在之前的"啟動條件"一節(jié)我們說了,I Cache是可以打開也可以關(guān)閉的,這里這么做的原因是要保證在I Cache打開的時(shí)候,打開mmu的操作也能正常執(zhí)行.
第184行: 這是一個(gè)空操作,相當(dāng)于nop. 在arm中,nop操作經(jīng)常用指令 mov rd, rd 來實(shí)現(xiàn).
        注意: 為什么這里要有一個(gè)nop,我思考了很長時(shí)間,這里是我的猜測,可能不是正確的:
        因?yàn)橹�前設(shè)置了頁表基地址(set ttb),到下一行(185行)打開mmu操作,中間的指令序列是這樣的:
        set ttb(第167行)
        branch(第168行)
        nop(第184行)
        enable mmu(第185行)
        對于arm的五級流水線: fetch - decode - execute - memory - write
        
        他們執(zhí)行的情況如下圖所示:



        這里需要說明的是,branch操作會在3個(gè)cycle中完成,并且會導(dǎo)致重新取指.
        
        從這個(gè)圖我們可以看出來,在enable mmu操作取指的時(shí)候, set ttb操作剛好完成.
     
        
第185行: 寫cp15的控制寄存器c1, 這里是打開mmu的操作,同時(shí)會打開cache等(根據(jù)r0相應(yīng)的配置)
第186行: 讀取id寄存器.
第187 - 188行: 兩個(gè)nop.
第189行: 取r13到pc中,我們前面已經(jīng)看到了, r13中存儲的是 __switch_data (在 arch/arm/kernel/head.S 91行),下面會跳到 __switch_data.

第187,188行的兩個(gè)nop是非常重要的,因?yàn)樵?85行打開mmu操作之后,要等到3個(gè)cycle之后才會生效,這和arm的流水線有關(guān)系.
因而,在打開mmu操作之后的加了兩個(gè)nop操作.

xpl

6. 切換數(shù)據(jù)

        在 arch/arm/kernel/head-common.S 中:

00014:         .type        __switch_data, %object
00015: __switch_data:
00016:         .long        __mmap_switched
00017:         .long        __data_loc                        @ r4
00018:         .long        __data_start                        @ r5
00019:         .long        __bss_start                        @ r6
00020:         .long        _end                                @ r7
00021:         .long        processor_id                        @ r4
00022:         .long        __machine_arch_type                @ r5
00023:         .long        cr_alignment                        @ r6
00024:         .long        init_thread_union + THREAD_START_SP @ sp
00025:
00026: /*
00027:  * The following fragment of code is executed with the MMU on in MMU mode,
00028:  * and uses absolute addresses; this is not position independent.
00029:  *
00030:  *  r0  = cp#15 control register
00031:  *  r1  = machine ID
00032:  *  r9  = processor ID
00033:  */
00034:         .type        __mmap_switched, %function
00035: __mmap_switched:
00036:         adr        r3, __switch_data + 4
00037:
00038:         ldmia        r3!, {r4, r5, r6, r7}
00039:         cmp        r4, r5                                @ Copy data segment if needed
00040: 1:        cmpne        r5, r6
00041:         ldrne        fp, [r4], #4
00042:         strne        fp, [r5], #4
00043:         bne        1b
00044:
00045:         mov        fp, #0                                @ Clear BSS (and zero fp)
00046: 1:        cmp        r6, r7
00047:         strcc        fp, [r6],#4
00048:         bcc        1b
00049:
00050:         ldmia        r3, {r4, r5, r6, sp}
00051:         str        r9, [r4]                        @ Save processor ID
00052:         str        r1, [r5]                        @ Save machine type
00053:         bic        r4, r0, #CR_A                        @ Clear 'A' bit
00054:         stmia        r6, {r0, r4}                        @ Save control register values
00055:         b        start_kernel        

第14, 15行: 函數(shù)聲明
第16 - 24行: 定義了一些地址,例如第16行存儲的是 __mmap_switched 的地址, 第17行存儲的是 __data_loc 的地址 ......
第34, 35行: 函數(shù) __mmap_switched
第36行: 取 __switch_data + 4的地址到r3. 從上文可以看到這個(gè)地址就是第17行的地址.
第37行:　依次取出從第17行到第20行的地址,存儲到r4, r5, r6, r7 中. 并且累加r3的值.當(dāng)執(zhí)行完后, r3指向了第21行的位置.
        對照上文,我們可以得知:
                r4 - __data_loc
                r5 - __data_start
                r6 - __bss_start
                r7 - _end
        這幾個(gè)符號都是在 arch/arm/kernel/vmlinux.lds.S 中定義的變量:

        00102: #ifdef CONFIG_XIP_KERNEL
        00103:         __data_loc = ALIGN(4);                /* location in binary */
        00104:         . = PAGE_OFFSET + TEXT_OFFSET;
        00105: #else
        00106:         . = ALIGN(THREAD_SIZE);
        00107:         __data_loc = .;
        00108: #endif
        00109:
        00110:         .data : AT(__data_loc) {
        00111:                 __data_start = .;        /* address in memory */
        00112:
        00113:                 /*
        00114:                  * first, the init task union, aligned
        00115:                  * to an 8192 byte boundary.
        00116:                  */
        00117:                 *(.init.task)
        
                ......
               
        00158:         .bss : {
        00159:                 __bss_start = .;        /* BSS                                */
        00160:                 *(.bss)
        00161:                 *(COMMON)
        00162:                 _end = .;
        00163:         }
        
        對于這四個(gè)變量,我們簡單的介紹一下:
        __data_loc 是數(shù)據(jù)存放的位置
        __data_start 是數(shù)據(jù)開始的位置
        
        __bss_start 是bss開始的位置
        _end 是bss結(jié)束的位置, 也是內(nèi)核結(jié)束的位置
        
        其中對第110行的指令講解一下: 這里定義了.data 段,后面的AT(__data_loc) 的意思是這部分的內(nèi)容是在__data_loc中存儲的(要注意,儲存的位置和鏈接的位置是可以不相同的).
        關(guān)于 AT 詳細(xì)的信息請參考 ld.info
        
        
        
        
第38行: 比較 __data_loc 和 __data_start
第39 - 43行: 這幾行是判斷數(shù)據(jù)存儲的位置和數(shù)據(jù)的開始的位置是否相等,如果不相等,則需要搬運(yùn)數(shù)據(jù),從 __data_loc 將數(shù)據(jù)搬到 __data_start.
        其中 __bss_start 是bss的開始的位置,也標(biāo)志了 data 結(jié)束的位置,因而用其作為判斷數(shù)據(jù)是否搬運(yùn)完成.

第45 - 48行:　是清除 bss 段的內(nèi)容,將其都置成0. 這里使用 _end 來判斷 bss 的結(jié)束位置.
第50行: 因?yàn)樵诘?8行的時(shí)候,r3被更新到指向第21行的位置.因而這里取得r4, r5, r6, sp的值分別是:
        r4 - processor_id
        r5 - __machine_arch_type
        r6 - cr_alignment
        sp - init_thread_union + THREAD_START_SP

        processor_id 和 __machine_arch_type 這兩個(gè)變量是在 arch/arm/kernel/setup.c 中 第62, 63行中定義的.
        cr_alignment 是在 arch/arm/kernel/entry-armv.S 中定義的:

        00182:         .globl        cr_alignment
        00183:         .globl        cr_no_alignment
        00184: cr_alignment:
        00185:         .space        4
        00186: cr_no_alignment:
        00187:         .space        4
        
        init_thread_union 是 init進(jìn)程的基地址. 在 arch/arm/kernel/init_task.c 中:

        00033: union thread_union init_thread_union
        00034:         __attribute__((__section__(".init.task"))) =
        00035:                 { INIT_THREAD_INFO(init_task) };        

        對照 vmlnux.lds.S 中的 的117行,我們可以知道init task是存放在 .data 段的開始8k, 并且是THREAD_SIZE(8k)對齊的
第51行: 將r9中存放的 processor id (在arch/arm/kernel/head.S 75行) 賦值給變量 processor_id
第52行: 將r1中存放的 machine id (見"啟動條件"一節(jié))賦值給變量　__machine_arch_type
第53行: 清除r0中的 CR_A 位并將值存到r4中. CR_A 是在 include/asm-arm/system.h 21行定義, 是cp15控制寄存器c1的Bit[1](alignment fault enable/disable)
第54行: 這一行是存儲控制寄存器的值.
        從上面 arch/arm/kernel/entry-armv.S 的代碼我們可以得知.
        這一句是將r0存儲到了 cr_alignment 中,將r4存儲到了 cr_no_alignment 中.
第55行: 最終跳轉(zhuǎn)到start_kernel