NAND OOB data.

NAND OOB data.

[ANDY KENNEDY]

I have overwritten my OOB data, to the point where all blocks are seen
as bad.  What do I do to recover from this?

Thanks,
Andy

RE: NAND OOB data.

[THOMSON, Adam (Adam)]

Andy Kennedy wrote:
> 
> I have overwritten my OOB data, to the point where all blocks 
> are seen as bad.  What do I do to recover from this?

If you're using u-boot then you can use the 'nand scrub' command which wipes all of the data from NAND, including OOB data. Only problem with that is you will lose any factory marked bad block markers, but sounds like in your current situation that isn't much of a concern for you. :o)

> 
> Thanks,
> Andy

Thanks

Adam

RE: NAND OOB data.

[Atlant Schmidt]

Andy:

  If you don't have the old bad block information saved
  away somewhere (a bad block table, a scrap of paper,
  etc.), then you *CAN'T* completely recover from this
  situation; the original bad block data for that chip
  is probably irretrievably lost.*

  You can mark all the blocks as "good", of course, and
  then exercise the chip a bit, marking bad blocks as you
  go. You'll probably never achieve the same depth of
  testing that the factory was able to achieve using
  voltage, temperature, and timing margining, of course,
  but the results may be "good enough".

                          Atlant


* A few chip designs apparently blow fuses for the
  factory bad sectors and these blown fuses prevent
  you from ever writing the OOB bits to the state
  that would indicate a good block. For chips of
  these designs, you can fully recover the factory
  bad block data.


-----Original Message-----
From: linux-mtd-bounces@lists.infradead.org [mailto:linux-mtd-bounces@lists.infradead.org] On Behalf Of ANDY KENNEDY
Sent: Friday, June 17, 2011 18:09
To: linux-mtd@lists.infradead.org
Subject: NAND OOB data.

I have overwritten my OOB data, to the point where all blocks are seen
as bad.  What do I do to recover from this?

Thanks,
Andy

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message.

Thank you.

Please consider the environment before printing this email.

RE: NAND OOB data.

[ANDY KENNEDY]

> -----Original Message-----
> From: Atlant Schmidt [mailto:aschmidt@dekaresearch.com]
> Sent: Monday, June 20, 2011 6:14 AM
> To: ANDY KENNEDY; linux-mtd@lists.infradead.org
> Subject: RE: NAND OOB data.
> 
> Andy:
> 
>   If you don't have the old bad block information saved
>   away somewhere (a bad block table, a scrap of paper,
>   etc.), then you *CAN'T* completely recover from this
>   situation; the original bad block data for that chip
>   is probably irretrievably lost.*

All the other boards apparently are all good (is that normal?), but,
I'm not worried about the NAND having KNOWN bad blocks as this board
is supposed to be mine.

> 
>   You can mark all the blocks as "good", of course, and
>   then exercise the chip a bit, marking bad blocks as you
>   go. You'll probably never achieve the same depth of
>   testing that the factory was able to achieve using
>   voltage, temperature, and timing margining, of course,
>   but the results may be "good enough".
> 
>                           Atlant

Okay, so how do I (without the luxury of u-boot), in user or
kernel space, wipe the OOB data?  I'm looking at the code for
u-boot nand_erase_nand right now.  I mean, I'm not above writing
an userspace app that will do kernel level work for me.  I'm okay
with using /dev/mem and screwing with stuff.  Am I on the right
track?  I mean, I hate to go down this road if I'm just heading
for a dead-end.

Andy

> 
> 
> * A few chip designs apparently blow fuses for the
>   factory bad sectors and these blown fuses prevent
>   you from ever writing the OOB bits to the state
>   that would indicate a good block. For chips of
>   these designs, you can fully recover the factory
>   bad block data.
> 
> 
> -----Original Message-----
> From: linux-mtd-bounces@lists.infradead.org [mailto:linux-mtd-
> bounces@lists.infradead.org] On Behalf Of ANDY KENNEDY
> Sent: Friday, June 17, 2011 18:09
> To: linux-mtd@lists.infradead.org
> Subject: NAND OOB data.
> 
> I have overwritten my OOB data, to the point where all blocks are
> seen
> as bad.  What do I do to recover from this?
> 
> Thanks,
> Andy
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 
> This e-mail and the information, including any attachments, it
> contains are intended to be a confidential communication only to
> the person or entity to whom it is addressed and may contain
> information that is privileged. If the reader of this message is
> not the intended recipient, you are hereby notified that any
> dissemination, distribution or copying of this communication is
> strictly prohibited. If you have received this communication in
> error, please immediately notify the sender and destroy the
> original message.
> 
> Thank you.
> 
> Please consider the environment before printing this email.

Re: NAND OOB data.

[Matthew L. Creech]

On Mon, Jun 20, 2011 at 1:53 PM, ANDY KENNEDY <ANDY.KENNEDY@adtran.com> wrote:
>
> Okay, so how do I (without the luxury of u-boot), in user or
> kernel space, wipe the OOB data?  I'm looking at the code for
> u-boot nand_erase_nand right now.  I mean, I'm not above writing
> an userspace app that will do kernel level work for me.  I'm okay
> with using /dev/mem and screwing with stuff.  Am I on the right
> track?  I mean, I hate to go down this road if I'm just heading
> for a dead-end.
>

If you don't have U-Boot, it sounds like you need a Linux equivalent
to U-Boot's "nand scrub" command.  A quick search yields this:

http://patchwork.ozlabs.org/patch/65406/

Then I guess you'd need to set the corresponding flag in your
mtd-utils when doing flash_eraseall.

-- 
Matthew L. Creech

RE: NAND OOB data.

[Atlant Schmidt]

Andy:

> All the other boards apparently are all good
> (is that normal?),

  It happens; we're in the midst of switching from
  MLC to SLC flash and while I'd never expect that
  from our MLC parts, it seems to be pretty-commonly
  true for our SLC parts.


> Okay, so how do I (without the luxury of u-boot), in user or
> kernel space, wipe the OOB data?  I'm looking at the code for
> u-boot nand_erase_nand right now.  I mean, I'm not above writing
> an userspace app that will do kernel level work for me.  I'm okay
> with using /dev/mem and screwing with stuff.  Am I on the right
> track?  I mean, I hate to go down this road if I'm just heading
> for a dead-end.

  I think there's enough "stuff" available simply through
  /dev/mtd... to let you do any of this. I do a lot of
  Flash manipulation simply using Perl, mtdinfo, ubinfo
  and the /dev/mtd... and /dev/ubi... devices.

  (Unfortunately, I can't share any of that code.)

                               Atlant

-----Original Message-----
From: ANDY KENNEDY [mailto:ANDY.KENNEDY@adtran.com]
Sent: Monday, June 20, 2011 13:54
To: Atlant Schmidt; linux-mtd@lists.infradead.org
Subject: RE: NAND OOB data.

> -----Original Message-----
> From: Atlant Schmidt [mailto:aschmidt@dekaresearch.com]
> Sent: Monday, June 20, 2011 6:14 AM
> To: ANDY KENNEDY; linux-mtd@lists.infradead.org
> Subject: RE: NAND OOB data.
>
> Andy:
>
>   If you don't have the old bad block information saved
>   away somewhere (a bad block table, a scrap of paper,
>   etc.), then you *CAN'T* completely recover from this
>   situation; the original bad block data for that chip
>   is probably irretrievably lost.*

All the other boards apparently are all good (is that normal?), but,
I'm not worried about the NAND having KNOWN bad blocks as this board
is supposed to be mine.

>
>   You can mark all the blocks as "good", of course, and
>   then exercise the chip a bit, marking bad blocks as you
>   go. You'll probably never achieve the same depth of
>   testing that the factory was able to achieve using
>   voltage, temperature, and timing margining, of course,
>   but the results may be "good enough".
>
>                           Atlant

Okay, so how do I (without the luxury of u-boot), in user or
kernel space, wipe the OOB data?  I'm looking at the code for
u-boot nand_erase_nand right now.  I mean, I'm not above writing
an userspace app that will do kernel level work for me.  I'm okay
with using /dev/mem and screwing with stuff.  Am I on the right
track?  I mean, I hate to go down this road if I'm just heading
for a dead-end.

Andy


This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message.

Thank you.

Please consider the environment before printing this email.

Re: NAND OOB data.

[Brian Norris]

On Mon, Jun 20, 2011 at 10:53 AM, ANDY KENNEDY <ANDY.KENNEDY@adtran.com> wrote:
> Okay, so how do I (without the luxury of u-boot), in user or
> kernel space, wipe the OOB data?  I'm looking at the code for
> u-boot nand_erase_nand right now.  I mean, I'm not above writing
> an userspace app that will do kernel level work for me.  I'm okay
> with using /dev/mem and screwing with stuff.  Am I on the right
> track?  I mean, I hate to go down this road if I'm just heading
> for a dead-end.

Well, it's hack-ish, but the easiest way I've found is just to
(temporarily) remove this piece of code from nand_erase_nand():
                /*
                 * heck if we have a bad block, we do not erase bad blocks !
                 */
                if (nand_block_checkbad(mtd, ((loff_t) page) <<
                                        chip->page_shift, 0, allowbbt)) {
                        printk(KERN_WARNING "%s: attempt to erase a bad block "
                                        "at page 0x%08x\n", __func__, page);
                        instr->state = MTD_ERASE_FAILED;
                        goto erase_exit;
                }

Then you can trick the MTD layer into erasing your bad blocks. Be sure
to undo this code change after you've erased the chip!

Brian

RE: NAND OOB data.

[Artem Bityutskiy]

On Mon, 2011-06-20 at 17:53 +0000, ANDY KENNEDY wrote:
> > -----Original Message-----
> > From: Atlant Schmidt [mailto:aschmidt@dekaresearch.com]
> > Sent: Monday, June 20, 2011 6:14 AM
> > To: ANDY KENNEDY; linux-mtd@lists.infradead.org
> > Subject: RE: NAND OOB data.
> > 
> > Andy:
> > 
> >   If you don't have the old bad block information saved
> >   away somewhere (a bad block table, a scrap of paper,
> >   etc.), then you *CAN'T* completely recover from this
> >   situation; the original bad block data for that chip
> >   is probably irretrievably lost.*
> 
> All the other boards apparently are all good (is that normal?), but,
> I'm not worried about the NAND having KNOWN bad blocks as this board
> is supposed to be mine.

I think someone implemented an utility or ioctl for this, probably
Matthew Castet, but I asked for some more improvements or something, and
he disappeared. Try to find the thread, may be you can continue his
work.

But in general, I think the ideal way would be:

1. be able to distinguish between factory-marked and user-marked bad
blocks.
2. allow unmarking user-marked bad blocks, but not factory marked.

Not sure this is always possible, though.

-- 
Best Regards,
Artem Bityutskiy