Hi, >From: Enric Balletbo Serra [mailto:eballetbo@xxxxxxxxx] >CCing Pekon Gupta <pekon@xxxxxx> > >>2013/12/2 Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxxxxxxxxx>: >>> Dear Javier Martinez Canillas, >> >>> > On Sun, 1 Dec 2013 13:27:25 +0100, Javier Martinez Canillas wrote: >> >>> > diff --git a/arch/arm/boot/dts/omap3-igep0020.dts b/arch/arm/boot/dts/omap3-igep0020.dts >>> > index d5cc792..4229e94 100644 >>> > --- a/arch/arm/boot/dts/omap3-igep0020.dts >>> > +++ b/arch/arm/boot/dts/omap3-igep0020.dts >>> > @@ -116,7 +116,7 @@ >>> > linux,mtd-name= "micron,mt29c4g96maz"; >>> > reg = <0 0 0>; >>> > nand-bus-width = <16>; >>> > - ti,nand-ecc-opt = "bch8"; >>> > + ti,nand-ecc-opt = "ham1"; >>> > A query Why are you going backward from BCH8 to HAM1 ? HAM1 is just kept for legacy reasons, it's not at all recommended for new development. As some field results have shown that devices with HAM1 become un-usable very soon and start reporting uncorrectable errors because HAM1 can only handle single bit-flip, which is inadequate in field conditions and large page device wears-n-tears. (especially considering your device density is of order of 4Gb - mt29c4g96maz). Also, just to inform that BCH8_SW ecc-scheme is implemented in such a way that *only* error correction is handled using s/w library (lib/bch.c). Rest all ECC calculation is handled using GPMC hardware. So, the CPU penalty will be seen only when there are bit-flips found during Read access, which are of rare conditions, occurring only few times in multi-megabit transfers. Also, On top of that ecc-schemes implementations have been optimized. And the patch-series is under review on mainline kernel. http://lists.infradead.org/pipermail/linux-mtd/2013-November/thread.html (Apologies for long suggestion, but in summary please don't use HAM1 for any new development. And with BCH8_SW you should see better bit-flip handling (longer device life) with no hit in performance). [...] >Pekon, the old ti,nand-ecc-opt = "sw" should be replaced by >ti,nand-ecc-opt = "ham1" ? Should be the same ? In that case, why this >different behavior ? > In addition, please use "HAM1" ecc-scheme on mainline u-boot also to flash. (following patches were accepted by domain maintainer 'Scott Woods'). http://lists.denx.de/pipermail/u-boot/2013-November/167548.html So, Kernel "ham1" and u-boot "ham1" should be in sync.. Once above is clean, you may like to pull another set of patches below (these are kernel equivalent of driver optimization for u-boot driver) http://lists.denx.de/pipermail/u-boot/2013-November/167445.html Also, for JFFS2, please erase the flash using -j option. '-j' option adds a clean marker to erased blocks. with regards, pekon ��.n��������+%������w��{.n�����{�������ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
