• State Suggested Answer
  • Locked Locked
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 350 subscribers
  • Views 1015 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

A9 MMU Questions

prahsman

I’m doing a bare metal project using an A9MP processor ( NXP/Freescale iMX6Q), and in the process of setting up the MMU. The project will be using 2 (of the 4) cores. Core 0 will be reading data in a common shareable data area in OCRAM and displaying the data on an LCD display. Core 1 is gathering the data and inserting it in the common area.  Reads/writes from/to the common area are protected using LDREX/STREX operations. The common data is set up as STRONGLY_ORDERED, no execute (I assume this is correct).

 I have a couple of questions:

  1. From reading in the ARM forum, I saw a suggestion that if using more than 1 core, the SMP bit should always be set, even if there is no interaction between the two working cores – is this correct? If the SMP bit is set, should the FW bit also be set – any downside to setting it?
  2. Pros and cons of setting the L1 Dcache prefetch bit
  3. Pros and cons of setting the Alloc in one way bit. Core 0 will be copying one frame buffer into another, so lots of huge (1.5MB) copies. Not sure yet whether to use memory to memory DMA or NEON copy – any suggestions? Is the bit to be enabled only during copy operations or left enabled all of the time?
  4. I noticed in one place that, for this processor, a user did a setup for STRONGLY_ORDERED memory and also set the shareable and RW access bits. I thought all STRONGLY_ORDERED memory (by default) is shareable with RW access. Which is correct?
  5. I plan on using write back (rather than write through) for DRAM memory (with code memory being RO, data memory RW nX) – is this best? We did find out early on that the frame buffer memory works much faster if it’s not cached.
  6. In the SDK for this processor, I noticed that the RAM (data) memory MMU entry was WBWA (TEX: 001, C: 1, B: 1) which doesn’t show up in the Memory Type options in Table 9-3 of the ARM Cortex-A Series Programmer’s Guide (V4.0). What other options are available?
Parents
  • 0 Arm Employee Badge
    prahsman said:
    From reading in the ARM forum, I saw a suggestion that if using more than 1 core, the SMP bit should always be set, even if there is no interaction between the two working cores – is this correct? If the SMP bit is set, should the FW bit also be set – any downside to setting it?

    I believe you pretty much always want to set the SMP bit.

    For FW - do the two cores share translation tables?

    prahsman said:
    noticed in one place that, for this processor, a user did a setup for STRONGLY_ORDERED memory and also set the shareable and RW access bits. I thought all STRONGLY_ORDERED memory (by default) is shareable with RW access.

    Any region which is Strongly Ordered is also Shareable.  See Table B3-10 "TEX, C, and B encodings when TRE ==0" and Table B3-13 "Determining shareability, with TEX remap" in the Armv7-A/R Architecture Reference Manual (C.d).

    Type (Normal vs Device vs SO) is independent of access permission.  So marking a region as SO doesn't imply that it is RW, it could be RO (for example).

    prahsman said:
    I plan on using write back (rather than write through) for DRAM memory (with code memory being RO, data memory RW nX) – is this best?

    I believe the Cortex-A9 doesn't support write-through (gets treated as non-cacheable), so yes :-)

    prahsman said:
    In the SDK for this processor, I noticed that the RAM (data) memory MMU entry was WBWA (TEX: 001, C: 1, B: 1) which doesn’t show up in the Memory Type options in Table 9-3 of the ARM Cortex-A Series Programmer’s Guide (V4.0). What other options are available?

    The Programmer's Guide isn't exhaustive, it's only intended as a guide.

    Looking at the Table B3-10 "TEX, C, and B encodings when TRE == 0" in the Arm ARM - and that encoding looks valid to me:

    "Outer and Inner Write-Back, Write-Allocate Normal"

Reply
  • 0 Arm Employee Badge
    prahsman said:
    From reading in the ARM forum, I saw a suggestion that if using more than 1 core, the SMP bit should always be set, even if there is no interaction between the two working cores – is this correct? If the SMP bit is set, should the FW bit also be set – any downside to setting it?

    I believe you pretty much always want to set the SMP bit.

    For FW - do the two cores share translation tables?

    prahsman said:
    noticed in one place that, for this processor, a user did a setup for STRONGLY_ORDERED memory and also set the shareable and RW access bits. I thought all STRONGLY_ORDERED memory (by default) is shareable with RW access.

    Any region which is Strongly Ordered is also Shareable.  See Table B3-10 "TEX, C, and B encodings when TRE ==0" and Table B3-13 "Determining shareability, with TEX remap" in the Armv7-A/R Architecture Reference Manual (C.d).

    Type (Normal vs Device vs SO) is independent of access permission.  So marking a region as SO doesn't imply that it is RW, it could be RO (for example).

    prahsman said:
    I plan on using write back (rather than write through) for DRAM memory (with code memory being RO, data memory RW nX) – is this best?

    I believe the Cortex-A9 doesn't support write-through (gets treated as non-cacheable), so yes :-)

    prahsman said:
    In the SDK for this processor, I noticed that the RAM (data) memory MMU entry was WBWA (TEX: 001, C: 1, B: 1) which doesn’t show up in the Memory Type options in Table 9-3 of the ARM Cortex-A Series Programmer’s Guide (V4.0). What other options are available?

    The Programmer's Guide isn't exhaustive, it's only intended as a guide.

    Looking at the Table B3-10 "TEX, C, and B encodings when TRE == 0" in the Arm ARM - and that encoding looks valid to me:

    "Outer and Inner Write-Back, Write-Allocate Normal"

Children
No data