new Cortex_M MPU config facility#460
Conversation
pat-rogers
changed the title
pat-rogers
changed the title
pat-rogers
force-pushed
the
add_mpu_configuration
branch
from
a5a0c7b to
875ea06
Compare
|
Looks like the Microbit build is failing. I guess that is not V2, ie not Cortex M4, and is instead an M0 and so doesn't have MPU support. But that's just a guess. |
| -- This package provides subprograms to configure the Memory Protection | ||
| -- Unit (MPU) on the Cortex-M7 family of CPU. | ||
| -- | ||
| -- On Cortex-M7, the MPU is required when the D-cache is enabled in order | ||
| -- to prevent speculative reads from causing bus contention on external | ||
| -- memory interfaces (e.g., FMC/SDRAM). Without MPU configuration, the | ||
| -- default memory map treats all external memory as Normal, allowing the | ||
| -- CPU to issue speculative reads that can starve bus masters such as the | ||
| -- LTDC display controller. |
There was a problem hiding this comment.
As this is specific to the Cortex-M7 I suggest to move the file to arch/ARM/cortex_m/src/cm7. This should also fix the build failure. The failure is caused by the builds using Cortex-M0 failing as they pull this unit but don't provide an SVD for that.
If that unit is supposed to work on other Cortex-M I suggest to add the MPU SVD for Cortex-M0. According to the documentation I could find the M0 should also come with an MPU.
|
On 14-Apr-26 6:18 AM, JK wrote:
***@***.**** requested changes on this pull request.
------------------------------------------------------------------------
In arch/ARM/cortex_m/src/cortex_m-mpu.ads <https://github.com/AdaCore/
Ada_Drivers_Library/pull/460#discussion_r3079036820>:
> +-- This package provides subprograms to configure the Memory Protection
+-- Unit (MPU) on the Cortex-M7 family of CPU.
+--
+-- On Cortex-M7, the MPU is required when the D-cache is enabled in order
+-- to prevent speculative reads from causing bus contention on external
+-- memory interfaces (e.g., FMC/SDRAM). Without MPU configuration, the
+-- default memory map treats all external memory as Normal, allowing the
+-- CPU to issue speculative reads that can starve bus masters such as the
+-- LTDC display controller.
As this is specific to the Cortex-M7 I suggest to move the file to |
arch/ARM/cortex_m/src/cm7|. This should also fix the build failure. The
failure is caused by the builds using Cortex-M0 failing as they pull
this unit but don't provide an SVD for that.
The header comment block is too specific. It should work on several
others too, not just the F7.
If that unit is supposed to work on other Cortex-M I suggest to add the
MPU SVD for Cortex-M0. According to the documentation I could find the
M0 should also come with an MPU.
Ugh. :-)
|
|
As far as I can see, the M0+ does support an MPU, but the M0 does not. Therefore I propose that we take the same approach as was used for the nvic_cm4_cm7 directory, and so create an mpu_cm4_cm7 directory that the gpr files reference for those MCUs, omitting the M0. |
That sounds like a good solution! |
…d Cortex-M families. Created new directory arch/ARM/cortex_m/src/mpu_cm4_cm7/ and moved the two source files defining the MPU facility into that directory. Updated the scripts/config/archs.py file to include that new source directory for the supported MCU families (all the M4 and M7 boards, excluding the M0). Manually updated all the relevant gpr files to reference that new directory.
…d Cortex-M families. Created new directory arch/ARM/cortex_m/src/mpu_cm4_cm7/ and moved the two source files defining the MPU facility into that directory. Updated the scripts/config/archs.py file to include that new source directory for the supported MCU families (all the M4 and M7 boards, excluding the M0). Manually updated all the relevant gpr files to reference that new directory.
2 participants
Note that when used this will fix the LTDC "slew" problem too.