mtd_nandbitserr and seed using pl35x NAND controller

mtd_nandbitserr and seed using pl35x NAND controller

[Andrea Scian]

Dear all,

I'm facing a weird behavior on mtd_nandbitserr mtd_test while working on a Zynk7k based platform, running kernel 6.6.0

As many of you suggest me, this test is part of our validation for the whole lowlevel support (NAND chip, hardware design, NAND controller).

I've found that this test, in my testbed, fails when using seed=1 but it seems to end successfully when using default parameters (so seed=0)

Here it is the test output in the two cases:

root@sw0005-devel:~# modprobe mtd_nandbiterrs seed=1

==================================================
mtd_nandbiterrs: MTD device: 0
mtd_nandbiterrs: MTD device size 1073741824, eraseblock=131072, page=2048, oob=64
mtd_nandbiterrs: Device uses 1 subpages of 2048 bytes
mtd_nandbiterrs: Using page=0, offset=0, eraseblock=0
mtd_nandbiterrs: incremental biterrors test
mtd_nandbiterrs: write_page
mtd_nandbiterrs: rewrite page
mtd_nandbiterrs: read_page
mtd_nandbiterrs: verify_page
mtd_nandbiterrs: Successfully corrected 0 bit errors per subpage
mtd_nandbiterrs: Inserted biterror @ 0/7
mtd_nandbiterrs: rewrite page
mtd_nandbiterrs: read_page
mtd_nandbiterrs: Read reported 1 corrected bit errors
mtd_nandbiterrs: verify_page
mtd_nandbiterrs: Successfully corrected 1 bit errors per subpage
mtd_nandbiterrs: Inserted biterror @ 0/5
mtd_nandbiterrs: rewrite page
mtd_nandbiterrs: read_page
mtd_nandbiterrs: Read reported 1 corrected bit errors
mtd_nandbiterrs: verify_page
mtd_nandbiterrs: Error: page offset 0, expected a5, got 05
mtd_nandbiterrs: ECC failure, read data is incorrect despite read success
modprobe: ERROR: could not insert 'mtd_nandbiterrs': Input/output error

root@sw0005-devel:~# modprobe mtd_nandbiterrs

==================================================
mtd_nandbiterrs: MTD device: 0
mtd_nandbiterrs: MTD device size 1073741824, eraseblock=131072, page=2048, oob=64
mtd_nandbiterrs: Device uses 1 subpages of 2048 bytes
mtd_nandbiterrs: Using page=0, offset=0, eraseblock=0
mtd_nandbiterrs: incremental biterrors test
mtd_nandbiterrs: write_page
mtd_nandbiterrs: rewrite page
mtd_nandbiterrs: read_page
mtd_nandbiterrs: verify_page
mtd_nandbiterrs: Successfully corrected 0 bit errors per subpage
mtd_nandbiterrs: Inserted biterror @ 0/5
mtd_nandbiterrs: rewrite page
mtd_nandbiterrs: read_page
mtd_nandbiterrs: Read reported 1 corrected bit errors
mtd_nandbiterrs: verify_page
mtd_nandbiterrs: Successfully corrected 1 bit errors per subpage
mtd_nandbiterrs: Inserted biterror @ 0/2
mtd_nandbiterrs: rewrite page
mtd_nandbiterrs: read_page
mtd_nandbiterrs: error: read failed at 0x0
mtd_nandbiterrs: After 2 biterrors per subpage, read reported error -74
mtd_nandbiterrs: finished successfully.
==================================================
modprobe: ERROR: could not insert 'mtd_nandbiterrs': Input/output error


After a bit of hacking (and looking at older kernel releases) I've seen that by re-enabling subpage writes all testcases end successfully
This is the patch that I've apply

From 1cb448ec34b39f0958db262c4a44e29ff9581b1e Mon Sep 17 00:00:00 2001
From: Andrea Scian <andrea.scian@dave.eu>
Date: Wed, 23 Jul 2025 11:25:55 +0200
Subject: [PATCH] mtd: nand: pl35x: enable subpage write

---
 drivers/mtd/nand/raw/pl35x-nand-controller.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/raw/pl35x-nand-controller.c b/drivers/mtd/nand/raw/pl35x-nand-controller.c
index c506e92a3e457..542ec853e9a69 100644
--- a/drivers/mtd/nand/raw/pl35x-nand-controller.c
+++ b/drivers/mtd/nand/raw/pl35x-nand-controller.c
@@ -1064,7 +1064,7 @@ static int pl35x_nand_chip_init(struct pl35x_nandc *nfc,
      plnand->cs = cs;
 
      chip = &plnand->chip;
-     chip->options = NAND_BUSWIDTH_AUTO | NAND_USES_DMA | NAND_NO_SUBPAGE_WRITE;
+     chip->options = NAND_BUSWIDTH_AUTO | NAND_USES_DMA;
      chip->bbt_options = NAND_BBT_USE_FLASH;
      chip->controller = &nfc->controller;
      mtd = nand_to_mtd(chip);

So here it comes the questions:

* is it correct that changing seed in mtd_nandbiterrs make such a difference? IIUC this is just a "random" seed so I'll expect to fail in both cases or none
* is it correct that subpage write has been disabled in pl35x NAND controller? AFAIK on older kernel subpages were enable but maybe I'm missing something. Unfortunately git history doesn't help in this

I didn't have the chance to try a newer kernel but, at least on these two files, I don't see any significant changes

Kind Regards and thanks in advance,

Andrea SCIAN

SW Development Manager






______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: mtd_nandbitserr and seed using pl35x NAND controller

[Miquel Raynal]

Hello Andrea,

On 25/11/2025 at 10:12:47 GMT, Andrea Scian <andrea.scian@dave.eu> wrote:

> Dear all,
>
> I'm facing a weird behavior on mtd_nandbitserr mtd_test while working on a Zynk7k based platform, running kernel 6.6.0
>
> As many of you suggest me, this test is part of our validation for the whole lowlevel support (NAND chip, hardware design, NAND controller).
>
> I've found that this test, in my testbed, fails when using seed=1 but it seems to end successfully when using default parameters (so seed=0)
>
> Here it is the test output in the two cases:
>
> root@sw0005-devel:~# modprobe mtd_nandbiterrs seed=1

...

> --- a/drivers/mtd/nand/raw/pl35x-nand-controller.c
> +++ b/drivers/mtd/nand/raw/pl35x-nand-controller.c
> @@ -1064,7 +1064,7 @@ static int pl35x_nand_chip_init(struct pl35x_nandc *nfc,
>       plnand->cs = cs;
>  
>       chip = &plnand->chip;
> -     chip->options = NAND_BUSWIDTH_AUTO | NAND_USES_DMA | NAND_NO_SUBPAGE_WRITE;
> +     chip->options = NAND_BUSWIDTH_AUTO | NAND_USES_DMA;

I no longer remember why this flag was set, tbh. If you enable subpage
writes, you should make sure that page and subpage tests really pass,
because it means I have not tested this possibility.

Nevertheless, I find this causal effect very unsatisfying. I do not
understand how this might be related to your issue.

Are you sure of the ECC configuration (can you show the DT snippet)?

Is the issue consistent?

> * is it correct that changing seed in mtd_nandbiterrs make such a
> difference? IIUC this is just a "random" seed so I'll expect to fail
> in both cases or none

Yes, exactly. I can't make sense out of this observation :-)

> * is it correct that subpage write has been disabled in pl35x NAND
> controller? AFAIK on older kernel subpages were enable but maybe I'm
> missing something. Unfortunately git history doesn't help in this

This flag has always been there, so what does that mean? Aren't you
talking about a Xilinx downstream kernel here?

> I didn't have the chance to try a newer kernel but, at least on these
> two files, I don't see any significant changes

Did you observe what seed=0/1 meant in practice? I clearly do not
understand the link it might have with subpages.

Can you try with the mtd-utils userspace tool instead? Kernel modules
are no longer actively maintained, so maybe there is a bug (?) inside.

Also, can you try manually flipping bits with nandflipbits and target
various area in the page (outside of the first subpage, unlike the
nandbiterrs test).

Thanks,
Miquèl

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: R: mtd_nandbitserr and seed using pl35x NAND controller

[Miquel Raynal]

Hi Andrea,

> root@sw0005-devel:~# nandflipbits /dev/mtd0 5@0
> root@sw0005-devel:~# nanddump -c -s 0 --length=100 /dev/mtd0  | head
> ECC failed: 0
> ECC corrected: 2
> Number of bad blocks: 0
> Number of bbt blocks: 4
> Block size 131072, page size 2048, OOB size 64
> Dumping data starting at 0x00000000 and ending at 0x00000064...
> ECC: 1 corrected bitflip(s) at offset 0x00000000
> 0x00000000: 65 42 49 23 01 00 00 00 00 00 00 00 00 00 00 02  |eBI#............|
> 0x00000010: 00 00 08 00 00 00 10 00 00 00 00 00 00 00 00 00  |................|
> 0x00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
> 0x00000030: 00 00 00 00 00 00 00 00 00 00 00 00 40 93 2d 8c  |............@.-.|
> 0x00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
> 0x00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
> 0x00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
> 0x00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
> 0x00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
> 0x00000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
>
> I'm wondering how the author if this driver (you, IIUC) has tested it initially,
> especially regarding ECC functionality.

I was using nandbiterrs -i, but I was on a mainline kernel, I never
tested the backports, even though if they picked the driver entirely
there are little chances this could be a problem.

Subpage writes are normally completely orthogonal to ECC handling, so I
still do not understand what you get here. Maybe you can track the
register statuses and look at what is different.

Good luck and sorry but I have no idea what is wrong here.
Miquèl

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/