Re: [PATCH] omap3_beagle: Change NAND ECC scheme back to OMAP_ECC_HAM1_CODE_HW
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 >> wrote: >>> >>> On 12/22/19 3:48 PM, Adam Ford wrote: >>>> On Sun, Dec 22, 2019 at 8:28 AM Tom Rini 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: >>>>>>>> >>>>>>>> >>>>>>>> +#define CONFIG_NAND_OMAP_ECCSCHEME >>>>>>>> OMAP_ECC_BCH8_CODE_HW_DETECTION_SW >>>>>>>> >>>>>>>> -#define CONFIG_NAND_OMAP_ECCSCHEME OMAP_ECC_HAM1_CODE_HW >>>>>>>> >>>>>>>> >>>>>>>> Based on your comment, I tested this configuration: >>>>>>>> >>>>>>>> #define CONFIG_SYS_NAND_ECCBYTES14 >>>>>>>> #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-6-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 8000 MLO >>>>>>>> nand erase 0 8 >>>>>>>> nandecc hw >>>>>>>> cp.b 8000 8002 2 >>>>>>>> cp.b 8000 8004 2 >>>>>>>> cp.b 8000 8006 2 >>>>>>>> nand write 8000 0 8 >>>>>>>> fatload mmc 0 8000 u-boot.img >>>>>>>> nand erase 8 16 >>>>>>>> nand write 8000 8 16 >>>>>>>> >>>>>>>> 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 rele
Re: [PATCH] omap3_beagle: Change NAND ECC scheme back to OMAP_ECC_HAM1_CODE_HW
On 12/22/19 3:48 PM, Adam Ford wrote: > On Sun, Dec 22, 2019 at 8:28 AM Tom Rini 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: >>>>> >>>>> >>>>> +#define CONFIG_NAND_OMAP_ECCSCHEME >>>>> OMAP_ECC_BCH8_CODE_HW_DETECTION_SW >>>>> >>>>> -#define CONFIG_NAND_OMAP_ECCSCHEME OMAP_ECC_HAM1_CODE_HW >>>>> >>>>> >>>>> Based on your comment, I tested this configuration: >>>>> >>>>> #define CONFIG_SYS_NAND_ECCBYTES14 >>>>> #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-6-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 8000 MLO >>>>> nand erase 0 8 >>>>> nandecc hw >>>>> cp.b 8000 8002 2 >>>>> cp.b 8000 8004 2 >>>>> cp.b 8000 8006 2 >>>>> nand write 8000 0 8 >>>>> fatload mmc 0 8000 u-boot.img >>>>> nand erase 8 16 >>>>> nand write 8000 8 16 >>>>> >>>>> 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
Re: [PATCH] omap3_beagle: Change NAND ECC scheme back to OMAP_ECC_HAM1_CODE_HW
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: +#define CONFIG_NAND_OMAP_ECCSCHEME OMAP_ECC_BCH8_CODE_HW_DETECTION_SW -#define CONFIG_NAND_OMAP_ECCSCHEME OMAP_ECC_HAM1_CODE_HW Based on your comment, I tested this configuration: #define CONFIG_SYS_NAND_ECCBYTES14 #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-6-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 8000 MLO nand erase 0 8 nandecc hw cp.b 8000 8002 2 cp.b 8000 8004 2 cp.b 8000 8006 2 nand write 8000 0 8 fatload mmc 0 8000 u-boot.img nand erase 8 16 nand write 8000 8 16 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 >> --- >> 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_ECCBYTES3 >> -#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 0x8 >> #define CONFIG_SYS_ENV_SECT_SIZESZ_128K >> #define CONFIG_ENV_OVERWRITE >> -- >> 2.17.1 >>
