Hi Pekon, On 12/11/13 23:18, Gupta, Pekon wrote: > 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 ?
Well, we think that having that line is actually the right behavior, and it is a pity we did not have this from the start in the X-Loader. So that is why we did not want to change it in a brutal way... But if you say: > 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) > ----------------------------- then it makes real sense to just revert the ecc.size setting to what it was prior to your patches. > > 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. The problem is not the ROM code... Our systems are in production phase already for a long time and we have customers relying on the old behavior, so we cannot just switch the ECC to HW and stop using the SW one. > 'HAM1_SW' will un-necessary burden your CPU by calculating ECC in > software, inspite the fact that GPMC controller can do that in hardware. Well, that is indeed the case. I think TI should have think about it in first place before releasing the SW ECC based drivers... ;-) -- Regards, Igor. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
