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

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

[Enric Balletbo i Serra]

Legacy board files for IGEP Processor Boards used 1-bit Hamming ECC layout but
new DT uses BCH8 software layout. This breaks the backward compatibility for
people that used board files before and switch to DT and have the problem that
they can't flash the rootfs using the bootloader.

This patch sets the ECC layout to 1-bit Hamming ECC in order to maintain this
compatibility.

Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reported-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Enric Balletbo i Serra <eballetbo@gmail.com>
---
 arch/arm/boot/dts/omap3-igep0020.dts | 2 +-
 arch/arm/boot/dts/omap3-igep0030.dts | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-igep0020.dts b/arch/arm/boot/dts/omap3-igep0020.dts
index d5cc792..4229e94 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -116,7 +116,7 @@
 		linux,mtd-name= "micron,mt29c4g96maz";
 		reg = <0 0 0>;
 		nand-bus-width = <16>;
-		ti,nand-ecc-opt = "bch8";
+		ti,nand-ecc-opt = "ham1";
 
 		gpmc,sync-clk-ps = <0>;
 		gpmc,cs-on-ns = <0>;
diff --git a/arch/arm/boot/dts/omap3-igep0030.dts b/arch/arm/boot/dts/omap3-igep0030.dts
index 525e6d9..9043e97 100644
--- a/arch/arm/boot/dts/omap3-igep0030.dts
+++ b/arch/arm/boot/dts/omap3-igep0030.dts
@@ -59,7 +59,7 @@
 		linux,mtd-name= "micron,mt29c4g96maz";
 		reg = <0 0 0>;
 		nand-bus-width = <16>;
-		ti,nand-ecc-opt = "bch8";
+		ti,nand-ecc-opt = "ham1";
 
 		gpmc,sync-clk-ps = <0>;
 		gpmc,cs-on-ns = <0>;
-- 
1.8.1.2

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

[Javier Martinez Canillas]

Hi Enric,

Thanks a lot for fixing this.

When adding NAND support for the IGEP boards I used as a base the
example from Documentation/devicetree/bindings/mtd/gpmc-nand.txt and I
wrongly assumed that bch8 was also the ECC scheme used in the legacy
IGEP board file. Sorry for the inconvenience.

On Sun, Dec 1, 2013 at 12:23 PM, Enric Balletbo i Serra
<eballetbo@gmail.com> wrote:
> Legacy board files for IGEP Processor Boards used 1-bit Hamming ECC layout but
> new DT uses BCH8 software layout. This breaks the backward compatibility for
> people that used board files before and switch to DT and have the problem that
> they can't flash the rootfs using the bootloader.
>
> This patch sets the ECC layout to 1-bit Hamming ECC in order to maintain this
> compatibility.
>
> Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Reported-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
> Signed-off-by: Enric Balletbo i Serra <eballetbo@gmail.com>
> ---
>  arch/arm/boot/dts/omap3-igep0020.dts | 2 +-
>  arch/arm/boot/dts/omap3-igep0030.dts | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap3-igep0020.dts b/arch/arm/boot/dts/omap3-igep0020.dts
> index d5cc792..4229e94 100644
> --- a/arch/arm/boot/dts/omap3-igep0020.dts
> +++ b/arch/arm/boot/dts/omap3-igep0020.dts
> @@ -116,7 +116,7 @@
>                 linux,mtd-name= "micron,mt29c4g96maz";
>                 reg = <0 0 0>;
>                 nand-bus-width = <16>;
> -               ti,nand-ecc-opt = "bch8";
> +               ti,nand-ecc-opt = "ham1";
>
>                 gpmc,sync-clk-ps = <0>;
>                 gpmc,cs-on-ns = <0>;
> diff --git a/arch/arm/boot/dts/omap3-igep0030.dts b/arch/arm/boot/dts/omap3-igep0030.dts
> index 525e6d9..9043e97 100644
> --- a/arch/arm/boot/dts/omap3-igep0030.dts
> +++ b/arch/arm/boot/dts/omap3-igep0030.dts
> @@ -59,7 +59,7 @@
>                 linux,mtd-name= "micron,mt29c4g96maz";
>                 reg = <0 0 0>;
>                 nand-bus-width = <16>;
> -               ti,nand-ecc-opt = "bch8";
> +               ti,nand-ecc-opt = "ham1";

Just a note that this binding property got renamed for v3.13 on

commit c66d039197e42af8867e5d0d9b904daf0fb9e6bc
Author: Pekon Gupta <pekon@ti.com>
Date:   Thu Oct 24 18:20:18 2013 +0530

    mtd: nand: omap: combine different flavours of 1-bit hamming ecc schemes

so users using current v3.12 kernel or older should use

ti,nand-ecc-opt = "sw";

instead.

>
>                 gpmc,sync-clk-ps = <0>;
>                 gpmc,cs-on-ns = <0>;
> --
> 1.8.1.2
>
> --

Acked-by: Javier Martinez Canillas <javier@dowhile0.org>

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

[Thomas Petazzoni]

Dear Javier Martinez Canillas,

On Sun, 1 Dec 2013 13:27:25 +0100, Javier Martinez Canillas wrote:

> > diff --git a/arch/arm/boot/dts/omap3-igep0020.dts b/arch/arm/boot/dts/omap3-igep0020.dts
> > index d5cc792..4229e94 100644
> > --- a/arch/arm/boot/dts/omap3-igep0020.dts
> > +++ b/arch/arm/boot/dts/omap3-igep0020.dts
> > @@ -116,7 +116,7 @@
> >                 linux,mtd-name= "micron,mt29c4g96maz";
> >                 reg = <0 0 0>;
> >                 nand-bus-width = <16>;
> > -               ti,nand-ecc-opt = "bch8";
> > +               ti,nand-ecc-opt = "ham1";
> >
> >                 gpmc,sync-clk-ps = <0>;
> >                 gpmc,cs-on-ns = <0>;
> > diff --git a/arch/arm/boot/dts/omap3-igep0030.dts b/arch/arm/boot/dts/omap3-igep0030.dts
> > index 525e6d9..9043e97 100644
> > --- a/arch/arm/boot/dts/omap3-igep0030.dts
> > +++ b/arch/arm/boot/dts/omap3-igep0030.dts
> > @@ -59,7 +59,7 @@
> >                 linux,mtd-name= "micron,mt29c4g96maz";
> >                 reg = <0 0 0>;
> >                 nand-bus-width = <16>;
> > -               ti,nand-ecc-opt = "bch8";
> > +               ti,nand-ecc-opt = "ham1";

Tested this with 3.13-rc1, and it somewhat works, but causes some ECC
error messages:

# mount -t jffs2 /dev/mtdblock3 /mnt/
[   10.423736] jffs2: CLEANMARKER node found at 0x00000000 has totlen 0xc != normal 0x0
[   10.444671] jffs2: CLEANMARKER node found at 0x00020000 has totlen 0xc != normal 0x0
[   10.472290] jffs2: mtd->read(0x100 bytes from 0x40000) returned ECC error
[   10.480743] jffs2: mtd->read(0x100 bytes from 0x60000) returned ECC error
[   10.489013] jffs2: mtd->read(0x100 bytes from 0x80000) returned ECC error
[   10.497283] jffs2: mtd->read(0x100 bytes from 0xa0000) returned ECC error
[   10.505126] jffs2: mtd->read(0x100 bytes from 0xc0000) returned ECC error
[   10.513458] jffs2: mtd->read(0x100 bytes from 0xe0000) returned ECC error
[   10.521667] jffs2: mtd->read(0x100 bytes from 0x100000) returned ECC error
[   10.529968] jffs2: mtd->read(0x100 bytes from 0x120000) returned ECC error
[   10.538269] jffs2: mtd->read(0x100 bytes from 0x140000) returned ECC error
[   10.546295] jffs2: mtd->read(0x100 bytes from 0x160000) returned ECC error
[   10.554534] jffs2: mtd->read(0x100 bytes from 0x180000) returned ECC error
[   10.563323] jffs2: mtd->read(0x100 bytes from 0x1a0000) returned ECC error
[   10.571685] jffs2: mtd->read(0x100 bytes from 0x1c0000) returned ECC error
[   10.579986] jffs2: mtd->read(0x100 bytes from 0x1e0000) returned ECC error
[   10.588287] jffs2: mtd->read(0x100 bytes from 0x200000) returned ECC error
[   10.596313] jffs2: mtd->read(0x100 bytes from 0x220000) returned ECC error
[   10.604522] jffs2: mtd->read(0x100 bytes from 0x240000) returned ECC error
[   10.613037] jffs2: mtd->read(0x100 bytes from 0x260000) returned ECC error
[   10.621307] jffs2: mtd->read(0x100 bytes from 0x280000) returned ECC error
[   10.629608] jffs2: mtd->read(0x100 bytes from 0x2a0000) returned ECC error
[   10.637908] jffs2: mtd->read(0x100 bytes from 0x2c0000) returned ECC error
[   10.645843] jffs2: mtd->read(0x100 bytes from 0x2e0000) returned ECC error
[   10.654113] jffs2: notice: (851) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found.
# 
# 
# cd /mnt/
# ls
MD5SUMS  foo10    foo3     foo5     foo7     foo9
foo1     foo2     foo4     foo6     foo8
# md5sum -c MD5SUMS 
foo1: OK
foo10: OK
foo2: OK
foo3: OK
foo4: OK
foo5: OK
foo6: OK
foo7: OK
foo8: OK
foo9: OK

This is with a JFFS2 image flashed after doing "nandecc sw" in U-Boot.

> Just a note that this binding property got renamed for v3.13 on
> 
> commit c66d039197e42af8867e5d0d9b904daf0fb9e6bc
> Author: Pekon Gupta <pekon@ti.com>
> Date:   Thu Oct 24 18:20:18 2013 +0530
> 
>     mtd: nand: omap: combine different flavours of 1-bit hamming ecc schemes
> 
> so users using current v3.12 kernel or older should use
> 
> ti,nand-ecc-opt = "sw";
> 
> instead.

However, this works perfectly fine, with the same JFFS2 image, flashed
in the same way in U-Boot:

# mount -t jffs2 /dev/mtdblock3 /mnt/
[   19.789306] jffs2: CLEANMARKER node found at 0x00000000 has totlen 0xc != normal 0x0
[   19.810455] jffs2: CLEANMARKER node found at 0x00020000 has totlen 0xc != normal 0x0
[   19.850860] jffs2: notice: (802) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found.
# cd /mnt/
# ls
MD5SUMS  foo10    foo3     foo5     foo7     foo9
foo1     foo2     foo4     foo6     foo8
# md5sum -c MD5SUMS 
foo1: OK
foo10: OK
foo2: OK
foo3: OK
foo4: OK
foo5: OK
foo6: OK
foo7: OK
foo8: OK
foo9: OK

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

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

[Enric Balletbo Serra]

Hi,

CCing Pekon Gupta <pekon@ti.com>

2013/12/2 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>:
> Dear Javier Martinez Canillas,
>
> On Sun, 1 Dec 2013 13:27:25 +0100, Javier Martinez Canillas wrote:
>
>> > diff --git a/arch/arm/boot/dts/omap3-igep0020.dts b/arch/arm/boot/dts/omap3-igep0020.dts
>> > index d5cc792..4229e94 100644
>> > --- a/arch/arm/boot/dts/omap3-igep0020.dts
>> > +++ b/arch/arm/boot/dts/omap3-igep0020.dts
>> > @@ -116,7 +116,7 @@
>> >                 linux,mtd-name= "micron,mt29c4g96maz";
>> >                 reg = <0 0 0>;
>> >                 nand-bus-width = <16>;
>> > -               ti,nand-ecc-opt = "bch8";
>> > +               ti,nand-ecc-opt = "ham1";
>> >
>> >                 gpmc,sync-clk-ps = <0>;
>> >                 gpmc,cs-on-ns = <0>;
>> > diff --git a/arch/arm/boot/dts/omap3-igep0030.dts b/arch/arm/boot/dts/omap3-igep0030.dts
>> > index 525e6d9..9043e97 100644
>> > --- a/arch/arm/boot/dts/omap3-igep0030.dts
>> > +++ b/arch/arm/boot/dts/omap3-igep0030.dts
>> > @@ -59,7 +59,7 @@
>> >                 linux,mtd-name= "micron,mt29c4g96maz";
>> >                 reg = <0 0 0>;
>> >                 nand-bus-width = <16>;
>> > -               ti,nand-ecc-opt = "bch8";
>> > +               ti,nand-ecc-opt = "ham1";
>
> Tested this with 3.13-rc1, and it somewhat works, but causes some ECC
> error messages:
>
> # mount -t jffs2 /dev/mtdblock3 /mnt/
> [   10.423736] jffs2: CLEANMARKER node found at 0x00000000 has totlen 0xc != normal 0x0
> [   10.444671] jffs2: CLEANMARKER node found at 0x00020000 has totlen 0xc != normal 0x0
> [   10.472290] jffs2: mtd->read(0x100 bytes from 0x40000) returned ECC error
> [   10.480743] jffs2: mtd->read(0x100 bytes from 0x60000) returned ECC error
> [   10.489013] jffs2: mtd->read(0x100 bytes from 0x80000) returned ECC error
> [   10.497283] jffs2: mtd->read(0x100 bytes from 0xa0000) returned ECC error
> [   10.505126] jffs2: mtd->read(0x100 bytes from 0xc0000) returned ECC error
> [   10.513458] jffs2: mtd->read(0x100 bytes from 0xe0000) returned ECC error
> [   10.521667] jffs2: mtd->read(0x100 bytes from 0x100000) returned ECC error
> [   10.529968] jffs2: mtd->read(0x100 bytes from 0x120000) returned ECC error
> [   10.538269] jffs2: mtd->read(0x100 bytes from 0x140000) returned ECC error
> [   10.546295] jffs2: mtd->read(0x100 bytes from 0x160000) returned ECC error
> [   10.554534] jffs2: mtd->read(0x100 bytes from 0x180000) returned ECC error
> [   10.563323] jffs2: mtd->read(0x100 bytes from 0x1a0000) returned ECC error
> [   10.571685] jffs2: mtd->read(0x100 bytes from 0x1c0000) returned ECC error
> [   10.579986] jffs2: mtd->read(0x100 bytes from 0x1e0000) returned ECC error
> [   10.588287] jffs2: mtd->read(0x100 bytes from 0x200000) returned ECC error
> [   10.596313] jffs2: mtd->read(0x100 bytes from 0x220000) returned ECC error
> [   10.604522] jffs2: mtd->read(0x100 bytes from 0x240000) returned ECC error
> [   10.613037] jffs2: mtd->read(0x100 bytes from 0x260000) returned ECC error
> [   10.621307] jffs2: mtd->read(0x100 bytes from 0x280000) returned ECC error
> [   10.629608] jffs2: mtd->read(0x100 bytes from 0x2a0000) returned ECC error
> [   10.637908] jffs2: mtd->read(0x100 bytes from 0x2c0000) returned ECC error
> [   10.645843] jffs2: mtd->read(0x100 bytes from 0x2e0000) returned ECC error
> [   10.654113] jffs2: notice: (851) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found.
> #
> #
> # cd /mnt/
> # ls
> MD5SUMS  foo10    foo3     foo5     foo7     foo9
> foo1     foo2     foo4     foo6     foo8
> # md5sum -c MD5SUMS
> foo1: OK
> foo10: OK
> foo2: OK
> foo3: OK
> foo4: OK
> foo5: OK
> foo6: OK
> foo7: OK
> foo8: OK
> foo9: OK
>
> This is with a JFFS2 image flashed after doing "nandecc sw" in U-Boot.
>
>> Just a note that this binding property got renamed for v3.13 on
>>
>> commit c66d039197e42af8867e5d0d9b904daf0fb9e6bc
>> Author: Pekon Gupta <pekon@ti.com>
>> Date:   Thu Oct 24 18:20:18 2013 +0530
>>
>>     mtd: nand: omap: combine different flavours of 1-bit hamming ecc schemes
>>
>> so users using current v3.12 kernel or older should use
>>
>> ti,nand-ecc-opt = "sw";
>>
>> instead.
>
> However, this works perfectly fine, with the same JFFS2 image, flashed
> in the same way in U-Boot:
>

Pekon, the old ti,nand-ecc-opt = "sw" should be replaced by
ti,nand-ecc-opt = "ham1" ? Should be the same ? In that case, why this
different behavior ?


> # mount -t jffs2 /dev/mtdblock3 /mnt/
> [   19.789306] jffs2: CLEANMARKER node found at 0x00000000 has totlen 0xc != normal 0x0
> [   19.810455] jffs2: CLEANMARKER node found at 0x00020000 has totlen 0xc != normal 0x0
> [   19.850860] jffs2: notice: (802) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found.
> # cd /mnt/
> # ls
> MD5SUMS  foo10    foo3     foo5     foo7     foo9
> foo1     foo2     foo4     foo6     foo8
> # md5sum -c MD5SUMS
> foo1: OK
> foo10: OK
> foo2: OK
> foo3: OK
> foo4: OK
> foo5: OK
> foo6: OK
> foo7: OK
> foo8: OK
> foo9: OK
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com

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

[Gupta, Pekon]

Hi, 

>From: Enric Balletbo Serra [mailto:eballetbo@gmail.com]
>CCing Pekon Gupta <pekon@ti.com>
>
>>2013/12/2 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>:
>>> Dear Javier Martinez Canillas,
>>
>>> > On Sun, 1 Dec 2013 13:27:25 +0100, Javier Martinez Canillas wrote:
>>
>>> > diff --git a/arch/arm/boot/dts/omap3-igep0020.dts b/arch/arm/boot/dts/omap3-igep0020.dts
>>> > index d5cc792..4229e94 100644
>>> > --- a/arch/arm/boot/dts/omap3-igep0020.dts
>>> > +++ b/arch/arm/boot/dts/omap3-igep0020.dts
>>> > @@ -116,7 +116,7 @@
>>> >                 linux,mtd-name= "micron,mt29c4g96maz";
>>> >                 reg = <0 0 0>;
>>> >                 nand-bus-width = <16>;
>>> > -               ti,nand-ecc-opt = "bch8";
>>> > +               ti,nand-ecc-opt = "ham1";
>>> >
A query Why are you going backward from BCH8 to HAM1 ?

HAM1 is just kept for legacy reasons, it's not at all recommended for new
development. As some field results have shown that devices with
HAM1 become un-usable very soon and start reporting uncorrectable errors
because HAM1 can only handle single bit-flip, which is inadequate in field
conditions and large page device wears-n-tears. (especially considering
your device density is of order of 4Gb - mt29c4g96maz).

Also, just to inform that BCH8_SW ecc-scheme is implemented in such
a way that *only* error correction is handled using s/w library (lib/bch.c).
Rest all ECC calculation is handled using GPMC hardware.
So, the CPU penalty will be seen only when there are bit-flips found
during Read access, which are of rare conditions, occurring only few times
in multi-megabit transfers.

Also, On top of that ecc-schemes implementations have been optimized.
And the patch-series is under review on mainline kernel.
http://lists.infradead.org/pipermail/linux-mtd/2013-November/thread.html

(Apologies for long suggestion, but in summary please don't use HAM1
for any new development. And with BCH8_SW you should see better
bit-flip handling (longer device life) with no hit in performance).

[...]

>Pekon, the old ti,nand-ecc-opt = "sw" should be replaced by
>ti,nand-ecc-opt = "ham1" ? Should be the same ? In that case, why this
>different behavior ?
>
In addition, please use "HAM1" ecc-scheme on mainline u-boot also to flash.
(following patches were accepted by domain maintainer 'Scott Woods').
http://lists.denx.de/pipermail/u-boot/2013-November/167548.html
So, Kernel "ham1" and u-boot "ham1" should be in sync..


Once above is clean, you may like to pull another set of patches below
(these are kernel equivalent of driver optimization for u-boot driver)
 http://lists.denx.de/pipermail/u-boot/2013-November/167445.html


Also, for JFFS2, please erase the flash using -j option.
'-j' option adds a clean marker to erased blocks.


with regards, pekon

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

[Thomas Petazzoni]

Dear Gupta, Pekon,

On Mon, 2 Dec 2013 14:56:09 +0000, Gupta, Pekon wrote:

> A query Why are you going backward from BCH8 to HAM1 ?
> 
> HAM1 is just kept for legacy reasons, it's not at all recommended for new
> development. As some field results have shown that devices with
> HAM1 become un-usable very soon and start reporting uncorrectable errors
> because HAM1 can only handle single bit-flip, which is inadequate in field
> conditions and large page device wears-n-tears. (especially considering
> your device density is of order of 4Gb - mt29c4g96maz).
> 
> Also, just to inform that BCH8_SW ecc-scheme is implemented in such
> a way that *only* error correction is handled using s/w library (lib/bch.c).
> Rest all ECC calculation is handled using GPMC hardware.
> So, the CPU penalty will be seen only when there are bit-flips found
> during Read access, which are of rare conditions, occurring only few times
> in multi-megabit transfers.
> 
> Also, On top of that ecc-schemes implementations have been optimized.
> And the patch-series is under review on mainline kernel.
> http://lists.infradead.org/pipermail/linux-mtd/2013-November/thread.html
> 
> (Apologies for long suggestion, but in summary please don't use HAM1
> for any new development. And with BCH8_SW you should see better
> bit-flip handling (longer device life) with no hit in performance).

The crucial point here is that the interaction between the bootloader
and the kernel. The use case I have is that I'm flashing a filesystem
image from the bootloader, and mounting it from the kernel.

Using a mainline 2013.10 U-Boot for IGEPv2 + the mainline kernel booted
in legacy mode (no Device Tree) works fine. Using the same 2013.10
U-Boot for IGEPv2 + the mainline kernel booted in DT no longer works,
because the kernel disagrees with the bootloader on the ECC scheme to
use.

So I'm not saying that Hamming is better than BCH, certainly not. I'm
just saying that changing ECC scheme in the kernel without looking at
the more global picture of what support the bootloaders are offering is
not nice. At least, the bootloader should provide a command, or option,
to be able to use an ECC scheme that is compatible with what the kernel
expects.

The current result is that booting a mainline kernel with DT on
existing bootloaders simply breaks existing configurations.

> >Pekon, the old ti,nand-ecc-opt = "sw" should be replaced by
> >ti,nand-ecc-opt = "ham1" ? Should be the same ? In that case, why this
> >different behavior ?
> >
> In addition, please use "HAM1" ecc-scheme on mainline u-boot also to flash.
> (following patches were accepted by domain maintainer 'Scott Woods').
> http://lists.denx.de/pipermail/u-boot/2013-November/167548.html
> So, Kernel "ham1" and u-boot "ham1" should be in sync..
> 
> Once above is clean, you may like to pull another set of patches below
> (these are kernel equivalent of driver optimization for u-boot driver)
>  http://lists.denx.de/pipermail/u-boot/2013-November/167445.html
> 
> Also, for JFFS2, please erase the flash using -j option.
> '-j' option adds a clean marker to erased blocks.

As said, I'm erasing/flashing from U-Boot, so flash_eraseall options
are not really useful here :)

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

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

[Gupta, Pekon]

>From: Thomas Petazzoni [mailto:thomas.petazzoni@free-electrons.com]
>>On Mon, 2 Dec 2013 14:56:09 +0000, Gupta, Pekon wrote:
>
>> A query Why are you going backward from BCH8 to HAM1 ?
>>
>> HAM1 is just kept for legacy reasons, it's not at all recommended for new
>> development. As some field results have shown that devices with
>> HAM1 become un-usable very soon and start reporting uncorrectable errors
>> because HAM1 can only handle single bit-flip, which is inadequate in field
>> conditions and large page device wears-n-tears. (especially considering
>> your device density is of order of 4Gb - mt29c4g96maz).
>>
>> Also, just to inform that BCH8_SW ecc-scheme is implemented in such
>> a way that *only* error correction is handled using s/w library (lib/bch.c).
>> Rest all ECC calculation is handled using GPMC hardware.
>> So, the CPU penalty will be seen only when there are bit-flips found
>> during Read access, which are of rare conditions, occurring only few times
>> in multi-megabit transfers.
>>
>> Also, On top of that ecc-schemes implementations have been optimized.
>> And the patch-series is under review on mainline kernel.
>> http://lists.infradead.org/pipermail/linux-mtd/2013-November/thread.html
>>
>> (Apologies for long suggestion, but in summary please don't use HAM1
>> for any new development. And with BCH8_SW you should see better
>> bit-flip handling (longer device life) with no hit in performance).
>
>The crucial point here is that the interaction between the bootloader
>and the kernel. The use case I have is that I'm flashing a filesystem
>image from the bootloader, and mounting it from the kernel.
>
>Using a mainline 2013.10 U-Boot for IGEPv2 + the mainline kernel booted
>in legacy mode (no Device Tree) works fine. Using the same 2013.10
>U-Boot for IGEPv2 + the mainline kernel booted in DT no longer works,
>because the kernel disagrees with the bootloader on the ECC scheme to
>use.
>
>So I'm not saying that Hamming is better than BCH, certainly not. I'm
>just saying that changing ECC scheme in the kernel without looking at
>the more global picture of what support the bootloaders are offering is
>not nice. At least, the bootloader should provide a command, or option,
>to be able to use an ECC scheme that is compatible with what the kernel
>expects.
>
Yes, there is a way to change ecc-scheme in u-boot..
Also, you can modify to any ecc-scheme in u-boot using
"CONFIG_NAND_OMAP_ECCSCHEME" as documented in doc/README.nand

Also your board should boot seamlessly from mainline u-boot in sync
with mainline kernel. As per my knowledge following patch is already
in mainline u-boot. And touches your board as well. (omap3_igep00x0.h)
http://lists.denx.de/pipermail/u-boot/2013-November/167550.html

AFAIK these patches should be in u-boot mainline.

Though I have taken at-most care that no existing board should break.
But, I'm sorry if there is something broken in between the u-boot and
Kernel builds. Let me know if I can help in fixing that somehow.


with regards, pekon

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

[Enric Balletbo Serra]

Hi all,

2013/12/2 Gupta, Pekon <pekon@ti.com>:
>>From: Thomas Petazzoni [mailto:thomas.petazzoni@free-electrons.com]
>>>On Mon, 2 Dec 2013 14:56:09 +0000, Gupta, Pekon wrote:
>>
>>> A query Why are you going backward from BCH8 to HAM1 ?
>>>
>>> HAM1 is just kept for legacy reasons, it's not at all recommended for new
>>> development. As some field results have shown that devices with
>>> HAM1 become un-usable very soon and start reporting uncorrectable errors
>>> because HAM1 can only handle single bit-flip, which is inadequate in field
>>> conditions and large page device wears-n-tears. (especially considering
>>> your device density is of order of 4Gb - mt29c4g96maz).
>>>
>>> Also, just to inform that BCH8_SW ecc-scheme is implemented in such
>>> a way that *only* error correction is handled using s/w library (lib/bch.c).
>>> Rest all ECC calculation is handled using GPMC hardware.
>>> So, the CPU penalty will be seen only when there are bit-flips found
>>> during Read access, which are of rare conditions, occurring only few times
>>> in multi-megabit transfers.
>>>
>>> Also, On top of that ecc-schemes implementations have been optimized.
>>> And the patch-series is under review on mainline kernel.
>>> http://lists.infradead.org/pipermail/linux-mtd/2013-November/thread.html
>>>
>>> (Apologies for long suggestion, but in summary please don't use HAM1
>>> for any new development. And with BCH8_SW you should see better
>>> bit-flip handling (longer device life) with no hit in performance).
>>
>>The crucial point here is that the interaction between the bootloader
>>and the kernel. The use case I have is that I'm flashing a filesystem
>>image from the bootloader, and mounting it from the kernel.
>>
>>Using a mainline 2013.10 U-Boot for IGEPv2 + the mainline kernel booted
>>in legacy mode (no Device Tree) works fine. Using the same 2013.10
>>U-Boot for IGEPv2 + the mainline kernel booted in DT no longer works,
>>because the kernel disagrees with the bootloader on the ECC scheme to
>>use.
>>
>>So I'm not saying that Hamming is better than BCH, certainly not. I'm
>>just saying that changing ECC scheme in the kernel without looking at
>>the more global picture of what support the bootloaders are offering is
>>not nice. At least, the bootloader should provide a command, or option,
>>to be able to use an ECC scheme that is compatible with what the kernel
>>expects.
>>
> Yes, there is a way to change ecc-scheme in u-boot..
> Also, you can modify to any ecc-scheme in u-boot using
> "CONFIG_NAND_OMAP_ECCSCHEME" as documented in doc/README.nand
>
> Also your board should boot seamlessly from mainline u-boot in sync
> with mainline kernel. As per my knowledge following patch is already
> in mainline u-boot. And touches your board as well. (omap3_igep00x0.h)
> http://lists.denx.de/pipermail/u-boot/2013-November/167550.html
>
> AFAIK these patches should be in u-boot mainline.
>
> Though I have taken at-most care that no existing board should break.
> But, I'm sorry if there is something broken in between the u-boot and
> Kernel builds. Let me know if I can help in fixing that somehow.
>
>
> with regards, pekon

Thanks for the explanations to all.

Although the new ECC schema breaks the compatibility between the board
files and new DT based kernel, I think we should use BCH8 scheme.
Sorry, because I had not realized that this was configurable in
u-boot, so I think, if Thomas is also agree, the better fix in that
case is change CONFIG_NAND_OMAP_ECCSCHEME to
OMAP_ECC_BCH8_CODE_HW_DETECTION_SW in u-boot. If this works we can
discard this patch.

Best regards,
   Enric

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

[Thomas Petazzoni]

Dear Enric Balletbo Serra,

On Mon, 2 Dec 2013 16:39:09 +0100, Enric Balletbo Serra wrote:

> Thanks for the explanations to all.
> 
> Although the new ECC schema breaks the compatibility between the board
> files and new DT based kernel, I think we should use BCH8 scheme.
> Sorry, because I had not realized that this was configurable in
> u-boot, so I think, if Thomas is also agree, the better fix in that
> case is change CONFIG_NAND_OMAP_ECCSCHEME to
> OMAP_ECC_BCH8_CODE_HW_DETECTION_SW in u-boot. If this works we can
> discard this patch.

I theoretically don't have anything against that, but if I do this
change in U-Boot, and then use U-Boot to reflash to NAND the SPL and
U-Boot itself, will the OMAP ROM code still be able to read the SPL
from NAND ? I'm not sure which ECC scheme does the OMAP ROM code
support, and how it detects (or not) which ECC scheme to use to read
the SPL.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

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

[Tom Rini]

On 12/02/2013 10:51 AM, Thomas Petazzoni wrote:
> Dear Enric Balletbo Serra,
> 
> On Mon, 2 Dec 2013 16:39:09 +0100, Enric Balletbo Serra wrote:
> 
>> Thanks for the explanations to all.
>>
>> Although the new ECC schema breaks the compatibility between the board
>> files and new DT based kernel, I think we should use BCH8 scheme.
>> Sorry, because I had not realized that this was configurable in
>> u-boot, so I think, if Thomas is also agree, the better fix in that
>> case is change CONFIG_NAND_OMAP_ECCSCHEME to
>> OMAP_ECC_BCH8_CODE_HW_DETECTION_SW in u-boot. If this works we can
>> discard this patch.
> 
> I theoretically don't have anything against that, but if I do this
> change in U-Boot, and then use U-Boot to reflash to NAND the SPL and
> U-Boot itself, will the OMAP ROM code still be able to read the SPL
> from NAND ? I'm not sure which ECC scheme does the OMAP ROM code
> support, and how it detects (or not) which ECC scheme to use to read
> the SPL.

Yes, this brings us back to one of the old and long-standing problems.
The ROM on these devices will generally speak one format and that means
using NAND chips that say for the first block (or N blocks or whatever)
you only need 1bit ECC but for the rest 4/8/16/whatever.  And then
informing the kernel (and anything else) that "partitions" N need this
format and the rest need that.

-- 
Tom

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

[Thomas Petazzoni]

Dear Tom Rini,

On Mon, 2 Dec 2013 11:00:35 -0500, Tom Rini wrote:

> >> Although the new ECC schema breaks the compatibility between the board
> >> files and new DT based kernel, I think we should use BCH8 scheme.
> >> Sorry, because I had not realized that this was configurable in
> >> u-boot, so I think, if Thomas is also agree, the better fix in that
> >> case is change CONFIG_NAND_OMAP_ECCSCHEME to
> >> OMAP_ECC_BCH8_CODE_HW_DETECTION_SW in u-boot. If this works we can
> >> discard this patch.
> > 
> > I theoretically don't have anything against that, but if I do this
> > change in U-Boot, and then use U-Boot to reflash to NAND the SPL and
> > U-Boot itself, will the OMAP ROM code still be able to read the SPL
> > from NAND ? I'm not sure which ECC scheme does the OMAP ROM code
> > support, and how it detects (or not) which ECC scheme to use to read
> > the SPL.
> 
> Yes, this brings us back to one of the old and long-standing problems.
> The ROM on these devices will generally speak one format and that means
> using NAND chips that say for the first block (or N blocks or whatever)
> you only need 1bit ECC but for the rest 4/8/16/whatever.  And then
> informing the kernel (and anything else) that "partitions" N need this
> format and the rest need that.

As long as U-Boot provides separate commands, or a "nandecc" command
that allows to switch between ECC scheme, and select the ECC scheme
expected by the ROM code when flashing the SPL, and then the ECC scheme
expected by the SPL and the kernel to flash U-Boot itself, the kernel
image, and the various filesystem images, then it's all fine, we can
leave with different ECC schemes used for different things on the NAND
flash.

Of course, ideally, we should also be able to tell the kernel about the
ECC scheme on a per-partition basis.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

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

[Gupta, Pekon]

>From: Thomas Petazzoni [mailto:thomas.petazzoni@free-electrons.com]
> >On Mon, 2 Dec 2013 11:00:35 -0500, Tom Rini wrote:
>
>> >> Although the new ECC schema breaks the compatibility between the board
>> >> files and new DT based kernel, I think we should use BCH8 scheme.
>> >> Sorry, because I had not realized that this was configurable in
>> >> u-boot, so I think, if Thomas is also agree, the better fix in that
>> >> case is change CONFIG_NAND_OMAP_ECCSCHEME to
>> >> OMAP_ECC_BCH8_CODE_HW_DETECTION_SW in u-boot. If this works we can
>> >> discard this patch.
>> >
>> > I theoretically don't have anything against that, but if I do this
>> > change in U-Boot, and then use U-Boot to reflash to NAND the SPL and
>> > U-Boot itself, will the OMAP ROM code still be able to read the SPL
>> > from NAND ? I'm not sure which ECC scheme does the OMAP ROM code
>> > support, and how it detects (or not) which ECC scheme to use to read
>> > the SPL.
>>
>> Yes, this brings us back to one of the old and long-standing problems.
>> The ROM on these devices will generally speak one format and that means
>> using NAND chips that say for the first block (or N blocks or whatever)
>> you only need 1bit ECC but for the rest 4/8/16/whatever.  And then
>> informing the kernel (and anything else) that "partitions" N need this
>> format and the rest need that.
>
>As long as U-Boot provides separate commands, or a "nandecc" command
>that allows to switch between ECC scheme, and select the ECC scheme
>expected by the ROM code when flashing the SPL, and then the ECC scheme
>expected by the SPL and the kernel to flash U-Boot itself, the kernel
>image, and the various filesystem images, then it's all fine, we can
>leave with different ECC schemes used for different things on the NAND
>flash.
>
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'.

But for all these, images need to be flashed from u-boot. As kernel
cannot switch ecc-schemes on-the-fly.

with regards, pekon

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

[Thomas Petazzoni]

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?

> But for all these, images need to be flashed from u-boot. As kernel
> cannot switch ecc-schemes on-the-fly.

Which as I was saying, is a bit of shame. There is technically nothing
that makes the ECC scheme something that needs to be applied globally
on the entire flash. And we see real practical cases where being able
to specify a different ECC scheme per partition would make sense: when
the ROM code uses a weaker ECC scheme than the one used for most other
partitions.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

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

[Gupta, Pekon]

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

[...]

>> But for all these, images need to be flashed from u-boot. As kernel
>> cannot switch ecc-schemes on-the-fly.
>
>Which as I was saying, is a bit of shame. There is technically nothing
>that makes the ECC scheme something that needs to be applied globally
>on the entire flash.

No, I don't think that kernel needs to ever dynamically switch ecc-schemes.
This feature should be limited only to u-boot (or bootloaders) because:

(1) Adding support for dynamic switching of ecc-schemes will require all
  code to be compiled in driver which increases the kernel  driver footprint.
  (example adding BCH8_SW means you need to compile in lib/bch.c)

(2) Also selection of ecc-scheme mainly depends on NAND device parameter
     (like density, page-size, oobsize) which remain constant for a device
    (all NAND partitions). Thus all partitions should use *same* ecc-scheme
    preferable highest possible available with NAND device & kernel.

(3) Kernel uses same driver instance to handle all MTD partitions, so if one
   partition uses HAM1 while other uses BCH8, and both are simultaneously
   mounted, then it would be difficult for driver to switch ecc-schemes while
  doing interleaved Read/Write between the partitions.
  (though it can be added in framework, but then it's too much over-head).

In my opinion, kernel driver should be free from all over-heads, And should
be *as lite as possible, while continuing to be strong in catching bit-flips.*
Because there are lot of file-system layers over it, to handle more severe
failures. 
Example: even if you use HAM1 and report un-correctable errors, still
UBIFS has too much redundancy of critical metadata, that it can still
recover your volume.
Therefore, I preferred having ecc-scheme selectable via DT (static) for
kernel. However these are purely my opinions based on my assessments.


> And we see real practical cases where being able
>to specify a different ECC scheme per partition would make sense: when
>the ROM code uses a weaker ECC scheme than the one used for most other
>partitions.
>
This constrain of changing ecc-scheme has come because ROM code
ecc-scheme is hardened to select HAM1. And so u-boot (bootloaders)
is used to between bridge gaps between ROM code and kernel.
- This could have been avoided, if u-boot still supported 'nandecc'  OR
- ROM code had mechanism to change its ecc-scheme based on some
   Boot-mode setting (sysboot pins on board).


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.


with regards, pekon

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

[Michael Trimarchi]

Hi Pekon

On Mon, Dec 2, 2013 at 6:05 PM, Gupta, Pekon <pekon@ti.com> 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.
>
> [...]
>
>>> But for all these, images need to be flashed from u-boot. As kernel
>>> cannot switch ecc-schemes on-the-fly.
>>
>>Which as I was saying, is a bit of shame. There is technically nothing
>>that makes the ECC scheme something that needs to be applied globally
>>on the entire flash.
>
> No, I don't think that kernel needs to ever dynamically switch ecc-schemes.
> This feature should be limited only to u-boot (or bootloaders) because:
>

I don't think so. There are cpu that can be boot only using some ecc scheme
but for a lot of reason you should require to have for the filesystem
a different ecc scheme

> (1) Adding support for dynamic switching of ecc-schemes will require all
>   code to be compiled in driver which increases the kernel  driver footprint.
>   (example adding BCH8_SW means you need to compile in lib/bch.c)
>

It depends on the system that you are using and sometime increase the
kernel size is less important that guarantee system consistency

> (2) Also selection of ecc-scheme mainly depends on NAND device parameter
>      (like density, page-size, oobsize) which remain constant for a device
>     (all NAND partitions). Thus all partitions should use *same* ecc-scheme
>     preferable highest possible available with NAND device & kernel.
>

same as above. It can be a limitation on the bootrom

> (3) Kernel uses same driver instance to handle all MTD partitions, so if one
>    partition uses HAM1 while other uses BCH8, and both are simultaneously
>    mounted, then it would be difficult for driver to switch ecc-schemes while
>   doing interleaved Read/Write between the partitions.
>   (though it can be added in framework, but then it's too much over-head).
>

agree

Michael

> In my opinion, kernel driver should be free from all over-heads, And should
> be *as lite as possible, while continuing to be strong in catching bit-flips.*
> Because there are lot of file-system layers over it, to handle more severe
> failures.
> Example: even if you use HAM1 and report un-correctable errors, still
> UBIFS has too much redundancy of critical metadata, that it can still
> recover your volume.
> Therefore, I preferred having ecc-scheme selectable via DT (static) for
> kernel. However these are purely my opinions based on my assessments.
>
>
>> And we see real practical cases where being able
>>to specify a different ECC scheme per partition would make sense: when
>>the ROM code uses a weaker ECC scheme than the one used for most other
>>partitions.
>>
> This constrain of changing ecc-scheme has come because ROM code
> ecc-scheme is hardened to select HAM1. And so u-boot (bootloaders)
> is used to between bridge gaps between ROM code and kernel.
> - This could have been avoided, if u-boot still supported 'nandecc'  OR
> - ROM code had mechanism to change its ecc-scheme based on some
>    Boot-mode setting (sysboot pins on board).
>
>
> 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.
>
>
> with regards, pekon
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Gupta, Pekon]

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

Hope this helps ..

with regards, pekon

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

[Tom Rini]

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

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

[Tom Rini]

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

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

[Scott Wood]

On Mon, 2013-12-02 at 17:05 +0000, Gupta, Pekon wrote:
> (2) Also selection of ecc-scheme mainly depends on NAND device parameter
>      (like density, page-size, oobsize) which remain constant for a device
>     (all NAND partitions). Thus all partitions should use *same* ecc-scheme
>     preferable highest possible available with NAND device & kernel.

It was pointed out earlier in the thread that there are chips for which
it is not constant throughout the device (i.e. the boot block is
special, presumably implemented differently in hardware).

> (3) Kernel uses same driver instance to handle all MTD partitions, so if one
>    partition uses HAM1 while other uses BCH8, and both are simultaneously
>    mounted, then it would be difficult for driver to switch ecc-schemes while
>   doing interleaved Read/Write between the partitions.
>   (though it can be added in framework, but then it's too much over-head).

Don't think of it as switching back and forth for every access, but
rather having dynamic dispatch to the proper code for any given access.

I'm not sure that partitions are the right place to implement this, as
they're a higher level abstraction.  If the NAND chip says that 1-bit
correction is good enough for certain blocks but not others, then that's
chip-level information that the driver ought to know about independently
of partitioning.  OTOH, that doesn't provide the ability to manage
compatibility with entities that use stronger correction than is needed
(or different ways of achieving the same level of correction), but it
could be a simpler way to solve the basic problem of boot blocks being
special.

-Scott

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

[Tom Rini]

On 12/02/2013 11:13 AM, Gupta, Pekon wrote:
>> From: Thomas Petazzoni [mailto:thomas.petazzoni@free-electrons.com]
>>> On Mon, 2 Dec 2013 11:00:35 -0500, Tom Rini wrote:
>>
>>>>> Although the new ECC schema breaks the compatibility between the board
>>>>> files and new DT based kernel, I think we should use BCH8 scheme.
>>>>> Sorry, because I had not realized that this was configurable in
>>>>> u-boot, so I think, if Thomas is also agree, the better fix in that
>>>>> case is change CONFIG_NAND_OMAP_ECCSCHEME to
>>>>> OMAP_ECC_BCH8_CODE_HW_DETECTION_SW in u-boot. If this works we can
>>>>> discard this patch.
>>>>
>>>> I theoretically don't have anything against that, but if I do this
>>>> change in U-Boot, and then use U-Boot to reflash to NAND the SPL and
>>>> U-Boot itself, will the OMAP ROM code still be able to read the SPL
>>>> from NAND ? I'm not sure which ECC scheme does the OMAP ROM code
>>>> support, and how it detects (or not) which ECC scheme to use to read
>>>> the SPL.
>>>
>>> Yes, this brings us back to one of the old and long-standing problems.
>>> The ROM on these devices will generally speak one format and that means
>>> using NAND chips that say for the first block (or N blocks or whatever)
>>> you only need 1bit ECC but for the rest 4/8/16/whatever.  And then
>>> informing the kernel (and anything else) that "partitions" N need this
>>> format and the rest need that.
>>
>> As long as U-Boot provides separate commands, or a "nandecc" command
>> that allows to switch between ECC scheme, and select the ECC scheme
>> expected by the ROM code when flashing the SPL, and then the ECC scheme
>> expected by the SPL and the kernel to flash U-Boot itself, the kernel
>> image, and the various filesystem images, then it's all fine, we can
>> leave with different ECC schemes used for different things on the NAND
>> flash.
>>
> 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'.

Right, on OMAP3 (and related) we have the issue of ROM only doing 1bit
ECC, but being used with parts that require more, so what I said above
is important.  OMAP4/am335x/later ship with ROM that groks at least
BCH16.  With my U-Boot hat on, I really don't want to encourage people
to come up with designs that require on the fly switching because..

> But for all these, images need to be flashed from u-boot. As kernel
> cannot switch ecc-schemes on-the-fly.

Exactly.  The kernel hasn't, and I get the feeling won't, support this
case of needing different ECC schemes for different areas of the NAND,
so we'll continue to be in the position of the Linux for flashing
everything but bootloader or custom hacks to the kernel.

-- 
Tom

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

[Javier Martinez Canillas]

Hi Pekon,

On Mon, Dec 2, 2013 at 5:13 PM, Gupta, Pekon <pekon@ti.com> wrote:
>>From: Thomas Petazzoni [mailto:thomas.petazzoni@free-electrons.com]
>> >On Mon, 2 Dec 2013 11:00:35 -0500, Tom Rini wrote:
>>
>>> >> Although the new ECC schema breaks the compatibility between the board
>>> >> files and new DT based kernel, I think we should use BCH8 scheme.
>>> >> Sorry, because I had not realized that this was configurable in
>>> >> u-boot, so I think, if Thomas is also agree, the better fix in that
>>> >> case is change CONFIG_NAND_OMAP_ECCSCHEME to
>>> >> OMAP_ECC_BCH8_CODE_HW_DETECTION_SW in u-boot. If this works we can
>>> >> discard this patch.
>>> >
>>> > I theoretically don't have anything against that, but if I do this
>>> > change in U-Boot, and then use U-Boot to reflash to NAND the SPL and
>>> > U-Boot itself, will the OMAP ROM code still be able to read the SPL
>>> > from NAND ? I'm not sure which ECC scheme does the OMAP ROM code
>>> > support, and how it detects (or not) which ECC scheme to use to read
>>> > the SPL.
>>>
>>> Yes, this brings us back to one of the old and long-standing problems.
>>> The ROM on these devices will generally speak one format and that means
>>> using NAND chips that say for the first block (or N blocks or whatever)
>>> you only need 1bit ECC but for the rest 4/8/16/whatever.  And then
>>> informing the kernel (and anything else) that "partitions" N need this
>>> format and the rest need that.
>>
>>As long as U-Boot provides separate commands, or a "nandecc" command
>>that allows to switch between ECC scheme, and select the ECC scheme
>>expected by the ROM code when flashing the SPL, and then the ECC scheme
>>expected by the SPL and the kernel to flash U-Boot itself, the kernel
>>image, and the various filesystem images, then it's all fine, we can
>>leave with different ECC schemes used for different things on the NAND
>>flash.
>>

Yes, we used nandecc to write data on different mtd partitions for SPL
(nandecc hw) and the rootfs (nandecc hw bch8).

> 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()
>

Why nandecc is being deprecated from u-boot? How are you supposed to
use a different ECC scheme then?

By the way, a couple of years ago we wrote a small user-space utility
to write the SPL from Linux when a different ECC scheme than the 1-bit
hamming understand by the Boot ROM is used.

The writeloader [0] utility access the NAND mtd partition as raw and
manually writes the ECC in the OOB using the MTD_MODE_RAW and
MEMWRITEOOB ioctls.

> So with minor hacks, you should be able to bring-back 'nandecc'.
>
> But for all these, images need to be flashed from u-boot. As kernel
> cannot switch ecc-schemes on-the-fly.
>
> with regards, pekon

Best regards,
Javier

[0]: http://git.isee.biz/?p=pub/scm/writeloader.git

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

[Tom Rini]

On 12/02/2013 11:21 AM, Javier Martinez Canillas wrote:
> Hi Pekon,
> 
> On Mon, Dec 2, 2013 at 5:13 PM, Gupta, Pekon <pekon@ti.com> wrote:
>>> From: Thomas Petazzoni [mailto:thomas.petazzoni@free-electrons.com]
>>>> On Mon, 2 Dec 2013 11:00:35 -0500, Tom Rini wrote:
>>>
>>>>>> Although the new ECC schema breaks the compatibility between the board
>>>>>> files and new DT based kernel, I think we should use BCH8 scheme.
>>>>>> Sorry, because I had not realized that this was configurable in
>>>>>> u-boot, so I think, if Thomas is also agree, the better fix in that
>>>>>> case is change CONFIG_NAND_OMAP_ECCSCHEME to
>>>>>> OMAP_ECC_BCH8_CODE_HW_DETECTION_SW in u-boot. If this works we can
>>>>>> discard this patch.
>>>>>
>>>>> I theoretically don't have anything against that, but if I do this
>>>>> change in U-Boot, and then use U-Boot to reflash to NAND the SPL and
>>>>> U-Boot itself, will the OMAP ROM code still be able to read the SPL
>>>>> from NAND ? I'm not sure which ECC scheme does the OMAP ROM code
>>>>> support, and how it detects (or not) which ECC scheme to use to read
>>>>> the SPL.
>>>>
>>>> Yes, this brings us back to one of the old and long-standing problems.
>>>> The ROM on these devices will generally speak one format and that means
>>>> using NAND chips that say for the first block (or N blocks or whatever)
>>>> you only need 1bit ECC but for the rest 4/8/16/whatever.  And then
>>>> informing the kernel (and anything else) that "partitions" N need this
>>>> format and the rest need that.
>>>
>>> As long as U-Boot provides separate commands, or a "nandecc" command
>>> that allows to switch between ECC scheme, and select the ECC scheme
>>> expected by the ROM code when flashing the SPL, and then the ECC scheme
>>> expected by the SPL and the kernel to flash U-Boot itself, the kernel
>>> image, and the various filesystem images, then it's all fine, we can
>>> leave with different ECC schemes used for different things on the NAND
>>> flash.
>>>
> 
> Yes, we used nandecc to write data on different mtd partitions for SPL
> (nandecc hw) and the rootfs (nandecc hw bch8).
> 
>> 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()
>>
> 
> Why nandecc is being deprecated from u-boot? How are you supposed to
> use a different ECC scheme then?

We (I) had killed off all of the mainline users of the nandecc command,
once everyone was using the same 1bit scheme layout.  None of the people
that had mixed HAM1/BCH4 at the time wanted to work upstream on it.

-- 
Tom

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

[Javier Martinez Canillas]

On Mon, Dec 2, 2013 at 5:24 PM, Tom Rini <trini@ti.com> wrote:
> On 12/02/2013 11:21 AM, Javier Martinez Canillas wrote:
>> Hi Pekon,
>>
>> On Mon, Dec 2, 2013 at 5:13 PM, Gupta, Pekon <pekon@ti.com> wrote:
>>>> From: Thomas Petazzoni [mailto:thomas.petazzoni@free-electrons.com]
>>>>> On Mon, 2 Dec 2013 11:00:35 -0500, Tom Rini wrote:
>>>>
>>>>>>> Although the new ECC schema breaks the compatibility between the board
>>>>>>> files and new DT based kernel, I think we should use BCH8 scheme.
>>>>>>> Sorry, because I had not realized that this was configurable in
>>>>>>> u-boot, so I think, if Thomas is also agree, the better fix in that
>>>>>>> case is change CONFIG_NAND_OMAP_ECCSCHEME to
>>>>>>> OMAP_ECC_BCH8_CODE_HW_DETECTION_SW in u-boot. If this works we can
>>>>>>> discard this patch.
>>>>>>
>>>>>> I theoretically don't have anything against that, but if I do this
>>>>>> change in U-Boot, and then use U-Boot to reflash to NAND the SPL and
>>>>>> U-Boot itself, will the OMAP ROM code still be able to read the SPL
>>>>>> from NAND ? I'm not sure which ECC scheme does the OMAP ROM code
>>>>>> support, and how it detects (or not) which ECC scheme to use to read
>>>>>> the SPL.
>>>>>
>>>>> Yes, this brings us back to one of the old and long-standing problems.
>>>>> The ROM on these devices will generally speak one format and that means
>>>>> using NAND chips that say for the first block (or N blocks or whatever)
>>>>> you only need 1bit ECC but for the rest 4/8/16/whatever.  And then
>>>>> informing the kernel (and anything else) that "partitions" N need this
>>>>> format and the rest need that.
>>>>
>>>> As long as U-Boot provides separate commands, or a "nandecc" command
>>>> that allows to switch between ECC scheme, and select the ECC scheme
>>>> expected by the ROM code when flashing the SPL, and then the ECC scheme
>>>> expected by the SPL and the kernel to flash U-Boot itself, the kernel
>>>> image, and the various filesystem images, then it's all fine, we can
>>>> leave with different ECC schemes used for different things on the NAND
>>>> flash.
>>>>
>>
>> Yes, we used nandecc to write data on different mtd partitions for SPL
>> (nandecc hw) and the rootfs (nandecc hw bch8).
>>
>>> 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()
>>>
>>
>> Why nandecc is being deprecated from u-boot? How are you supposed to
>> use a different ECC scheme then?
>
> We (I) had killed off all of the mainline users of the nandecc command,
> once everyone was using the same 1bit scheme layout.  None of the people
> that had mixed HAM1/BCH4 at the time wanted to work upstream on it.

I see, so.. what's the solution then :-)

We can push Enric's patch and change to HAM1 in the kernel so Thomas
(and others) can write everything from U-boot (SPL, rootfs, etc) but I
think is safer to use BCH8 since the NAND requires at least a 4-bit
ECC.

But doing that we can no longer write the SPL from neither U-Boot nor
the kernel. Yes, this can be made from user-space using ISEE's
writeloader utility and afair there is one from TI too written in C#
but this is not very convenient for users.

I believe Thomas is right and the correct approach is to change the
OMAP NAND and GPMC drivers to support a per MTD partition ECC scheme
but we need a temporal solution until someone implements this.

>
> --
> Tom

Thanks a lot and best regards,
Javier

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

[Tom Rini]

On 12/02/2013 11:46 AM, Javier Martinez Canillas wrote:
> On Mon, Dec 2, 2013 at 5:24 PM, Tom Rini <trini@ti.com> wrote:
>> On 12/02/2013 11:21 AM, Javier Martinez Canillas wrote:
>>> Hi Pekon,
>>>
>>> On Mon, Dec 2, 2013 at 5:13 PM, Gupta, Pekon <pekon@ti.com> wrote:
>>>>> From: Thomas Petazzoni [mailto:thomas.petazzoni@free-electrons.com]
>>>>>> On Mon, 2 Dec 2013 11:00:35 -0500, Tom Rini wrote:
>>>>>
>>>>>>>> Although the new ECC schema breaks the compatibility between the board
>>>>>>>> files and new DT based kernel, I think we should use BCH8 scheme.
>>>>>>>> Sorry, because I had not realized that this was configurable in
>>>>>>>> u-boot, so I think, if Thomas is also agree, the better fix in that
>>>>>>>> case is change CONFIG_NAND_OMAP_ECCSCHEME to
>>>>>>>> OMAP_ECC_BCH8_CODE_HW_DETECTION_SW in u-boot. If this works we can
>>>>>>>> discard this patch.
>>>>>>>
>>>>>>> I theoretically don't have anything against that, but if I do this
>>>>>>> change in U-Boot, and then use U-Boot to reflash to NAND the SPL and
>>>>>>> U-Boot itself, will the OMAP ROM code still be able to read the SPL
>>>>>>> from NAND ? I'm not sure which ECC scheme does the OMAP ROM code
>>>>>>> support, and how it detects (or not) which ECC scheme to use to read
>>>>>>> the SPL.
>>>>>>
>>>>>> Yes, this brings us back to one of the old and long-standing problems.
>>>>>> The ROM on these devices will generally speak one format and that means
>>>>>> using NAND chips that say for the first block (or N blocks or whatever)
>>>>>> you only need 1bit ECC but for the rest 4/8/16/whatever.  And then
>>>>>> informing the kernel (and anything else) that "partitions" N need this
>>>>>> format and the rest need that.
>>>>>
>>>>> As long as U-Boot provides separate commands, or a "nandecc" command
>>>>> that allows to switch between ECC scheme, and select the ECC scheme
>>>>> expected by the ROM code when flashing the SPL, and then the ECC scheme
>>>>> expected by the SPL and the kernel to flash U-Boot itself, the kernel
>>>>> image, and the various filesystem images, then it's all fine, we can
>>>>> leave with different ECC schemes used for different things on the NAND
>>>>> flash.
>>>>>
>>>
>>> Yes, we used nandecc to write data on different mtd partitions for SPL
>>> (nandecc hw) and the rootfs (nandecc hw bch8).
>>>
>>>> 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()
>>>>
>>>
>>> Why nandecc is being deprecated from u-boot? How are you supposed to
>>> use a different ECC scheme then?
>>
>> We (I) had killed off all of the mainline users of the nandecc command,
>> once everyone was using the same 1bit scheme layout.  None of the people
>> that had mixed HAM1/BCH4 at the time wanted to work upstream on it.
> 
> I see, so.. what's the solution then :-)
> 
> We can push Enric's patch and change to HAM1 in the kernel so Thomas
> (and others) can write everything from U-boot (SPL, rootfs, etc) but I
> think is safer to use BCH8 since the NAND requires at least a 4-bit
> ECC.

We _need_ to bring this back in U-Boot (so please just link to this
thread somewhere in the patch that brings the command back), for
omap3/etc at least.

> But doing that we can no longer write the SPL from neither U-Boot nor
> the kernel. Yes, this can be made from user-space using ISEE's
> writeloader utility and afair there is one from TI too written in C#
> but this is not very convenient for users.
> 
> I believe Thomas is right and the correct approach is to change the
> OMAP NAND and GPMC drivers to support a per MTD partition ECC scheme
> but we need a temporal solution until someone implements this.

I would argue that yes, Linux should also support on the fly ECC schemes
per partition (with some sort of default too, so you can say "everything
is BCH_X except ..").  But I'm not one of the people that needs to be
convinced of this, and I assume there was a thread about this problem
from before, so someone should dig it up and avoid / address the
problems from before, or at least try and re-start the discussion and
see if people have changed there mind as the problem is here again, and
if we ignore it again will show up again in 5 years when we need BCH16
on the bootloader part, but BCH64 on the rest of the block.

-- 
Tom