Re: AW: NAND ECC errors

From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Chris Packham <Chris.Packham@alliedtelesis.co.nz>
Cc: "markus.stockhausen@gmx.de" <markus.stockhausen@gmx.de>,
	"vigneshr@ti.com" <vigneshr@ti.com>,
	 "richard@nod.at" <richard@nod.at>,
	"tudor.ambarus@linaro.org" <tudor.ambarus@linaro.org>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: AW: NAND ECC errors
Date: Fri, 08 Aug 2025 10:41:35 +0200	[thread overview]
Message-ID: <87pld6b3y8.fsf@bootlin.com> (raw)
In-Reply-To: <a1794cf8-ed93-45db-8ac1-7e5d2ccd9fe9@alliedtelesis.co.nz> (Chris Packham's message of "Thu, 7 Aug 2025 21:32:37 +0000")

On 07/08/2025 at 21:32:37 GMT, Chris Packham <Chris.Packham@alliedtelesis.co.nz> wrote:

> On 08/08/2025 09:23, markus.stockhausen@gmx.de wrote:
>>> Anyone good ideas what to do first from here?
>>>
>>> Probably depends. Blanking the NAND chip and reformatting it will
>>> resolve the errors from and upstream point of view. That's obviously not
>>> really going to be something you want to do if you expect to swap back
>>> and forth between the stock firmware and an upstream kernel.
>>>
>>> You'll probably want to convince the mtd code to allow the on-die ECC to
>>> be disabled and find whatever software BCH settings are needed that work
>>> with the stock firmware. Then we could maybe look at using the ECC
>>> controller to accelerate that.
>> Good direction. So assumption is:
>> - vendor wrote BCH6 into OOB
>> - This design is also active in his firmware (with Realtek ECC engine)
>> - now we read data with upstream kernel and on-die ECC
>> - Each read produces an on-die ECC error
>> - As soon as we write new data on-die ECC will be created
>>
>> But where is the ECC knob in between spi-realtek-nand, mtd and ubi?
> Yeah that's the part I don't know. I don't think there is an existing 
> one for SPI-NAND (there is one for parallel NAND). I think it's a chip 
> level thing so spi-realtek-nand will probably be ignorant of any such 
> option (at least until the ECC controller comes into play). I also think 
> ubi doesn't care who does the ECC as long as they tell them when there 
> is an error.

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,
Miquèl

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