[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 at 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