[PATCH] mtd: nand: omap: Fix NAND enumeration on 3430 LDP

Tony Lindgren tony at atomide.com
Thu Nov 13 09:54:14 PST 2014


* Tom Rini <trini at ti.com> [141113 08:02]:
> On 11/13/2014 06:29 AM, Roger Quadros wrote:
> > On 11/12/2014 08:02 PM, Tony Lindgren wrote:
> >>
> >> Right no objections to using BCH8 for rootfs, except it stopped working
> >> over past year or so.
> > 
> > This would be BCH8-sw on OMAP3 right? AM3xx uses BCH8-hw and that seems to work fine.
> > So it seems nobody has used/tested BCH8-sw.
> 
> A few years back, and I want to choose my words carefully when talking
> about error correction, BCH8-sw was "working" well enough for rootfs (I
> didn't induce any particular amount of errors or try and cause corner
> cases, etc, etc).

Yes it still works, but for LDP it broke because of the regression
discussed in $thread.
 
> >> And it seems the settings should be partition specific because of u-boot
> >> requiring HAM1.
> >>
> > I don't think we have partition specific ECC scheme support in u-boot or kernel,
> > so it will become messy to manage.
> > That means we either stick with HAM1 for all partitions or don't support NAND boot
> > at all and go with any other ECC scheme for OMAP3.
> 
> This is indeed where life starts getting more complicated than what we
> allow for today in both U-Boot and Kernel, as I recall things anyhow.  I
> think omap3 does (and I know am335x and later do) allow for saying ECC
> is all done on-chip and ROM should do nothing.  But if you want to boot
> you're going to be limited to HAM1 (or in some cases BCH4?  I didn't
> have to deal with these parts myself so second-hand recollections here)
> if you want to _boot_.  So you'll be in that particular area of the part
> life-span where you have to worry about read disturbances and so forth.
> 
> We _really_ do need (in both kernel and U-Boot) the ability to say a
> "partition" has ECC scheme X and another has scheme Y due to limitations
> on what you can boot from vs what you need for the (continued) life span
> of the device in question.

Totally. Updating the bootloader should be doable safely from userspace
after booting the kernel. Or else should disable those partitions for
kernel because people are trashing their u-boot while trying to update.

Regards,

Tony



More information about the linux-mtd mailing list