stm32: add memory-mapped mode for QUADSPI #72339

arbrauns · 2024-05-06T08:23:39Z

This CONFIG_STM32_MEMMAP is for enabling the MemoryMapped mode on external octo or quad spi memory. In this case, the flash_stm32_read is done in mem map mode the flash_stm32_erase is not available. Signed-off-by: Francois Ramu <francois.ramu@st.com>

FRASTM · 2024-05-06T15:06:31Z

Thanks for implementing the memorymapped mode with the stm32 quadspi flash driver
Aborting the memory-mapped mode is required before erasing and writing (most of the quad flash cannot be written with memcopy).

Did you check that access to the quad-NOR is still possible in erase/read/write with your change.
When I tried this sequence (in stm32 QSPI flash driver enables XiP on external NOR flash #68607), I realized that the samples/drivers/spi_flash fails after successive abort_memorymapped/set_memroymapped/abort_memorymapped. Did you run this example ?
Do you confirm that the flash_stm32_qspi.c is also supporting stm32h7 and stm32l4 series that have quad-spi peripherals ?

drivers/flash/flash_stm32_qspi.c

arbrauns · 2024-05-06T15:46:07Z

samples/drivers/spi_flash fails after successive abort_memorymapped/set_memroymapped/abort_memorymapped. Did you run this example ?

Yes, it works fine here after fixing the CR/CCR bug you noted. I have found another issue though: if the flash is already set to memory-mapped by e.g. openocd, the init is short-circuited, which causes any flash operations by the firmware to hang (semaphore not available). In my opinion this short-circuiting in flash_stm32_qspi_init() isn't even required:

either firmware needs the flash to remain memory-mapped (as setup by the bootloader) continuously, in which case it will simply not include the flash driver,
or the firmware uses the flash through flash_*() functions, in which case it doesn't care about it being memory-mapped during boot.

I can't imagine a firmware that requires continuous memory-mapping in order to boot, but then later also uses the flash_*() functions for the same device - do you agree that this use-case is rare enough that it can simply be ignored for now (more elaborate hacks can still be added later should anyone need them)?

Do you confirm that the flash_stm32_qspi.c is also supporting stm32h7 and stm32l4 series that have quad-spi peripherals ?

I initially developed it for a custom stm32l452 board, it works fine there. I don't have an h7 board with QSPI flash to test.

FRASTM · 2024-05-07T08:44:31Z

drivers/flash/flash_stm32_qspi.c

+		if (ret != 0) {
+			LOG_ERR("Failed to abort memory-mapped access before write");
+			goto end;
+		}


suggestion : LOG_DBG("Abort Memory-mapped before write");

That feels much less clear to me. For one it doesn't even mention that something went wrong, and it's also not the memory-mapping that's being aborted, just a latent read access, if any.

I think the suggestion was to put it after, once abort is completed.

I think the suggestion was to put it after, once abort is completed.

@arbrauns Can you check this comment ?

Ah, that makes sense, but then that LOG_DBG() would trigger on every single flash write/erase - would that make sense?

There's already a LOG_DBG on flash_stm32_qspi_read so, that would be coherent.

drivers/flash/flash_stm32_qspi.c

FRASTM · 2024-05-07T08:45:10Z

drivers/flash/flash_stm32_qspi.c

+		if (ret != 0) {
+			LOG_ERR("Failed to abort memory-mapped access before write");
+			goto end;
+		}


suggestion : LOG_DBG("Abort Memory-mapped before erase");

FRASTM

Cannot pass the samples/application_development/code_relocation_nocopy/ on stm32h747_disco or stm32h750b_dk.
Succesfully Tested with samples/drivers/spi_flash on stm32f746g_disco (single quad-flash) in memory mapped mode.

arbrauns · 2024-05-07T09:25:31Z

Cannot pass the samples/application_development/code_relocation_nocopy/ on stm32h747_disco or stm32h750b_dk.

As I said, I don't have h7 hardware, could you give some more information about the failures? A good candidate is the ATTR_MPU_EXTMEM QSPI placeholder region, it blocks execution access to the external flash and needs to be overridden with an ATTR_MPU_IO region the size of the actual attached flash, see 78c9ee7.

erwango

Thanks for putting this all together, some non blocking comments.
Otherwise LGTM once comments from @FRASTM are implemented.

drivers/flash/flash_stm32_qspi.c

boards/st/stm32f769i_disco/stm32f769i_disco.dts

erwango · 2024-05-07T09:26:43Z

boards/st/stm32f769i_disco/stm32f769i_disco.dts

@@ -74,6 +74,13 @@
 		sw0 = &user_button;
 		spi-flash0 = &mx25l51245g;
 	};
+
+	quadspi_memory_avail: memory-avail@90000000 {


It would be nice to update board documentation to provide some details on how this could be used.

samples/application_development/code_relocation_nocopy/linker_arm_nocopy.ld

erwango · 2024-05-07T09:31:43Z

Cannot pass the samples/application_development/code_relocation_nocopy/ on stm32h747_disco or stm32h750b_dk.

Not blocking for the current PR. Let's document clearly what ia available and enter a GH issue on the known issues.

FRASTM · 2024-05-07T09:37:13Z

Cannot pass the samples/application_development/code_relocation_nocopy/ on stm32h747_disco or stm32h750b_dk.

As I said, I don't have h7 hardware, could you give some more information about the failures? A good candidate is the ATTR_MPU_EXTMEM QSPI placeholder region, it blocks execution access to the external flash and needs to be overridden with an ATTR_MPU_IO region the size of the actual attached flash, see 78c9ee7.

Building west build -p auto -b stm32h750b_dk samples/application_development/code_relocation_nocopy/
with

	ext_memory: memory@90000000 {
		compatible = "zephyr,memory-region";
		reg = <0x90000000 DT_SIZE_M(64)>; /* max addressable area */
		zephyr,memory-region = "EXTMEM";
		/* The ATTR_MPU_EXTMEM attribut causing a MPU FAULT */
		zephyr,memory-attr = <( DT_MEM_ARM(ATTR_MPU_IO) )>;
	};

and

CONFIG_FLASH=y
CONFIG_STM32_MEMMAP=y

gives the following error:

...
[00:00:00.000,000] <inf> flash_stm32_qspi: Memory-mapped NOR quad-flash at 0x90000000 (0x4000000 bytes)
*** Booting Zephyr OS build v3.6.0-3420-g69d57d068729 ***
Address of main function 0x800066d
[00:00:00.000,000] <err> os: ***** USAGE FAULT *****
[00:00:00.000,000] <err> os:   Attempt to execute undefined instruction
[00:00:00.000,000] <err> os: r0/a1:  0x0000000e  r1/a2:  0x00000000  r2/a3:  0x0000000f
[00:00:00.000,000] <err> os: r3/a4:  0x00000000 r12/ip:  0x00000000 r14/lr:  0x08000681
[00:00:00.000,000] <err> os:  xpsr:  0x61000000
[00:00:00.000,000] <err> os: Faulting instruction address (r15/pc): 0x90000000
[00:00:00.000,000] <err> os: >>> ZEPHYR FATAL ERROR 36: Unknown error on CPU 0
[00:00:00.000,000] <err> os: Current thread: 0x240007f0 (unknown)
[00:00:00.058,000] <err> os: Halting system

And the STM32CubeProgrammer shows 0xFF (blank sector) at 0x90000000

arbrauns · 2024-05-07T09:49:54Z

Since I didn't see any complaints, I've also removed the hack in flash_stm32_qspi_init() now.

arbrauns · 2024-05-07T09:51:34Z

And the STM32CubeProgrammer shows 0xFF (blank sector) at 0x90000000

Are you sure the external flash programming worked then?

FRASTM · 2024-05-07T14:47:05Z

And the STM32CubeProgrammer shows 0xFF (blank sector) at 0x90000000

Are you sure the external flash programming worked then?

Yes, with the STM32CubeProgrammer from #68377
At least for stm32h750b_dk the dual quad-flash configuration requires to enable the dual flash mode, just before going to stm32_qspi_set_memory_mapped in the flash_stm32_qspi_init
MODIFY_REG(dev_data->hqspi.Instance->CR, (QUADSPI_CR_DFM), QSPI_DUALFLASH_ENABLE);

Then west build b -p auto -b stm32h750b_dk samples/application_development/code_relocation_nocopy ; west flash
gives:

[00:00:00.000,000] <dbg> flash_stm32_qspi: flash_stm32_qspi_init: Dual Flash Mode                                                                      
[00:00:00.000,000] <dbg> flash_stm32_qspi: stm32_qspi_set_memory_mapped: MemoryMap mode enabled                                                        
[00:00:00.000,000] <inf> flash_stm32_qspi: Memory-mapped NOR quad-flash at 0x90000000 (0x4000000 bytes)                                                
*** Booting Zephyr OS build v3.6.0-3067-gae992b9e37d6 ***                                                                                              
Address of main function 0x800066d                                                                                                                     
Address of function_in_ext_flash 0x90000001                                                                                                            
Address of var_ext_sram_data 0x240000e0 (10)                                                                                                           
Address of function_in_sram 0x24000001                                                                                                                 
Address of var_sram_data 0x240000e4 (10)                                                                                                               
Hello World! stm32h750b_dk

Refer to #72429

drivers/flash/flash_stm32_qspi.c

This puts the QSPI peripheral into memory-mapped mode when CONFIG_STM32_MEMMAP is set. Writes and erase put it back into indirect write mode. Signed-off-by: Armin Brauns <armin.brauns@embedded-solutions.at>

According to the datasheet, fRSCLK (Clock Frequency for READ instructions) is 66MHz; it doesn't mention 72MHz anywhere. Signed-off-by: Armin Brauns <armin.brauns@embedded-solutions.at>

…alt" The init script is required for QSPI flash setup. Signed-off-by: Armin Brauns <armin.brauns@embedded-solutions.at>

By default, the QSPI region is marked as EXTMEM and inaccessible (see zephyrproject-rtos#57467), mark the first 64MB as IO on stm32f769i_disco. Signed-off-by: Armin Brauns <armin.brauns@embedded-solutions.at>

This board has memory-mapped QSPI flash. Signed-off-by: Armin Brauns <armin.brauns@embedded-solutions.at>

erwango

Approved on my side as the latest discussion on logging doesn't feel blocking to me.

arbrauns requested review from erwango, ABOSTM and FRASTM as code owners May 6, 2024 08:23

zephyrbot added platform: STM32 ST Micro STM32 area: Flash area: Samples Samples labels May 6, 2024

zephyrbot requested review from ajarmouni-st, de-nordic, gautierg-st, GeorgeCGV, kartben and nashif May 6, 2024 08:24

zephyrbot assigned kartben May 6, 2024

kartben assigned erwango and unassigned kartben May 6, 2024

ajarmouni-st removed the request for review from ABOSTM May 6, 2024 09:04

FRASTM requested changes May 6, 2024

View reviewed changes

drivers/flash/flash_stm32_qspi.c Outdated Show resolved Hide resolved

drivers/flash/flash_stm32_qspi.c Outdated Show resolved Hide resolved

FRASTM reviewed May 7, 2024

View reviewed changes

drivers/flash/flash_stm32_qspi.c Show resolved Hide resolved

FRASTM reviewed May 7, 2024

View reviewed changes

erwango reviewed May 7, 2024

View reviewed changes

arbrauns force-pushed the stm32-qspi-memmapped branch from 69d57d0 to 3b43d4f Compare May 7, 2024 09:48

erwango self-requested a review May 7, 2024 16:23

FRASTM mentioned this pull request May 13, 2024

stm32 OSPI flash driver enables XiP on external NOR flash #68597

Merged

erwango reviewed May 13, 2024

View reviewed changes

drivers/flash/flash_stm32_qspi.c Outdated Show resolved Hide resolved

arbrauns added 5 commits May 14, 2024 10:41

drivers/flash: enable memory-mapped mode for STM32 QSPI

bbbd842

This puts the QSPI peripheral into memory-mapped mode when CONFIG_STM32_MEMMAP is set. Writes and erase put it back into indirect write mode. Signed-off-by: Armin Brauns <armin.brauns@embedded-solutions.at>

boards/stm32f769i_disco: fix NOR flash max frequency

ff7863f

According to the datasheet, fRSCLK (Clock Frequency for READ instructions) is 66MHz; it doesn't mention 72MHz anywhere. Signed-off-by: Armin Brauns <armin.brauns@embedded-solutions.at>

boards/stm32f769i_disco: use openocd "reset init" instead of "reset h…

d5ced65

…alt" The init script is required for QSPI flash setup. Signed-off-by: Armin Brauns <armin.brauns@embedded-solutions.at>

boards/stm32f769i_disco: add accessible memory region for QSPI flash

582f702

By default, the QSPI region is marked as EXTMEM and inaccessible (see zephyrproject-rtos#57467), mark the first 64MB as IO on stm32f769i_disco. Signed-off-by: Armin Brauns <armin.brauns@embedded-solutions.at>

samples: code_relocation_nocopy: add stm32f769i_disco board

d46b248

This board has memory-mapped QSPI flash. Signed-off-by: Armin Brauns <armin.brauns@embedded-solutions.at>

arbrauns force-pushed the stm32-qspi-memmapped branch from 3b43d4f to d46b248 Compare May 14, 2024 10:42

erwango approved these changes May 14, 2024

View reviewed changes

FRASTM approved these changes May 16, 2024

View reviewed changes

carlescufi merged commit e7a53cf into zephyrproject-rtos:main May 16, 2024
21 checks passed

FRASTM mentioned this pull request May 17, 2024

stm32 QSPI flash driver enables XiP on external NOR flash #68607

Closed

GeorgeCGV mentioned this pull request Jul 9, 2024

drivers: clock_control: stm32h7: disabling PLL when executing in memory map mode leads to a stall #75653

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

stm32: add memory-mapped mode for QUADSPI #72339

stm32: add memory-mapped mode for QUADSPI #72339

arbrauns commented May 6, 2024

FRASTM commented May 6, 2024

arbrauns commented May 6, 2024

FRASTM May 7, 2024

arbrauns May 7, 2024

erwango May 13, 2024

erwango May 14, 2024

arbrauns May 14, 2024

erwango May 14, 2024

FRASTM May 7, 2024

FRASTM left a comment •

edited

Loading

arbrauns commented May 7, 2024

erwango left a comment

erwango May 7, 2024

erwango commented May 7, 2024 •

edited

Loading

FRASTM commented May 7, 2024 •

edited

Loading

arbrauns commented May 7, 2024

arbrauns commented May 7, 2024

FRASTM commented May 7, 2024 •

edited

Loading

erwango left a comment

stm32: add memory-mapped mode for QUADSPI #72339

stm32: add memory-mapped mode for QUADSPI #72339

Conversation

arbrauns commented May 6, 2024

FRASTM commented May 6, 2024

arbrauns commented May 6, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

FRASTM left a comment • edited Loading

Choose a reason for hiding this comment

arbrauns commented May 7, 2024

erwango left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

erwango commented May 7, 2024 • edited Loading

FRASTM commented May 7, 2024 • edited Loading

arbrauns commented May 7, 2024

arbrauns commented May 7, 2024

FRASTM commented May 7, 2024 • edited Loading

erwango left a comment

Choose a reason for hiding this comment

FRASTM left a comment •

edited

Loading

erwango commented May 7, 2024 •

edited

Loading

FRASTM commented May 7, 2024 •

edited

Loading

FRASTM commented May 7, 2024 •

edited

Loading