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

[Adam Ford]

On Thu, Dec 26, 2019 at 12:02 PM Patrik Dahlstrom <risca at dalakolonin.se> wrote:
>
> On 12/22/19 3:48 PM, Adam Ford wrote:
> > On Sun, Dec 22, 2019 at 8:28 AM Tom Rini <trini at konsulko.com> wrote:
> >>
> >> 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 :)
> >
> > I know the Logic PD Torpedo and SOM LV boards use the BCH8 HW
> > detection with SW Correction because the omap34/35 had a bit with
> > 4-bit and 1-bit wasn't sufficient.  Logic PD has some medical and
> > military users so having the 8-bit is preferred.  I haven't checked
> > lately, but to my knowledge, the Torpedo and SOM-LV boards have been
> > working fine with 8-bit.  I haven't changed them, so unless something
> > happened to the driver, I'd prefer to keep the various omap3_logic
> > boards as 8-bit.
> >
> > I know some of the Micron flash parts have available on-chip ECC, but
> > I haven't tried to use them and I don't know of those drivers are
> > enabled in U-Boot.  That might be an option for some people who want
> > more than 1-bit without the overhead of the software correction on
> > devices without ELM.
> Since this change only affect omap3_beagle it should be safe to apply, right?
> I don't see how it could affect any other board.

I have no objection to changing that board.   I was only commenting on
why I used 8-bit in response to Derald's question about applying this
to all omap34xx.  I would object to that.  :-)

adam
> >
> > adam
> >>
> >> --
> >> Tom
>