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.de...@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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
