Re: PL353 NAND Controller - SW vs HW ECC

[Miquel Raynal <miquel.raynal@bootlin.com>]

Hi Andrea,

>>>> This is obviously just speculation, maybe the errata you mentioned above
>>>> will bring an obvious hardware failure to our attention. The Arasan IP
>>>> used on ZynqMP also suffers from a similar limitation (not able to
>>>> correctly report failures) and I decided to implement one path using the
>>>> software BCH engine, with a time penalty of course.
>>>
>>> So that's nearly the same result I'm trying to get with Zynq7k
>>> platform ;-)
>> In this case, I can only recommend the blog post I wrote for the
>> Arasan
>> controller. I believe it should be easier to do as you won't need the
>> polynomial retro-engineering.
>> Link:
>> https://bootlin.com/blog/supporting-a-misbehaving-nand-ecc-engine/
>
> Thanks for this detailed article!
> I think I'll move to hamming code (if I make it work in u-boot) or BCH
> (after evaluating the performance impact)

Either you want to leverage the engine in the write path (because it is
faster than doing it with the CPU) and you must implement Hamming as
that's the only capability of the controller, or you want better
strength and in this case you do not have anything to do except
configuring for software ECC engines in the DT.

But for an upstream fix, which I would welcome, you need to use the
Hamming hardware for the write path and software in the read path.

> I have some issue with Linux to U-Boot interoperability (single bit
> error are not correctly handled in u-boot hamming implementation), is
> this the right mailing list to ask for advice or should I move to
> u-boot ML?

You could create a thread with both, I guess, if there is an
interoperability issue.

Thanks,
Miquèl

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