英文:
What is the reason of this data abort in ZYNQ 7000 (armA9)?
问题
我使用的是ZYNQ 7000 SoC，它有两个arm A9核心，core0和core1。有时候在我的core1代码（裸机）中会发生数据异常。在默认的数据异常处理程序Xil_DataAbortHandler中，它显示FaultStatus为0x1e，DataAbortAddr为0x2001bc9c。
我使用readelf -s a.elf来获取符号表，发现没有任何函数地址匹配到确切的0x2001bc9c。最接近的函数是位于地址2001bc64的Xil_L2CacheDisable。这是否意味着数据异常来自于Xil_L2CacheDisable？这个函数是由Xilinx提供的bsp库函数，我将其用于直接访问两个核心的共享内存。
全局变量u32 DataAbortAddr在以下汇编中被捕获：
DataAbortHandler: /* 数据异常处理程序 */
#ifdef CONFIG_ARM_ERRATA_775420
dsb
#endif
stmdb sp!,{r0-r3,r12,lr} /* 保存状态，来自编译代码 */
ldr r0, =DataAbortAddr
sub r1, lr, #8
str r1, [r0] /* 存储导致数据异常的指令 */
bl DataAbortInterrupt /* DataAbortInterrupt: 在此调用C函数 */
ldmia sp!,{r0-r3,r12,lr} /* 从编译代码中恢复状态 */
subs pc, lr, #8 /* 指向导致数据异常的指令 */
FaultStatus 在DataAbortInterrupt 中被捕获：
#define mfcp(rn) ({u32 rval = 0U; \
__asm__ __volatile__(\
"mrc " rn "\n"\
: "=r" (rval)\
);\
rval;\
})
#endif
#define XREG_CP15_DATA_FAULT_STATUS "cp15:0:c5:c0:0"
u32 FaultStatus = mfcp(XREG_CP15_DATA_FAULT_STATUS);
英文:
I'm using ZYNQ 7000 SoC which has 2 arm A9 cores, core0 and core1. Sometimes a data abort happens in my core1 code (bare metal). At the default data abort handler Xil_DataAbortHandler, it says the FaultStatus is 0x1e, and the DataAbortAddr is 0x2001bc9c.
I use readelf -s a.elf to get the symbol table, and find no function address match the exact 0x2001bc9c. The closest function is Xil_L2CacheDisable at address 2001bc64. Does this mean that the data abort is from Xil_L2CacheDisable? This function is a bsp library function provided by Xilinx. I'm using it for direct access to the shared memory for the 2 cores.
The global variable u32 DataAbortAddr is captured by the following assembly:
DataAbortHandler: /* Data Abort handler */
#ifdef CONFIG_ARM_ERRATA_775420
dsb
#endif
stmdb sp!,{r0-r3,r12,lr} /* state save from compiled code */
ldr r0, =DataAbortAddr
sub r1, lr, #8
str r1, [r0] /* Stores instruction causing data abort */
bl DataAbortInterrupt /*DataAbortInterrupt :call C function here */
ldmia sp!,{r0-r3,r12,lr} /* state restore from compiled code */
subs pc, lr, #8 /* points to the instruction that caused the Data Abort exception */
The FaultStatus is captured in DataAbortInterrupt
#define mfcp(rn) ({u32 rval = 0U; \
__asm__ __volatile__(\
"mrc " rn "\n"\
: "=r" (rval)\
);\
rval;\
})
#endif
#define XREG_CP15_DATA_FAULT_STATUS "cp15:0:c5:c0:0"
u32 FaultStatus = mfcp(XREG_CP15_DATA_FAULT_STATUS);
答案1
得分: 1
ZYNQ 7000 SoC基于ARMv7，全部来自ARMv7参考手册。
"cp15:0:c5:c0:0"正在读取DFSR，数据故障状态寄存器。
数值0x1E是DFSR寄存器中的'故障状态'位(DFSR链接)。
在这种情况下，意味着“在翻译表遍历的第二级上同步奇偶校验错误”（如果使用短描述符翻译表格式）(FSR编码)。
这很可能是由于坏内存芯片导致的ECC异常。
不清楚DataAbortAddr是如何获取的。但我相当有信心它是数据内存地址，而不是指令地址。或者换句话说，当某个指令正在读取地址0x2001bc9c处的数据字时，异常发生。
要获取指令地址，您需要回溯PC/LR寄存器到异常发生的点。
此外，我建议使用objdump而不是readelf工具来搜索指令。
英文:
ZYNQ 7000 SoC is based on ARMv7, all retrieved from ARMv7 reference manual.
"cp15:0:c5:c0:0" is reading DFSR, Data Fault Status Register.<br>
Value 0x1E is 'Fault Status' bits in DFSR register (DFSR Link)
<br>
And in this case means "Synchronous parity error on translation table walk, Second level" (if you using short-descriptor translation table format) (FSR encodings). <br>Which is likely ECC throwing exception due to bad memory chip.
It's not clear how DataAbortAddr is acquired. But I'm quite confident that's data memory address, not instruction address. Or by other words exception occurs when some instruction is reading data word at address 0x2001bc9c.
In order to get instruction address you would need backtrace PC/LR registers to the point where exception happens.
Also I'd recommend to use objdump instead of readelf tool to search for instructions.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论