This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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,

    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:

    • application.axf can always be exectuded in the debugger (Semi-Hosting).
    • application.bin can only be exectuded (using the fatload and go command) when the function alt_pt_init() is not called

    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

    Deas

    (*for context. The application is supposed to run on a Altera CycloneV containing a Cortex A9.)

Reply
  • Hello,

    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:

    • application.axf can always be exectuded in the debugger (Semi-Hosting).
    • application.bin can only be exectuded (using the fatload and go command) when the function alt_pt_init() is not called

    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

    Deas

    (*for context. The application is supposed to run on a Altera CycloneV containing a Cortex A9.)

Children
No data