• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 29 subscribers
  • Views 1374 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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 memory attribute change when EMAC DMA access memory

eric
Intellectual 885 points
Other Parts Discussed in Thread: RM57L843

Hi,

I am testing freertos+lwip on the RM57L843. Cache is enabled. I focus on the cache attribute i.e. Write-through or write-back.

Here the MPU I means the MPU in the core not the NMPU like the thread(I paste the URL in the end) discussed.

I configure the memory area(pbuf) used by the lwip task as the WT to enable the uSCU to keep the cache coherency(for CPU-reading) and enable EMAC DMA get the lastest data(for CPU-writing).

Now I have a question, there are several tasks in my system not just the lwip task, what will happen if the EMAC DMA is writing in-coming package into the memory while a task happened, I mean that the cache policy maybe changed(I am not sure about this, because another task will not specify the memory area used by the lwip(EMAC DMA)) and the the WT+uSCU mechanism maybe failed? or the EMAC DMA will not be affected?

  • 0
    TI__Guru 65600 points
    Hi Eric,

    I need to think this one through and get back to you - but the CPGMAC's embedded DMA should be writing to the L2SRAM or to the EMIF both of which are outside of the CPU on the RM57L.

    I understand the quesiton about the CPU MPU though from a standpoint of changing the caching policy and I think the real question then is what happens if you change the policy but still have data covered by a particular region stored in the cache during the change. That's what you're asking - isn't it?
  • 0 in reply to Anthony F. Seely
    TI__Guru 65600 points
    Hi Eric,

    There is a document, "ARM Cortex-R Series Programmer's Guide' DEN 0042A".
    It's got a chapter on the MPU and a section 'Cache maintenance recommendations'.

    I think in a nutshell it says that if you just change the *permission* of a range of memory but not the type attributes then you don't need to do the cache maintenance.

    Look at 9.5.1 Permission modification in context switching and how they show Region 0 and 1 being used together. They both have the same *type* attributes but region 0 is not excecutable, no access while Region 1 gets swapped in and out by the MPU during task switches.

    So this block of memory having the PBUF would always be hitting the MPU with the same *type* permissions but you could still guard it from being modified by the wrong task.

    The port you're worried about then is the ACP and all it does is to provide a way to invalidate memory that is written to by the external master automatically.

    I'm putting 1+1=2 together here but I would conclude from the appnote that if you take the approach of 9.5.1 you can keep the PBUF region in cache without allowing it to be accessible by the wrong tasks, and then if it's valid to be in cache the ACP should act correctly.

    To actually guard the other areas in the memory from the EMACs DMA .. there is an NMPU at the system level in front of the EMAC and I would use this to limit where the EMAC can access. This way you can restrict the EMAC only to the PBUF not whatever is available for a particular task at any given momement. But that NMPU just handles permission - not type of memory.

    -Anthony
  • 0 in reply to Anthony F. Seely
    Intellectual 885 points
    Hi Anthony,

    No, the situation you stated is very similar to what I am considerring, but I think the situation you stated will not have problems if just consider the CPU core. E.g. two tasks have seperate memory regions, when a context switch happens, the MPU is changed also, that means the cache policy may be changed also, but the two tasks can run well if they don't have a Interrupt or DMA.

    My question focus more on the situation there is an interrupt or a EMAC DMA belonging to one task(lwIP). If another task which do not specify the memory area used by the lwIP task is running, what will happen when a EMAC interrupt happen or a EMAC DMA will be trigged to write in-coming package into L2SRAM.

    Best regards,
    -Eric
  • 0 in reply to Anthony F. Seely
    Intellectual 885 points
    Hi Anthony,

    This is my considerration about your second reply.

    So If I want to guard memory areas from the EMAC's DMA, I should use NMPU, the MPU in the core will not limit the DMA access (or a non-CPU master), although it runs in the user mode(I don't kwow RM57L, but for RM4x, EMAC's DMA runs in user mode), right?

    Although the MPU in the core will not limit the EMAC's DMA access but it will affect the cache coherency when the EMAC's DMA writing L2SRAM(cache WT or WB is different for uSCU component), right?

    From your perspective, a common region or a background region should be kept and it should cover the pbuf used by the EMAC's DMA to hold the attribute of the pbuf area when a context switching happens. Is this you suggest?

    -Eric
  • 0 in reply to eric
    TI__Guru 65600 points

    Hi Eric,

    eric said:
    So If I want to guard memory areas from the EMAC's DMA, I should use NMPU

    Yes.

    eric said:
    he MPU in the core will not limit the DMA access (or a non-CPU master), although it runs in the user mode(I don't kwow RM57L, but for RM4x, EMAC's DMA runs in user mode), right?

    So when I read the details of the ACP port it's not talking about any interaction with the MPU.  It just talks about creating coherency operations on the cache for certain writes.   This is applicable to the RM57L.

    On the other RM4x there is an AXI-S port to the TCM memory inside the CPU.  But the manual for the CPU also doesn't talk about interaction between this port and the MPU.  Instead there is a bit in the CP15 coprocessor that can block user mode accesses through this AXI-S port .. but it's not tied to any particular MPU region. 

    So the way I read these manuals the MPU in the processor is only for the processor not for DMA.

    eric said:

    Although the MPU in the core will not limit the EMAC's DMA access but it will affect the cache coherency when the EMAC's DMA writing L2SRAM(cache WT or WB is different for uSCU component), right?

    This is where that programmer's guide seems to indicate you should always either:

        a) perform the cache maintenance explicitly if you are in a context switch that changes the MPU setting.

            in this case you'd invalidate the PBUF from the cache in software before removing the MPU region covering them.

        -or-

        b) keep a second region programmed which makes this area cacheable, but not accessible by the CPU.

            this way the pbuf can stay in the cache,  but the the task you switch to cannot access them.

    This is just my interpretation of the documentation;  based on the rules it explains.   It's hard to read between the lines and find out if these rules are just stated for good practice & portability across processors as sometimes they are, or if there's really an issue breaking the rules.  So I'd suggest just keeping it simple and following the stated rules without trying too hard to understand them.    I'd do one or the other from the above (a or b) as described in the programmer's guide.

  • 0 in reply to eric
    TI__Guru 65600 points
    Eric,

    Well in this case you have to look at the OS. I doubt you would see the OS doing an MPU swap for an IRQ but I am not sure. Generally the IRQ is supposed to be kept short and low latency.. it's going to run *with privilege* so it will have access to everything that the *task* it interrupts has access to, *plus* it's going to have access to what is marked as privileged only. I think the idea is to limit what is in the ISR itself and keep your complex code that's doing lots of memory operations in a task that is running in user mode and triggered by the ISR... So ISR should be limited to the sort of time sensitive servicing of the EMAC DMA registers but not to the PBUF processing which could be a lot more error prone and difficult to inspect.
  • 0 in reply to Anthony F. Seely
    Intellectual 885 points
    Hi Anthony,

    That helps me a lot. I'll try to do it .
    Thank you.

    Best regards,
    -Eric