• State Suggested Answer
  • Locked Locked
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 349 subscribers
  • Views 573 views
  • Users 0 members are here
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
    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
    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