On Thu, Dec 26, 2019 at 12:02 PM Patrik Dahlstrom <ri...@dalakolonin.se> wrote: > > On 12/22/19 3:48 PM, Adam Ford wrote: > > On Sun, Dec 22, 2019 at 8:28 AM Tom Rini <tr...@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 >