• State Accepted Answer
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 351 subscribers
  • Views 639 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?

In Cortex-R5, the address of cache maintenance operations is not restricted by the MPU ？

SmileSX

Under Cortex-R5, the addresses for cache maintenance are not restricted by the MPU. For example, performing cache cleaning or invalidation operations on an address space without access permission will not cause any exceptions. For example, there are two contexts here called TaskA and TaskB, and during the task switching process, the OS is responsible for maintaining the memory permissions corresponding to each Task context; when TaskA is being executed on the CPU, if the CPU accesses the Memory Space of TaskB, it will be restricted by the MPU; however, at this time, it is allowed to perform a cache invalidation operation on address X belonging to TaskB while executing TaskA. Thus, if the address space corresponding to X is configured as Cacheable + write-back, incorrect cache maintenance behavior will cause Dirty Data in the cache to fail to be correctly written back to memory.

Parents
  • 0 in reply to Martin Weidmann
    First, thank you for your reply. Our environment is AutoSar OS, and whether a Task runs on PL0/PL1 is optional. In most cases, it runs on PL1, and the Task directly calls MCAL interfaces, which include cache maintenance operations. The current issue is that if an invalid cache operation in Task(PL1) occurs, it may cause memory consistency issues (Cortex-R5 recommends that the attribute of cacheable memory be write-back). I understand your point, so the conclusion is that in the current Coretex-R5, this scenario (Task In PL1) cannot achieve "protection" of cache maintenance through MPU.
Reply
  • 0 in reply to Martin Weidmann
    First, thank you for your reply. Our environment is AutoSar OS, and whether a Task runs on PL0/PL1 is optional. In most cases, it runs on PL1, and the Task directly calls MCAL interfaces, which include cache maintenance operations. The current issue is that if an invalid cache operation in Task(PL1) occurs, it may cause memory consistency issues (Cortex-R5 recommends that the attribute of cacheable memory be write-back). I understand your point, so the conclusion is that in the current Coretex-R5, this scenario (Task In PL1) cannot achieve "protection" of cache maintenance through MPU.
Children
  • +1 Arm Employee Badge in reply to SmileSX

    Interesting, I'm afraid I'm not an expert on AutoSar.

    SmileSX said:
    so the conclusion is that in the current Coretex-R5, this scenario (Task In PL1) cannot achieve "protection" of cache maintenance through MPU.

    I'd phrase that differently.  It's not possible to achieve your goals using your current software model.  The processor could give you the isolation you want, if you changed the software model to run Tasks A and B at PL0.  There might be plenty of good reasons why you don't want to do that (again, not an AutoSar expert) - but the basic assumption the architecture is that tasks run at PL0 and the management code/OS/RTOS/whatever running at PL1.

  • 0 in reply to Martin Weidmann
    Thank you again for your reply. You mentioned a good point that inspired me. If the Task does not run at PL0, it means that the MPU configuration can be modified within the current task, and in this case, the MPU will still be unable to restrict the Right of access.