CE5.0 - eboot汇编Startup.s中MMU设置流程详细分析

时间:2022-04-28 18:04:37

CE5.0 - eboot汇编Startup.s中MMU设置流程详细分析  
以下为SMDK开发板startup.s部分启动代码.  
;-------------------------------------------------------------------------------  
MemoryMap EQU 0x2a4  
BANK_SIZE EQU 0x00100000 ; 1MB per bank in MemoryMap array  
BANK_SHIFT EQU 20  
 
; Define RAM space for the Page Tables:  
;  
PHYBASE EQU 0x30000000 ; physical start  
PTs EQU 0x30010000 ; 1st level page table address (PHYBASE + 0x10000)  
                                        ; save room for interrupt vectors.  
;------------------------------------------------------------------------------  
; Copy boot loader to memory  
        ands r9, pc, #0xFF000000 ; see if we are in flash or in ram  
//如果高8字节非0,那么说明pc已经在ram,否则说明现在pc位于reset之后的0x00000000地址区间[luther.gliethttp]  
        bne %f20 ; go ahead if we are already in ram//高8字节非0,说明eboot已在DDR中,跳到下面的20标号  
 
        ; This is the loop that perform copying.  
        ldr r0, = 0x38000 ; offset into the RAM   
        add r0, r0, #PHYBASE ; add physical base //eboot最终的物理地址为0x30038000,这也就是PLATFORM/SMDK2440A/Src/Bootloader/Eboot_usb/boot.bib中定义的  
//eboot链接地址EBOOT 8c038000 00016800 RAMIMAGE //一个.bib允许由一个RAMIMAGE类型段,生成一个对应的.bin文件,之后由romimage.exe生成.nb0同时填充eboot的pTOC全局变量指针[luther.gliethttp]  
        mov r1, r0 ; (r1) copy destination  
//因为s3c2440在nand启动时,会将nand中前4k数据读取到s3c2440内部的4k ram中,同时ram映射成0地址,cpu  
//跳转到ram开始执行从nand读取的前4k代码数据,于是读取位于ram中0地址之后的4k数据就等同于读取了nand的前4k数据[luther.gliethttp].  
        ldr r2, =0x0 ; (r2) flash started at physical address 0  
        ldr r3, =0x10000 ; counter (0x40000/4)//循环读取4k字节  
10 ldr r4, [r2], #4  
        str r4, [r1], #4  
        subs r3, r3, #1  
        bne %b10  
        ; Restart from the RAM position after copying.  
        mov pc, r0 //跳转到物理地址0x30038000重新执行上面的reset代码,再次执行时因为已经位于ram,所以将执行上面的bne %f20语句[luther.gliethttp]  
        nop //为流水线添加可能存在的指令最大空取次数  
        nop  
        nop  
        ; Shouldn't get here.  
        b       .  
        INCLUDE oemaddrtab_cfg.inc  //这就是eboot的mmu映射表,位于PLATFORM/SMDK2440A/Src/Inc/oemaddrtab_cfg.inc  
/* 
        EXPORT  g_oalAddressTable[DATA] 
g_oalAddressTable 
        DCD     0x80000000, 0x32000000, 32      ; 32 MB DRAM BANK 6 
        DCD     0x82000000, 0x08000000, 32      ; 32 MB SROM(SRAM/ROM) BANK 1 
        DCD     0x84000000, 0x10000000, 32      ; nGCS2: PCMCIA/PCCARD 
        DCD     0x86000000, 0x18000000, 32      ; 32 MB SROM(SRAM/ROM) BANK 3 
        DCD     0x88000000, 0x20000000, 32      ; 32 MB SROM(SRAM/ROM) BANK 4 
        DCD     0x8A000000, 0x28000000, 32      ; 32 MB SROM(SRAM/ROM) BANK 5 
        DCD     0x8C000000, 0x30000000, 32      ; 32 MB DRAM BANK 6 
        DCD     0x90800000, 0x48000000,  1      ; Memory control register 
        DCD     0x90900000, 0x49000000,  1      ; USB Host register 
        DCD     0x90A00000, 0x4A000000,  1      ; Interrupt Control register 
        DCD     0x90B00000, 0x4B000000,  1      ; DMA control register 
        DCD     0x90C00000, 0x4C000000,  1      ; Clock & Power register 
        DCD     0x90D00000, 0x4D000000,  1      ; LCD control register 
        DCD     0x90E00000, 0x4E000000,  1      ; NAND flash control register 
        DCD     0x90F00000, 0x4F000000,  1      ; Camera control register 
        DCD     0x91000000, 0x50000000,  1      ; UART control register 
        DCD     0x91100000, 0x51000000,  1      ; PWM timer register 
        DCD     0x91200000, 0x52000000,  1      ; USB device register 
        DCD     0x91300000, 0x53000000,  1      ; Watchdog Timer register 
        DCD     0x91400000, 0x54000000,  1      ; IIC control register 
        DCD     0x91500000, 0x55000000,  1      ; IIS control register 
        DCD     0x91600000, 0x56000000,  1      ; I/O Port register 
        DCD     0x91700000, 0x57000000,  1      ; RTC control register 
        DCD     0x91800000, 0x58000000,  1      ; A/D convert register 
        DCD     0x91900000, 0x59000000,  1      ; SPI register 
        DCD     0x91A00000, 0x5A000000,  1      ; SD Interface register 
        DCD     0x92000000, 0x00000000, 32      ; 32 MB SROM(SRAM/ROM) BANK 0 
        DCD     0x00000000, 0x00000000,  0      ; end of table 
*/   
        ; Compute physical address of the OEMAddressTable.  
20      add     r11, pc, #g_oalAddressTable - (. + 8)  
        ldr     r10, =PTs                ; (r10) = 1st level page table  
0x20000000  
        ; Setup 1st level page table (using section descriptor)       
        ; Fill in first level page table entries to create "un-mapped" regions  
        ; from the contents of the MemoryMap array.  
        ;  
        ;   (r10) = 1st level page table  
        ;   (r11) = ptr to MemoryMap array  
//PTR的地址大家都选在了DDR开始的offset处,ce为64k偏移,linux也是这样做的  
//然后第1级MMU入口为pc地址的高14位(过滤掉低18位)[luther.gliethttp]  
//比如0x80000000地址对应的第1级MMU入口偏移为0x80000000 >> 18 = 0x2000  
        add     r10, r10, #0x2000       ; (r10) = ptr to 1st PTE for "unmapped space" 
//r10存放0x80000000虚拟地址在PTR中的对应地址  
        mov     r0, #0x0E               ; (r0) = PTE for 0: 1MB cachable bufferable //有高速缓存C和写缓冲B  
        orr     r0, r0, #0x400          ; set kernel r/w permission  
25      mov     r1, r11                 ; (r1) = ptr to MemoryMap array  
          
30      ldr     r2, [r1], #4            ; (r2) = virtual address to map Bank at  
        ldr     r3, [r1], #4            ; (r3) = physical address to map from  
        ldr     r4, [r1], #4            ; (r4) = num MB to map  
        cmp     r4, #0                  ; End of table?  
        beq     %f40    //表示cachable地址0x80000000~0xa0000000映射MMU创建完毕,表结尾,前跳到40标号,创建对应的uncached映射MMU[luther.gliethttp]  
        ldr     r5, =0x1FF00000  
        and     r2, r2, r5              ; VA needs 512MB, 1MB aligned.  //对va虚拟地址进行512M对齐[luther.gliethttp]  
//也就是r2的上限值不能超过0x20000000即512M,因为r10现在指向1级映射表的0x80000000虚拟地址,  
//又因为0x80000000+0x20000000=0xa0000000开始地址存放的是uncached地址,所以这里要做512M数据限制[luther.gliethttp]  
        ldr     r5, =0xFFF00000  
        and     r3, r3, r5              ; PA needs 4GB, 1MB aligned.    //对pa物理地址进行4G对齐  
        add     r2, r10, r2, LSR #18  
        add     r0, r0, r3              ; (r0) = PTE for next physical page //在MMU控制flag基础上追加映射到的pa物理地址[luther.gliethttp]  
35      str     r0, [r2], #4            //存到r2对应的PTR偏移中  
        add     r0, r0, #0x00100000     ; (r0) = PTE for next physical page //1M递增,因为1<<18=256K,而每一个pte描述4k页,所以最终描述256k*4k=1M地址空间[luther.gliethttp]  
        sub     r4, r4, #1              ; Decrement number of MB left   
        cmp     r4, #0  
        bne     %b35                    ; Map next MB   //遍历到该region结束  
        bic     r0, r0, #0xF0000000     ; Clear Section Base Address Field  
        bic     r0, r0, #0x0FF00000     ; Clear Section Base Address Field//清空r0中的地址信息[lutehr.gliethttp]  
        b       %b30                    ; Get next element  //继续创建oemaddrtab_cfg.inc描述的下一region[luther.gliethttp]  
//创建对应的0xa0000000开始的uncached映射MMU表   
40      tst     r0, #8        
//比较C高速缓存是否仍然置位,如果仍然置位了,那么说明还没有执行uncached创建,如果C位已经清0,那么说明,uncached循环也执行完毕了,所以跳回到25标号继续创建[luther.gliethttp]  
        bic     r0, r0, #0x0C           ; clear cachable & bufferable bits in PTE//清除B写缓冲和C高速缓存[luther.gliethttp]  
        add     r10, r10, #0x0800       ; (r10) = ptr to 1st PTE for "unmapped uncached space"//r10现在对应0x80000000虚拟地址的PTR起始地址,hex(0x20000000>>18)为0x800,  
//所以r10 = r10 + 0x800;之后r10指向了0xa0000000虚拟地址对应的PTR起始地址[luther.gliethtp]  
        bne     %b25                    ; go setup PTEs for uncached space  
//ok,现在0x80000000 cachable空间和0xa0000000 uncached空间都已经创建完毕了[luther.gliethttp]  
        sub     r10, r10, #0x3000       ; (r10) = restore address of 1st level page table//该句好像有问题,不过还好后面用到r10之前,又对r10进行了重新赋值,所以也更说明,该句操作无意义[luther.gliethttp]  
//接下来为虚拟0地址建立cachable和uncached映射[lutehr.gliethttp]  
        ; Setup mmu to map (VA == 0) to (PA == 0x30000000).  
        ldr     r0, =PTs                ; PTE entry for VA = 0  
        ldr     r1, =0x3000040E         ; uncache/unbuffer/rw, PA base == 0x30000000//以C,B均开启的方式映射虚拟地址0到pa物理地址0x30000000  
        str     r1, [r0]  
        ; uncached area.  
        add     r0, r0, #0x0800         ; PTE entry for VA = 0x0200.0000 , uncached//接下来的0x2000000虚拟地址被映射为虚拟0地址的uncached起始地址[luther.gliethttp]  
        ldr     r1, =0x30000402         ; uncache/unbuffer/rw, base == 0x30000000//以C,B均不开启的方式映射虚拟地址0到pa物理地址0x30000000  
        str     r1, [r0]  
//经过上面设置可以看到  
//虚拟地址0对应0x30000000的cachable  
//虚拟地址0x2000000对应0x30000000的uncached.[luther.gliethttp]  
        ; Comment:  
        ; The following loop is to direct map RAM VA == PA. i.e.   
        ;   VA == 0x30XXXXXX => PA == 0x30XXXXXX for S3C2400  
        ; Fill in 8 entries to have a direct mapping for DRAM  
        ;  
        ldr     r10, =PTs               ; restore address of 1st level page table  
        ldr     r0,  =PHYBASE           //PHYBASE为0x30000000,将虚拟地址映射到相同的物理地址  
        add     r10, r10, #(0x3000 / 4) ; (r10) = ptr to 1st PTE for 0x30000000 //就是(0x30000000 >> 16) >> 2即(0x30000000 >> 16) / 4 [luther.gliethttp]  
//现在r10指向了和DDR地址相等的PA地址对应的PTR地址处  
        add     r0, r0, #0x1E           ; 1MB cachable bufferable  
        orr     r0, r0, #0x400          ; set kernel r/w permission  
        mov     r1, #0   
        mov     r3, #64                 //映射64M空间,因为我们的物理DDR只有64M(见上面的oemaddrtab_cfg.inc表图),不能大于512,因为下面只支持到512次循环(r1为循环次数,每循环1次,创建1M空间映射表)[luther.gliethtp]  
45      mov     r2, r1                  ; (r2) = virtual address to map Bank at  
        cmp     r2, #0x20000000:SHR:BANK_SHIFT  //0x20000000>>20=512M,  
        add     r2, r10, r2, LSL #BANK_SHIFT-18 //add r2, r10, r2, 4即r2 = r10 + r2*4;正好为PTR操作时的4字节对齐边界[luther.gliethttp]  
        strlo   r0, [r2]                        //如果还没有操作到512M,那么填充PTR,如果现在映射操作已经操作过了512M大小,那么忽略  
        add     r0, r0, #0x00100000     ; (r0) = PTE for next physical page  
        subs    r3, r3, #1  
        add     r1, r1, #1  
        bgt     %b45  
        ldr     r10, =PTs               ; (r10) = restore address of 1st level page table  
        ; The page tables and exception vectors are setup.  
        ; Initialize the MMU and turn it on.  
        mov     r1, #1  
        mcr     p15, 0, r1, c3, c0, 0   ; setup access to domain 0  
        mcr     p15, 0, r10, c2, c0, 0  
        mcr     p15, 0, r0, c8, c7, 0   ; flush I+D TLBs    //flush所有MMU相关空间  
        mov     r1, #0x0071             ; Enable: MMU       //设置打开MMU标志到r1  
        orr     r1, r1, #0x0004         ; Enable the cache  //设置打开cache标志到r1  
        ldr     r0, =VirtualStart       //取出VirtualStart编译期间得到的虚拟地址值,在0x30038000~0x30038000+eboot_size之间[luther.gliethtp]  
        cmp     r0, #0                  ; make sure no stall on "mov pc,r0" below //执行该比较,使r0踏实的读入VirtualStart数值  
        mcr     p15, 0, r1, c1, c0, 0   //将MMU设置标志写入p15协处理器,生效设置[luther.gliethttp]  
        mov     pc, r0                  ;  & jump to new virtual address //跳转过去,此刻之后MMU已经打开,所有允许操作的虚拟地址都在PLATFORM/SMDK2440A/Src/Inc/oemaddrtab_cfg.inc中定义[luther.gliethttp]  
        nop  
        ; MMU & caches now enabled.  
        ;   (r10) = physcial address of 1st level page table  
        ;  
VirtualStart  
        mov     sp, #0x8C000000         //设置栈空间,从这里来看,sp栈顶对应的DDR物理地址为0x30030000,然后向下生长,从boot.bib中  
/* 
MEMORY 
;   Name     Start     Size      Type 
;   -------  --------  --------  ---- 
    ARGS     8c020800  00000800  RESERVED 
    BINFS    8c021000  00005000  RESERVED 
    RAM      8c026000  00006000  RAM     
    STACK    8c02c000  00004000  RESERVED  //0x2c000+0x4000=0x30000 保留该16K地址空间用作eboot的sp栈空间 
    EBOOT    8c038000  00016800  RAMIMAGE 
*/ 
可以看到sp栈空间由.bib保留,位于0x30030000~0x3002c000,栈sp从0x30030000开始向下生长[luther.gliethttp]  
        add     sp, sp, #0x30000        ; arbitrary initial super-page stack pointer  
        b       main //跳转到main主函数, 


本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/UN_ChairMan/archive/2010/12/16/6081151.aspx