• State Not Answered
  • Locked Locked
  • Replies 17 replies
  • Subscribers 352 subscribers
  • Views 25258 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
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

deas

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
  • 0 in reply to Zhifei Yang

    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
  • 0 in reply to Zhifei Yang

    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