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 <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. :-) >> > > 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 >>>
