soc: arm: stm32h7x mapping system memory region #60765
Conversation
FRASTM
force-pushed
the
issue60449
branch
2 times, most recently
from
c32429b to
dec3d41
Compare
FRASTM
force-pushed
the
issue60449
branch
2 times, most recently
from
931f0bf to
a4dfac0
Compare
|
rebased on 8505986 |
| MPU_REGION_ENTRY("SYSTEM", 0x1FF00000, | ||
| { (STRONGLY_ORDERED_SHAREABLE | | ||
| REGION_512K | | ||
| FULL_ACCESS_Msk) }), |
There was a problem hiding this comment.
Wouldn't MPU_RASR_XN_Msk | P_RW_U_NA_Msk instead of FULL_ACCESS_Msk be more appropriate? Then it would be the same as REGION_RAM_ATTR above. But generally STRONGLY_ORDERED_SHAREABLE solves all issues in our application.
There was a problem hiding this comment.
yes, this also removes the RDSERR (even if do not really catch the difference)
There was a problem hiding this comment.
My understanding is that with MPU_RASR_XN_Msk we avoid to execute code from this region and with P_RW_U_NA_Msk we avoid that a user mode thread can access it. Both should not happen in my point of view and the configuration should therefore be a bit more secure.
System memory declared by the MPU as 'Strongly Ordered' with region attributes which will inhibit the speculative fetch, preventing the Flash RDSERR. Signed-off-by: Francois Ramu <[email protected]>
|
Changing attributes to |
|
Is there something blocking the PR from being merged? |
System memory declared by the MPU as 'Execute-Never' will inhibit the speculative fetch, preventing the RDSERR.
This is explained by the https://community.st.com/t5/stm32-mcu-products/spurious-rdperr-and-rdserr-when-all-protection-and-security/td-p/279852
Fixes #60449