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