Hi Pekon,
On 12/11/13 23:18, Gupta, Pekon wrote:
Hi Nikita,
From: Nikita Kiryanov [mailto:nikita@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... ;-)