AW: NAND ECC errors

From: <markus.stockhausen@gmx.de>
To: "'Chris Packham'" <Chris.Packham@alliedtelesis.co.nz>,
	<miquel.raynal@bootlin.com>, <vigneshr@ti.com>, <richard@nod.at>,
	<tudor.ambarus@linaro.org>, <linux-mtd@lists.infradead.org>
Subject: AW: NAND ECC errors
Date: Thu, 7 Aug 2025 23:23:41 +0200	[thread overview]
Message-ID: <034f01dc07e1$8dd75dd0$a9861970$@gmx.de> (raw)
In-Reply-To: <2537e2a1-f958-4e9c-b346-b4fac2152a47@alliedtelesis.co.nz>

> 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?

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