SoC STM32H7RS MPU configuration issues

[TD-JBL]

Describe the bug

To better understand the issues surrounding #99164 and #98866, I created a function that outputs the current MPU region configuration and then compared these. Attached are the outputs of the following MPU configurations:

• mpu_regions_0_mcuboot.txt: Bootloader
• mpu_regions_1_with_mcuboot.txt: Sample with_mcuboot original
• mpu_regions_2_with_mcuboot_ethernet.txt: Sample with_mcuboot with enabled ethernet (like in STM32: H7S3L8 does not boot when networking is enabled #98866)
• mpu_regions_2_with_mcuboot_ethernet_sram2.txt: Sample with_mcuboot with enabled ethernet and sram2 zephyr,memory-attr = <DT_MEM_ARM(ATTR_MPU_RAM)> set in dt (like proposed in STM32H7S78-DK Ethernet support #99164)

The first regions come from mpu_regions.c, then from the nodes with zephyr,memory-attr-property, and the last one is set dynamically and protects some memory (comes from CONFIG_HW_STACK_PROTECTION).

I noticed the following:

1. Output 0 (mcuboot): Region 2 points out that mcuboot/blob/main/boot/zephyr/boards/nucleo_h7s3l8.conf#L1 sets CONFIG_BOOT_DIRECT_XIP=y. This is the only board in mcuboot's board folder with this configuration set and I think this configuration should not be active for the bootloader. CONFIG_XIP is set for mcuboot also. I think it shouldn't be set, but I don't know where it comes from. However, if we remove this, the MPU region for the internal flash 0x0800 0000 is not created. It should be created either via zephyr, memory-attr in the flash0-node of the SoC, or in mpu_regions.c as always RO.

2. Output 1 (with_mcuboot): Region 2 is the external flash @ 0x7000 000 with 32MB, but its size is set to the 64k of the internal flash. The entry comes from mpu_regions. c#L23 and I don't understand the reason, since CONFIG_FLASH_SIZE is set to 32768 (kB) in autoconf.h this is caused by CONFIG_FLASH_SIZE beeing set to 0. Not absolutely sure why, but has to do with the size/reg properties of the external flash node. I found out that with the changes from PR boards: st: nucleo_h7s3l8: Introduce App in Ext Flash variant #99647 this is fixed.
   But this region gets overlayed by another region, see my point 4 and the code could be removed from mpu_regions. c at all.

3. Output 0 / 1: Region 4 (read-only area in flash with unique device ID, ADC calibration data, etc.) is marked as RW in mcuboot, but correctly as RO in the sample. The reason is that CONFIG_MPU_ALLOW_FLASH_WRITE is set in mcuboot. Would it be better to set (MPU_RASR_C_Msk | REGION_2K | P_RO_U_RO_Msk) here instead of REGION_FLASH_ATTR(REGION_2K)?
   Edit: The type should be changed to REGION_IO_ATTR (same as region 1 "PERIPH") and size can be reduced to 512 bytes (see RM0477 table 28 and chapter 5.3.12)
   This gets fixed in soc: st: stm32: h7rsxx: Fix MPU region for read-only id flash region #99745

4. Output 1: Region 6 is the external flash @ 0x7000 000 the correct size of 32MB coming from the zephyr, memory-attr of the ext_memory-node. properties like zephyr,memory-region and zephyr,memory-attr are set in the soc and the boards (nucleo_h7s3l8, stm32h7s78_dk) - I think we can remove it from the SoC and have it only in the boards soc (same as with the sram config).
   This gets fixed in STM32: Fix h7rs MPU memory type for XSPI external flash #99668

5. Output 2 / 3: This is to show why we disabled sram2 per default to not overlay the ethernet dma memory regions defined earlier. I still don't know why ethernet is working if we do it anyway.

6. Output 0-3: Region 6 is configured as device memory (TEX2 S0 C0 B0) which means unaligned access is not allowed. But this happens quite often. @bklaric1 reported and @mariopaja reported such a behaviour and I get it when not building with CONFIG_DEBUG_OPTIMIZATIONS=y. In the mem fault prints you can see register values starting with 0x7000xxxx and having an odd LSB most likely pointing to a unaligned memory in the external flash. The external XiP flash should be configured as Normal, Write-back, no write allocate memory (TEX0 S0 C1 B1) which corresponds to <DT_MEM_ARM(ATTR_MPU_FLASH)>.
   This gets fixed in STM32: Fix h7rs MPU memory type for XSPI external flash #99668

7. The comment /* The ATTR_MPU_EXTMEM attribute causing a MPU FAULT */ in the ext_memory-node of the SoC is definitley correct, because ATTR_MPU_EXTMEM results in: STRONGLY_ORDERED_SHAREABLE | size | NO_ACCESS_Msk which means to no access at all - whats the purpose of this define?

Regression

• This is a regression.

Steps to reproduce

Use the my branch https://github.com/JB-Lighting/zephyr/tree/jb_mpu_print and apply mcuboot-extra.diff.txt to your mcuboot repo.

This will give you 2 complete MPU region configuration debug prints, one from mcuboot and one frome the chain-loaded application. See the output called from to check if it is coming from mcuboot (0x08000 xxxx) or the app (0x7000 xxxx)

I used the nucleo_h7s3l8 board, but there are only a few changes needed to run it on the stm32h7s78-dk.

Relevant log output

Impact

Functional Limitation – Some features not working as expected, but system usable.

Environment

• OS: Windows
• Toolchain: VScode with Zephyr IDE extension, SDK 17.3
• Zephyr 4.3, see branch url above

Additional Context

No response

[github-actions]

Hi @TD-JBL! We appreciate you submitting your first issue for our open-source project. 🌟

Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙

[JarmouniA]

The external XiP flash should be configured as Normal, Write-back, no write allocate memory (TEX0 S0 C1 B1) which corresponds to <DT_MEM_ARM(ATTR_MPU_FLASH)>.

@erwango related to #97992 (comment)

[JarmouniA]

Output 0 (mbcuboot): Region 2 points out that mcuboot/blob/main/boot/zephyr/boards/nucleo_h7s3l8.conf#L1 sets CONFIG_BOOT_DIRECT_XIP=y. This is the only board in mcuboot's board folder with this configuration set and I think this configuration should not be active for the bootloader.

It is the MCUboot mode used to load/upgrade the app image, but it is not required to be that one. Also I agree it shouldn't be set on MCUboot side, see #97992 and mcu-tools/mcuboot#2510

[TD-JBL]

Output 0 (mbcuboot): Region 2 points out that mcuboot/blob/main/boot/zephyr/boards/nucleo_h7s3l8.conf#L1 sets CONFIG_BOOT_DIRECT_XIP=y. This is the only board in mcuboot's board folder with this configuration set and I think this configuration should not be active for the bootloader.

It is the MCUboot mode used to load/upgrade the app image, but it is not required to be that one. Also I agree it shouldn't be set on MCUboot side, see #97992 and mcu-tools/mcuboot#2510

I mixed up CONFIG_XIP and CONFIG_BOOT_DIRECT_XIP: CONFIG_XIP is set in mcuboot, I don't know where it gets set. This is why Region 2 is created by mpu_regions.c. Your point about CONFIG_BOOT_DIRECT_XIP is also good, though.

[erwango]

CONFIG_XIP is set for mcuboot also. I think it shouldn't be set,

Why so ? MCUBoot running from flash is quite a common case. I guess it is set at the following location https://github.com/zephyrproject-rtos/zephyr/blob/94aad3b1abd48c5bc5927f1fd535c1ad21ca9ee6/arch/arm/core/Kconfig#L28

[erwango]

Thanks for this detailed analysis.
Do I sum it up correctly if I say that the shaky point of the mpu configuration is that:

	MPU_REGION_ENTRY("FLASH_0", CONFIG_FLASH_BASE_ADDRESS,
			 REGION_FLASH_ATTR(REGION_FLASH_SIZE)

will have different behavior depending binary is run from internal flash or external flash and with a unexpected FLASH_SIZE when in external flash ?

[TD-JBL]

CONFIG_XIP is set for mcuboot also. I think it shouldn't be set,

Why so ? [...]

I thought CONFIG_XIP should only be set on the chain-loaded application itself and not the bootloader. I guess I was wrong about that.

Do I sum it up correctly if I say that the shaky point of the mpu configuration is that: [...]

I wouldn't say that. The incorrect size of region 2 in the chain-loaded application is overlaid by region 6 (see mpu_regions_1_with_mcuboot.txt) and therefore has no effect. I would fix both things: The wrong size and having two regions for the same memory. (Those are my points 1 and 2.)

My 3rd point concerns the R/W configuration for Region 4 for mcuboot, the read-only flash starting at 0x8fff800. Not a real problem, but not correct.

My 4th point simply points out that some properties of the ext_memory-node exists twice (in the soc and on the board). I have revised this point above slightly to make it clearer.

My 6th point concerns the type of region 6 (external flash). Setting this area as "device memory" and thus blocking unaligned memory access is (in my opinion) the actual shaky point of the MPU configuration.

I'm happy to create PRs once we've agreed on a way forward. Currently working on ext_flash_app variant for the nucleo_h7s3l8 similar to PR #97992.