From: Grant Edwards <grant.b.edwards@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] handling of bad blocks in nand
Date: Mon, 16 Aug 2010 19:13:34 +0000 (UTC) [thread overview]
Message-ID: <i4c2ku$lbj$1@dough.gmane.org> (raw)
In-Reply-To: 20100816185540.GA1804@schlenkerla.am.freescale.net
On 2010-08-16, Scott Wood <scottwood@freescale.com> wrote:
> On Fri, Aug 13, 2010 at 09:22:21PM +0000, Grant Edwards wrote:
> At one point in the legacy NAND code, a distinction was made when
> reading between completely skipping bad blocks, and filling the
> buffer with zeroes in place of the bad blocks. It looks like
> ".jffs2" or ".e" would get you zeroes, and ".jffs2s" or ".i" would
> get you block skipping.
>
> The zero-fill mode is no longer supported. In 1.3.4, assuming you're
> not using the legacy NAND code, you need to specify one of ".jffs2",
> ".e", or ".i" to get block skipping. It doesn't matter which one.
> In current u-boot these suffixes are accepted and ignored as legacy
> (bad blocks are always skipped), except for "jffs2s" which apparently
> never made an appearance outside the legacy code.
OK, that clears up quite a bit of my confusion.
> Yes, it's a bit of a mess.
It does appear to be improving. :)
>> 3) In the 1.3.4 source code, there are lots of instances where there
>> are boolean flags with names like "jffs2". AFAICT those flags
>> have nothing to do with the JFFS2 filesystem, but simply control
>> whether or not bad flash blocks are skipped during read/write
>> operations. Am I reading the code correctly?
>
> The user interface .jffs2 suffix was to indicate bad block skipping,
> but opts->jffs2 (which is still around) refers to writing JFFS2
> cleanmarkers after erasing a block.
Thanks, that helps.
>> 4) If in a custom command, I want to read/write a large block of
>> data to/from nand flash while skipping bad blocks what functions
>> do I call? Right now I'm doing something like this:
>>
>> nand_info[0].read(nand_info+0, offset, sizeof(buffer), &len, buffer)
>>
>> nand_info[0].write(nand_info+0, offset, bytecount, &len, buffer)
>>
>> but, I have a feeling that's not right (though it seems to work,
>> I suspect it's not going to skip bad blocks).
>
> You suspect correctly.
>
> In current code there is nand_write_skip_bad() and
> nand_read_skip_bad() in drivers/mtd/nand/nand_util.c.
Yup, I found those, and the read version is exactly what I need.
I've still got to figure out how to write.
The problem is that the data to be written is streaming. I don't know
how much there is, and I don't want to allocate arbitrarily large
buffers. So I want to write it one erase-block at a time as it
arrives. AFAICT nand_write_skip_bad() can't be used in that
situation. Since it provides no indication of how many blocks were
skipped, I have no way of knowing where the next block should be
written.
I guess that means I need to use the same lower-level API that is
being used by nand_write_skip_bad().
> In 1.3.4 use nand_read_opts()/nand_write_opts(). Or convince Atmel
> to support something more recent. :-)
It turns out that Atmel's patches have been merged into the main
sources and 2010.6 works fine for the board in question. I don't know
why the official Atmel web-page still instructs you to use
1.3.4+patches.
--
Grant Edwards grant.b.edwards Yow! I'm encased in the
at lining of a pure pork
gmail.com sausage!!
prev parent reply other threads:[~2010-08-16 19:13 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-23 12:40 [U-Boot] handling of bad blocks in nand Arno Steffen
2010-06-23 19:08 ` Scott Wood
2010-06-24 6:28 ` Arno Steffen
2010-06-24 7:44 ` Wolfgang Denk
2010-06-24 15:36 ` Scott Wood
2010-06-25 10:18 ` Arno Steffen
2010-06-25 15:50 ` Scott Wood
2010-06-28 13:35 ` Arno Steffen
2010-07-09 9:12 ` Arno Steffen
2010-07-09 12:56 ` Ben Gardiner
2010-07-09 18:15 ` Scott Wood
2010-08-13 21:22 ` Grant Edwards
2010-08-13 22:17 ` Grant Edwards
2010-08-16 18:55 ` Scott Wood
2010-08-16 19:13 ` Grant Edwards [this message]
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='i4c2ku$lbj$1@dough.gmane.org' \
--to=grant.b.edwards@gmail.com \
--cc=u-boot@lists.denx.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.