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

[Tom Rini]

On Sun, Dec 22, 2019 at 08:24:14AM -0600, Derald D. Woods wrote:
> 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?

Lets add in a few more maintainers.  From memory, there are reasons to
move to BCH8 on omap3 platforms if for example you're moving to newer
NAND chips that in turn require it.  If you want to keep the EVM on
BCH8, that's fine, I don't know much about the overall user base there.
But I do know the Beagleboard one :)

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20191222/6cf59beb/attachment.sig>