[WIP] stm32 mspi drivers for the MSPI flash and controller

[FRASTM]

this PR is introducing the MSPI driver device a controller for the stm32 mcus : stm32H5 serie

• MSPI device = nor flash node drivers/flash/flash_mspi_nor_mx typically the mx25lm51245 mounted on the disco kit
  ---> compat is mspi_nor_mx25
• MSPI controller : drivers/mspi/mspi_stm 32 typically the octospi peripherals of the stm32 devices.
  ---> compat is st,stm32-mspi-controller

Build an run the samples/drivers/mspi/mspi_flash/ on stm32h573i_dk disco kit​

• only SPI / STR mode : configure/
• SPI / STR mode : read (in async. IT ) ​
• SPI / STR mode : erase/write (in async. IT ) wait for mem ready (typ. SPI_NOR_WEL_MATCH/SPI_NOR_WEL_MASK)
• OPI/QUAD and DTR mode : configure/erase/read/write (octal commands)​
• read/erase/write with DMA
• XIP configuration (stm32 memorymap mode)​
• Support more platforms (and NOR flash devices)​
• Support psRAM device

[FRASTM]

reading external NOR at offset 0 in spi/str mode :

Perform test read on single sector
 command Instruction = 0x13
Data read at is 
Read at 00000000 read 08
Read at 00000001 read b5
Read at 00000002 read 06
Read at 00000003 read 4a                                                        
Read at 00000004 read 06                                                        
Read at 00000005 read 49                                                        
Read at 00000006 read 07                                                        
Read at 00000007 read 48                                                        
Read at 00000008 read 00                                                        
Read at 00000009 read f0                                                        
Read at 0000000a read 12                                                        
Read at 0000000b read f8                                                        
Read at 0000000c read bd                                                        
Read at 0000000d read e8                                                        
Read at 0000000e read 08                                                        
Read at 0000000f read 40  

Perform test on single sector                                                                                
Test 1: Flash erase at 0xff000                                                                               
Flash erase succeeded!                                                                                       
                                                                                                             
Test 2: Flash write at 0xff000                                                                               
Attempting to write 4 bytes                                                                                  
                                                                                                             
Test 3: Flash read at 0xff000                                                                                
Data read matches data written. Good!!                                                                       
                                                                                                             
Perform test on multiple consecutive sectors                                                                 
Test 1: Flash erase from 0xff000                                                                             
Flash erase succeeded!                                                                                       
                                                                                                             
Test 2: Flash write from 0xff000                                                                             
Attempting to write 4 bytes at offset 0xff000                                                                
Attempting to read 4 bytes at offset 0xff000                                                                 
Data read matches data written. Good!!                                                                       
Attempting to write 4 bytes at offset 0x100000                                                               
Attempting to read 4 bytes at offset 0x100000                                                                
Data read matches data written. Good!!                                                                       
==========================        

[swift-tk]

I will start by thanking your support for the MSPI API. @FRASTM
After taking a brief look and I think there are quite a lot of work to be done for both the controller and device driver.
Additionally, I would like to stress one more time that it is important to shroud hardware differences in the device driver. In this case, it is the flash_mspi_nor_mx.c. So that we may have shared drivers that can be used across platform.

[swift-tk]

So the user context way did not work out?
The methods(auto polling) introduced in this function is not a common one thus should not appear like this in a shared driver as others(controllers) will not be able to use this driver.
Also I'm confused with the use of async PIO but does not register callback?

[FRASTM]

actually, I did not find a proper way to handle that with a user context
There is a struct mspi_xfer trans; or a struct mspi_xfer_packet packet; that are available in the flash_mspi_nor_mx_data but no user context structure appears clearly

I understand that the flash driver could first, give the AutoPolling bit (mask/match) to the MSPI controller and then call a flash_mspi_nor_mx_busy_wait(). But what should be the way to pass that AutoPolling bit (mask/match) from the flash to the mspi controller ?

[swift-tk]

I have a example raw implementation of autopoll using Ambiq controller. We don't support autopoll natively by hardware but the upper layer should suffice to demonstrate my suggestion.
Please checkout https://github.com/AmbiqMicro/ambiqzephyr/commits/apollo3p-mspi-autopoll-trial/ and this commit 39e35c83590bdef7096e4e13e53a35346cbfaa23

You need to define your own user context for autopolling in the device driver as this may not be generic.

[FRASTM]

ur own user context for autopolling in the device driver as this may

Ok, I can see the data->autopoll to pass to the mspi driver
What is not yet really clear is

• the goal of the magic
• the role of flash_mspi_atxp032_autopoll.match_ap/mask_ap compared to mspi_ambiq_autopoll_cfg->match
  / flash_mspi_atxp032_autopoll-> mask
• in the mspi_stm32_transceive I still have a check on the command to send (RDSR) but I do not see where the autopoll_cb is used
• https://github.com/FRASTM/zephyr/tree/stm32_mspi_autopoll

[swift-tk]

the goal of the magic

It is for type safety to make sure the upper layer did pass the correct structure one defined as the ctx defined in struct mspi_callback_context is of type void *.

the role of flash_mspi_atxp032_autopoll.match_ap/mask_ap compared to mspi_ambiq_autopoll_cfg->match
/ flash_mspi_atxp032_autopoll-> mask

I try to design the autopoll feature to not just about pulling one byte and verify one bit in the flash status register. So in mspi_ambiq_autopoll_cfg the mask and match are array of values and masks that one can use to match with what will be read from the MSPI interface. You don't have to follow through on this.

in the mspi_stm32_transceive I still have a check on the command to send (RDSR) but I do not see where the autopoll_cb is used

Here everything is configured and waiting for a interrupt, correct? What should happen is that your HAL_XSPI_IRQHandler should call the autopull_cb when the interrupt fires. I see you have copied mspi_autopoll_callback to your file, this is equivalent to your HAL_XSPI_xxxxCallback. Without looking into your hal, you may need to find a way to register mspi_autopoll_callback, similarly to how mspi_dma_callback is being registered.

Below is irrelevent to autopoll
MSPI_DMA : async/sync is meaningless with DMA (no DMA IT function)
I'm curious that since you have mspi_dma_callback this means dma operation can be async, why are you saying in your comment that it is meaningless?

One side note after looking at https://github.com/FRASTM/zephyr/tree/stm32_mspi_autopoll :
I think you are skewing the controller driver a bit too much to one specific use i.e. flash with all that mspi_stm32_mem_ready and mspi_stm32_write_enable. How do you already know that your device is already a flash and just do mspi_stm32_config_mem in mspi_stm32_dev_config?
My suggestion is to think about the scope of the controller driver as just managing transfers not its device's state.

[swift-tk]

You will need to consider controllers that does not support XIP read.
The config CONFIG_MSPI_XIP is used to indicate a controller's support on that.
It was my bad that I did not include those config in my PR for the atxp032 flash driver and will be fixed in the near future. You should consider adding them like this #79513

[swift-tk]

You can't assume that only setting IO mode and data rate is enough.
Different controller have different defaults when it comes to the member of struct mspi_dev_cfg. Even the initialization process may needed different values. So they should specified and configure clearly.
Thus this should be a CONFIG_ALL.

[swift-tk]

That is the point actually. The initial mspi_dev_config is only for device initialization and the settings should be power on default/OTP default. You can have several mspi_dev_config if needed be but the final mspi_dev_config should bring it to the target operational state.

[swift-tk]

Not sure I understand the reason why DMA is not used. Now that I think of it, maybe we should make it configurable for different controllers or users.

[swift-tk]

Does mspi_transceive return before DMA completes the transfer? If so, it is async. The complete status is updated through callback.

[GeorgeCGV]

The MSPI adds an abstraction layer and allows for the addition of device-specific MSPI drivers (e.g., for MX, Winbond, etc.). However, it looks like a step backward from existing O/Q/X/SPI drivers. The SFDP autoconfiguration capabilities are dropped, and dependencies between lines and opcodes are not considered. The command configuration happens on the lowest level outside the device MSPI driver. That will lead to a bloated low-level driver, increasing footprint, and potentially degrading performance.

Perhaps I am missing something. But what advantages does MSPI offer over the existing Q/O/X/SPI drivers, particularly for STM32 NOR-Flash support?

To address some of these issues, device-specific drivers must have greater control over low-level aspects (e.g., data lines, opcodes, etc.). However, this could lead to code duplication across drivers for MX, Winbond, and other NOR-Flash devices. A potential solution might be a generic MSPI-NOR-Flash driver that works in conjunction with a specific low-level Q/O/X/SPI MSPI driver. For example, the Q/O/X/SPI MSPI driver must use the mspi-io-mode when it performs mspi_stm32_prepare_cmd. However, as MSPI allows users to provide write/read opcodes and io-mode over DT a bit of logic is required to figure out what is used to configure the lines mspi-io-mode or opcode (that complicates the matter for the end-user). While this approach reduces code duplication across Q/O/X/SPI drivers it would come at the cost of some performance (but perf. hit applies to all approaches).

[decsny]

compatible should not be named after subsystems, why not something like jedec,mx25

[FRASTM]

changing to jedec,mx25 is fine for me. Then using the DT_HAS_JEDEC_MX25_ENABLED

Should then, the CONFIG_FLASH_MSPI_NOR_MX also be named CONFIG_FLASH_MSPI_JEDEC_MX25 or so ?

[decsny]

the kconfig name doesn't matter to me

[swift-tk]

My suggestion is

Suggested change

	compatible: "mspi-nor-mx25"
	compatible: "jedec,mspi-nor-mx25"

[FRASTM]

let's go for "jedec,mspi-nor-mx25"

[FRASTM]

Perhaps I am missing something. But what advantages does MSPI offer over the existing Q/O/X/SPI drivers, particularly for STM32 NOR-Flash support?

@GeorgeCGV, if you asking the question to me, I am not in a position to answer

[swift-tk]

@GeorgeCGV

However, it looks like a step backward from existing O/Q/X/SPI drivers. The SFDP autoconfiguration capabilities are dropped, and dependencies between lines and opcodes are not considered. The command configuration happens on the lowest level outside the device MSPI driver. That will lead to a bloated low-level driver, increasing footprint, and potentially degrading performance.

The SFDP autoconfiguration can definitely be handled within the device (flash) driver layer. Since opcodes and line dependencies are specific to the device or JEDEC standard, they should be managed by the device (flash) driver. While there are methods to optimize overhead and reduce footprint, I don't have sufficient knowledge of STM Q/O/X SPI hardware to offer specific recommendations. Ultimately, the implementation of the controller driver is entirely your decision.

To address some of these issues, device-specific drivers must have greater control over low-level aspects (e.g., data lines, opcodes, etc.). However, this could lead to code duplication across drivers for MX, Winbond, and other NOR-Flash devices. A potential solution might be a generic MSPI-NOR-Flash driver that works in conjunction with a specific low-level Q/O/X/SPI MSPI driver. For example, the Q/O/X/SPI MSPI driver must use the mspi-io-mode when it performs mspi_stm32_prepare_cmd. However, as MSPI allows users to provide write/read opcodes and io-mode over DT a bit of logic is required to figure out what is used to configure the lines mspi-io-mode or opcode (that complicates the matter for the end-user). While this approach reduces code duplication across Q/O/X/SPI drivers it would come at the cost of some performance (but perf. hit applies to all approaches).

I attempted to develop an MSPI NOR flash driver, but I found the JEDEC specification to be rather chaotic and cumbersome when trying to consolidate everything into a single driver. I don't recently have time to continue this endeavor and I'd be happy to see a better implementation.

The opcode and IO mode specified in the device tree are part of the target device's configuration after initialization, reflecting the most common operational state of the device. I think surely the device lines and write and read opcode would not change frequently if the user are aiming for performance.

To make it more friendly to the end user, we can save a set of default for the target operating condition in each device bindings.

An important optimization for all controllers would be to skip reconfiguring settings in struct mspi_xfer and struct mspi_packet when they match the target device settings defined in the device tree. I did it through our hardware command queue, maybe you could try software queue like RTIO or the zephyr work queue.

[github-actions]

This pull request 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 pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

[github-actions]

This pull request 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 pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.