蜗窝科技

你可以先用arm-linux-objdump的命令看看是否你编译的异常向量表就是这样的。 指令“EAFFFFFE”应该是被翻译成一个跳转指令，跳转范围是24-bit的立即数，对于“EAFFFFFE”，显然还没有填入这个立即数，一般而言，当你编译出.o文件的时候，异常向量表的反汇编结果就是： __vectors_start(): arch/arm/kernel/entry-armv.S:1134 0: eaffffff b 4 <__vectors_start+0x4> arch/arm/kernel/entry-armv.S:1135 4: eafffffe b 1a0 <vector_und> arch/arm/kernel/entry-armv.S:1136 8: e59ffff0 ldr pc, [pc, #4080] ; 1000 <.vectors+0x1000> arch/arm/kernel/entry-armv.S:1137 c: eafffffe b 120 <vector_pabt> arch/arm/kernel/entry-armv.S:1138 10: eafffffe b a0 <vector_dabt> arch/arm/kernel/entry-armv.S:1139 14: ea000086 b 220 <vector_swi> arch/arm/kernel/entry-armv.S:1140 18: eafffffe b 20 <vector_irq> arch/arm/kernel/entry-armv.S:1141 1c: ea000087 b 224 <vector_fiq_offset> 这时候，还没有link，因此地址还是reallocated。当连接完成，“EAFFFFFE”会被修正，其24-bit的立即数的位置会被填入真正跳转的地址，例如： __vectors_start(): c000e4e4: ef9f0000 svc 0x009f0000 c000e4e8: ea0000dd b c000e864 <early_mem+0x8> c000e4ec: e59ff410 ldr pc, [pc, #1040] ; c000e904 <early_initrd+0x38> c000e4f0: ea0000bb b c000e7e4 <parse_tag_serialnr+0x8> c000e4f4: ea00009a b c000e764 <parse_tag_ramdisk+0x20> c000e4f8: ea0000fa b c000e8e8 <early_initrd+0x1c> c000e4fc: ea000078 b c000e6e4 <parse_tag_videotext+0x20> c000e500: ea0000f7 b c000e8e4 <early_initrd+0x18> 我建议你一步一步的检查： 1、先检查你编译出来的kernel image 2、完成early_trap_init之后，检查看看exception table的copy的对不对 3、是否运行时，有些代码误操作了exception table

hi linuxer 我现在遇到一个问题，就是很多时候我看到0xffff000c的地方是一个机器码为EAFFFFFE也就是 while（1）一样的指令，我不知道什么情况下vector table 会变成这样，不知道你有什么思路没有

@741342765：我参与的平台比较多，但2440没有用过，我用过2410和2451这两个SOC

博主，都是用2440的开发板写的代码吗？

@linuxer：感謝linuxer的說明，看來我原先的理解應該是正確的 再多請教一個問題，在中斷時序圖T64到T126的中間，如果有更高優先權的外設P發生了中斷，nFIQCPU在這段時間內是不是又會assert low? 另外，是的，我來自台灣。感謝蝸窩提供這麼多優質文章，這裡每篇文章我都慢慢吸收，再配著內核代碼看，真的是種享受。 以前很急著想要短時間看很多東西，理解不紮實，結果最後也是都忘記。 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 目前回复的次数有限制，因此我重新开一个评论。 我的理解：T64到T126之间，如果有更高优先级的中断进来，nFIQCPU会assert low的，当然，对于linux kernel，这时候由于关中断不能响应。 欢迎来自台湾的朋友，其实我现在就职于一家台湾公司，也算是有缘了。大家都是对linux kernel有兴趣才走到一起，多交流，多提出问题，一起进步吧！

@linuxer：感謝linuxer的說明，看來我原先的理解應該是正確的 再多請教一個問題，在中斷時序圖T64到T126的中間，如果有更高優先權的外設P發生了中斷，nFIQCPU在這段時間內是不是又會assert low? 另外，是的，我來自台灣。感謝蝸窩提供這麼多優質文章，這裡每篇文章我都慢慢吸收，再配著內核代碼看，真的是種享受。 以前很急著想要短時間看很多東西，理解不紮實，結果最後也是都忘記。

@海：不用客气，我的理解也不一定准确，可以多讨论。

@海：好的，欢迎多讨论。

@Xiang：可能我这里描述的不清楚。"当然，我上面的话对于linux kernel而言是正确的"，这里“上面的话”是指上一个回复中的话，具体如下： ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 一个中断抢占的窗口size是从发生中断的那一刻到ack中断前16个clock这段时间。之所以抢占窗口的end point是ack中断前16个clock，是因为GIC需要时间（16个clock）来识别该中断（更新GICC_IAR寄存器） ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 对于GIC而言（从硬件角度看），它的抢占就是更新GICC_IAR寄存器病assert CPU，具体CPU是否响应就不是我家的事情了。 对于linux kernel而言（从软件角度看），抢占是中断handler的抢占，因此，上面++++符号围起来的那段描述对linux kernel而言是正确的，因为一旦读出了GICC_IAR寄存器，中断handler将不会再被抢占，因为整个handler中都是关闭中断的。 BTW，您使用繁体中文，冒昧的问一句：你是不是来自台湾或者香港？

上篇文章的这些counter，很早在看内核文档时候，那时候还不了解，这次明白了。 谢谢！