Cortex A9 MMU

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

Parents
  • Hello Deas,

    The MMU of your bare metal application is only initialized with alt_pt_init function?

    You should check the symbol in your linker script (usually mmu_tbl) and check if there are other assembly files (such as translation_table.S) which also initialize the MMU table.

    The alt_pt_init seems to change access permissions to privileged... which is mostly reserved for OS kernels, and trusted applications...

    You get an alignment exception, which occurs when MMU is enabled only for accesses to device regions. Thus you shall check that your accesses to the region starting at 0x40000000 are all 32-bit word aligned.

    But I did not see the piece of assembly code where it is enabled... it shall be in the piece of code called right away from the base address of the vector table (entry point for ARMv7). For example, you may have a routine called _boot, which includes enabling MMU and caches in the CPU.

    Good luck.

    Florian

Reply
  • Hello Deas,

    The MMU of your bare metal application is only initialized with alt_pt_init function?

    You should check the symbol in your linker script (usually mmu_tbl) and check if there are other assembly files (such as translation_table.S) which also initialize the MMU table.

    The alt_pt_init seems to change access permissions to privileged... which is mostly reserved for OS kernels, and trusted applications...

    You get an alignment exception, which occurs when MMU is enabled only for accesses to device regions. Thus you shall check that your accesses to the region starting at 0x40000000 are all 32-bit word aligned.

    But I did not see the piece of assembly code where it is enabled... it shall be in the piece of code called right away from the base address of the vector table (entry point for ARMv7). For example, you may have a routine called _boot, which includes enabling MMU and caches in the CPU.

    Good luck.

    Florian

Children
More questions in this forum