[PATCH] omap3_beagle: Change NAND ECC scheme back to OMAP_ECC_HAM1_CODE_HW

Derald D. Woods woods.technical at gmail.com
Sun Dec 22 15:24:14 CET 2019


On Sun, Dec 22, 2019 at 09:10:50AM -0500, Tom Rini wrote:
> On Sun, Dec 22, 2019 at 09:46:27AM +0100, Patrik Dahlstrom wrote:
> > On 12/22/19 4:24 AM, Derald D. Woods wrote:
> > > On Sat, Dec 21, 2019 at 05:18:22PM +0100, Patrik Dahlström wrote:
> > >> The omap3_beagle NAND ECC scheme was changed in 4b37928d357 for unknown
> > >> reasons, leading to uncorrectible ecc errors. This commit changes it
> > >> back to what it was before.
> > >>
> > > 
> > > Hello Patrick,
> > > 
> > > Is there a setup/test that you are using for OMAP_ECC_HAM1_CODE_HW? I
> > > just want to give it a try. I have three OMAP3 boards, with NAND, that
> > > I would like to test.
> > 
> > I'm using a BeagleBoard rev. C4 (yes, the one that came out in 2009)
> > for testing.
> > 
> > > 
> > > I also see that the SYS_NAND_ECC_BYTES should have been changed to '14'
> > > per the 'doc/README.nand' for OMAP_ECC_BCH8_CODE_HW_DETECTION_SW. This
> > > may be the issue with this particular ECC scheme.
> > > 
> > I based my changes on reverting 4b37928d357, which did this:
> > 
> > <snip>
> >  +#define CONFIG_NAND_OMAP_ECCSCHEME      OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
> > <snip>
> >  -#define CONFIG_NAND_OMAP_ECCSCHEME     OMAP_ECC_HAM1_CODE_HW
> > <snip>
> > 
> > Based on your comment, I tested this configuration:
> > 
> >  #define CONFIG_SYS_NAND_ECCBYTES        14
> >  #define CONFIG_NAND_OMAP_ECCSCHEME      OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
> > 
> > It worked to boot from SD card (only had to do saveenv), but only
> > partly from NAND:
> > 
> >  U-Boot SPL 2020.01-rc5-00006-gda26dd89c8-dirty (Dec 22 2019 - 09:26:14 +0100)
> >  Trying to boot from NAND
> > 
> > Then it just hangs. Here's how I flashed SPL and U-Boot:
> > 
> >  mmc rescan
> >  fatload mmc 0 80000000 MLO
> >  nand erase 0 80000
> >  nandecc hw
> >  cp.b 80000000 80020000 20000
> >  cp.b 80000000 80040000 20000
> >  cp.b 80000000 80060000 20000
> >  nand write 80000000 0 80000
> >  fatload mmc 0 80000000 u-boot.img
> >  nand erase 80000 160000
> >  nand write 80000000 80000 160000
> > 
> > I then tried adjusting the "nandecc hw" line, but here's how that went:
> > 
> >  BeagleBoard # nandecc hw bch8
> >  nand: error: CONFIG_NAND_OMAP_ELM required for ECC
> > 
> > Unfortunately CONFIG_NAND_OMAP_ELM is not available for OMAP34XX.
> 
> Yeah, ugh, I'm sorry I didn't catch this at the time (my Beagleboard is
> old and I worry about killing the NAND but I guess I need to move it to
> manual testing a few releases a year).  For the beagleboard I believe
> the right answer is to move back to the ECC scheme that it was before as
> that's what's deployed and used by anyone that's using the boards.  If
> memory serves there is a way to switch to doing SW and BCH8 but that's
> not going to be a win for these boards both for speed and for the
> incompatibility.
> 

Tom,

Are you going to modify the remaining affected OMAP34XX boards? Or will this
patchset be expanded?

Derald


More information about the U-Boot mailing list