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

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

[Patrik Dahlström]

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.

Signed-off-by: Patrik Dahlström <risca@dalakolonin.se>
---
 include/configs/omap3_beagle.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
index 4157d7614f..bc8aa7adf5 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -37,7 +37,7 @@
                                          10, 11, 12, 13}
 #define CONFIG_SYS_NAND_ECCSIZE         512
 #define CONFIG_SYS_NAND_ECCBYTES        3
-#define CONFIG_NAND_OMAP_ECCSCHEME      OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
+#define CONFIG_NAND_OMAP_ECCSCHEME      OMAP_ECC_HAM1_CODE_HW
 #define CONFIG_SYS_NAND_U_BOOT_OFFS     0x80000
 #define CONFIG_SYS_ENV_SECT_SIZE        SZ_128K
 #define CONFIG_ENV_OVERWRITE
-- 
2.17.1

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

[Derald D. Woods]

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 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.

Derald


> Signed-off-by: Patrik Dahlström <risca@dalakolonin.se>
> ---
>  include/configs/omap3_beagle.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
> index 4157d7614f..bc8aa7adf5 100644
> --- a/include/configs/omap3_beagle.h
> +++ b/include/configs/omap3_beagle.h
> @@ -37,7 +37,7 @@
>                                           10, 11, 12, 13}
>  #define CONFIG_SYS_NAND_ECCSIZE         512
>  #define CONFIG_SYS_NAND_ECCBYTES        3
> -#define CONFIG_NAND_OMAP_ECCSCHEME      OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
> +#define CONFIG_NAND_OMAP_ECCSCHEME      OMAP_ECC_HAM1_CODE_HW
>  #define CONFIG_SYS_NAND_U_BOOT_OFFS     0x80000
>  #define CONFIG_SYS_ENV_SECT_SIZE        SZ_128K
>  #define CONFIG_ENV_OVERWRITE
> -- 
> 2.17.1
> 

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

[Patrik Dahlstrom]

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.

> Derald
> 
> 
>> Signed-off-by: Patrik Dahlström <risca@dalakolonin.se>
>> ---
>>  include/configs/omap3_beagle.h | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
>> index 4157d7614f..bc8aa7adf5 100644
>> --- a/include/configs/omap3_beagle.h
>> +++ b/include/configs/omap3_beagle.h
>> @@ -37,7 +37,7 @@
>>                                           10, 11, 12, 13}
>>  #define CONFIG_SYS_NAND_ECCSIZE         512
>>  #define CONFIG_SYS_NAND_ECCBYTES        3
>> -#define CONFIG_NAND_OMAP_ECCSCHEME      OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
>> +#define CONFIG_NAND_OMAP_ECCSCHEME      OMAP_ECC_HAM1_CODE_HW
>>  #define CONFIG_SYS_NAND_U_BOOT_OFFS     0x80000
>>  #define CONFIG_SYS_ENV_SECT_SIZE        SZ_128K
>>  #define CONFIG_ENV_OVERWRITE
>> -- 
>> 2.17.1
>>

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

[Tom Rini]

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
-------------- 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/5efbe0f5/attachment.sig>

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

[Derald D. Woods]

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

[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>

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

[Adam Ford]

On Sun, Dec 22, 2019 at 8:28 AM Tom Rini <trini@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.

adam
>
> --
> Tom

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

[Patrik Dahlstrom]

On 12/22/19 3:48 PM, Adam Ford wrote:
> On Sun, Dec 22, 2019 at 8:28 AM Tom Rini <trini@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.
> 
> adam
>>
>> --
>> Tom

[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@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@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
>

[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@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@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
> >

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

[Patrik Dahlstrom]

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@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@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
>>>

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

[Derald D. Woods]

On Thu, Dec 26, 2019 at 10:24:24PM +0100, Patrik Dahlstrom wrote:
> 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@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@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.

No. My BeagleBoard Rev. C4 boots fine from master with SD/MMC. That much
I usually test with each release. The console boots all the way to Linux
user space. The serial lines, through the 'RS232' header, are not
allowing me to input characters at the moment. I see the full boot
process though. My current build does not include that serial patch.

Derald

> > 
> > 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
> >>>
> 

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

[Tom Rini]

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.
> 
> Signed-off-by: Patrik Dahlström <risca@dalakolonin.se>

Applied to u-boot/master, thanks!

-- 
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/20191227/a30edc69/attachment.sig>