linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: <markus.stockhausen@gmx.de>
To: "'Miquel Raynal'" <miquel.raynal@bootlin.com>
Cc: <vigneshr@ti.com>, <richard@nod.at>, <tudor.ambarus@linaro.org>,
	<linux-mtd@lists.infradead.org>,
	"'Chris Packham'" <Chris.Packham@alliedtelesis.co.nz>
Subject: AW: AW: NAND ECC errors
Date: Fri, 8 Aug 2025 14:25:18 +0200	[thread overview]
Message-ID: <052001dc085f$81e731c0$85b59540$@gmx.de> (raw)
In-Reply-To: <87pld6b3y8.fsf@bootlin.com>

Hi Miguel,

> -----Ursprüngliche Nachricht-----
> Von: Miquel Raynal <miquel.raynal@bootlin.com> 
> Gesendet: Freitag, 8. August 2025 10:42
>
>
> As explained in my other answer, you can now choose between ECC engines
> when there are several. All happens at the SPI NAND level though, MTD,
> UBI of filesystems are ignorant about it. They just expect (corrected)
> data.
>
> However if your fw used to play with an external or pipelined ECC
> engine, you are good to write a driver for it! But be happy, now there
> is all the infrastructure needed for it.
>
> Reference implementations:
> - drivers/mtd/nand/ecc-mxic.c
> - drivers/mtd/nand/ecc-mtk.c

Thanks a lot for your detailed explanations. The missing bit was the 
info that all is in place for spi nand. I just was focused on that 
on-die code snippet. So I was able to configure all I need. The DTS 
reads now:

  flash@0 {
    compatible = "spi-nand";
    reg = <0>;
	
    nand-use-soft-ecc-engine;
    nand-ecc-algo = "bch";
    nand-ecc-placement = "oob";
    nand-ecc-strength = <6>;
    nand-ecc-step-size = <512>;

The software BCH engine is finally kicking in. Now there is a last
small bit that is somehow off. As explained I found this data

4*512 bytes data
4*6 bytes (set to 0xff 0xff 0xff 0xff 0xff 0xff)
4*10 bytes ECC.

While the bch6 code is automatically directed to the right ECC
data slot the calculated checksums are totally different. So
still unrecoverable errors. Looking deeper I noticed that the 
original ECC was not only calculated over the 512 bytes data 
but also over the 6*0xff extra bytes. These are simply appended.

So we have

DATA:
000 : 55 42 49 23 01 00 00 00 00 00 00 00 00 00 00 01 00 00 08 00 00 00 10 00 7b 6d c1 75 00 00 00 00
032 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 9f 21 e9 0b
064 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
096 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
128 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
160 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
192 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
224 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
256 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
288 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
320 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
352 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
384 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
416 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
448 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
480 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

ECC read from flash: a8 5e 66 15 61 32 de 2b 8b 44
ECC BCH6 512 bytes : fa 7c bc 7b 44 c5 c7 b7 d8 6b
ECC BCH6 518 (0xff): a8 5e 66 15 61 32 de 2b 8b 44

This is consistent for all blocks. I'll add some hacks to
software bch engine to verify it. Aside from the stupid
idea of coding a bch "proxy" engine what would be a proper 
solution? 

Markus




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

  reply	other threads:[~2025-08-08 12:42 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-07 15:16 NAND ECC errors markus.stockhausen
2025-08-07 20:36 ` Chris Packham
2025-08-07 21:23   ` AW: " markus.stockhausen
2025-08-07 21:32     ` Chris Packham
2025-08-08  8:41       ` Miquel Raynal
2025-08-08 12:25         ` markus.stockhausen [this message]
2025-08-08 12:41           ` AW: " Miquel Raynal
2025-08-08 13:21             ` AW: " markus.stockhausen
2025-08-08 13:31               ` Miquel Raynal
2025-08-08  8:37   ` Miquel Raynal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='052001dc085f$81e731c0$85b59540$@gmx.de' \
    --to=markus.stockhausen@gmx.de \
    --cc=Chris.Packham@alliedtelesis.co.nz \
    --cc=linux-mtd@lists.infradead.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=richard@nod.at \
    --cc=tudor.ambarus@linaro.org \
    --cc=vigneshr@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).