stm32: tests: drivers : fix mpu faults by enabling SRAM clocks and configuring MPU regions on stm32h7rsx #97731
Conversation
zephyrbot
added
area: Clock Control
platform: STM32
zephyrbot
requested review from
FRASTM,
GeorgeCGV,
erwango,
etienne-lms,
gautierg-st,
marwaiehm-st,
mathieuchopstm and
nordic-krch
djiatsaf-st
force-pushed
the
ztb_fix_h7rs_issue
branch
from
66d1877 to
8b9ef67
Compare
dts/arm/st/h7rs/stm32h7rs.dtsi
Outdated
| compatible = "zephyr,memory-region", "mmio-sram"; | ||
| reg = <0x30004000 DT_SIZE_K(16)>; | ||
| zephyr,memory-region = "SRAM2"; | ||
| zephyr,memory-attr = <DT_MEM_ARM(ATTR_MPU_RAM)>; |
There was a problem hiding this comment.
My PR #97364 most likely gets a problem with adding the memory attribute to sram2, because the order of MPU region initialization (see arm_mpu.c):
- elements from
mpu_regions.c - entries from the device tree with
zephyr,memory-attrproperty - entries resulting from
CONFIG_USERSPACE,CONFIG_NOCACHE_MEMORYetc - dynamic entries
As later defined regions overlapping earlier ones have a higher priority (called region overlay), the ATTR_MPU_RAM from dt will overlay the REGION_RAM_NOCACHE_ATTR / REGION_PPB_ATTR from my PR's mpu_regions.c. Never tried to overlay a smaller region with a bigger one, so maybe this is even illegal? Anyway, I need to figure a way to define my DMA memory regions after it is configured as standard memory.
I see the point of this change (and use it in my custom boards dts for other mem nodes), but how can I solve this?
There was a problem hiding this comment.
To prevent conflicts with Ethernet support, an overlay was added on the driver test side that explicitly sets the zephyr,memory-attr property to DT_MEM_ARM(ATTR_MPU_RAM).
Changes was only required for testing purpose.
enables the AHB2 peripheral clocks for SRAM1 and SRAM2 on STM32H7RSX series using LL_AHB2_GRP1_EnableClock. These clocks are required to access the corresponding SRAM regions during runtime. Fixes potential access faults when using SRAM1 and SRAM2. Signed-off-by: Fabrice DJIATSA <[email protected]>
djiatsaf-st
force-pushed
the
ztb_fix_h7rs_issue
branch
from
8b9ef67 to
ba95743
Compare
zephyrbot
added
area: MEMC
area: Tests
| zephyr,memory-attr = <DT_MEM_ARM(ATTR_MPU_RAM)>; | ||
| }; | ||
|
|
||
| /* System data RAM accessible over AHB bus: SRAM2 in D2 domain */ |
There was a problem hiding this comment.
Make SRAM2 status = "disabled"; by default and add comment that zephyr,memory-attr must be added explicitly for the SRAM to be accessible.
adds the `zephyr,memory-attr` property to the SRAM1 and SRAM2 memory nodes to explicitly define their MPU attributes as normal RAM. This ensures proper memory protection and caching behavior when these regions are used by the kernel or application. Resolve a Data Access Violation encountered during test, where the faulting address was 0x30000000. Note: add the zephyr,memory-attr property in the board overlay for SRAM2 to avoid conflict with the support of h7rs ethernet with MPU regions enabled. see link below for more details : https://github.com/zephyrproject-rtos/zephyr/pull/97364/files#r2439668915 Signed-off-by: Fabrice DJIATSA <[email protected]>
djiatsaf-st
force-pushed
the
ztb_fix_h7rs_issue
branch
from
ba95743 to
8c0e426
Compare
|
| reg = <0x30000000 DT_SIZE_K(16)>; | ||
| compatible = "zephyr,memory-region", "mmio-sram"; | ||
| zephyr,memory-region = "SRAM1"; | ||
| zephyr,memory-attr = <DT_MEM_ARM(ATTR_MPU_RAM)>; |
There was a problem hiding this comment.
Should sram1 mapping attributes also be set by the system overlay, or at least the board?
There was a problem hiding this comment.
I previously did that https://github.com/zephyrproject-rtos/zephyr/pull/97731#discussion_r2436709223 but is better to do it this way unless there is a conflict, such as with SRAM2
7 participants
This pull request addresses multiple MPU-related faults observed during runtime tests on the
STM32H7RSXseries by introducing the following changes: