[U-Boot] NAND write error with HW ECC on OMAP3

[U-Boot] NAND write error with HW ECC on OMAP3

[Ash Charles]

Hi,

When using 'nandecc hw' on an OMAP3 platform, data is not being
correctly written to NAND.  I see the issue on 2013.10-rc2 and 2013.07
but not on 2012.10.  Specifically, when I read back a SPL binary
written with hardware Hamming ECC, I don't get a matching CRC.  With
the BCH8 ECC algorithm, the CRC is correct (but SPL must be written
with Hamming otherwise the board doesn't boot)

I've shown my steps here: http://pastebin.com/tLZsr9zH
The expected CRC is 46745188.

Any suggestions/ideas much appreciated!

--Ash

[U-Boot] NAND write error with HW ECC on OMAP3

[Andreas Bießmann]

Dear Ash Charles,

On 09/03/2013 09:34 PM, Ash Charles wrote:
> Hi,
> 
> When using 'nandecc hw' on an OMAP3 platform, data is not being
> correctly written to NAND.  I see the issue on 2013.10-rc2 and 2013.07
> but not on 2012.10.  Specifically, when I read back a SPL binary
> written with hardware Hamming ECC, I don't get a matching CRC.  With
> the BCH8 ECC algorithm, the CRC is correct (but SPL must be written
> with Hamming otherwise the board doesn't boot)
> 
> I've shown my steps here: http://pastebin.com/tLZsr9zH
> The expected CRC is 46745188.
> 
> Any suggestions/ideas much appreciated!

I'd swear this worked when I changed the command to use BCH ... I'll
check it again today.

Best regards

Andreas Bie?mann

[U-Boot] NAND write error with HW ECC on OMAP3

[Andreas Bießmann]

Dear Ash Charles,

On 09/04/2013 09:35 AM, Andreas Bie?mann wrote:
> Dear Ash Charles,
> 
> On 09/03/2013 09:34 PM, Ash Charles wrote:
>> Hi,
>>
>> When using 'nandecc hw' on an OMAP3 platform, data is not being
>> correctly written to NAND.  I see the issue on 2013.10-rc2 and 2013.07
>> but not on 2012.10.  Specifically, when I read back a SPL binary
>> written with hardware Hamming ECC, I don't get a matching CRC.  With
>> the BCH8 ECC algorithm, the CRC is correct (but SPL must be written
>> with Hamming otherwise the board doesn't boot)
>>
>> I've shown my steps here: http://pastebin.com/tLZsr9zH
>> The expected CRC is 46745188.
>>
>> Any suggestions/ideas much appreciated!
> 
> I'd swear this worked when I changed the command to use BCH ... I'll
> check it again today.

I can't confirm your complaints. Here it works (at least on tricorder,
which utilizes BCH for U-Boot section in SPL):

---8<---
U-Boot SPL 2013.10-rc2-00014-g2d5878e (Sep 04 2013 - 10:39:57)
reading u-boot.img
reading u-boot.img


U-Boot 2013.10-rc2-00014-g2d5878e (Sep 04 2013 - 10:39:57)

OMAP36XX/37XX-GP ES1.2, CPU-OPP2, L3-200MHz, Max CPU Clock 1 Ghz
OMAP3 Tricorder + LPDDR/NAND
I2C:   ready
DRAM:  128 MiB
NAND:  512 MiB
MMC:   OMAP SD/MMC: 0
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Board : serial
Die ID #246000029e38000001683b060102002d
Hit any key to stop autoboot:  0
OMAP3 Tricorder # fatload mmc 0 ${loadaddr} MLO
reading MLO
55052 bytes read in 11 ms (4.8 MiB/s)
OMAP3 Tricorder # nandecc hw
1-bit hamming HW ECC selected
OMAP3 Tricorder # nand erase.part SPL

NAND erase.part: device 0 offset 0x0, size 0x20000
Erasing@0x0 -- 100% complete.
OK
OMAP3 Tricorder # crc32 ${loadaddr} ${filesize}
CRC32 for 82000000 ... 8200d70b ==> b182f0a2
OMAP3 Tricorder # nand write ${loadaddr} SPL ${filesize}

NAND write: device 0 offset 0x0, size 0xd70c
 55052 bytes written: OK
OMAP3 Tricorder # nand read 0x80000000 SPL ${filesize}

NAND read: device 0 offset 0x0, size 0xd70c
 55052 bytes read: OK
OMAP3 Tricorder # crc32 0x80000000 ${filesize}
CRC32 for 80000000 ... 8000d70b ==> b182f0a2
OMAP3 Tricorder #
--->8---

The 14 patches on top of -rc2 are just local board changes (will be sent
soon):

---8<---
2d5878e (HEAD, tricorder-TOT) tricorder: fixup for led.c
c3806ea tricorder: read kernel directly from NAND
c158ec1 tricorder: switch to alternative memtest
9bcc57b tricorder: Make u-boot faster
441857b tricorder: add led support
b8bb65a tricorder: panic() on unknown board
8c5e0a8 tricorder: add tricordereeprom command
4c86cad tricorder: add mtdparts to environment
3ac9838 tricorder: add cmdline history
7fe344d tricorder: move commonargs to common settings
3bd1a05 tricorder: add configuration for a flashcard u-boot
d2578c5 tricorder: use generic provided loadaddr
649f8dc tricorder: update flash partitioning
e34c01a tricorder: remove lcdmode from bootargs
fb18fa9 (tag: v2013.10-rc2, origin/master, origin/HEAD, cs/master)
Prepare v2013.10-rc2
--->8---

Best regards

Andreas Bie?mann

[U-Boot] NAND write error with HW ECC on OMAP3

[Ash Charles]

On Wed, Sep 4, 2013 at 1:54 AM, Andreas Bie?mann
<andreas.devel@googlemail.com> wrote:
> I can't confirm your complaints. Here it works (at least on tricorder,
> which utilizes BCH for U-Boot section in SPL):
Hi Andreas,

Thanks for your response---this was very helpful.  When I boot my
board using the tricorder board file, it flashes nand correctly.
Likewise, I moved over some of the NAND configuration from
include/configs/tricorder.h to include/configs/omap3_overo.h and,
after a little rearranging to enlarge SPL, it also flashed NAND
correctly.

So...any guesses what it is about setting these variables that gets
NAND flashing to work properly?

+#define CONFIG_NAND_OMAP_BCH8
+#define CONFIG_BCH
-#define CONFIG_SYS_NAND_ECCPOS         {2, 3, 4, 5, 6, 7, 8, 9,\
-                                               10, 11, 12, 13}
+#define CONFIG_SYS_NAND_ECCPOS         {12, 13, 14, 15, 16, 17, 18, 19, 20, \
+                        21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33,\
+                        34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46,\
+                        47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59,\
+                        60, 61, 62, 63}
-#define CONFIG_SYS_NAND_ECCBYTES       3
+#define CONFIG_SYS_NAND_ECCBYTES       13

--Ash

[U-Boot] NAND write error with HW ECC on OMAP3

[Ash Charles]

Hi,

I did a little bit more work with git bisect and found an issue on
commit c788ecfdc3eb577757ffc1bfb8416added07ef33 "nand: Move the
sub-page read support enable to a flag".

Making this change on top of v2013.07 allowed me to again write to
NAND correctly.

-#define NAND_HAS_SUBPAGE_READ(chip) ((chip->options & NAND_SUBPAGE_READ))
+#define NAND_HAS_SUBPAGE_READ(chip) ((chip->ecc.mode == NAND_ECC_SOFT) \
+                                       && (chip->page_shift > 9))

Like some other OMAP3 platforms, my platform uses 1-bit hardware ECC
for the first NAND partition and software ECC elsewhere.  Does this
ecc.mode switch need to be partition specific?

--Ash

On Wed, Sep 4, 2013 at 11:00 AM, Ash Charles <ashcharles@gmail.com> wrote:
> On Wed, Sep 4, 2013 at 1:54 AM, Andreas Bie?mann
> <andreas.devel@googlemail.com> wrote:
>> I can't confirm your complaints. Here it works (at least on tricorder,
>> which utilizes BCH for U-Boot section in SPL):
> Hi Andreas,
>
> Thanks for your response---this was very helpful.  When I boot my
> board using the tricorder board file, it flashes nand correctly.
> Likewise, I moved over some of the NAND configuration from
> include/configs/tricorder.h to include/configs/omap3_overo.h and,
> after a little rearranging to enlarge SPL, it also flashed NAND
> correctly.
>
> So...any guesses what it is about setting these variables that gets
> NAND flashing to work properly?
>
> +#define CONFIG_NAND_OMAP_BCH8
> +#define CONFIG_BCH
> -#define CONFIG_SYS_NAND_ECCPOS         {2, 3, 4, 5, 6, 7, 8, 9,\
> -                                               10, 11, 12, 13}
> +#define CONFIG_SYS_NAND_ECCPOS         {12, 13, 14, 15, 16, 17, 18, 19, 20, \
> +                        21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33,\
> +                        34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46,\
> +                        47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59,\
> +                        60, 61, 62, 63}
> -#define CONFIG_SYS_NAND_ECCBYTES       3
> +#define CONFIG_SYS_NAND_ECCBYTES       13
>
> --Ash

[U-Boot] NAND write error with HW ECC on OMAP3

[Andreas Bießmann]

Dear Ash Charles,

On 09/05/2013 01:02 AM, Ash Charles wrote:
> Hi,
> 
> I did a little bit more work with git bisect and found an issue on
> commit c788ecfdc3eb577757ffc1bfb8416added07ef33 "nand: Move the
> sub-page read support enable to a flag".
> 
> Making this change on top of v2013.07 allowed me to again write to
> NAND correctly.
> 
> -#define NAND_HAS_SUBPAGE_READ(chip) ((chip->options & NAND_SUBPAGE_READ))
> +#define NAND_HAS_SUBPAGE_READ(chip) ((chip->ecc.mode == NAND_ECC_SOFT) \
> +                                       && (chip->page_shift > 9))

this check moved into nand_scan_tail() which is also handled when
calling nandecc from u-boot cmdline, on first sight your change isn't
not necessary. Can you please check if the chip->options is modified
somewhere between the nand_scan_tail() and the place where the
NAND_SUBPAGE_READ flag is checked?

> Like some other OMAP3 platforms, my platform uses 1-bit hardware ECC
> for the first NAND partition and software ECC elsewhere.  Does this
> ecc.mode switch need to be partition specific?

This can not be partition specific by design. The ecc scheme is bound to
an NAND device and therefore we introduced the nandecc command for omap3
(cause ROM code can only handle 1 bit hamming, but today's devices
require sometimes more than 1 bit ecc).

Best regards

Andreas Bie?mann

[U-Boot] NAND write error with HW ECC on OMAP3

[Ash Charles]

Dear Andreas,

Thanks for your responses.

Based on a little more testing, I found this: with 'nandecc hw',
NAND_HAS_SUBPAGE_READ must be false otherwise data is not written
correct to NAND.

My hardware (a Micron flash chip) supports subpage reads and behaves
correctly with 'nandecc sw'.  On boot, chip->ecc.mode == NAND_ECC_SOFT
which sets (correctly for my NAND), the NAND_SUBPAGE_READ option. If I
change the 'nandecc hw', chip->ecc.mode == NAND_ECC_HARD (seems
correct) but NAND_SUBPAGE_READ is still set.

I suspect then that commit c788ecfdc3eb577757ffc1bfb8416added07ef33 is
not to blame.  It just exposes a bug where if 'nandecc hw', subpage
reads don't work properly even if the NAND flash supports it.  Seem
okay?

Thanks again for your help.

--Ash

On Thu, Sep 5, 2013 at 1:57 AM, Andreas Bie?mann
<andreas.devel@googlemail.com> wrote:
> Dear Ash Charles,
>
> On 09/05/2013 01:02 AM, Ash Charles wrote:
>> Hi,
>>
>> I did a little bit more work with git bisect and found an issue on
>> commit c788ecfdc3eb577757ffc1bfb8416added07ef33 "nand: Move the
>> sub-page read support enable to a flag".
>>
>> Making this change on top of v2013.07 allowed me to again write to
>> NAND correctly.
>>
>> -#define NAND_HAS_SUBPAGE_READ(chip) ((chip->options & NAND_SUBPAGE_READ))
>> +#define NAND_HAS_SUBPAGE_READ(chip) ((chip->ecc.mode == NAND_ECC_SOFT) \
>> +                                       && (chip->page_shift > 9))
>
> this check moved into nand_scan_tail() which is also handled when
> calling nandecc from u-boot cmdline, on first sight your change isn't
> not necessary. Can you please check if the chip->options is modified
> somewhere between the nand_scan_tail() and the place where the
> NAND_SUBPAGE_READ flag is checked?
>
>> Like some other OMAP3 platforms, my platform uses 1-bit hardware ECC
>> for the first NAND partition and software ECC elsewhere.  Does this
>> ecc.mode switch need to be partition specific?
>
> This can not be partition specific by design. The ecc scheme is bound to
> an NAND device and therefore we introduced the nandecc command for omap3
> (cause ROM code can only handle 1 bit hamming, but today's devices
> require sometimes more than 1 bit ecc).
>
> Best regards
>
> Andreas Bie?mann

[U-Boot] NAND write error with HW ECC on OMAP3

[Andreas Bießmann]

Dear Ash Charles,

On 09/04/2013 08:00 PM, Ash Charles wrote:
> On Wed, Sep 4, 2013 at 1:54 AM, Andreas Bie?mann
> <andreas.devel@googlemail.com> wrote:
>> I can't confirm your complaints. Here it works (at least on tricorder,
>> which utilizes BCH for U-Boot section in SPL):
> Hi Andreas,
> 
> Thanks for your response---this was very helpful.  When I boot my
> board using the tricorder board file, it flashes nand correctly.
> Likewise, I moved over some of the NAND configuration from
> include/configs/tricorder.h to include/configs/omap3_overo.h and,
> after a little rearranging to enlarge SPL, it also flashed NAND
> correctly.
> 
> So...any guesses what it is about setting these variables that gets
> NAND flashing to work properly?
> 
> +#define CONFIG_NAND_OMAP_BCH8
> +#define CONFIG_BCH
> -#define CONFIG_SYS_NAND_ECCPOS         {2, 3, 4, 5, 6, 7, 8, 9,\
> -                                               10, 11, 12, 13}
> +#define CONFIG_SYS_NAND_ECCPOS         {12, 13, 14, 15, 16, 17, 18, 19, 20, \
> +                        21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33,\
> +                        34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46,\
> +                        47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59,\
> +                        60, 61, 62, 63}
> -#define CONFIG_SYS_NAND_ECCBYTES       3
> +#define CONFIG_SYS_NAND_ECCBYTES       13

these settings are for BCH8! The original settings you replaced are for
so called 'SW hamming' (1 bit ecc with special OOB layout for omap3,
differs from 1 bit ecc mapping used by the omap3 HW calculation in ROM
code).

If you need higher ECC schemes for your NAND, you should update your
setup (u-boot + SPL _and_ linux) to use some BCH codec. BCH4 calculation
seems buggy on some omap3, therefore I used BCH8 here.
Obviously is it a required step, since even SLC need 4 bit ecc nowadays,
some allow just 1 bit for the first sector if only a few erasures occur.

Best regards

Andreas Bie?mann