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

[Tom Rini <trini@ti.com>]

On 12/02/2013 12:46 PM, Gupta, Pekon wrote:
>>> So coming back to the specific problem here.
>>> I think we need 'nandecc' back in u-boot till atleast all systems have
>>> migrated to BCH16 or whatever highest ecc-scheme which can be
>>> supported on OMAP devices.
>>>
> 
> Forgot to mention, one more way of updating boot-loaders with
> different ecc-scheme via kernel. This can be helpful when:
> - you want to remotely upgrade your u-boot, but your kernel is statically
>    build with different ecc-scheme.
> - In production environment, where you boot multiple devices in parallel
>   (using say NFS boot), and then flash multiple devices without bothering
>    about ecc-schemes..
> 
> *Method*
> (1) Flash the u-boot image on one *sample* device selecting appropriate
>    ecc-scheme which ROM code understands.
> (2) Dump the complete image along with OOB appended (as a binary)
> (3) Use this binary image (with OOB included) to flash other devices
> from kernel as *raw* data (that means kernel will not append ECC while
> writing data, it will blindly write the image as-it-is on the partition).
> 
> This way the ECC with which u-boot image was built in (1) will get
> programmed, irrespective of what kernel supports..
> - I have seen at-least one customer going into production this way.
> - And I have been using this often too, though with older mtd-utils.

There are many ways to in essentially work around this problem, given
the ability to raw write (including OOB) from the kernel and from
u-boot.  This doesn't change the general problem of "we have cases where
we need part of the NAND with one scheme, another part of it with a
different one".

-- 
Tom