Re: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.

[Tom Rini <trini@ti.com>]

On 12/02/2013 12:05 PM, Gupta, Pekon wrote:
>> From: Thomas Petazzoni [mailto:thomas.petazzoni@free-electrons.com]
>> Dear Gupta, Pekon,
>>
>> On Mon, 2 Dec 2013 16:13:56 +0000, Gupta, Pekon wrote:
>>
>>> Yes, at-least OMAP3 arch u-boot should still supports 'nandecc'.
>>> The infrastructure is still in place, however the command 'nandecc' is
>>> deprecated in newer versions.
>>> References in mainline u-boot:
>>> arch/arm/cpu/armv7/omap3/board.c  @@do_switch_ecc()
>>> driver/mtd/nand/omap_gpmc.c @@omap_nand_switch_ecc()
>>>
>>> So with minor hacks, you should be able to bring-back 'nandecc'.
>>
>> So in short, what it means is that indeed the fact of switching to BCH8
>> on the kernel side is really breaking things, because U-Boot users now
>> have the choice between:
>>
>> * Configuring U-Boot to use Hamming ECC, and be able to reflash their
>>   SPL, but not their filesystem images.
>>
>> * Configuring U-Boot to use BCH8, and be able to reflash their
>>   filesystem images, but not their SPL.
>>
>> Seems a little bit annoying for users, no?
>>
> Yes, agree ..
> But this is only because we have mis-match in ecc-scheme between
> ROM-code (while reading SPL) v/s  rest of system.
> However, if you continue using 'HAM1' for *both* u-boot and kernel
> you should not face any issue. And with latest patch on u-boot
> your board file should also remain unchanged.

I'm sorry, this is wrong.  When the hardware says you MUST use BCH8 or
more for a given chip using HAM1 you will have issues.  And chips that
say you must use BCH4/8/16 are why we get into this issue.

-- 
Tom