stm32h7: qspi: Not accessible in memory mapped mode

[erwango]

Describe the bug
Issue raised from a coworker following merge of #57467:

I'm not sure if this is the best solution, although I have zero experience with Zephyr RTOS (I have some basic knowledge of the DTS concept from Linux).
As I understand, the code will disable (Strongly ordered, no access) the QSPI memory region by default for all Zephyr projects. Then if you want to use QSPI in memory-mapped mode in your project, you need to override this setting in the project specific DTS.

I think better solution would be to have Region 0 with following configuration:

• Base address: 0x0
• Region size: 4GB (whole memory range)
• SubRegion disable: 0x87 (this excludes internal memories and peripherals)
• TEX: 0, Bufferable: 0, Cacheable: 0, Shareable: 1 (Strongly ordered)
• All access disabled
• Instruction access: disabled

Since this is defined as Region 0, any higher MPU regions can overwrite such setting.
This what is recommended and applied via pop-up window when configuring new CubeMX project for STM32F7 or STM32H7.

This solution might prevent similar issue in more wide range of projects. E.g. similar issues can be encountered with FMC peripheral.
However I'm not sure how easy it would be to integrate to Zephyr, since I haven't seen e.g. the subregion option for the zephyr,memory-region node. Also I'm not sure if it possible to force this configuration to be region 0. Maybe it would need to be done some other way.

Also I'm not sure if "EXTMEM" is a good name for attribute that disables all access.

Impact
The code will disable (Strongly ordered, no access) the QSPI memory region by default for all Zephyr projects. Then if you want to use QSPI in memory-mapped mode in your project, you need to override this setting in the project specific DTS.

[erwango]

@benjaminbjornsson ^^, This point will have to be solved (or commit reverted) before being able to enable XIP on H7 series.

[erwango]

@carlocaione I'm staring at #60049 right now.
Do you think it could solve current point?
My understanding is: not fully, but can now be extended to fulfill it. Am I right ?

[carlocaione]

That commit is only introducing a couple of helpers to manage memory nodes and their attributes, what you do with these helpers is really up to the developer. So yes, you can leverage that commit if you want.

I think what you specifically need from that commit is the fact that you can use a memory attribute on an mmio-sram region and build an MPU region on that, so yeah, I think that could be helpful for this case.

[erwango]

Thanks @carlocaione we'll have a closer look

[FRASTM]

Adding such a region 0 to the static const struct arm_mpu_region mpu_regions[] in /soc/arm/st_stm32/stm32h7/mpu_regions.c with

	MPU_REGION_ENTRY("REGION_0", 0,
					{ (STRONGLY_ORDERED_SHAREABLE | REGION_4G | NO_ACCESS_Msk) }),

is not enough.

Neither

	MPU_REGION_ENTRY("REGION_0", 0,
					{ (STRONGLY_ORDERED_SHAREABLE | REGION_4G | NO_ACCESS_Msk |
						SUB_REGION_0_DISABLED |
						SUB_REGION_1_DISABLED |
						SUB_REGION_2_DISABLED |
						SUB_REGION_7_DISABLED) }),

The qspi flash cannot be read @ 0x90000000 --> z_arm_usage_fault
with quadspi_memory node removed and with or w/o
MPU_REGION_ENTRY("EXTMEM", 0x90000000, REGION_EXTMEM_ATTR(REGION_256M)),

[FRASTM]

When declaring the external qspi NOR flash node with

	quadspi_memory: memory@90000000 {
		compatible = "zephyr,memory-region", "mmio-sram";
		device_type = "memory";
		reg = <0x90000000 DT_SIZE_M(256)>;
		zephyr,memory-region = "EXTMEM";
		zephyr,memory-attr = "RAM";
	};

The include/zephyr/arch/arm/aarch32/mpu/arm_mpu_v7m.h does have a REGION_EXTMEM_ATTR()

Branch : https://github.com/FRASTM/zephyr/tree/stm32h7_qspi_memmap

[00:00:00.000,000] <inf> flash_stm32_qspi: QSPI: MemoryMapped Ready at 0x90000000                          
*** Booting Zephyr OS build zephyr-v3.4.0-1798-gba20844eb94d ***                                           
[00:00:00.008,000] <inf> flash_stm32_qspi: MemoryMapped Read offset: 0x-1879048192, len: 4  

However, the application reads wrong data from quad NOR Flash at 0x90000000, after NOR flash erase :

(gdb) x /4x 0x90000000
0x90000000: 0x66882244 0xffffaacc 0xffffffff 0xffffffff

which  is similar to  what the flash_read with command mode:
```
00000000  read 44                                                                                  
00000001  read 22                                                                                  
00000002  read 88                                                                                  
00000003  read 66                                                                                  
00000004  read cc                                                                                  
00000005  read aa                                                                                  
00000006  read ff                                                                                  
00000007  read ff   
```

[FRASTM]

See PR #61122

[FRASTM]

When Using the qspi NOR flash in MemoryMapped mode, it is accessible for reading
Even is writing is possible it is not recommended and the erase is not possible.

--> There is a question about how should behave the driver on flash_erase/flash_write API in MemoryMapped mode.

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

[FRASTM]

For the stm32H7x serie, when the zephyr driver is executing the same sequence as the stm32CubeMX, to enter the MemoryMapped mode, then the memory at 0x90000000 becomes readable (write always fails) but one byte out of two:

offset = 00000000 ; read 20
offset = 00000001 ; read 2a
offset = 00000002 ; read 2a
offset = 00000003 ; read 65
offset = 00000004 ; read 6f
offset = 00000005 ; read 79
offset = 00000006 ; read 6d
offset = 00000007 ; read 70
offset = 00000008 ; read 65

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.