Hi Nikita, >From: Nikita Kiryanov [mailto:nik...@compulab.co.il] >Commit "mtd: nand: omap: enable BCH ECC scheme using ELM for generic platform" >(d016dc42cedbf6102e100fa9ecb58462edfb14f8) changed the way software ECC is >configured, both during boot, and during ecc switch, in a way that is not >backwards compatible with older systems (for example, X-Loader on CM-T35 relies >on the old behavior). > >The culprit is the line which assigns ecc.size for software ECC. >Older version of omap_gpmc.c always assigned ecc.size = 0 when configuring for >software ecc, relying on nand_scan_tail() to select a default for ecc.size >(256), while the new version of omap_gpmc.c assigns ecc.size = pagesize, which >is likely to not be 256. > Then its just one-line change.. Remove "ecc.size = pagesize". Why do you need to add a newer config for that ? This ecc-scheme (HAM1_SW) is anyways only kept for backward compatibility with legacy devices. (As also mentioned in doc/README.nand) ----------------------------- CONFIG_NAND_OMAP_ECCSCHEME On OMAP platforms, this CONFIG specifies NAND ECC scheme. It can take following values: OMAP_ECC_HAM1_CODE_SW 1-bit Hamming code using software lib. (for legacy devices only) -----------------------------
But I don't have any board to boot-test this, because all my boards have newer ROM code, which auto-detects BCH8 or BCH16 based on block-size of NAND device connected to it. Also, I suggest to migrate to 'HAM1_HW' as this should be compatible to OMAP3 ROM code (for NAND boot), at-least I could check that based on NAND ecc-layout given in OMAP35xx TRM. 'HAM1_SW' will un-necessary burden your CPU by calculating ECC in software, inspite the fact that GPMC controller can do that in hardware. with regards, pekon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
