[PATCH] omap3_beagle: Change NAND ECC scheme back to OMAP_ECC_HAM1_CODE_HW
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
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
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
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.
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
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 :)
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
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
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
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
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:
Derald
adam
adam
-- Tom
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:
Derald
adam
adam
-- Tom
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!
participants (5)
-
Adam Ford -
Derald D. Woods -
Patrik Dahlstrom -
Patrik Dahlström
-
Tom Rini