AW: NAND ECC errors
Chris Packham
Chris.Packham at alliedtelesis.co.nz
Thu Aug 7 14:32:37 PDT 2025
On 08/08/2025 09:23, markus.stockhausen at 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.
More information about the linux-mtd
mailing list