[U-Boot] handling of bad blocks in nand

[U-Boot] handling of bad blocks in nand

[Arno Steffen]

A short question to handling of bad blocks:
My nand shows a few bad blocks (example 100000)

What is happen when I write / read from that block via nand write / read.
Is content than ok (by mapping good blocks do that address)?

Other way around - if I have commands like

"get_kn=nand read.i 0x80000000 c0000 200000"

do I have to care for bad blocks in that range ?
Di I have to make the part bigger to have some extra blocks, if one is
skipped while write/read as it is bad?

Best regards
Arno

[U-Boot] handling of bad blocks in nand

[Scott Wood]

On Wed, Jun 23, 2010 at 02:40:51PM +0200, Arno Steffen wrote:
> A short question to handling of bad blocks:
> My nand shows a few bad blocks (example 100000)
> 
> What is happen when I write / read from that block via nand write / read.
> Is content than ok (by mapping good blocks do that address)?

Bad blocks are skipped, and all subsequent blocks are shifted out by one.

> Other way around - if I have commands like
> 
> "get_kn=nand read.i 0x80000000 c0000 200000"
> 
> do I have to care for bad blocks in that range ?
> Di I have to make the part bigger to have some extra blocks, if one is
> skipped while write/read as it is bad?

The partition must be at least as large as the number of real data blocks
you want to write, plus the number of bad blocks within that range.

-Scott

[U-Boot] handling of bad blocks in nand

[Arno Steffen]

2010/6/23 Scott Wood <scottwood@freescale.com>:
> On Wed, Jun 23, 2010 at 02:40:51PM +0200, Arno Steffen wrote:
>> A short question to handling of bad blocks:
>> My nand shows a few bad blocks (example 100000)
>>
>> What is happen when I write / read from that block via nand write / read.
>> Is content than ok (by mapping good blocks do that address)?
>
> Bad blocks are skipped, and all subsequent blocks are shifted out by one.
>
>> Other way around - if I have commands like
>>
>> "get_kn=nand read.i 0x80000000 c0000 200000"
>>
>> do I have to care for bad blocks in that range ?
>> Di I have to make the part bigger to have some extra blocks, if one is
>> skipped while write/read as it is bad?
>
> The partition must be at least as large as the number of real data blocks
> you want to write, plus the number of bad blocks within that range.
>
> -Scott
>

Thanks Scott,
does it mean in other words - I don't have to care for the bad block,
can write on the bad block address as it would be ok?

The only thing I have to care is, that I have leave enough space
between the partitions. As for instance : I need 10 blocks for a
certain filesystem, give it 12 ? So it could correct 2 bad blocks in
this range.

Best regards
Arno

[U-Boot] handling of bad blocks in nand

[Wolfgang Denk]

Dear Arno Steffen,

In message <AANLkTiktrnXK-erEMjHh9ALHMOhfJZMr09G57fidAsv1@mail.gmail.com> you wrote:
>
> The only thing I have to care is, that I have leave enough space
> between the partitions. As for instance : I need 10 blocks for a
> certain filesystem, give it 12 ? So it could correct 2 bad blocks in
> this range.

If you are dealing with NAND, and want any sort of reliability, you
want to use UBI.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The existence of god implies a violation of causality.

[U-Boot] handling of bad blocks in nand

[Scott Wood]

On 06/24/2010 01:28 AM, Arno Steffen wrote:
> does it mean in other words - I don't have to care for the bad block,
> can write on the bad block address as it would be ok?

You can't write directly to that block, but it can be included in a 
range of blocks as long as the range is large enough to hold the data 
blocks plus the bad blocks.

> The only thing I have to care is, that I have leave enough space
> between the partitions. As for instance : I need 10 blocks for a
> certain filesystem, give it 12 ? So it could correct 2 bad blocks in
> this range.

Right.

-Scott

[U-Boot] handling of bad blocks in nand

[Arno Steffen]

2010/6/24 Scott Wood <scottwood@freescale.com>:
> On 06/24/2010 01:28 AM, Arno Steffen wrote:
>>
>> does it mean in other words - I don't have to care for the bad block,
>> can write on the bad block address as it would be ok?
>
> You can't write directly to that block, but it can be included in a range of
> blocks as long as the range is large enough to hold the data blocks plus the
> bad blocks.

Mhh. Think we misunderstood each other.
Lets asume block with 0x10.0000 is bad.

I would guess from what you told me before that I could read/write to 0x10.0000.
Of course this is than internally redirected, but from uboot point of
view I hope to
can do

nand write 0x8000.0000 0x10.0000 1000

>
>> The only thing I have to care is, that I have leave enough space
>> between the partitions. As for instance : I need 10 blocks for a
>> certain filesystem, give it 12 ? So it could correct 2 bad blocks in
>> this range.
>
> Right.
>
> -Scott
>

@ Wolfgang:
Ubi is probably better, but I can't start everything from beginning
again. And this is a completly new topic for me.

[U-Boot] handling of bad blocks in nand

[Scott Wood]

On 06/25/2010 05:18 AM, Arno Steffen wrote:
> 2010/6/24 Scott Wood<scottwood@freescale.com>:
>> On 06/24/2010 01:28 AM, Arno Steffen wrote:
>>>
>>> does it mean in other words - I don't have to care for the bad block,
>>> can write on the bad block address as it would be ok?
>>
>> You can't write directly to that block, but it can be included in a range of
>> blocks as long as the range is large enough to hold the data blocks plus the
>> bad blocks.
>
> Mhh. Think we misunderstood each other.
> Lets asume block with 0x10.0000 is bad.
>
> I would guess from what you told me before that I could read/write to 0x10.0000.
> Of course this is than internally redirected, but from uboot point of
> view I hope to
> can do
>
> nand write 0x8000.0000 0x10.0000 1000

It is "redirected" to the next good block after the one you're trying to 
write to.  But it is not fully transparent.  Suppose the block at 
0x100000 is bad, and the next block at 0x120000 is good.

If you do the above command, it will skip the bad block and write to 
0x120000.  But if you then do "nand write 80000000 120000 1000", you 
will overwrite what you previously wrote.

-Scott

[U-Boot] handling of bad blocks in nand

[Arno Steffen]

2010/6/25 Scott Wood <scottwood@freescale.com>:
> On 06/25/2010 05:18 AM, Arno Steffen wrote:
>>
>> 2010/6/24 Scott Wood<scottwood@freescale.com>:
>>>
>>> On 06/24/2010 01:28 AM, Arno Steffen wrote:
>>>>
>>>> does it mean in other words - I don't have to care for the bad block,
>>>> can write on the bad block address as it would be ok?
>>>
>>> You can't write directly to that block, but it can be included in a range
>>> of
>>> blocks as long as the range is large enough to hold the data blocks plus
>>> the
>>> bad blocks.
>>
>> Mhh. Think we misunderstood each other.
>> Lets asume block with 0x10.0000 is bad.
>>
>> I would guess from what you told me before that I could read/write to
>> 0x10.0000.
>> Of course this is than internally redirected, but from uboot point of
>> view I hope to
>> can do
>>
>> nand write 0x8000.0000 0x10.0000 1000
>
> It is "redirected" to the next good block after the one you're trying to
> write to. ?But it is not fully transparent. ?Suppose the block at 0x100000
> is bad, and the next block at 0x120000 is good.
>
> If you do the above command, it will skip the bad block and write to
> 0x120000. ?But if you then do "nand write 80000000 120000 1000", you will
> overwrite what you previously wrote.
>
> -Scott
>

Ok, understood it now. Thanks a  lot.
-Arno

[U-Boot] handling of bad blocks in nand

[Arno Steffen]

Sorry another question to that.

As for instance I want to have 10MB for root partion and keep 2 blocks
extra as reserve for some bad blocks.
I will erase the hole 10MB+2block, write 10MB. That's what I do in uboot.

But in Kernel I have some partition table like this:

    {
        .name           = "root(1)",
        .offset         = MTDPART_OFS_APPEND,
        .size           = 82*(64*2048),        /*10MB + 256k*/
        .mask_flags     = MTD_WRITEABLE /* force read-only */
    },

There are right now the 2 extra blocks inside (but they haven't been
written or formatted).
That is wrong, isn't it? The kernel might now write beyond the 10MB.

I think I have to set size to 80*(62*2048) and append the 2 extra
blocks to the offset in the next Partition to leave this 2 block free.

But I am not sure. So thanks for a quick look and an advice.

[U-Boot] handling of bad blocks in nand

[Ben Gardiner]

On Fri, Jul 9, 2010 at 5:12 AM, Arno Steffen
<arno.steffen@googlemail.com> wrote:
> Sorry another question to that.
>
> As for instance I want to have 10MB for root partion and keep 2 blocks
> extra as reserve for some bad blocks.
> I will erase the hole 10MB+2block, write 10MB. That's what I do in uboot.
>
> But in Kernel I have some partition table like this:
>
> ? ?{
> ? ? ? ?.name ? ? ? ? ? = "root(1)",
> ? ? ? ?.offset ? ? ? ? = MTDPART_OFS_APPEND,
> ? ? ? ?.size ? ? ? ? ? = 82*(64*2048), ? ? ? ?/*10MB + 256k*/
> ? ? ? ?.mask_flags ? ? = MTD_WRITEABLE /* force read-only */
> ? ?},
>
> There are right now the 2 extra blocks inside (but they haven't been
> written or formatted).
> That is wrong, isn't it? The kernel might now write beyond the 10MB.
>
> I think I have to set size to 80*(62*2048) and append the 2 extra
> blocks to the offset in the next Partition to leave this 2 block free.
>
> But I am not sure. So thanks for a quick look and an advice.

I think you are are correct in specifying the total size of your partition.

If you are putting an MTD filesystem in that partition then the
filesystem itself will take care of bad blocks that might occur in the
partition during runtime. During the flash programming of this
filesystem using nand write.jffs2 (or .e) will skip bad blocks that
might occur in the partition.

If you are putting an image (kernel or initrd) into the partition then
the 'nand read.e' and 'nand write.e' (as well as mtd-utils nandwrite)
will handle bad blocks by skipping over them.

Either way, it is best to specify the partition by its total size.

Best Regards,
Ben Gardiner

---
Nanometrics Inc.
+1 (613) 592-6776 x239
http://www.nanometrics.ca

[U-Boot] handling of bad blocks in nand

[Scott Wood]

On Fri, Jul 09, 2010 at 08:56:40AM -0400, Ben Gardiner wrote:
> If you are putting an MTD filesystem in that partition then the
> filesystem itself will take care of bad blocks that might occur in the
> partition during runtime. During the flash programming of this
> filesystem using nand write.jffs2 (or .e) will skip bad blocks that
> might occur in the partition.
> 
> If you are putting an image (kernel or initrd) into the partition then
> the 'nand read.e' and 'nand write.e' (as well as mtd-utils nandwrite)
> will handle bad blocks by skipping over them.

On any recent u-boot, the .jffs2/.e/.i suffixes are maintained for
compatibility only -- bad block skipping is now the default behavior.

-Scott

[U-Boot] handling of bad blocks in nand

[Grant Edwards]

On 2010-07-09, Scott Wood <scottwood@freescale.com> wrote:
> On Fri, Jul 09, 2010 at 08:56:40AM -0400, Ben Gardiner wrote:
>
>> If you are putting an MTD filesystem in that partition then the
>> filesystem itself will take care of bad blocks that might occur in
>> the partition during runtime. During the flash programming of this
>> filesystem using nand write.jffs2 (or .e) will skip bad blocks that
>> might occur in the partition.
>> 
>> If you are putting an image (kernel or initrd) into the partition then
>> the 'nand read.e' and 'nand write.e' (as well as mtd-utils nandwrite)
>> will handle bad blocks by skipping over them.
>
> On any recent u-boot, the .jffs2/.e/.i suffixes are maintained for
> compatibility only -- bad block skipping is now the default behavior.

I'm using 1.3.4 (that's what's supported by Atmel).  While that's the
current "released" version, it appears to be over two years old?

I've been reading nand flash docs and source code for a while now, and
I must admit the more I read the more questions I have.

 1) Is there any documentation for the "nand" commands?
 
    There's nothing in the manual, and doc/README.nand appears to be
    incomplete, and self-contradictory.  [There's no mention at all of
    .e or .i, and there are contradictory descriptions for .jffs2.]

 2) Are the behaviors of ".jffs2", ".e", and ".i" the same? (It
    appears so from the source code.) If not how do they differ?

 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?

 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).
    
-- 
Grant Edwards               grant.b.edwards        Yow! Hello, GORRY-O!!
                                  at               I'm a GENIUS from HARVARD!!
                              gmail.com            

[U-Boot] handling of bad blocks in nand

[Grant Edwards]

On 2010-08-13, Grant Edwards <grant.b.edwards@gmail.com> wrote:
> On 2010-07-09, Scott Wood <scottwood@freescale.com> wrote:
>> On Fri, Jul 09, 2010 at 08:56:40AM -0400, Ben Gardiner wrote:
>>
>>> If you are putting an MTD filesystem in that partition then the
>>> filesystem itself will take care of bad blocks that might occur in
>>> the partition during runtime. During the flash programming of this
>>> filesystem using nand write.jffs2 (or .e) will skip bad blocks that
>>> might occur in the partition.
>>> 
>>> If you are putting an image (kernel or initrd) into the partition then
>>> the 'nand read.e' and 'nand write.e' (as well as mtd-utils nandwrite)
>>> will handle bad blocks by skipping over them.
>>
>> On any recent u-boot, the .jffs2/.e/.i suffixes are maintained for
>> compatibility only -- bad block skipping is now the default behavior.
>
> I'm using 1.3.4 (that's what's supported by Atmel).  While that's the
> current "released" version, it appears to be over two years old?

Never mind.  I see that the version naming scheme has changed and what
I mistook for datestamped snapshots are actually released versions.

That said, 1.3.4 is the most recent version supported by Atmel.  So my
choices are try to port Atmels patches to a recent version or make do
with the nand flash support in 1.3.4.

-- 
Grant Edwards               grant.b.edwards        Yow! When this load is
                                  at               DONE I think I'll wash it
                              gmail.com            AGAIN ...

[U-Boot] handling of bad blocks in nand

[Scott Wood]

On Fri, Aug 13, 2010 at 09:22:21PM +0000, Grant Edwards wrote:
> I'm using 1.3.4 (that's what's supported by Atmel).  While that's the
> current "released" version, it appears to be over two years old?
> 
> I've been reading nand flash docs and source code for a while now, and
> I must admit the more I read the more questions I have.
> 
>  1) Is there any documentation for the "nand" commands?
>  
>     There's nothing in the manual, and doc/README.nand appears to be
>     incomplete, and self-contradictory.  [There's no mention at all of
>     .e or .i, and there are contradictory descriptions for .jffs2.]
> 
>  2) Are the behaviors of ".jffs2", ".e", and ".i" the same? (It
>     appears so from the source code.) If not how do they differ?

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.

Yes, it's a bit of a mess.

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

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

In 1.3.4 use nand_read_opts()/nand_write_opts().  Or convince Atmel to
support something more recent.  :-)

-Scott

[U-Boot] handling of bad blocks in nand

[Grant Edwards]

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!!