Hi,
From: Igor Grinberg [mailto:grinberg@compulab.co.il]
On 12/11/13 23:18, Gupta, Pekon wrote:
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.
Yes, please fix this..
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.
I understand, sorry my update caused you regression, but OMAP3 EVM, were released so long back [1], that I myself find it difficult to get a working setup to test.
'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... ;-)
Though I'm not the right person to answer this, but some of my assumptions on why TI continued supporting HAM1_SW at the time of OMAP3 production (2006-2007) [1]: - Noone could have predict which ecc-scheme would become popular, and so TI kept both HAM1_SW and introduced HAM1_HW. - Also, I think TI introduced HAM1_SW because they did not want to be gated if GPMC hardware engine had some silicon issues.
But if I'm not wrong, you cannot boot from NAND when using HAM1_SW, because the ecc-layout for HAM1_SW is in-compatible to ROM code. So, I still suggest you to migrate to HAM1_HW, or higher ecc-schemes like BCH8. Also in mainline kernel HAM1_SW support is deprecated for omap2.c. I can help you to migrate to higher ecc-schemes, if your customer agrees..
[1] http://www.prnewswire.com/news-releases/texas-instruments-new-omaptm-3-archi... " TI's OMAP3430 multimedia processor is expected to sample in mid-2006, with volume production scheduled for 2007. For additional information regarding the OMAP3430 processor, please visit http://www.ti.com/omap3 ."
with regards, pekon