search

zephyrproject-rtos / zephyr

Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
https://docs.zephyrproject.org
Apache License 2.0
11.01k stars 6.7k forks source link

Suggestion on the framework of Flash driver #46399

Open rogeryou opened 2 years ago

rogeryou commented 2 years ago

As a Flash manufacturer, we hope to integrate various types of Flash drivers in Zephyr, such as SPI NOR Flash ,QSPI NOR Flash, Octal NOR Flash, SPI NAND Flash and ONFI NAND Flash.

We found that the framework of the existing Flash driver is shown in the following figure. 1

In the Flash folder there are various drivers, even for the same type of Flash, such as flash_stm32_qspi.c, nrf_qspi_nor.c. Each MCU manufacturer maintains a separate driver, which we think is inconvenient to maintain.

Therefore, we propose to modify the framework structure of the Flash driver. We divide the drivers of QSPI NOR Flash and OSPI NOR Flash into two layers, just like the drivers of SPI NOR Flash. The upper layer is a pure Flash driver. Each type of Flash has only one driver file. This layer has nothing to do with which MCU is used.

The lower layer is about the drivers of the Flash controllers of various MCU manufacturers. For example, the QSPI controller of ST corresponds to qspi_ll_stm32.c, the OSPI controller of ST corresponds to ospi_ll_stm32.c, and other manufacturers implement the corresponding ospi_xx. c. Each program in this layer needs to provide several APIs for the upper layer to call, such as ospi_read() and ospi_write() and so on.

We provide the following two solutions, as shown in the figure below: 2

We consider SPI NAND Flash and ONFI NAND Flash, and the expansion of the above picture is as follows: 3

We consider that there are already definitions for QSPI and OSPI modes in spi.h, and some drivers use these definitions, we provide solution 2: 4

At present, we have implemented the modification of the OSPI related program of solution 2, and passed the test on the STM32L562E-DK development board. A PR will be submitted later.

nvlsianpu commented 2 years ago

I'm looking forward for this rework. Probably the key factor for success will be proper API interface between vendors low layer driver part and higher generic flash driver part.

carlescufi commented 2 years ago

@rogeryou since the flash subsystem maintainer, @nvlsianpu, seems to have no objections to the proposal as it stands, will you send a Pull Request to start work on this?

rogeryou commented 2 years ago

@rogeryou since the flash subsystem maintainer, @nvlsianpu, seems to have no objections to the proposal as it stands, will you send a Pull Request to start work on this?

Hi，@carlescufi I have submitted the source code，please review.

manoj153 commented 2 years ago

Sorry for going off-topic. What application do you use to create the diagram? @rogeryou they look great!

rogeryou commented 2 years ago

Sorry for going off-topic. What application do you use to create the diagram? @rogeryou they look great!

draw.io

MaureenHelm commented 1 year ago

@rogeryou do you plan to return to this?

savvn001 commented 1 year ago

Any updates on this? Am interested also in using NAND flash with Zephyr

hongshui3000 commented 1 year ago

+1

mintisan commented 1 year ago

+1

clockis commented 1 year ago

+1

rogeryou commented 1 year ago

@MaureenHelm @carlescufi @nvlsianpu Hi, Because some developers are also interested in using NAND flash with Zephyr, we will submit a PR for NFTL. The PR is based on the SPI NAND driver #50690. Can we reopen that PR and discuss how to merge it?"

carlescufi commented 1 year ago

Because some developers are also interested in using NAND flash with Zephyr, we will submit a PR for NFTL. The PR is based on the SPI NAND driver #50690. Can we reopen that PR and discuss how to merge it?"

I see the PR is opened now, so let's continue the discussion in the PR.