stm32 with external NOR ospi flash in MemoryMapped mode

[FRASTM]

This PR is enabling the MemoryMapped to access the octo NOR flash at the end of the initialization.
With this configuration, the NOR flash access is done with memcopy in read or write
Note that the erase is not supported but writing is possible in MemoryMapped mode.
(It is not recommended to fill the memory with 0xFFFFFFFF)

The drivers detects the CONFIG_STM32_MEMMAP flag to enable the MemoryMapped mode.

[FRASTM]

reading flash of the b_u585i_iot02a in memory mapped mode (@ 0x70000000) :

Data read : 
00000000 read 3d
00000001 read b8
00000002 read f3
00000003 read 96
[00:00:00.140,000] <inf> flash_stm32_ospi: OSPI flash config is OPI / DTR
[00:00:00.140,000] <inf> flash_stm32_ospi: Read SFDP from octoFlash
[00:00:00.140,000] <inf> flash_stm32_ospi: Read SFDP from octoFlash
NOR in MemoryMapped mode 

[zephyrbot]

The following west manifest projects have been modified in this Pull Request:

Name	Old Revision	New Revision	Diff

Note: This message is automatically posted and updated by the Manifest GitHub Action.

[FRASTM]

rebase on 4d304a2
take the ../modules/hal/stm32/stm32cube/ PR 178

[FRASTM]

rebase on e9dd938

[FRASTM]

New version where the HAL is not changed thanks to direct access to the hospi instance in the flash_stm32_ospi driver
The flash base addresse and size are directly placed in the flash-controller node of the Device Tree : reg = <0x70000000 DT_SIZE_M(64)>; (no more size property required)

Using a sample to demonstrate (adapted from samples/drivers/spi_flash) to read operation in memorymapped mode (no erase sector).
Requires the CONFIG_BOOT_DIRECT_XIP=y when compiling the mcuboot

Tested with the b_u585i_iot02a disco board ;

*** Booting Zephyr OS build zephyr-v3.4.0-3121-g4df7ebf34d86 ***
I: Starting Direct-XIP bootloader
I: Image 0 Primary slot: Image not found
I: Secondary slot: version=0.0.0+0
I: Image 0 loaded from the secondary slot
I: Bootloader chainload address offset: 0x0
�*** Booting Zephyr OS build zephyr-v3.4.0-3121-g4df7ebf34d86 ***
Hello World! from external flash  b_u585i_iot02a

[de-nordic]

This PR is enabling the MemoryMapped to access the octo NOR flash at the end of the initialization. With this configuration, the NOR flash access is done with memcopy in read or write Note that the erase is not supported but writing is possible in MemoryMapped mode. (It is not recommended to fill the memory with 0xFFFFFFFF)

Maybe this could be useful here #62228.

[Laczen]

@FRASTM, thanks for the PR.

Is my conclusion correct that when using XIP and memory mapped mode there is no part of the flash device that can be used by a fs (that always need an erase) ?

[Laczen]

When the CONFIG_STM32_MEMMAP is set this version adds an Abort function to resume the MemoryMapped mode, so that erasing is possible and restore the MemoryMapped mode after completion Note that flash read and write are using memcpy.

Nice, if write works with memcpy that is OK. Is it not needed to disable irq's when memory mapped mode is aborted (would there be irq code that is not available during the erase) ?

[FRASTM]

Rebase on d7873e2

Requires MCUboot PR mcu-tools/mcuboot#1891 where the mcuboot is built/linked/stored at the boot_partition in internal mcu flash ( 0x8000000)

Add an example samples/subsys/fs/littlefs/ where the application is running in external NOR memory (XiP) and where the lfs1 partition is in internal MCU memory.

The slot0 where to execute the application is located in external flash memory and chosen as zephyr,code-partition = &slot0_partition; (slot0 partition is located in the external flash, offset 0)

1. building/linking The sample application with

west build -p always -b b_u585i_iot02a samples/subsys/fs/littlefs/ --sysbuild --
-DCONFIG_FLASH_BASE_ADDRESS=0x70000000
-DSB_CONFIG_BOOTLOADER_MCUBOOT=y

2. sign The sample application with

west sign -t imgtool -- --key ../bootloader/mcuboot/root-rsa-2048.pem

3. load sample application with STM32CubeProgrammer at address of the external flash slot1

~/STMicroelectronics/STM32CubeProgrammer/bin/STM32_Programmer_CLI -c port=swd -el ~/STMicroelectronics/STM32CubeProgrammer/bin/ExternalLoader/MX25LM51245G_STM32U585I-IOT02A.stldr -d build/littlefs/zephyr/zephyr.signed.bin 0x70000000 -rst

• Note that 0x70000000 is the address of the external flash where image is stored (slo0at offset 0, or offset of slot1)

	chosen {
		zephyr,flash = &mt25ql512ab1;
		zephyr,code-partition = &slot0_partition;
	};

• Note that the mcuboot is built/linked/flashed for (internal MCU) address 0x8000000 (no image-0/1 required)

[FRASTM]

*** Booting Zephyr OS build zephyr-v3.5.0-3956-gbea3951f1683 ***
I: Starting Direct-XIP bootloader
I: Image 0 Primary slot: Image not found
I: Secondary slot: version=0.0.0+0
I: Image 0 loaded from the secondary slot
I: Bootloader chainload address offset: 0x100000
I: Jumping to the image slot
I: NOR init'd in MemMapped mode

I: littlefs partition at /lfs1
I: LittleFS version 2.5, disk version 2.0
I: FS at flash-controller@40022000:0xd0000 is 8 0x2000-byte blocks with 512 cyce
I: sizes: rd 256 ; pr 256 ; ca 4096 ; la 256
I: Automount /lfs1 succeeded
*** Booting Zephyr OS build zephyr-v3.5.0-3956-gbea3951f1683 ***
Sample program to r/w files on littlefs
Area 0 at 0xd0000 on flash-controller@40022000 for 65536 bytes
/lfs1 automounted
/lfs1: bsize = 256 ; frsize = 8192 ; blocks = 8 ; bfree = 6
                                                                                
Listing dir /lfs1 ...                                                           
[FILE] boot_count (size = 1)                                                    
[FILE] pattern.bin (size = 547)                                                 
/lfs1/boot_count read count:4 (bytes: 1)                                        
/lfs1/boot_count write new boot count 5: [wr:1]                                 
------ FILE: /lfs1/pattern.bin ------                                           
05 aa aa aa aa aa aa aa 06 aa aa aa aa aa aa aa                                 
...                             
                                                                
I: /lfs1 unmounted                                                              
/lfs1 unmount: 0  

[FRASTM]

When the CONFIG_STM32_MEMMAP is set this version adds an Abort function to resume the MemoryMapped mode, so that erasing is possible and restore the MemoryMapped mode after completion Note that flash read and write are using memcpy.

Nice, if write works with memcpy that is OK. Is it not needed to disable irq's when memory mapped mode is aborted (would there be irq code that is not available during the erase) ?

Write is not really guaranteed. in memorymapped mode : with stm32u585, the data written (with memcopy) and read back (in memcopy) are correct but do not seem persistent in flash !?

[Laczen]

@FRASTM, your commit comments are still showing that erase and write is not supported, is this still the case ? If erase works, can't you use the same methodology (go out of memmap, do erase, return to memmap) for the write ?

[de-nordic]

stm32u585

https://www.st.com/resource/en/reference_manual/rm0456-stm32u5-series-armbased-32bit-mcus-stmicroelectronics.pdf

RM0456 Rev 5 1061/3637
RM0456 Octo-SPI interface (OCTOSPI)
1095
28.4.11 OCTOSPI memory-mapped mode:

"It is not recommended to program the flash memory using the memory-mapped writes:
the indirect-write mode fulfills this operation."

Page 1064 explains more.

Reads/writes to OSPI connected, memory-mapped, device will be probably cached, so unless you invalidate cache and force OQSPI to re-read the area then you will not know whether data has been written correctly, as it seems that there is no auto-erase on writes, writes are probably not verified.

The reservations are only for flash, so I guess that SRAM connected device will work fine, but that kind device changes bits in any to any transition, while flash in any to 0 only.

[FRASTM]

@FRASTM, your commit comments are still showing that erase and write is not supported, is this still the case ? If erase works, can't you use the same methodology (go out of memmap, do erase, return to memmap) for the write ?

Yes it works : erasing/writing the NOR octo-flash after aborting the mem map mode.

[FRASTM]

adding a commit to abort the memorymapped mode before erasing or writing to the external NOR octoflash

[FRASTM]

The PR #68597 is now replacing this PR