On Fri, Aug 5, 2016 at 10:47 PM, Ran Shalit <ranshalit@xxxxxxxxx> wrote: > On Fri, Aug 5, 2016 at 6:07 PM, Peter Barada <peter.barada@xxxxxxxxx> wrote: >> 1-bit hamming (either HW or SW) is applicable only for the boot block(s). >> For the rest of the NAND chip, you'll need more than 1-bit ECC to maintain >> an adequately low UBER (Unrecoverable Bit Error Rate). Look at using 4-bit >> BCH ECC, or adding code to use the in-chip ECC (however that precludes >> partial page writes which JFFS2 is want to do with erase markers). "ECC: Data stored in NANDs can get corrupted (randomly). " If ecc is randomly corrupted, so how can the error issue we observer , which always happens in the same address in nand, can be explained as ecc issue ? > > Why is it that 1-bit suffecient for boot but not for other sections ? > > Is it that using 1-bit error can explaing that the boards get wrong > bits always in same address in NAND ? > > >> >> >> On 08/05/2016 10:42 AM, Ran Shalit wrote: >>> >>> Hi, >>> >>> We have some severe issue with many products. >>> After long investigation, we see that some address in nand get bad >>> after several read and writes. >>> On writing the same binary, we get that it is always the same address >>> (!) in different boards ! >>> We use MS29C4G48MAZAKC1-XX_rev4-MSC_029 nand. >>> >>> We have no idea what's the problem. >>> We do the tesing of nand programming from u-boot. >>> We tried to change from hw ecc (1-bit hamming) to sw ecc, but the >>> behaviour is the same ! >>> >>> One more question: >>> 1. on trying to burn jffs section with sw ecc, we het errors (ecc >>> error) on mounting, and linux hang, so we had to burn that section >>> with hw ecc. Is jffs limited to hw ecc ? >>> 2. Is it nand ecc issue or bad block issue ? >>> >>> We in a point where there are no more ideas what to do so any >>> suggestion will help. >>> >>> Thank you, >>> Ran >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in >>> the body of a message to majordomo@xxxxxxxxxxxxxxx >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >> >> -- >> Peter Barada >> peter.barada@xxxxxxxxx >> -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
