[U-Boot] [PATCH 1/2] arm: omap: nand: introduce CONFIG_NAND_OMAP_SW_ECC_LEGACY

[Gupta, Pekon]

Hi,

>From: Igor Grinberg [mailto:grinberg at compulab.co.il]
>>On 12/11/13 23:18, Gupta, Pekon wrote:
>>> From: Nikita Kiryanov [mailto:nikita at 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-architecture-will-spark-development-of-a-new-class-of-mobile-phones-55318217.html
" 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