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

[Igor Grinberg]

On 12/12/13 11:16, Gupta, Pekon wrote:
> 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. 

This is understood. I'm not blaming anyone...

> 
> 
>>> '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.

Well, once again, I'm not blaming anyone, and
the above are pretty much valid arguments.
I myself make similar decisions based on similar facts...

> 
> 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.

Indeed that is the case, but I'm not talking about the ROM code.

> So, I still
> suggest you to migrate to HAM1_HW, or higher ecc-schemes like BCH8.

This will work for new projects based on the OMAP3 hardware,
and it will introduce an overhead which we cannot live with.
If we migrate completely to ECC HW, it will most likely break our
customers production. That is why we have to support OMAP3
hardware with SW ECC.

> Also in mainline kernel HAM1_SW support is deprecated for omap2.c.

This is new to me, I haven't been following OMAP GPMC NAND driver
for a while... I will check this.
Nevertheless, our customers production is not based on mainline kernel.

> I can help
> you to migrate to higher ecc-schemes, if your customer agrees..

Thanks for the proposition, but I don't see this happening any when
in the near future.

> 
> 
> [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
> 

-- 
Regards,
Igor.