On 12/02/2013 12:05 PM, Gupta, Pekon wrote: >> From: Thomas Petazzoni [mailto:thomas.petazzoni@xxxxxxxxxxxxxxxxxx] >> Dear Gupta, Pekon, >> >> On Mon, 2 Dec 2013 16:13:56 +0000, Gupta, Pekon wrote: >> >>> Yes, at-least OMAP3 arch u-boot should still supports 'nandecc'. >>> The infrastructure is still in place, however the command 'nandecc' is >>> deprecated in newer versions. >>> References in mainline u-boot: >>> arch/arm/cpu/armv7/omap3/board.c @@do_switch_ecc() >>> driver/mtd/nand/omap_gpmc.c @@omap_nand_switch_ecc() >>> >>> So with minor hacks, you should be able to bring-back 'nandecc'. >> >> So in short, what it means is that indeed the fact of switching to BCH8 >> on the kernel side is really breaking things, because U-Boot users now >> have the choice between: >> >> * Configuring U-Boot to use Hamming ECC, and be able to reflash their >> SPL, but not their filesystem images. >> >> * Configuring U-Boot to use BCH8, and be able to reflash their >> filesystem images, but not their SPL. >> >> Seems a little bit annoying for users, no? >> > Yes, agree .. > But this is only because we have mis-match in ecc-scheme between > ROM-code (while reading SPL) v/s rest of system. > However, if you continue using 'HAM1' for *both* u-boot and kernel > you should not face any issue. And with latest patch on u-boot > your board file should also remain unchanged. I'm sorry, this is wrong. When the hardware says you MUST use BCH8 or more for a given chip using HAM1 you will have issues. And chips that say you must use BCH4/8/16 are why we get into this issue. -- Tom -- 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
