wince5.0的中断向量地址问题

kk7718

wince5.0的中断向量地址问题 [复制链接]

shuiyan　大哥你好！
　小弟最近在搞OAL里的中断函数OALTimerInit遇到个问题，是这样的：
　我在private下的armtrap.s里发现了中断的异常跳转表
VectorInstructions
        ldr     pc, [pc, #0x3E0-8]              ; reset
        ldr     pc, [pc, #0x3E0-8]              ; undefined instruction
        ldr     pc, [pc, #0x3E0-8]              ; SVC
        ldr     pc, [pc, #0x3E0-8]              ; Prefetch abort
        ldr     pc, [pc, #0x3E0-8]              ; data abort
        ldr     pc, [pc, #0x3E0-8]              ; unused vector location
        ldr     pc, [pc, #0x3E0-8]              ; IRQ
        ldr     pc, [pc, #0x3E0-8]              ; FIQ
和
VectorTable
        DCD     -1                              ; reset
        DCD     UndefException                  ; undefined instruction
        DCD     SWIHandler                      ; SVC
        DCD     PrefetchAbort                   ; Prefetch abort


        DCD     DataAbortHandler                ; data abort


        DCD     -1                              ; unused vector
        DCD     IRQHandler                      ; IRQ
        DCD     FIQHandler                      ; FIQ

        END

上面说是wince在异常时选择跳转到高向量地址0xFFFF0000处，此处放了VectorInstructions，然后在0xFFFF03E0处放置了VectorTable，这个我还能理解，可是不明白：
１：当运行wince的ARM进入异常时，ARM是工作在虚拟地址模式还是物理地址模式？
２：一般ARM采用0x00-０x1c作为异常地址时，我可以直接把异常跳转表放在0地址就可以了,而wince用的是高向量地址，上面的高向量地址我觉得应该是物理地址，我的ARM在0xFFFF0000处是reserved的，不能使用啊，不知你是怎么作到的？
３：如下所示是wince在高向量地址处的放置情况，而我的ARM在0xFFFD0000-0xFFFFCC00 全是reserved 不知怎样才能把数据放上去？
　　; High memory layout:
;       FFFD0000 - first level page table (uncached)
;       FFFD4000 - not used
;       FFFE0000 - disabled for protection
;       FFFF0000 - exception vectors
;       FFFF03E0 - exception vector jump table
;       FFFF0400 - not used (r/o)
;       FFFF1000 - disabled for protection
;       FFFF2000 - r/o (physical overlaps with vectors)
;       FFFF2400 - Interrupt stack (1k)
;       FFFF2800 - r/o (physical overlaps with Abort stack)
;       FFFF3000 - disabled for protection
;       FFFF4000 - r/o (physical memory overlaps with vectors & intr. stack & FIQ stack)
;       FFFF4900 - Abort stack (2k - 256 bytes)
;       FFFF5000 - disabled for protection
;       FFFF6000 - r/o (physical memory overlaps with vectors & intr. stack)
;       FFFF6800 - FIQ stack (256 bytes)
;       FFFF6900 - r/o (physical memory overlaps with Abort stack)
;       FFFF7000 - disabled
;       FFFFC000 - kernel stack
;       FFFFC800 - KDataStruct
;       FFFFCC00 - r/o for protection (2nd level page table for 0xFFF00000)

        ^ 0xFFFD0000
FirstPT         # 0x4000
                # 0x4000
                # 0x8000
                # 0x10000       ; not mapped
ExVector        # 0x1000
                # 0x1400        ; not mapped
                # 0x0400        ; 1K interrupt stack
IntStack        # 0x2000        ; not mapped                    (ffff2800)
                # 0x0100        ; not mapped (FIQ stack)        (ffff4800)
                # 0x0700        ; 2K-256 abort stack            (ffff4900)
AbortStack      # 0x1800        ; not mapped                    (ffff5000)
                # 0x0100        ; not mapped (FIQ stack)        (ffff6800)
FIQStack        # 0xC000-0x6900 ; not mapped                    (ffff6900)
KDBase          # 0x07E0        ; 2K-32 kernel stack
KStack          # 0x0020        ; temporary register save area
KData           # 0x400         ; kernel data area


恳请shuiyan大哥赐教啊，万分感谢！！！！

情为谁牵

刚想了一下,觉得高向量地址0xFFFF0000处应该是个虚拟地址,唯一说的通的方法就是应该把一块RAM/FLASH物理地址通过
OEMaddresstable数组给映射到0xFFFF0000处,如下:

DCD     AT91SAM9261EK_VA_BASE_SRAM,    AT91SAM9261EK_BASE_SDRAM, 1      ;INTERNAL SRAM (160KB).

其中AT91SAM9261EK_VA_BASE_SDRAM=0xFFF00000,AT91SAM9261EK_BASE_SDRAM是SDRAM的最后1M的物理地址.一般都是将0x80000000-0xA0000000,0xA0000000-0xC0000000这两段虚拟地址给映射到物理地址空间，不知可不可以这样映射wince的其他虚拟地址空间？


自己顶！

holystw

我记得有一本书上对内存映射写得比较好的,暂时忘了书名,下次记得发给你

何贵君

没有做过BSP。
楼主赞一个。

不过我觉得这个wince中断向量是虚拟地址。
编译的时候受bib文件控制的，BIB文件里面是虚拟地址，
编译出来不指定就是虚拟地址的。

你使用什么来调试啊？

如果你能搞出来能学很多知识，但是这样一个人搞真的会要很长时间哦。
这芯片不至于 什么样板都没有吧。

MEGANTWJ

回hudaweikevin :
   如果那样的话就先谢谢啦,呵呵

fu200621140

回gooogleman :
  "不过我觉得这个wince中断向量是虚拟地址。
编译的时候受bib文件控制的，BIB文件里面是虚拟地址，
编译出来不指定就是虚拟地址的。 "
兄弟所言甚是,刚才仔细看了以下armtrap.s里的kernelStart开头处的几个虚实地址转换,确定是为虚拟地址了.还得继续研究下,呵呵

现在kitl还没起来,只能每次编译好nk.bin再通过sboot下下去运行,点点灯了,很麻烦费时啊,等到了oalkitlstart还得向你请教呢,哈哈

没买学习板,只有个bsp包,硬着头皮学了

jingon

这个地址确认是：虚拟地址。为此我曾经专门请教过高人，不过到最后我还是没搞懂:-( 囧啊。

tyyuy

KITL我的还有问题，估计以后还要回来整整。

这个编译地址的问题我看多了代码觉得是这么回事。

damu

KITL我的还有问题，估计以后还要回来整整。

这个编译地址的问题我看多了代码觉得是这么回事。

eugenew

雖然不是 shuiyan, 但看了手癢, 越俎代庖, 代為回答一下, 希望不會太突兀

ARM CP15 R1 V bit(bit 13) = Base location of exception registers
0 = Low address = 0x00000000
1 = High address = 0xFFFF0000

所以 WinCE 啟動後, 會將該 bit 設為 1, 大多數 ARM 的 CPU 在 RESET 後, default is 0.

After windows ce startup, every address is virtual address. Windows CE will map the kernel code to 0xFFFF0000 virtual address to handle exception.

This address is handle by private code, so it's not assign in config.bib.

回歸問題的本質, OALTimerInit 有問題, 應該不用去追 exception handler 吧.

Paul, Chao @ Techware

ljsvws

ARM CP15:c1有一个位可以设中断向量使用高地址还是低地址。理论上应该是物理地址和虚拟地址都可以，但是实践中很少有人会在这个地址段接一块内存吧，因此最常见的做法是通过地址映射来使用这个高地址，这也是CE的做法。所以你看到的这个地址是虚拟地址。
我也很奇怪你OALTimerInit有问题怎么研究起中断向量地址来了。

fanzi

MMU开了就是虚拟, 关了就是物理.

dengqiang

这里有必要澄清一下,呵呵

我发现在OALTimerInit中将要调用AT91SAM926x_InitSystemTimer,这个函数就是按照设定的时间(我设为5ms)来产生系统所需的tick,利用cpu内部的周期性定时器到时间就要产生一个tick中断,现在发现定时器已经可以工作,但是无法进入armtrap.s里的IRQHandler,也就是说并没有跳到指定的0xFFFF0000.所以就研究起中断向量地址来了,事情就是这样的.

多谢paul_chao 兄指教!你所说的那个决定位我明白,应该就是下面的0x3200地方吧,呵呵
mfc15   r1, c1
        orr     r1, r1, #0x007F                 ; changed to read-mod-write for ARM920 Enable: MMU, Align, DCache, WriteBuffer
        orr     r1, r1, #0x3200                 ; vector adjust, ICache, ROM protection
        ldr     r0, VirtualStart
        cmp     r0, #0                          ; make sure no stall on "mov pc,r0" below
        mtc15   r1, c1                          ; enable the MMU & Caches
        mov     pc, r0                          ;  & jump to new virtual address

我以前就是按照书上所说的认为wince在异常时选择跳转到高向量地址0xFFFF0000处，此处放了VectorInstructions，然后在0xFFFF03E0处放置了VectorTable，但昨天特意在armtrap.s中kernelStart开头的PTs地址转换后面如下:
convert base of PTs to Physical address
        ldr     r4, =PTs                        ; (r4) = virtual address of FirstPT
        mov     r0, r4                          ; (r0) = virtual address of FirstPT
        mov     r1, r11                         ; (r1) = &MemoryMap (2nd argument to PaFromVa)
        bl      PaFromVa
        mov     r10, r0                         ; (r10) = ptr to FirstPT (physical)
加入了一段指令如下:
LDR     r4,=0x300000
        STR     r10,[r4]
        LDR     r4,=0x300004
        add     r7, r10, #ExceptionVectors-PTs  ; (r8) = ptr to vector page
        STR     r7,[r4]
loop2      
       B       loop2  

就是为了看看r10的值是否就是FirstPT虚拟地址(0xFFFD0000)的对应物理地址,因为这个将影响到
后来的在0xFFFF0000处放置VectorInstructions,但是发现并不是它的物理地址(我将它的值暂存进RAM观察到的),同时
r7也不是希望的0xFFFF0000对应的物理地址.就是不明白既然是放在高向量地址,它怎样和0xFFFF0000建立联系??


建立exception vectors的过程如下:下面的r8就是通过 add     r8, r10, #ExceptionVectors-PTs来得到的.
add     r7, pc, #VectorInstructions - (.+8)
        ldmia   r7!, {r0-r3}                    ; load 4 instructions
        stmia   r8!, {r0-r3}                    ; store the 4 vector instructions
        ldmia   r7!, {r0-r3}                    ; load 4 instructions
        stmia   r8!, {r0-r3}                    ; store the 4 vector instructions
  IF {FALSE}
        sub     r0, r8, #8*4
        mov     r1, #8  ; dump 8 words
        CALL    WriteHex
  ENDIF
        ; convert VectorTable to Physical Address
        ldr     r0, =VectorTable                ; (r0) = VA of VectorTable
        mov     r1, r11                         ; (r1) = &OEMAddressTable[0]
        bl      PaFromVa
        mov     r7, r0                          ; (r7) = PA of VectorTable
        add     r8, r8, #0x3E0-(8*4)            ; (r8) = target location of the vector table
        ldmia   r7!, {r0-r3}
        stmia   r8!, {r0-r3}
        ldmia   r7!, {r0-r3}
        stmia   r8!, {r0-r3}

bolzman

你在 create BSP 嗎? 不然怎麼會遇到這個問題

你 intr.c 內該設定好的都設好了嗎?? 還是在 OEMInit 內就 Hang 住了.

建議你將 KITL 連起來, Build Tiny Kernel 的 debug mode.

比起追 armtrap.s 可能會比較有進度.

Paul, Chao @ Techware

loveitboy

是在搞bsp,昨天终于发现问题所在,原来在调用ARMInit之前的汇编里已经禁止IRQ和FIQ中断了,所以无法进入IRQHandler里,后来我发现在OEMInit中调用了INTERRUPTS_ON函数,它是汇编函数可以使能IRQ中断,调用了该函数后就可以了,呵呵

问题是解决了,可还是有个疑问:
上面的建立exception vectors过程中的r8是怎样和0xFFFF0000建立联系的?按照我的理解它的值应该是ExceptionVectors的物理地址,而不是希望的ExVector的物理地址啊?

希望大家多多指教啊!谢谢!!

wang72175

原来这样!!
刚才仔细看了一下ARM的MMU 手册里的二级映射过程,才明白exception vectors是怎样和0xFFFF0000建立起虚实对应关系的.先通过coarse page table映射一级页表描述符,再通过small page 映射2级描述符,这里的small page为4k大小,正好对应exception vectors处的范围,并将同一个描述符映射到了4个不同的虚拟地址:0xFFFF0000,0xFFFF2400,
0xFFFF4900,0XFFFF6800!
以前总是想通过修改config.bib来修改他们的影射关系,现在看来真是可笑啊,呵呵

结贴去

belongto

哈哈，恭喜楼主，理解了
MMU。

哈哈，我去年看过。但是还是有些疑惑。这里没有什么人看，比较难搞。就放下了。

transhuman

哈, 若是要寫 eboot, 則要自己建立該 coarse page table, 且此時 Exception vector 就會落在 0x00000000.

config.bib 所能用的位址, 其實全在 0x80000000 ~ 0x9FFFFFFF 內, 其它的位址 (except 0xA0000000~0xBFFFFFFF) 全都是由作業系統自己運用, 其實 wince 也就是用該技巧來達成的.

Paul, Chao @ Techware

0442323

mark

manman9258

eeworld啥时候这么垃圾了,不登陆看不了得分的帖子,shit