brcmnand (iproc): bitflips and ECC errors due to ignored ECC config

[Kamal Dasu]

Brian,

Current driver  defaults to using hamming when we see 1 bit ecc strength.

"It kinda sounds like Rafal is suggesting this product uses 1-bit BCH."

That explains the read errors, if the image that is being read back
was written with 1-bit BCH encoding.

"Unfortunately, we don't really have a way to clearly differentiate 1-bit
Hamming and 1-bit BCH in DT, do we?"

Yes hamming is a special case in that sense. Adding an optional
"ecc_algo"  field would help.
If Rafal has the ability to  create an image with BCH-2 through BCH-8
that can also work on this part. However the current issue needs to
get fixed to have 1-bit hamming along side 1-bit BCH support. And
maybe we default to using BCH, unless hamming is chosen for 1-bit.

Kamal

On Mon, Feb 8, 2016 at 2:21 PM, Brian Norris
<computersforpeace at gmail.com> wrote:
> On Mon, Feb 08, 2016 at 02:15:16PM -0500, Kamal Dasu wrote:
>> When SECTOR_SIZE = 512B, SPARE_AREA_SIZE  = 16, ECC_LEVEL = 15 enables
>> 1-bit Hamming ECC protection. So the ecc_level field is the SoC
>> internal representation for 1-bit hamming. If you mean by "removing
>> handling" you made strength=ecc_level=1, then you are now using 1-bit
>> BCH.
>
> It kinda sounds like Rafal is suggesting this product uses 1-bit BCH.
> I didn't even remember such a thing existed on this controller.
> Unfortunately, we don't really have a way to clearly differentiate 1-bit
> Hamming and 1-bit BCH in DT, do we? Both could equally well be described
> by:
>
>         nand-ecc-strength = <1>;
>         nand-ecc-step-size = <512>;
>
> Maybe we need a custom BRCM property?
>
> Brian