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
For Cortex-A9, when MMU is disabled, the data accesses are treated as Strongly Ordered. When MMU is enabled, it will check the memory address permission.
If SCTLR.U == 1, unaligned access support for loads and stores of 16-bit halfwords and 32-bit words. Unaligned access support only applies to Normal memory. Unaligned accesses to Strongly-ordered or Device memory are UNPREDICTABLE.
SCTLR.A = 1 bit forces an abort on an unaligned access.
many thanks for your replies. I went through the specs. The enabling of the MMU resp. the population of the pagetable has to occur after the SSBL. I presume the SSBL is not part of the problem.
After the SSBL has finished - the baremetal application is started, the latter initilizes the system. The function alt_pt_init(void) enables the MMU and populates the page table, according to the required specifications.
ALT_STATUS_CODE alt_pt_init (void) { /* Populate the page table with sections (1 MiB regions). */ ALT_MMU_MEM_REGION_t regions[] = { /* Memory area: 1 GiB */ { .va = (void *) 0x00000000, .pa = (void *) 0x00000000, .size = 0x40000000, .access = ALT_MMU_AP_PRIV_ACCESS, // 1, /*!< Privileged access only .attributes = ALT_MMU_ATTR_WBA, // 0x13, /*!< Inner/Outer Write-Back, Write Allocate, Shareability determined by [S] bit */ .shareable = ALT_MMU_TTB_S_NON_SHAREABLE, // 0, /*!< Non-Shareable address map */ .execute = ALT_MMU_TTB_XN_DISABLE, // 0, .security = ALT_MMU_TTB_NS_SECURE}, // 0, /* Device area: Everything else */ { .va = (void *) 0x40000000, .pa = (void *) 0x40000000, .size = 0xc0000000, .access = ALT_MMU_AP_PRIV_ACCESS, // 1, /*!< Privileged access only */ .attributes = ALT_MMU_ATTR_DEVICE_NS, // 0x20, /*!< Device Non-Shareable */ .shareable = ALT_MMU_TTB_S_NON_SHAREABLE, // 0 /*!< Non-Shareable address map */ .execute = ALT_MMU_TTB_XN_ENABLE, // 1 .security = ALT_MMU_TTB_NS_SECURE} // 0, };
When the compiled (application.axf) is run in the debugger everything works as it should, however, when the binary (application.bin) is started I get the above message (via - UART Interface): (data abort ...) .
The application.bin is started via UART with the command:
fatload mmc 0:1 0x00100000 application.bin go 0x00100040;
This procedure works fine as long as the function alt_pt_init() is not executed.
In summary:
Question:
Why does the function alt_pt_init(void) prevent the application.bin from getting executed? Why can the application.axf still be executed in the debugger?
I am quite sure, that I am missing something rather substantial - and I would be really glad if somebody could provide me with some more tipps.
Many thanks and all the best
(*for context. The application is supposed to run on a Altera CycloneV containing a Cortex A9.)