Erasing NAND bad blocks?

Erasing NAND bad blocks?

[Steven Hein]

(Yes, I do know that erasing NAND flash blocks that are marked bad
is a VERY BAD IDEA.....I'm asking the question regarding a
specific HW/SW debug situation.......)

In the course of bringing up new hardware with NAND flash attached
I have had occasions where a software bug will cause a NAND-based
filesystem (such as YAFFS) to mark *all* of the blocks in a filesystem
as bad.  In the past, I have hacked the nand_erase() function to
allow erasing of bad blocks, then wrote a custom app to scan the OOB
data, doing a MEM_ERASE for blocks that had been marked bad by the FS.
Just wondering.....has anyone else
run into this situation, and is there a more graceful way of doing
this (i.e. without hacking the MTD NAND driver)?

Thanks!
Steve

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Steve Hein (ssh@sgi.com)              Engineering Diagnostics/Software
Silicon Graphics, Inc.                          
1168 Industrial Blvd.                 Phone: (715) 726-8410
Chippewa Falls, WI 54729              Fax:   (715) 726-6715
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~	

Re: Erasing NAND bad blocks?

[Thomas Gleixner]

On Tue, 2005-08-09 at 11:41 -0500, Steven Hein wrote:
> (Yes, I do know that erasing NAND flash blocks that are marked bad
> is a VERY BAD IDEA.....I'm asking the question regarding a
> specific HW/SW debug situation.......)
> 
> In the course of bringing up new hardware with NAND flash attached
> I have had occasions where a software bug will cause a NAND-based
> filesystem (such as YAFFS) to mark *all* of the blocks in a filesystem
> as bad.  In the past, I have hacked the nand_erase() function to
> allow erasing of bad blocks, then wrote a custom app to scan the OOB
> data, doing a MEM_ERASE for blocks that had been marked bad by the FS.
> Just wondering.....has anyone else
> run into this situation, and is there a more graceful way of doing
> this (i.e. without hacking the MTD NAND driver)?

This topic comes around on a regular base. 

I was more than once tempted to provide a user space interface to do
that. There are pro and cons. 

The con which holds me off is the experince that >90% of the bad block
complaints are related to buggy hardware and board drivers. Most of the
people trapping into this spend plenty of time to tinker around the real
problem.

Adding this functionality (it's simple) would just add some more
confusing reports like "Hey, I erased all the bad blocks with the
--force-erase-bad-block option, but it still shows me those annoying
messages".

OTH, we do enough witchcraft based help already, as obviously a lot of
those people 
- ignore documentation 
- are to a high grade advisory resistant
- ...

So it might just adding another shade of nerve racking, but helpful for
those who know what they are doing.

I'm not going to implement it myself, but patches are welcome. :)

Hint: 

	case MEMERASEFORCED:
		check_root_priviledges()
		force = 1;
	case MEMERASE:
		......
		erase->state = force ? ...FORCE... : 0;

erase.state seems to be a nice transport mechanism and it will uncover
all un/half initialized instances of struct erase_info by a simple check
for ...FORCE... || 0


tglx

Re: Erasing NAND bad blocks?

[Charles Manning]

On Wednesday 10 August 2005 11:33, Thomas Gleixner wrote:
> On Tue, 2005-08-09 at 11:41 -0500, Steven Hein wrote:
> > (Yes, I do know that erasing NAND flash blocks that are marked bad
> > is a VERY BAD IDEA.....I'm asking the question regarding a
> > specific HW/SW debug situation.......)
> >
> > In the course of bringing up new hardware with NAND flash attached
> > I have had occasions where a software bug will cause a NAND-based
> > filesystem (such as YAFFS) to mark *all* of the blocks in a filesystem
> > as bad.  In the past, I have hacked the nand_erase() function to
> > allow erasing of bad blocks, then wrote a custom app to scan the OOB
> > data, doing a MEM_ERASE for blocks that had been marked bad by the FS.
> > Just wondering.....has anyone else
> > run into this situation, and is there a more graceful way of doing
> > this (i.e. without hacking the MTD NAND driver)?
>

As this comes around often wrt YAFFS1, I think there are two things that can 
be done in YAFFS to help address the issue:
1) Make the bad block marker used in YAFFS1 something that is easy to 
recognise (eg. 'Y' ) instead of 0x00. That way it should be easy to recognise 
yaffs -vs- factory marked bad blocks.
2) Add a config in yaffs to not do any bad block marking during board bring 
up.

-- CHarles

Re: Erasing NAND bad blocks?

[Sergei Sharonov]

Charles,


> 2) Add a config in yaffs to not do any bad block marking during board bring 
> up.

I suggest to disable retiring blocks that failed ECC on read. I see it happening
during power cycling. YAFFS leaks good blocks, e.g. disrupted write/erase
creates bad ECC and then GC retires perfectly good block. JFFS2 does not do that.
AFAIK, manufacturers suggest discarding only blocks that fail on write.

Sergei 

Re: Erasing NAND bad blocks?

[Thomas Gleixner]

On Thu, 2005-08-11 at 08:08 +1200, Charles Manning wrote:
> As this comes around often wrt YAFFS1, I think there are two things that can 
> be done in YAFFS to help address the issue:
> 1) Make the bad block marker used in YAFFS1 something that is easy to 
> recognise (eg. 'Y' ) instead of 0x00. That way it should be easy to recognise 
> yaffs -vs- factory marked bad blocks.
> 2) Add a config in yaffs to not do any bad block marking during board bring 
> up.

2) is the safe way, but it should be blocked in the MTD/NAND layer to
protect all fs developers from the usual complaints resulting from "try
and error bring up"

tglx