Hello,
I run a baremetal program on one core of the Cortex A9. The First Stage Bootloader (FSBL, Pre-Loader) and the Second Stage Bootloader (SSBL) perform perfectly. When the baremetal application (axf-file) is started in the debugger it executes without a problem. However when the baremetal application (bin-file) is exectued directly on the machine, the baremetal application cannot be started and the follwing error is thrown:
data abort
MAYBE you should read doc/README.arm-unligned-accesses
However, when the MMU is deactivated, the application (bin-file and axf-file) execute perfectly.
This leads me to the follwing questions:
Why can the program be started in the Debugger, and at the same time cause a data abort, when the binary is executed on the machine?
Why could the MMU cause a data abort, when the bin-file is started on the machine?
I would be grateful for any hints and tips. Many thanks in advance.
Deas
Hi,
I think you did not decode it properly. For the short descriptor format, we have the fault status as the concatenation of bit 10 and bits 3~0.
So we have FS = ((DFSR[10] & 0x400) >> 6) | (DFSR[3:0] & 0xF)
As a result I found that you have FS = 0x7, that is SDTFMT_MMU_L2_TRANSLATION_FAULT
And the DFAR should be valid
Florian
Hello Florian,
thanks for your answer! Perhaps I am missing something too obvious here ;), but as far as I can tell, I followed the exact same procedure as you. i.e.:
The content in DFSR is: 0x0000_1C97
*DFSR = 0x0000_1C97 = 0b0000..._0001_1100_1001_0111;
stringing together the bit numbers [10,3,2,1,0] leads to: 0b10111=0x17.
Could you give me hint how you got to the fault status of 0x7 instead of 0x17?
Many thanks again.
Sorry Deas, I meant 0x17 indeed. But that code does not make sense, except if Large Page Address Extension and Long Descriptor Format are used and supported.
Maybe check something related to privilege level...
Hi Florian,
thanks for the clarification an the further input, I will look into it.
cheers