On 12/02/2013 11:21 AM, Javier Martinez Canillas wrote: > Hi Pekon, > > On Mon, Dec 2, 2013 at 5:13 PM, Gupta, Pekon <pekon@xxxxxx> 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, we used nandecc to write data on different mtd partitions for SPL > (nandecc hw) and the rootfs (nandecc hw bch8). > >> 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() >> > > Why nandecc is being deprecated from u-boot? How are you supposed to > use a different ECC scheme then? We (I) had killed off all of the mainline users of the nandecc command, once everyone was using the same 1bit scheme layout. None of the people that had mixed HAM1/BCH4 at the time wanted to work upstream on it. -- 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
