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). 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
