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

[Derald D. Woods]

On Thu, Dec 26, 2019 at 02:57:44PM -0600, Adam Ford wrote:
> 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.  :-)
> 

I agree with Adam. At the time, there were efforts to to get boards
updated for DM purposes and Kconfig. I was checking configurations and
build while booting to SD/MMC. My BeagleBoard Rev. C4 is not working at
the moment. It may be dying.

The fix looks good to me. As long as the UBI stuff still works with
HAM1.

Here is an interesting thread from the Linux side of things:

- https://patches.linaro.org/patch/34908


Derald


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