drivers: flash_mspi_nor: Apply a few improvements #93093

anangl · 2025-07-14T11:53:37Z

Apply a few improvements in the flash_mspi_nor driver, most notably:

use parameters from SFDP for all the used flash commands with possibility to override those through dts (with the read-command, write-command, and rx-dummy properties)
use all available erase types as specified by SFDP
allow using all IO modes
add support for switching to 4-byte addressing mode
complete handling of Quad Enable Requirements and add handling of Octal Enable Requirements
add Soft Reset.

See the individual commit messages for details.

danieldegrasse

I'm not specifically opposed to using SFDP for this driver, but I honestly doubt we are going to get the best performance out of most flash devices with this method. My primary concern is that not all flash devices actually implement SFDP discoverability, particularly for octal or quad settings (as least as far as I've seen)

Do you have any thoughts on the approach I took in #88920? I think these methods can coexist if they need to, but I personally feel like we may just be better off using compatibles for flash settings at build time, and JEDEC ID to select flash settings at runtime.

swift-tk

This reminds me of the attempt I took adding mspi_nor... The global storage needed by SFDP would explode flash_data as we continue to add more DWORDS.
Therefore, IMO, it would better the SFDP can have its own data struct and separate .c file and then we could have it enabled through Kconfig.

swift-tk · 2025-07-16T10:04:43Z

I'm not specifically opposed to using SFDP for this driver, but I honestly doubt we are going to get the best performance out of most flash devices with this method. My primary concern is that not all flash devices actually implement SFDP discoverability, particularly for octal or quad settings (as least as far as I've seen)

Do you have any thoughts on the approach I took in #88920? I think these methods can coexist if they need to, but I personally feel like we may just be better off using compatibles for flash settings at build time, and JEDEC ID to select flash settings at runtime.

The SFDP should be used for generic flash that does support it and enable through a Kconfig and dts property. With SFDP, it should load cmd and other properties through DWORDS instead of using the generic or the vendor table. It is essentially a different way of runtime probing, so I think it could coexist well provided that it doesn't get in and mess up the core all over the place.

anangl · 2025-07-24T15:50:26Z

Rebased.

anangl · 2025-07-25T11:10:41Z

@danieldegrasse @swift-tk I moved almost all processing of SFDP to a separate file (FLASH_SIZE() and FLASH_PAGE_EXP() macros are the only exceptions). SFDP processing is done only at build time, using data from dts arrays. Obtained information can be overridden through dts with the read-command, write-command, and rx-dummy properties. All the read parameters are stored in RAM, so they can be overridden or completely replaced with data provided by some other mechanism, like the one from #88920.

anangl · 2025-07-25T16:07:58Z

Rebased on #93724, added support for supply-gpios.

swift-tk

Thanks @anangl, while I appreciate the effort, there are a number of places that looks sketchy or I'm just confused by.
Additionally, could we first merge #88920 and then work on this one?

drivers/flash/flash_mspi_nor.c

anangl · 2025-07-30T15:07:51Z

Rebased.

swift-tk · 2025-09-10T05:37:04Z

drivers/flash/flash_mspi_nor_sfdp.h

+
+#define DEFAULT_SWITCH_INFO(inst) { \
+	.quad_enable_req = DT_INST_ENUM_IDX(inst, quad_enable_requirements), \
+	.octal_enable_req = OCTAL_ENABLE_REQ_NONE, \


I think both should be added, otherwise it is SFDP only and should be wrapped with CONFIG_FLASH_MSPI_NOR_USE_SFDP or JESD216 kconfig.

drivers/flash/Kconfig.mspi

dts/bindings/mtd/jedec,mspi-nor.yaml

Get parameters for used flash commands and requirements for enabling Quad and Octal modes from dts uint8-arrays containing data read from SFDP tables for particular flash chips. Also introduce `pre_init` quirk that allows alteration of the above parameters or complementation of them in a specific way for particular flash chip families. Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>

- Use standard operation codes and parameters from SFDP for handling the used flash commands (allow to override some of them through dts with the `read-command`, `write-command`, and `rx-dummy` properties) - Use all available erase types as specified by SFDP - Allow using all IO modes - Add support for switching to 4-byte addressing mode - Use common functions for reading and writing of status registers and for enabling write operations - Switch IO mode (between the target one and Single IO) in a common function that performs transfers and do it only when required for a given command - Make checking of JEDEC ID at initialization optional Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>

Complete implementation of quad_enable_set() by adding support for all possible Quad Enable Requirements (QER) as specified by the SFDP JEDEC standard (JESD216). Add also corresponding octal_enable_set() to handle Octal Enable Requirements. Also remove initial waiting from mxicy_mx25r_post_switch_mode() which became unneeded, as now such waiting is done in cmd_wrsr() which is called at the end of quad_enable_set(). Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>

Add implementation of the most common Soft Reset routine (sequence of reset enable instruction 0x66 and reset instruction 0x99). Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>

Using a GPIO reset for a flash chip that has a dual function pin (RESET# or SIO3) and is to be used in Quad mode is rather a bad idea and so is clearing of the Quad Enable bit at every initialization of the flash driver, since this bit is usually non-volatile, so such operation means unnecessary wearing of the flash chip. Soft Reset should be use instead in such case. Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>

Add support for supplying power to the flash chip by activation of a GPIO specified through the "supply-gpios" property. Implementation of gpio_reset() is also slightly modified so that it is consistent with soft_reset() and the new power_supply() and so that all these functions can use a common routine that performs a reset recovery delay. Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>

When Octal IO mode is to be used with DDR in mx25u family chips, bit 1 instead of 0 must be set in the Configuration Register 2 at address 0. Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>

It is no longer needed to specify the read command parameters in dts, as the flash driver is capable of obtaining those from SFDP structures, so the redundant properties are removed. After commit 612fd94 got merged, both the EXMIF and flash nodes in dts are not enabled by default so this needs to be done in the overlay. Although nrfutil is still not capable of programming the external flash on nRF54H20 DK, thus `west flash` will not work in this case, `nrf54h20dk/nrf54h20/cpuapp` is added as an allowed platform so that the sample is at least built in CI for it. Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>

sonarqubecloud · 2025-09-10T08:35:54Z

Quality Gate passed

Issues
4 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

ExaltZephyr · 2025-09-10T11:49:21Z

@anangl Hi
Were you able to run your flash in MSPI_IO_OCTAL_MODE without any issues when using the status command ?

Also, I noticed that you added cmd_extension only for Octal DTR mode.
However, we also need it for Octal SDR since its opcodes are 2 bytes. Am I missing something here?

anangl · 2025-09-10T12:24:35Z

@ExaltZephyr

@anangl Hi Were you able to run your flash in MSPI_IO_OCTAL_MODE without any issues when using the status command ?

Yes, the following samples/tests work fine for the nrf54h20dk/nrf54h20/cpuapp target, which uses a mx25uw6345g flash in MSPI_IO_MODE_OCTAL:

Also samples/drivers/mspi/mspi_flash works fine for that target if I add there a related overlay from one of the above complemented with required alias: flash0 = &mx25uw63;.

Also, I noticed that you added cmd_extension only for Octal DTR mode. However, we also need it for Octal SDR since its opcodes are 2 bytes.

For that flash mentioned above, it is also required to use commands with extension in SDR mode. Thus, the cmd_info structure is altered in pre_init quirk for it. It looks like you need the same for the flash you use. Is it also a Macronix one?

anangl requested a review from masz-nordic July 14, 2025 11:53

github-actions bot added area: Flash platform: nRF Nordic nRFx area: MSPI labels Jul 14, 2025

github-actions bot requested review from de-nordic, jaz1-nordic, kl-cruz, magp-nordic, nika-nordic, rghaddab and swift-tk July 14, 2025 11:54

github-actions bot assigned de-nordic Jul 14, 2025

swift-tk requested a review from danieldegrasse July 14, 2025 13:40

danieldegrasse reviewed Jul 14, 2025

View reviewed changes

swift-tk reviewed Jul 16, 2025

View reviewed changes

anangl force-pushed the improve_flash_mspi_nor branch from 64f66e8 to 4704353 Compare July 24, 2025 15:50

anangl force-pushed the improve_flash_mspi_nor branch 2 times, most recently from fe6dcee to 548d3b3 Compare July 25, 2025 10:29

carlescufi requested review from danieldegrasse and swift-tk July 25, 2025 14:19

anangl force-pushed the improve_flash_mspi_nor branch from 548d3b3 to 57a8256 Compare July 25, 2025 16:07

anangl force-pushed the improve_flash_mspi_nor branch from 57a8256 to 99a49ae Compare July 25, 2025 16:10

anangl mentioned this pull request Jul 28, 2025

[nrf fromlist] drivers: flash_mspi_nor: Apply a few improvements nrfconnect/sdk-zephyr#3091

Merged

swift-tk reviewed Jul 28, 2025

View reviewed changes

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

drivers/flash/flash_mspi_nor.c Show resolved Hide resolved

drivers/flash/flash_mspi_nor.c Show resolved Hide resolved

anangl force-pushed the improve_flash_mspi_nor branch from 99a49ae to e30312d Compare July 30, 2025 15:07

zephyrbot added area: Samples Samples area: Linker Scripts area: Build System labels Sep 9, 2025

zephyrbot requested review from jeremybettis, nashif, nordicjm and tejlmand September 9, 2025 07:31

anangl requested review from de-nordic and maass-hamburg September 9, 2025 07:47

anangl force-pushed the improve_flash_mspi_nor branch from 6af1921 to d531e90 Compare September 9, 2025 12:08

swift-tk reviewed Sep 10, 2025

View reviewed changes

maass-hamburg reviewed Sep 10, 2025

View reviewed changes

dts/bindings/mtd/jedec,mspi-nor.yaml Show resolved Hide resolved

anangl added 8 commits September 10, 2025 10:03

drivers: flash_mspi_nor: Add Soft Reset

3b0a4d2

Add implementation of the most common Soft Reset routine (sequence of reset enable instruction 0x66 and reset instruction 0x99). Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>

drivers: flash_mspi_nor: Add support for DDR in mx25u family

cae2043

When Octal IO mode is to be used with DDR in mx25u family chips, bit 1 instead of 0 must be set in the Configuration Register 2 at address 0. Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>

anangl force-pushed the improve_flash_mspi_nor branch from d531e90 to b293310 Compare September 10, 2025 08:12

anangl requested review from maass-hamburg and swift-tk September 10, 2025 08:23

de-nordic approved these changes Sep 10, 2025

View reviewed changes

maass-hamburg approved these changes Sep 10, 2025

View reviewed changes

kartben merged commit 10740d6 into zephyrproject-rtos:main Sep 10, 2025
35 checks passed

anangl deleted the improve_flash_mspi_nor branch September 10, 2025 11:02

drivers: flash_mspi_nor: Apply a few improvements #93093

drivers: flash_mspi_nor: Apply a few improvements #93093

Uh oh!

Conversation

anangl commented Jul 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

danieldegrasse left a comment

Choose a reason for hiding this comment

Uh oh!

swift-tk left a comment

Choose a reason for hiding this comment

Uh oh!

swift-tk commented Jul 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

anangl commented Jul 24, 2025

Uh oh!

anangl commented Jul 25, 2025

Uh oh!

anangl commented Jul 25, 2025

Uh oh!

swift-tk left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

anangl commented Jul 30, 2025

Uh oh!

swift-tk Sep 10, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

sonarqubecloud bot commented Sep 10, 2025

Quality Gate passed

Uh oh!

Uh oh!

ExaltZephyr commented Sep 10, 2025

Uh oh!

anangl commented Sep 10, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

11 participants

anangl commented Jul 14, 2025 •

edited

Loading

swift-tk commented Jul 16, 2025 •

edited

Loading