Dear Tom Rini, 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. Of course, ideally, we should also be able to tell the kernel about the ECC scheme on a per-partition basis. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- 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
