AW: AW: AW: NAND ECC errors

[Miquel Raynal]

On 08/08/2025 at 15:21:40 +02, <markus.stockhausen at gmx.de> wrote:

>> Von: linux-mtd <linux-mtd-bounces at lists.infradead.org> Im Auftrag von Miquel Raynal
>> Gesendet: Freitag, 8. August 2025 14:42
>> 
>> On 08/08/2025 at 14:25:18 +02, <markus.stockhausen at gmx.de> wrote:
>> Just to fully understand, you are trying to replicate what the software
>> BCH engine of your realtek SPI controller does?
>>
>> If so, why not just configuring the engine directly and use it? It will
>> be much faster and easier to do.
>>
>> Otherwise, if you're trying to do in software what the hardware does,
>> you must be prepared to more maths:
>> https://bootlin.com/blog/supporting-a-misbehaving-nand-ecc-engine/
>
> Idea was to start with something I have fully understood. Wantet to
> leave Hardware for later as ECC is a total new area now (as it was with 
> NAND the last week). Had a short look at the hardware engine GPL 
> code. The most basic parts look straight forward with three functions
>
> - Prepare to to encoded data
> - Prepare to be decoded data
> - Kick engine
>
> ecc-mtk seems tightly integrated into the nand contoller while 
> ecc-mxic seems to be some passthrough/pipeline integration.
>
> What would be your advise for the most simple enhancement 
> for our existing Realtek spi-mem controller?

>From my current understanding, implementing the external approach (see
Maronix external ECC engine case) should be the easiest path forward.

If the engine is tightly integrated to the controller (I have no idea),
then use the pipelined example or MTK's example.

You need to implement very few callbacks for getting it to work, and
except the init which might be a bit painful they will all be simple
(like set/clear a bit, return the value of a register...).

Good luck!
Miquèl