• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 30 subscribers
  • Views 2302 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MPU : are strongly ordered RAM area executable ?

Christophe Beausoleil
Prodigy 245 points
Other Parts Discussed in Thread: HALCOGEN

Hi all,

I am using Halcogen default MPU configuration with an MCBTMS570 evaluation board.

So MPU region applying to EMIF area (0x60000000-0x6fffffff) is defined as :

  • STRONGLYORDERED_SHAREABLE (strongly ordered mode seems needed for programming the LCD display controller)
  • PRIV_RW_USER_RW_EXEC (full access and executable)

But when I try to execute some code located in external RAM (0x60000000-0x60080000) I get a prefetchAbort event.

Against that, same code executes well :

  • if MPU is disabled
  • or when POM is used

(but none of these configuration are relevant for me...)

So I would like to understand why strongly ordered mode does not seem be compatible with exec mode ?

Also what MPU configuration should I use ? I can use another region for 0x60000000-0x63ffffff area (but I must sacrifice another region for that...)

Thanks for any help.

Best regards,

Christophe

  • 0
    Prodigy 245 points

    I meant :

    why strongly ordered mode does not seem to be compatible with exec mode ?

    Sorry

  • 0 in reply to Christophe Beausoleil
    TI__Guru 68920 points

    Hi Christophe,

    Would it be possible to see your entire set of MPU region configurations?   The regions can overlap and when they do this affects the final access rights, so it's possible that it's something as simple as a higher priority MPU region overriding the EXEC rights.

    Best Regards

    -Anthony

  • 0 in reply to Anthony F. Seely
    Prodigy 245 points

    Hi Anthony,

    Thanks for your answer. Here is a screenshot of my original Halcogen configuration. Unfortunately, I am almost sure they are no overlapping regions (except for region 1 which covers the whole range), because I tried both strongly-ordered (which leads to prefetchAbort) and normal mode (OK).

    I really think that strongly-ordered memory are not executable, but I do not understand the reason why... and I have still not found this information in any document (but there are so many pages still to read :-)

    Thanks

    Best regards

    Christophe

     

  • 0 in reply to Christophe Beausoleil
    TI__Guru 68920 points

    Hi Christophe,

    Doesn't look as though regions 6,7, or 8 overlap region 5 at all - so we can scratch the overlap off the list.

    I'm looking through the PMSA section of the Arm Architecture Manual now to check on your question about strongly ordered and XN being tied together; haven't found anything yet but will keep looking.  

    Best Regards,

    Anthony

  • 0 in reply to Anthony F. Seely
    TI__Guru 68920 points

    Hi Christophe,

    I think we need to check the hex value that HalCoGen creates to be written into the DRACR for region 5, to see if XN is set.

    There is a section of the architecture manual (A3.5.7) that says:

    • " Any instruction fetch must access only Normal memory. If it accesses Device or Strongly-ordered
      memory, the result is UNPREDICTABLE. For example, instruction fetches must not be performed to an
      area of memory that contains read-sensitive devices, because there is no ordering requirement
      between instruction fetches and explicit accesses."

    There's also another note that explains that if you've got peripherals in a region that's strongly ordered, you should mark the region as XN becuase this disables speculative instruction fetches by the CPU which could affect a peripheral device that is sensitive to being accessed.

    So, it might be as simple as HalCoGen inferring that it needs to set XN on any region not marked as normal, to enforce the rule.  Otherwise we may need to keep digging to see if the hardware is doing this behind the scenes.

    I'll check my copy of HalCoGen to see if this is happening...

    Best Regards,

    Anthony

  • 0 in reply to Anthony F. Seely
    TI__Guru 68920 points

    Hi Christophe,

    It doesn't look like HalCoGen is inferring XN either.   I tried to match your settings and see the generated code is:

    from file "sys_mpu.asm"

            ; Setup region 5
            mov   r0,  #4
            mcr   p15, #0,    r0, c6, c2, #0
            ldr   r0,  r5Base
            mcr   p15, #0,    r0, c6, c1, #0
            mov   r0,  #0x0000
            orr   r0,  r0,    #0x0300
            mcr   p15, #0,    r0, c6, c1, #4
            movw  r0,  #((0 << 15) + (0 << 14) + (0 << 13) + (0 << 12) + (0 << 11) + (0 << 10) + (0 <<  9) + (0 <<  8) + (0x1B << 1) + (1))
            mcr   p15, #0,    r0, c6, c1, #2

    Where c6, c1, #4 is the DRACR register.   Putting a value of 0x300 into that register matches the GUI,  RW for both Priv & User, and Strongly Ordered.

    XN would be bit 12 and this isn't set.

    Does this match your generated code? 

    Also do you 'see' the value 0x300 in DRACR if you inspect it through the CCS interface?

    (you'll need to poke the value #4 to c6,c2,#0 or  RGNR register first before checking DRACR to make sure region 5 is selected).

    Other than checking these things, I'm at a bit of a loss in being able to explain the abort you are seeing as directly related to the MPU setting.   We can still check the CPU specific guide for the R4 and errata - and go back to ask ARM if needed.  

    I think though that the statement in the architecture manual which says instruction fetches from strongly ordered are unpredictable probably means that the area on EMIF you need to be strongly ordered should be separate from the area you need to be executable;   otherwise your application will at best have the uncertainty in it of not following the letter of the architecture manual - and that can lead to trouble down the line.  

    Best Regards,

    Anthony

  • 0 in reply to Anthony F. Seely
    TI__Mastermind 49120 points

    Hi Christophe, Anthony,

    The Cortex-R4F technical reference manual (ARM DDI 0363C) is very clear about this. Section 7.1.1 describes the memory region types that can be defined using the MPU. The "Region Access Permissions" description includes the below:

    /* Text quoted from TRM */

    Region access permissions

    Each region can be given no access, read-only access, or read/write access permissions for Privileged or all modes. In addition, each region can be marked as eXecute Never (XN) to prevent instructions being fetched from that region.

    For example, if a User mode application attempts to access a Privileged mode access only region a permission fault occurs.

    The ARM architecture uses constants known as inline literals to perform address calculations. The assembler and compiler automatically generate these constants and they are stored inline with the instruction code. To ensure correct operation, only a memory region that has permission for data read access can execute instructions. For more information, see the ARM Architecture Reference Manual. For information about how to program access permissions, see Table 4-34 on page 4-66.

    Instructions cannot be executed from regions with Device or Strongly-Ordered memory type attributes. The processor treats such regions as if they have XN permissions.

    /* End of quoted text */

    Regards,

    Sunil

     

  • 0 in reply to Sunil Oak
    Prodigy 245 points

    Hi Anthony, Sunil,

    Thanks a lot for your help and support.

    Well, I will be damned, I remember the passage about "inline literals", but I certainly got over the line after, although I read this section more than once.

    I will try background region mode, so region 1 could be freed...

    Thanks again !

    Best regards

    Christophe