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

Thu Dec 26 22:24:24 CET 2019

On 12/26/19 10:22 PM, Derald D. Woods wrote:
> 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.
Could it be related to my other patch?
serial: ns16550: Use old baud rate divisor for flushing if not given

Without it, SPL will hang during boot.
> 
> 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
>>>