On 12/02/2013 11:13 AM, Gupta, Pekon wrote: >> From: Thomas Petazzoni [mailto:thomas.petazzoni@xxxxxxxxxxxxxxxxxx] >>> On Mon, 2 Dec 2013 11:00:35 -0500, Tom Rini wrote: >> >>>>> Although the new ECC schema breaks the compatibility between the board >>>>> files and new DT based kernel, I think we should use BCH8 scheme. >>>>> Sorry, because I had not realized that this was configurable in >>>>> u-boot, so I think, if Thomas is also agree, the better fix in that >>>>> case is change CONFIG_NAND_OMAP_ECCSCHEME to >>>>> OMAP_ECC_BCH8_CODE_HW_DETECTION_SW in u-boot. If this works we can >>>>> discard this patch. >>>> >>>> I theoretically don't have anything against that, but if I do this >>>> change in U-Boot, and then use U-Boot to reflash to NAND the SPL and >>>> U-Boot itself, will the OMAP ROM code still be able to read the SPL >>>> from NAND ? I'm not sure which ECC scheme does the OMAP ROM code >>>> support, and how it detects (or not) which ECC scheme to use to read >>>> the SPL. >>> >>> Yes, this brings us back to one of the old and long-standing problems. >>> The ROM on these devices will generally speak one format and that means >>> using NAND chips that say for the first block (or N blocks or whatever) >>> you only need 1bit ECC but for the rest 4/8/16/whatever. And then >>> informing the kernel (and anything else) that "partitions" N need this >>> format and the rest need that. >> >> As long as U-Boot provides separate commands, or a "nandecc" command >> that allows to switch between ECC scheme, and select the ECC scheme >> expected by the ROM code when flashing the SPL, and then the ECC scheme >> expected by the SPL and the kernel to flash U-Boot itself, the kernel >> image, and the various filesystem images, then it's all fine, we can >> leave with different ECC schemes used for different things on the NAND >> flash. >> > 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'. Right, on OMAP3 (and related) we have the issue of ROM only doing 1bit ECC, but being used with parts that require more, so what I said above is important. OMAP4/am335x/later ship with ROM that groks at least BCH16. With my U-Boot hat on, I really don't want to encourage people to come up with designs that require on the fly switching because.. > But for all these, images need to be flashed from u-boot. As kernel > cannot switch ecc-schemes on-the-fly. Exactly. The kernel hasn't, and I get the feeling won't, support this case of needing different ECC schemes for different areas of the NAND, so we'll continue to be in the position of the Linux for flashing everything but bootloader or custom hacks to the kernel. -- 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
