MT29F4G08 NAND Flash Driver by LinderPi · Pull Request #100683 · zephyrproject-rtos/zephyr

LinderPi · 2025-12-08T15:14:21Z

Introduces a NAND flash driver for Micron's MT29F4G08 memory device that is configurable via devicetree. A generic flash controller driver communicates to the flexible memory controller of STM32 MCUs. Any other NAND flash driver can be implemented to work via FMC in the future. The chip-specific driver provides the flash API for upper layers and enables the on-die ECC feature.

The flash controller is strongly inspired by the STM32 HAL NAND driver following the ONFI specification. However, it optionally uses DMA to transfer a read page. In future, an additional function can be implemented for entire page reads. At the moment this is not required by upper layers and the direct memory transfer is somehow slower to a yet unknown problem.

As it is the first NAND flash driver in Zephyr, some API extensions are foreseen for bad block management by a flash translation layer (FTL). As proposed in #99908, we are currently working on a NFTL disk driver module based on Dhara. A first version is implemented and available here for testing.

As an optional enhancement, a bad block map could be kept in memory such that the driver does not need to ask the memory device for bad blocks on every request.

etienne-lms

Minor comments only.

erwango · 2025-12-12T16:23:09Z

+	(void)FMC_NAND_CommonSpace_Timing_Init(dev_data->instance, &timing,
+					       dev_data->init.NandBank);
+	(void)FMC_NAND_AttributeSpace_Timing_Init(dev_data->instance, &timing,
+						  dev_data->init.NandBank);


In theory, we're not supposed to call directly these apis, which are not meant to be public, but API internal to the HAL driver. As such there is no guarantee on these APIs (portability, stability, ..).
Can you detail why you chose not to call HAL_NAND_Init() directly ?

The STM32 HAL NAND driver does not provide the entire functionality we need (DMA support, status read, etc.). Additionally, there is no intend to further develop it. This is the reasoning I got from ST's official support: "The NAND is not so popular since the xSPI memories we see the FMC usage less and less."

The STM32 HAL NAND driver does not provide the entire functionality we need (DMA support, status read, etc.).

Ok, that's clear. However, I need to check internally if FMC_NAND_() usage is safe.

etienne-lms · 2025-12-16T15:33:00Z

+		*(int *)out =
+			((ret == 0) && (spare_area[0] != 0xFF)) ? NAND_BLOCK_BAD : NAND_BLOCK_GOOD;
+		break;
+	}


I don't think these braces (in both case sequences) are useful. There indentation could be confusing. Could you remove them?

The advantage is to define operation specific variables in the block. Also, the indentation remains the same.

etienne-lms · 2025-12-16T15:38:19Z

+		struct nand_flash_address address;
+		uint8_t spare_area[config->spare_area_size];
+
+		if (block * config->block_size >= config->flash_size) {


Suggested change

if (block * config->block_size >= config->flash_size) {

off_t offset;

if (u32_mul_overflow(block, config->block_size, &offset) || (offset >= config->flash_size)) {

and below:

- address = flash_mt29f4g08_calculate_address(config, block * config->block_size); + address = flash_mt29f4g08_calculate_address(config, offset);

Nice point. Thanks :)

etienne-lms · 2025-12-16T15:49:59Z

+		/* Get page data into buffer */
+		for (size_t index = 0; index < dev_data->page_size; index++) {
+			config->page_buffer[index] = sys_read8(NAND_DEVICE);
+		}


Using config->page_buffer allocated in cache memory is useful when using DMAs, but here, maybe worth the straight load data read into the likely cached data buffer.
If using this scheme, you could avoid flash_stm32_fmc_nand_page_buffer_XXX[] allocations.

What could work is something like:

/* Read chunk of page data directly into output buffer */ for (size_t index = 0; index < dev_data->page_size; index++) { if (index >= page_offset && index < (page_offset + chunk)) { *data = sys_read8(NAND_DEVICE); data++; } else { (void)sys_read8(NAND_DEVICE); } }

In our case, this speeds up reading a page from 3.6 MiBps to 4.5 MiBps. Is this what you have imagined?

LinderPi · 2025-12-18T08:50:20Z

I also implemented the suggestions from #100858 (comment) moving the extended operations to the generic definition. The filename did no more make sense why it is now called nand_flash.h for NAND flash specific data structures and maybe functions in future.

Some API extensions are foreseen for bad block management by a flash translation layer (FTL). Signed-off-by: Pascal Linder <pascal.linder@zuehlke.com>

Introduces a NAND flash driver for Micron's MT29F4G08 memory device that is configurable via devicetree. A generic flash controller driver communicates to the flexible memory controller of STM32 MCUs. Any other NAND flash driver can be implemented to work via FMC in the future. The chip-specific driver provides the flash API for upper layers and enables the on-die ECC feature. As it is the first NAND flash driver in Zephyr, some API extensions are foreseen for bad block management by a flash translation layer (FTL). Signed-off-by: Pascal Linder <pascal.linder@zuehlke.com> Signed-off-by: Tim Pambor <tim.pambor@codewrights.de>

Renames overlays to be board-specific and adds a build test for the newly introduced NAND flash driver for MT29F4G08 via STM32 FMC. Signed-off-by: Pascal Linder <pascal.linder@zuehlke.com>

JarmouniA · 2026-01-14T18:02:52Z

+# SPDX-License-Identifier: Apache-2.0
+
+description: |
+  NAND flash driver for Micron MT29F4G08 flash memory.


Suggested change

NAND flash driver for Micron MT29F4G08 flash memory.

Micron MT29F4G08 NAND flash memory.

JarmouniA · 2026-01-14T18:03:29Z

+
+compatible: "micron,mt29f4g08"
+
+properties:


Please add a description to all the properties.

sonarqubecloud · 2026-01-14T18:26:18Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud

ttmut · 2026-01-16T10:56:00Z

+			flash_mt29f4g08_calculate_address(config, offset);
+
+		ret = flash_stm32_fmc_nand_read_page_chunk(controller, &address, page_offset, chunk,
+							   (uint8_t *)data);


Sorry if this was asked before but should not this driver be controller-independent instead? It seems every vendor will have to maintain their own variant of flash_vendor_mt29f4g08.c.

First, the split between flash_stm32_fmc_nand.c and flash_stm32_fmc_mt29f4g08.c is due to the MT29F4G08 driver making use of on‑die ECC, meaning error detection and correction are handled inside the NAND device itself. This is a vendor‑specific feature. As a result, supporting on‑die ECC reliably requires a NAND flash vendor‑specific flash driver rather than a fully generic one.

It would indeed be possible to add a controller‑specific but flash chip vendor‑agnostic driver such as a hypothetical flash_stm32_fmc_onfi.c. Such a driver could work with ONFI‑compliant NAND devices across different vendors. However, to stay generic, it would need to rely on host ECC (calculated in the MCU) or software ECC, and therefore could not take advantage of on‑die ECC features provided by some flashes.

The reason these drivers are NAND controller‑dependent is timing. Parallel NAND flashes have fairly strict and sometimes subtle timing requirements (setup/hold times, access times, etc.), and each controller exposes its own mechanism and parameters for generating those timings. In practice, it is very difficult to define a standardized, controller‑independent interface that maps cleanly onto the timing configuration model of every NAND controller. For the same reason, we also have vendor‑specific bindings for e.g. SDRAM, where the timing parameters are inherently tied to the memory controller’s register layout and capabilities. See, e.g.:

zephyr/dts/bindings/memory-controllers/st,stm32-fmc-sdram.yaml

Lines 142 to 166 in 32823f3

st,sdram-timing:

type: array

required: true

description: |

SDRAM timing configuration. Expected fields, in order, are,

- TMRD: Delay between a Load Mode Register command and an Active or

Refresh command in number of memory clock cycles.

- TXSR: Delay from releasing the Self-refresh command to issuing the

Activate command in number of memory clock cycles. If two SDRAM

devices are used, the FMC_SDTR1 and FMC_SDTR2 must be programmed with

the same TXSR timing corresponding to the slowest SDRAM device

- TRAS: Minimum Self-refresh period in number of memory clock cycles.

- TRC: Delay between the Refresh command and the Activate command, as

well as the delay between two consecutive Refresh commands. It is

expressed in number of memory clock cycles. If two SDRAM devices are

used, the TRC must be programmed with the timings of the slowest

device in both banks.

- TWP: Delay between a Write and a Precharge command in number of memory

clock cycles

- TRP: Delay between a Precharge command and another command in number

of memory clock cycles. If two SDRAM devices are used, the TRP must be

programmed with the timing of the slowest device in both banks.

- TRCD: Delay between the Activate command and a Read/Write command in

number of memory clock cycles.

First, the split between flash_stm32_fmc_nand.c and flash_stm32_fmc_mt29f4g08.c is due to the MT29F4G08 driver making use of on‑die ECC, meaning error detection and correction are handled inside the NAND device itself. This is a vendor‑specific feature. As a result, supporting on‑die ECC reliably requires a NAND flash vendor‑specific flash driver rather than a fully generic one.

It would indeed be possible to add a controller‑specific but flash chip vendor‑agnostic driver such as a hypothetical flash_stm32_fmc_onfi.c. Such a driver could work with ONFI‑compliant NAND devices across different vendors. However, to stay generic, it would need to rely on host ECC (calculated in the MCU) or software ECC, and therefore could not take advantage of on‑die ECC features provided by some flashes.

The reason these drivers are NAND controller‑dependent is timing. Parallel NAND flashes have fairly strict and sometimes subtle timing requirements (setup/hold times, access times, etc.), and each controller exposes its own mechanism and parameters for generating those timings. In practice, it is very difficult to define a standardized, controller‑independent interface that maps cleanly onto the timing configuration model of every NAND controller. For the same reason, we also have vendor‑specific bindings for e.g. SDRAM, where the timing parameters are inherently tied to the memory controller’s register layout and capabilities. See, e.g.:

zephyr/dts/bindings/memory-controllers/st,stm32-fmc-sdram.yaml

Lines 142 to 166 in 32823f3

st,sdram-timing:

type: array

required: true

description: |

SDRAM timing configuration. Expected fields, in order, are,

- TMRD: Delay between a Load Mode Register command and an Active or

Refresh command in number of memory clock cycles.

- TXSR: Delay from releasing the Self-refresh command to issuing the

Activate command in number of memory clock cycles. If two SDRAM

devices are used, the FMC_SDTR1 and FMC_SDTR2 must be programmed with

the same TXSR timing corresponding to the slowest SDRAM device

- TRAS: Minimum Self-refresh period in number of memory clock cycles.

- TRC: Delay between the Refresh command and the Activate command, as

well as the delay between two consecutive Refresh commands. It is

expressed in number of memory clock cycles. If two SDRAM devices are

used, the TRC must be programmed with the timings of the slowest

device in both banks.

- TWP: Delay between a Write and a Precharge command in number of memory

clock cycles

- TRP: Delay between a Precharge command and another command in number

of memory clock cycles. If two SDRAM devices are used, the TRP must be

programmed with the timing of the slowest device in both banks.

- TRCD: Delay between the Activate command and a Read/Write command in

number of memory clock cycles.

I did not actually mean that there should be single driver that covers all NAND chips. I was asking if it is possible to move the calls to STM32 FMC inside flash_stm32_fmc_mt29f4g08.c behind some common API so that it becomes vendor-agnostic, such as flash_mt29f4g08.c. Otherwise, we are going to end up with flash_vendorA_mt29f4g08.c, flash_vendorB_mt29f4g08.c whenever someone decides to add support for their controller.

I did not actually mean that there should be single driver that covers all NAND chips. I was asking if it is possible to move the calls to STM32 FMC inside flash_stm32_fmc_mt29f4g08.c behind some common API so that it becomes vendor-agnostic, such as flash_mt29f4g08.c. Otherwise, we are going to end up with flash_vendorA_mt29f4g08.c, flash_vendorB_mt29f4g08.c whenever someone decides to add support for their controller.

Yes, I wanted to make clear both decisions, why it is flash-chip dependent and why it is flash-controller dependent as others might have the same question. The second part was about the flash-controller dependency.

The reason these drivers are NAND controller‑dependent is timing. Parallel NAND flashes have fairly strict and sometimes subtle timing requirements (setup/hold times, access times, etc.), and each controller exposes its own mechanism and parameters for generating those timings. In practice, it is very difficult to define a standardized, controller‑independent interface that maps cleanly onto the timing configuration model of every NAND controller. For the same reason, we also have vendor‑specific bindings for e.g. SDRAM, where the timing parameters are inherently tied to the memory controller’s register layout and capabilities. See, e.g.:

zephyr/dts/bindings/memory-controllers/st,stm32-fmc-sdram.yaml

Lines 142 to 166 in 32823f3

st,sdram-timing:

type: array

required: true

description: |

SDRAM timing configuration. Expected fields, in order, are,

- TMRD: Delay between a Load Mode Register command and an Active or

Refresh command in number of memory clock cycles.

- TXSR: Delay from releasing the Self-refresh command to issuing the

Activate command in number of memory clock cycles. If two SDRAM

devices are used, the FMC_SDTR1 and FMC_SDTR2 must be programmed with

the same TXSR timing corresponding to the slowest SDRAM device

- TRAS: Minimum Self-refresh period in number of memory clock cycles.

- TRC: Delay between the Refresh command and the Activate command, as

well as the delay between two consecutive Refresh commands. It is

expressed in number of memory clock cycles. If two SDRAM devices are

used, the TRC must be programmed with the timings of the slowest

device in both banks.

- TWP: Delay between a Write and a Precharge command in number of memory

clock cycles

- TRP: Delay between a Precharge command and another command in number

of memory clock cycles. If two SDRAM devices are used, the TRP must be

programmed with the timing of the slowest device in both banks.

- TRCD: Delay between the Activate command and a Read/Write command in

number of memory clock cycles.

SuperHeroAbner · 2026-01-22T05:48:29Z

+
+	/* Feature data. */
+	uint8_t feature_data[4];
+};


Is this header common for both serial/parallel nand? This feature structure looks for parallel nand with ONFI definition.

hakehuang · 2026-02-09T13:59:13Z

Thanks for this NTFL driver and do we have any real board testing available for this? and what testing scope shall we defined?

de-nordic · 2026-03-23T17:20:45Z

+	const struct flash_mt29f4g08_config *config = dev->config;
+	const struct device *controller = config->controller;
+	int ret;
+


Chrck 'len==0' first, if call is not going to do any work do not fail it on other checks.

de-nordic · 2026-03-23T17:21:26Z

+	const struct flash_mt29f4g08_config *config = dev->config;
+	const struct device *controller = config->controller;
+	int ret;
+


Check size against 0 first, it is pointless to fail call when monwork is going to happen.

de-nordic · 2026-03-23T17:24:05Z

+  reg:
+    type: int
+    required: true
+
+  page-size:
+    type: int
+    required: true
+
+  spare-area-size:
+    type: int
+    required: true
+
+  block-size:
+    type: int
+    required: true
+
+  plane-size:
+    type: int
+    required: true
+
+  flash-size:
+    type: int
+    required: true
+
+  setup-time:
+    type: int
+    default: 0
+
+  wait-setup-time:
+    type: int
+    default: 0
+
+  hold-setup-time:
+    type: int
+    default: 0
+
+  hiz-setup-time:
+    type: int
+    default: 0


Missing descriptions, units are not explained.

de-nordic · 2026-03-23T17:25:59Z

+
+	/**
+	 * Checks whether a block is marked as bad. As input it takes the address of the block
+	 * (off_t *). As output it returns @ref flash_block_status (enum flash_block_status *).
+	 */
+	FLASH_IS_BAD_BLOCK,
+
+	/**
+	 * Marks a block as bad. As input it takes the address of the block (off_t *). There is no
+	 * output.
+	 */
+	FLASH_MARK_BAD_BLOCK,


Please explicitly number these. It is easier to debug when i do not have to count enums, and future depreciation, if happens, would be easier.

de-nordic · 2026-03-23T17:28:17Z

+	const struct flash_mt29f4g08_config *config = dev->config;
+	const struct device *controller = config->controller;
+	int ret;
+


Check len first, and return 0 if no work is going to happen.

tpambor · 2026-04-20T08:08:04Z

Currently, no capacity to work on this.

zephyrbot added area: Tests Issues related to a particular existing or missing test area: Devicetree Bindings platform: STM32 ST Micro STM32 area: Flash area: MEMC area: Boards/SoCs labels Dec 8, 2025

zephyrbot requested review from FRASTM, GeorgeCGV, de-nordic, djiatsaf-st, erwango, etienne-lms, gautierg-st, juickar, mathieuchopstm, nashif and rghaddab December 8, 2025 15:16

zephyrbot assigned de-nordic Dec 8, 2025

etienne-lms reviewed Dec 9, 2025

View reviewed changes

LinderPi force-pushed the mt29f4g08_driver branch 2 times, most recently from a5ce021 to 7514a70 Compare December 10, 2025 16:11

LinderPi requested a review from etienne-lms December 11, 2025 07:32

LinderPi force-pushed the mt29f4g08_driver branch from 7514a70 to 3aeb26d Compare December 12, 2025 08:03

erwango reviewed Dec 12, 2025

View reviewed changes

erwango reviewed Dec 15, 2025

View reviewed changes

Comment thread drivers/flash/flash_stm32_fmc_nand.c Outdated

etienne-lms reviewed Dec 16, 2025

View reviewed changes

LinderPi force-pushed the mt29f4g08_driver branch from 3aeb26d to 90bf138 Compare December 18, 2025 08:46

LinderPi force-pushed the mt29f4g08_driver branch from 90bf138 to 3076c54 Compare December 23, 2025 08:36

LinderPi requested a review from etienne-lms December 23, 2025 09:18

LinderPi requested a review from erwango December 23, 2025 09:18

tpambor mentioned this pull request Jan 14, 2026

NAND Flash Support (NFTL Disk Driver) #99908

Closed

LinderPi added 3 commits January 14, 2026 18:36

drivers: flash: Add NAND flash API extensions

63770ae

Some API extensions are foreseen for bad block management by a flash translation layer (FTL). Signed-off-by: Pascal Linder <pascal.linder@zuehlke.com>

tests: drivers: build_all: flash: Add build test for MT29F4G08

a47feb5

Renames overlays to be board-specific and adds a build test for the newly introduced NAND flash driver for MT29F4G08 via STM32 FMC. Signed-off-by: Pascal Linder <pascal.linder@zuehlke.com>

tpambor force-pushed the mt29f4g08_driver branch from 3076c54 to a47feb5 Compare January 14, 2026 17:40

zephyrbot added the area: Devicetree Binding PR modifies or adds a Device Tree binding label Jan 14, 2026

zephyrbot requested a review from JarmouniA January 14, 2026 17:41

JarmouniA requested changes Jan 14, 2026

View reviewed changes

ttmut reviewed Jan 16, 2026

View reviewed changes

SuperHeroAbner reviewed Jan 22, 2026

View reviewed changes

carlescufi requested a review from anangl February 5, 2026 12:26

carlescufi mentioned this pull request Feb 5, 2026

flash: spi_nand: initial generic driver #100845

Merged

tpambor mentioned this pull request Mar 11, 2026

NFTL Disk Driver #100858

Merged

de-nordic requested changes Mar 23, 2026

View reviewed changes

tpambor added this to the v4.5.0 milestone Mar 23, 2026

tpambor closed this Apr 20, 2026

-		if (block * config->block_size >= config->flash_size) {
+		off_t offset;
+		if (u32_mul_overflow(block, config->block_size, &offset) || (offset >= config->flash_size)) {

	NAND flash driver for Micron MT29F4G08 flash memory.
	Micron MT29F4G08 NAND flash memory.

	st,sdram-timing:
	type: array
	required: true
	description: \|
	SDRAM timing configuration. Expected fields, in order, are,

	- TMRD: Delay between a Load Mode Register command and an Active or
	Refresh command in number of memory clock cycles.
	- TXSR: Delay from releasing the Self-refresh command to issuing the
	Activate command in number of memory clock cycles. If two SDRAM
	devices are used, the FMC_SDTR1 and FMC_SDTR2 must be programmed with
	the same TXSR timing corresponding to the slowest SDRAM device
	- TRAS: Minimum Self-refresh period in number of memory clock cycles.
	- TRC: Delay between the Refresh command and the Activate command, as
	well as the delay between two consecutive Refresh commands. It is
	expressed in number of memory clock cycles. If two SDRAM devices are
	used, the TRC must be programmed with the timings of the slowest
	device in both banks.
	- TWP: Delay between a Write and a Precharge command in number of memory
	clock cycles
	- TRP: Delay between a Precharge command and another command in number
	of memory clock cycles. If two SDRAM devices are used, the TRP must be
	programmed with the timing of the slowest device in both banks.
	- TRCD: Delay between the Activate command and a Read/Write command in
	number of memory clock cycles.


		compatible: "micron,mt29f4g08"

		properties:

Conversation

LinderPi commented Dec 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

etienne-lms left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

LinderPi commented Dec 18, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sonarqubecloud Bot commented Jan 14, 2026

Quality Gate passed

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hakehuang commented Feb 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tpambor commented Apr 20, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

LinderPi commented Dec 8, 2025 •

edited

Loading

hakehuang commented Feb 9, 2026 •

edited

Loading