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
