External flash driver for the MX25Rxx

[GiulianoFranchetto]

Hi,

The Nordic nRF52840 PDK has an external flash built-in, connected to the nRF52840 by QSPI.

The driver is available using the nordic SDK, but it's not in Zephyr yet.

Has anybody already ported this driver on Zephyr, or @carlescufi does the Nordic team plan to do so?

We do not need a XIP-enabled driver, we just want to read-write on the flash.

Regards

[GiulianoFranchetto]

Hi,

any update on this issue?

[carlescufi]

Copying @kl-cruz who has more details on this flash.

[kl-cruz]

Hi,
For now there is no code to support this feature in Zephyr. We would like to support all the peripherals in Zephyr, but for now QSPI has lower priority. I'll try to escalate it.

In the simpliest way it looks like we will require to implement shim for flash API (https://github.com/zephyrproject-rtos/zephyr/blob/master/include/flash.h). API seems to fit ideally to the nrfx driver. Protocol configuration (I mean one/two/four data lines) should be placed in device tree. We should consider to place protocol configuration (op codes) in Kconfig. They are (in many cases, for example switch to quad-mode) chip-dependent.
In future work we could consider to base our solution at for example kernel's driver: https://github.com/torvalds/linux/blob/master/include/linux/mtd/spi-nor.h

XIP function in nRF SoCs require only to configure QSPI peripheral and then access to flash is possible at addresses started from 0x12000000 to 0x19FFFFFF. So... it should work as a side effect

[GiulianoFranchetto]

Hi,

The QSPI part is not really what we want for now, as we don't have code in the external flash.

Did Nordic developped a driver for the MX25Rxx when creating the nrf52 PDK?

Could it be easily ported using the Zephyr API?

Regards

[kl-cruz]

Hi,
I think QSPI could fit to your requirements. You do not have to use XiP. Just initialize QSPI and read/write/erase data from external memory. There is example application in Nordic's SDK (for example 15.2.0) based on QSPI. I think it is good starting point to write shim layer.
In my opinion using QSPI to drive MX25xxx memories is easier than preparing SPI driver

[nvlsianpu]

@kl-cruz is this somehow related? #7561

[kl-cruz]

@nvlsianpu yes, it is. #7561 contains code to read sfdp data to configure transmission protocol correctly and code to drive external memory. It should work with nRFs, but to speed up operations I recommend to read sfdp data using SPI and switch to QSPI in flash API.

[findlayfeng]

@kl-cruz
Reading sfdp using QSPI first is defined in the sfdp documentation.
And this attempt is only done during initialization, and the result can be returned immediately without waiting. It has little effect on the initialization time.
And for devices that only support spi to read sfdp, this is a more expensive attempt, but it will be faster for devices that support qspi to read sfdp.

[nvlsianpu]

QSPI based driver Introduced as Nordic QSPI nor driver (usage examples tests/subsys/fs/littlefs on nrf52840_pca10056).
#21535

Also possible to use spi nor driver.