From: Tony Lindgren <tony@atomide.com>
To: Tom Rini <trini@ti.com>
Cc: Roger Quadros <rogerq@ti.com>, pekon <pekon@pek-sem.com>,
computersforpeace@gmail.com, dwmw2@infradead.org,
ezequiel@vanguardiasur.com.ar, linux-mtd@lists.infradead.org,
linux-omap@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] mtd: nand: omap: Fix NAND enumeration on 3430 LDP
Date: Thu, 13 Nov 2014 09:54:14 -0800 [thread overview]
Message-ID: <20141113175414.GP26481@atomide.com> (raw)
In-Reply-To: <5464D5AD.30508@ti.com>
* Tom Rini <trini@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
next prev parent reply other threads:[~2014-11-13 17:54 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-05 11:00 [PATCH] mtd: nand: omap: Fix NAND enumeration on 3430 LDP Roger Quadros
2014-11-06 18:03 ` Tony Lindgren
2014-11-07 9:35 ` Roger Quadros
2014-11-07 9:58 ` Roger Quadros
2014-11-07 22:48 ` Tony Lindgren
2014-11-09 19:29 ` pekon
2014-11-12 18:02 ` Tony Lindgren
2014-11-13 11:29 ` Roger Quadros
2014-11-13 16:00 ` Tom Rini
2014-11-13 17:54 ` Tony Lindgren [this message]
2014-11-15 11:12 ` pekon
2014-11-13 12:00 ` Roger Quadros
2014-11-19 12:22 ` [PATCH v2] " Roger Quadros
2014-11-26 6:47 ` Brian Norris
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141113175414.GP26481@atomide.com \
--to=tony@atomide.com \
--cc=computersforpeace@gmail.com \
--cc=dwmw2@infradead.org \
--cc=ezequiel@vanguardiasur.com.ar \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=pekon@pek-sem.com \
--cc=rogerq@ti.com \
--cc=stable@vger.kernel.org \
--cc=trini@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).