* [PATCH] omap3_beagle: Change NAND ECC scheme back to OMAP_ECC_HAM1_CODE_HW @ 2019-12-21 16:18 Patrik Dahlström 2019-12-22 3:24 ` Derald D. Woods 2019-12-28 4:30 ` Tom Rini 0 siblings, 2 replies; 13+ messages in thread From: Patrik Dahlström @ 2019-12-21 16:18 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply related [flat|nested] 13+ messages in thread
* [PATCH] omap3_beagle: Change NAND ECC scheme back to OMAP_ECC_HAM1_CODE_HW 2019-12-21 16:18 [PATCH] omap3_beagle: Change NAND ECC scheme back to OMAP_ECC_HAM1_CODE_HW Patrik Dahlström @ 2019-12-22 3:24 ` Derald D. Woods 2019-12-22 8:46 ` Patrik Dahlstrom 2019-12-28 4:30 ` Tom Rini 1 sibling, 1 reply; 13+ messages in thread From: Derald D. Woods @ 2019-12-22 3:24 UTC (permalink / raw) To: u-boot 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 > ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH] omap3_beagle: Change NAND ECC scheme back to OMAP_ECC_HAM1_CODE_HW 2019-12-22 3:24 ` Derald D. Woods @ 2019-12-22 8:46 ` Patrik Dahlstrom 2019-12-22 14:10 ` Tom Rini 0 siblings, 1 reply; 13+ messages in thread From: Patrik Dahlstrom @ 2019-12-22 8:46 UTC (permalink / raw) To: u-boot 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 >> ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH] omap3_beagle: Change NAND ECC scheme back to OMAP_ECC_HAM1_CODE_HW 2019-12-22 8:46 ` Patrik Dahlstrom @ 2019-12-22 14:10 ` Tom Rini 2019-12-22 14:24 ` Derald D. Woods 0 siblings, 1 reply; 13+ messages in thread From: Tom Rini @ 2019-12-22 14:10 UTC (permalink / raw) To: u-boot 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> ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH] omap3_beagle: Change NAND ECC scheme back to OMAP_ECC_HAM1_CODE_HW 2019-12-22 14:10 ` Tom Rini @ 2019-12-22 14:24 ` Derald D. Woods 2019-12-22 14:28 ` Tom Rini 0 siblings, 1 reply; 13+ messages in thread From: Derald D. Woods @ 2019-12-22 14:24 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH] omap3_beagle: Change NAND ECC scheme back to OMAP_ECC_HAM1_CODE_HW 2019-12-22 14:24 ` Derald D. Woods @ 2019-12-22 14:28 ` Tom Rini 2019-12-22 14:48 ` Adam Ford 0 siblings, 1 reply; 13+ messages in thread From: Tom Rini @ 2019-12-22 14:28 UTC (permalink / raw) To: u-boot 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> ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH] omap3_beagle: Change NAND ECC scheme back to OMAP_ECC_HAM1_CODE_HW 2019-12-22 14:28 ` Tom Rini @ 2019-12-22 14:48 ` Adam Ford 2019-12-26 17:59 ` Patrik Dahlstrom 0 siblings, 1 reply; 13+ messages in thread From: Adam Ford @ 2019-12-22 14:48 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH] omap3_beagle: Change NAND ECC scheme back to OMAP_ECC_HAM1_CODE_HW 2019-12-22 14:48 ` Adam Ford @ 2019-12-26 17:59 ` Patrik Dahlstrom 2019-12-26 20:57 ` Adam Ford 0 siblings, 1 reply; 13+ messages in thread From: Patrik Dahlstrom @ 2019-12-26 17:59 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH] omap3_beagle: Change NAND ECC scheme back to OMAP_ECC_HAM1_CODE_HW 2019-12-26 17:59 ` Patrik Dahlstrom @ 2019-12-26 20:57 ` Adam Ford 2019-12-26 21:22 ` Derald D. Woods 0 siblings, 1 reply; 13+ messages in thread From: Adam Ford @ 2019-12-26 20:57 UTC (permalink / raw) To: u-boot 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 > ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH] omap3_beagle: Change NAND ECC scheme back to OMAP_ECC_HAM1_CODE_HW 2019-12-26 20:57 ` Adam Ford @ 2019-12-26 21:22 ` Derald D. Woods 2019-12-26 21:24 ` Patrik Dahlstrom 0 siblings, 1 reply; 13+ messages in thread From: Derald D. Woods @ 2019-12-26 21:22 UTC (permalink / raw) To: u-boot 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 > > ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH] omap3_beagle: Change NAND ECC scheme back to OMAP_ECC_HAM1_CODE_HW 2019-12-26 21:22 ` Derald D. Woods @ 2019-12-26 21:24 ` Patrik Dahlstrom 2019-12-27 1:23 ` Derald D. Woods 0 siblings, 1 reply; 13+ messages in thread From: Patrik Dahlstrom @ 2019-12-26 21:24 UTC (permalink / raw) To: u-boot 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 >>> ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH] omap3_beagle: Change NAND ECC scheme back to OMAP_ECC_HAM1_CODE_HW 2019-12-26 21:24 ` Patrik Dahlstrom @ 2019-12-27 1:23 ` Derald D. Woods 0 siblings, 0 replies; 13+ messages in thread From: Derald D. Woods @ 2019-12-27 1:23 UTC (permalink / raw) To: u-boot 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 > >>> > ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH] omap3_beagle: Change NAND ECC scheme back to OMAP_ECC_HAM1_CODE_HW 2019-12-21 16:18 [PATCH] omap3_beagle: Change NAND ECC scheme back to OMAP_ECC_HAM1_CODE_HW Patrik Dahlström 2019-12-22 3:24 ` Derald D. Woods @ 2019-12-28 4:30 ` Tom Rini 1 sibling, 0 replies; 13+ messages in thread From: Tom Rini @ 2019-12-28 4:30 UTC (permalink / raw) To: u-boot 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> ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2019-12-28 4:30 UTC | newest] Thread overview: 13+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2019-12-21 16:18 [PATCH] omap3_beagle: Change NAND ECC scheme back to OMAP_ECC_HAM1_CODE_HW Patrik Dahlström 2019-12-22 3:24 ` Derald D. Woods 2019-12-22 8:46 ` Patrik Dahlstrom 2019-12-22 14:10 ` Tom Rini 2019-12-22 14:24 ` Derald D. Woods 2019-12-22 14:28 ` Tom Rini 2019-12-22 14:48 ` Adam Ford 2019-12-26 17:59 ` Patrik Dahlstrom 2019-12-26 20:57 ` Adam Ford 2019-12-26 21:22 ` Derald D. Woods 2019-12-26 21:24 ` Patrik Dahlstrom 2019-12-27 1:23 ` Derald D. Woods 2019-12-28 4:30 ` Tom Rini
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.