0

According to ARM, the default behaviour of Cortex-M3 is to prevent execution from certain memory regions. Information here: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/CIHDHAEF.html

According to the above information page: "The optional MPU can override the default memory access behavior". That is all good, because we would like to execute code from the implementation specific 0xF0000000 region, which by default has the XN "Execute Never" flag set.

We are able to program the MPU to put additional restrictions on a memory region, so clearly the MPU works. But if we set the MPU to allow execution in the 0xF0000000 region, the CPU still enters exception when we try to execute at 0xF0000000.

Does anyone know if the Cortex-M3 MPU is supposed to be able to lift a default restriction, as the ARM page suggests?

artless noise
  • 21,212
  • 6
  • 68
  • 105
Timmy Brolin
  • 1,101
  • 1
  • 8
  • 18
  • On the linked page, region `0xE0100000- 0xFFFFFFFF` is `Implementation-specific`. I think you should look at specific datasheet of your MPU/SoC – LPs Jun 23 '17 at 07:30
  • XN must be 0 and access must be RO or RW as well as appropriate privilege settings. Also for overlapping regions, the highest numberd region attributes prevail. Perhaps your question should include _all_ your MPU configuration since all we know is that you set XN=0, and that alone does not guarantee excitability. – Clifford Jun 23 '17 at 09:38
  • You might want to add the `arm` tag. It has quite a few more followers than `cortex-m3`. – D Krueger Jun 23 '17 at 21:40
  • LPs: Datasheet of specific SoC mentions nothing specific about 0xE-0x0F. Besides, the MPU should be inside the M3 core, and not be affected by implementation specifics. Clifford: Tried RO & XN=0. The setting works in for example region 0x0, but not if we do the same in region 0xF. Also tried RO & XN=1 in region 0x0, and this prevents execution. So the MPU seems to work. It seems we can use the MPU to add access restrictions, be not remove a default restriction. – Timmy Brolin Jun 24 '17 at 17:09
  • @TimmyBrolin : Can you not tell us what this mystery SoC is or what specifically is mapped to that address region - it would make it far simpler to answer. – Clifford Jun 25 '17 at 06:59
  • why do you want to go against the design of the processor and use an address it cannot normally access? move the memory into a normal address space for this architecture. – old_timer Jun 26 '17 at 01:48
  • @Clifford: M2S010. But the question is M3 generic and implementation independent. – Timmy Brolin Jun 27 '17 at 08:15
  • @old_timer : Because the 0xF region is the only hardware accessible region within short-jump distance from the 0x0 region. All other regions require inefficient long jumps. – Timmy Brolin Jun 27 '17 at 08:17

1 Answers1

1

Although perhaps not clearly stated in the ARM documentation, it seems that the default MPU configuration is already the least restrictive possible, in order that a device with an MPU behaves identically to one without by default. So it makes sense that you cannot remove these restrictions.

The Memory access behaviour table shows the 0xE0100000- 0xFFFFFFFF region as a "Device" region rather then a memory region. The behaviour of the processor for device and normal regions is described at Memory regions, types and attributes. The requirement for a region with the device attribute preserve access order would require the processor to handle such memory differently when executing code, making the processor more complex. Execution from such memory would also be less efficient.

Essentially if the intent is to support execution from a memory, then it must be mapped to a memory region rather the a device region.

Note that in the Cortex-R4 documentation the restriction is clearly stated:

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.

I cannot however find a similarly unambiguous statement for M3.

Clifford
  • 88,407
  • 13
  • 85
  • 165
  • As I wrote in my question, I agree with your suspicion that the MPU cannot override the default restrictions. But I was hoping someone had hard knowledge about this, since this suspicion contradicts the official ARM documentation. What you say about device memory is probably true, but irrelevant since the MPU specifies the memory type, and we have set it to "normal". The big question is: Is the ARM documentation wrong about the MPU being capable of overriding the default restrictions, such as XN and memory type. – Timmy Brolin Jun 27 '17 at 08:20
  • These are the settings we try: MPU_CTRL=0x0; MPU_RBAR=0x00000010; MPU_RASR=0x0307003F; MPU_CTRL=0x3; That is: Lift all restrictions in the entire adr. space. – Timmy Brolin Jun 27 '17 at 08:30
  • @TimmyBrolin : The ARM documentation is not wrong because it does not explicitly say that. I suspect the _later_ documentation for R4 is also true for M3. The solution is simple - ask ARM tech support! Note that the table has columns for _Memory Region_ and _Memory Type_; _Memory_Type_ is an MPU configuration while _Memory Region_ is what the address map physically supports. Changing the MPU type cannot change the physical attributes. – Clifford Jun 27 '17 at 08:47