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

[Igor Grinberg <grinberg@compulab.co.il>]

Hi Pekon,

On 12/11/13 23:18, Gupta, Pekon wrote:
> Hi Nikita,
> 
>> 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.

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