>From: Thomas Petazzoni [mailto:thomas.petazz...@free-electrons.com] >>On Mon, 2 Dec 2013 14:56:09 +0000, Gupta, Pekon wrote: > >> 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). > >The crucial point here is that the interaction between the bootloader >and the kernel. The use case I have is that I'm flashing a filesystem >image from the bootloader, and mounting it from the kernel. > >Using a mainline 2013.10 U-Boot for IGEPv2 + the mainline kernel booted >in legacy mode (no Device Tree) works fine. Using the same 2013.10 >U-Boot for IGEPv2 + the mainline kernel booted in DT no longer works, >because the kernel disagrees with the bootloader on the ECC scheme to >use. > >So I'm not saying that Hamming is better than BCH, certainly not. I'm >just saying that changing ECC scheme in the kernel without looking at >the more global picture of what support the bootloaders are offering is >not nice. At least, the bootloader should provide a command, or option, >to be able to use an ECC scheme that is compatible with what the kernel >expects. > Yes, there is a way to change ecc-scheme in u-boot.. Also, you can modify to any ecc-scheme in u-boot using "CONFIG_NAND_OMAP_ECCSCHEME" as documented in doc/README.nand
Also your board should boot seamlessly from mainline u-boot in sync with mainline kernel. As per my knowledge following patch is already in mainline u-boot. And touches your board as well. (omap3_igep00x0.h) http://lists.denx.de/pipermail/u-boot/2013-November/167550.html AFAIK these patches should be in u-boot mainline. Though I have taken at-most care that no existing board should break. But, I'm sorry if there is something broken in between the u-boot and Kernel builds. Let me know if I can help in fixing that somehow. with regards, pekon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
