AW: AW: NAND ECC errors

[markus.stockhausen at gmx.de]

Hi Miguel,

> -----Ursprüngliche Nachricht-----
> Von: Miquel Raynal <miquel.raynal at 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 at 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