[U-Boot-Users] skipping bad blocks when erasing nand

[U-Boot-Users] skipping bad blocks when erasing nand

[David Byron]

Apologies if this should go to the patches list.

This change gets u-boot to skip bad blocks during an erase operation instead
of giving up.

Comments?

-DB
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nand_base.c.patch
Type: application/octet-stream
Size: 848 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20060713/38e1e905/attachment.obj 

[U-Boot-Users] skipping bad blocks when erasing nand

[Wolfgang Denk]

In message <001101c6a6c4$471b9a70$a134800a@RudiDell> you wrote:
> 
> Apologies if this should go to the patches list.
> 
> This change gets u-boot to skip bad blocks during an erase operation instead
> of giving up.
> 
> Comments?

Silently ignoring such errors without even  printing  a  message  and
setting the return code of the command is not acceptable.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
For those who like this sort of thing, this is the sort of thing they
like.                                               - Abraham Lincoln

[U-Boot-Users] skipping bad blocks when erasing nand

[David Byron]

> Silently ignoring such errors without even  printing  a  message  and
> setting the return code of the command is not acceptable.

I guess I don't understand what's going on enough then.  Is it really an
error to come across a bad block?  I thought that was part of the deal when
using nand chips.  If, for example, I want to erase a whole chip, then
silently skipping bad blocks seems like the way to go.  I could see keeping
some kind of debug message, but something less severe than KERN_WARNING.
Would that make this acceptable?

Thanks for your help.

-DB

[U-Boot-Users] skipping bad blocks when erasing nand

[Wolfgang Denk]

In message <000001c6a6ca$bd0b3230$a134800a@RudiDell> you wrote:
> > Silently ignoring such errors without even  printing  a  message  and
> > setting the return code of the command is not acceptable.
> 
> I guess I don't understand what's going on enough then.  Is it really an
> error to come across a bad block?  I thought that was part of the deal when

It should at least be reported to the user - otherwise he assumes  to
have an error-free medium.

> using nand chips.  If, for example, I want to erase a whole chip, then
> silently skipping bad blocks seems like the way to go.  I could see keeping

No, I think I would want to see reports about unerasable blocks here.

> some kind of debug message, but something less severe than KERN_WARNING.
> Would that make this acceptable?

It should be a regular message, not only debug.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Human beings were created by water to transport it uphill.

[U-Boot-Users] skipping bad blocks when erasing nand

[Dave Hylands]

Hi,

Replying to the whole list this time around....

> It should at least be reported to the user - otherwise he assumes  to
> have an error-free medium.

Hard-drives have bad blocks, but you don't see them being reported
when you format.

Somebody who knows that NAND chips have bad blocks as a normal course
of events won't be suprised to see them. People (i.e. end users - not
the programmers) who are unaware that NAND chips can have bad blocks
will be suprised, so the whole thing about bad blocks being normal now
has to be documented.

I think that if a block is marked as bad, then doing an erase should
just ignore blocks that already marked bad. However, if a block goes
bad as a result of the formatting, then that's worth reporting
(although, this is also a fact of life).

I think having a command to list the bad blocks would be useful.

-- 
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/

[U-Boot-Users] skipping bad blocks when erasing nand

[Joachim Jaeger]

Hi,

Dave Hylands wrote:
> Hard-drives have bad blocks, but you don't see them being reported
> when you format.
> 
> Somebody who knows that NAND chips have bad blocks as a normal course
> of events won't be suprised to see them. People (i.e. end users - not
> the programmers) who are unaware that NAND chips can have bad blocks
> will be suprised, so the whole thing about bad blocks being normal now
> has to be documented.
> 
> I think that if a block is marked as bad, then doing an erase should
> just ignore blocks that already marked bad. However, if a block goes
> bad as a result of the formatting, then that's worth reporting
> (although, this is also a fact of life).

I also think the patch from David is OK, because the bad blocks are not
skipped, which would be fatal crossing partition boundaries, but just
ignored.
I think even reporting about these ignored blocks isn't necessary.
Instead it would be much more interesting to know about the really bad
block free space.

> 
> I think having a command to list the bad blocks would be useful.

This already exists (nand bad)

Regards
Joachim

> 
-- 
Joachim Jaeger

FS Forth-Systeme GmbH
A DIGI International Company
Kueferstrasse 8
79206 Breisach
Germany
Phone: +49-7667-908-0
Fax: +49-7667-908-200
mailto:joachim_jaeger at digi.com
web: www.fsforth.de, www.digi.com

[U-Boot-Users] skipping bad blocks when erasing nand

[Stefan Roese]

On Friday 14 July 2006 00:45, Wolfgang Denk wrote:
> In message <000001c6a6ca$bd0b3230$a134800a@RudiDell> you wrote:
> > I guess I don't understand what's going on enough then.  Is it really an
> > error to come across a bad block?  I thought that was part of the deal
> > when
>
> It should at least be reported to the user - otherwise he assumes  to
> have an error-free medium.

I am "voting" for David's implementation, since bad blocks are "normal" on 
NAND chips. And if I remember correctly, the "old" U-Boot NAND driver also 
just skipped the bad block upon erasing without reproting them.

Best regards,
Stefan

[U-Boot-Users] skipping bad blocks when erasing nand

[Wolfgang Denk]

Hello Stefan,

in message <200607140914.07427.sr@denx.de> you wrote:
>
> I am "voting" for David's implementation, since bad blocks are "normal" on 
> NAND chips. And if I remember correctly, the "old" U-Boot NAND driver also 
> just skipped the bad block upon erasing without reproting them.

I'm sorry, but I disagree. This code is not coming out of  thin  air.
It is a more or less vrbatim copy of the corresponding Linux MTD NAND
code, see "drivers/mtd/nand/nand_base.c" in your Linux kernel tree.

In U-Boot, we have the additional #define NAND_ALLOW_ERASE_ALL  which
can be enabled if you don't like this behaviour.

If you believe that the U-Boot behavious is wrong, then the Linux MTD
driver would be wrong, too. In this case discussion  should  continue
on the MTD mailing list.

As long as I don't see any changes to the current MTD Linux code  you
will  need  really good arguments to talk me into changing the U-Boot
code.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
At the source of every error which is blamed on the computer you will
find at least two human errors, including the error of blaming it  on
the computer.

[U-Boot-Users] skipping bad blocks when erasing nand

[Stefan Roese]

Hello Wolfgang,

On Friday 14 July 2006 10:28, Wolfgang Denk wrote:
> in message <200607140914.07427.sr@denx.de> you wrote:
> > I am "voting" for David's implementation, since bad blocks are "normal"
> > on NAND chips. And if I remember correctly, the "old" U-Boot NAND driver
> > also just skipped the bad block upon erasing without reproting them.
>
> I'm sorry, but I disagree. This code is not coming out of  thin  air.
> It is a more or less vrbatim copy of the corresponding Linux MTD NAND
> code, see "drivers/mtd/nand/nand_base.c" in your Linux kernel tree.
>
> In U-Boot, we have the additional #define NAND_ALLOW_ERASE_ALL  which
> can be enabled if you don't like this behaviour.
>
> If you believe that the U-Boot behavious is wrong, then the Linux MTD
> driver would be wrong, too. In this case discussion  should  continue
> on the MTD mailing list.

I find it hard to believe that a linux NAND erase operation will stop upon 
reaching a bad block. But you are right: the code in question is the same in 
the current linux mtd driver. From my experience, I never had problems 
erasing NAND flash devices (from U-Boot & linux) which had bad blocks.

> As long as I don't see any changes to the current MTD Linux code  you
> will  need  really good arguments to talk me into changing the U-Boot
> code.

I see. You have a good point here. This needs some testing on a device with 
bad blocks. "Unfortunately" the device on my desk has no bad blocks at all:

=> nand bad

Device 0 bad blocks:

Perhaps somebody else can jump in here and test the current linux mtd driver 
behavior on a device with bad blocks. Thanks.

Best regards,
Stefan

[U-Boot-Users] skipping bad blocks when erasing nand

[Wolfgang Denk]

Dear Stefan,

in message <200607141047.08126.sr@denx.de> you wrote:
> 
> I find it hard to believe that a linux NAND erase operation will stop upon 
> reaching a bad block. But you are right: the code in question is the same in 
> the current linux mtd driver. From my experience, I never had problems 
> erasing NAND flash devices (from U-Boot & linux) which had bad blocks.

The code in the MTD CVS is also the same.

Note that in my understanding this code never gets executed  for  bad
blocks  (see comment "we do not erase bad blocks") in Linux, i. e. it
attempts to catch previous errors.

> I see. You have a good point here. This needs some testing on a device with 
> bad blocks. "Unfortunately" the device on my desk has no bad blocks at all:
> 
> => nand bad
> 
> Device 0 bad blocks:
> 
> Perhaps somebody else can jump in here and test the current linux mtd driver 
> behavior on a device with bad blocks. Thanks.

If you like you can use the "dave" board in our virtual lab. It has a
couple of bad blocks in device 1:

=> nand device 1
Device 1: NAND 32MiB 3,3V 8-bit... is now current device
=> nand bad

Device 1 bad blocks:
  00000000
  00004000
  00008000
  0000c000
  00010000
=>

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I don't know if it's what you want, but it's what you get.  :-)
                      - Larry Wall in <10502@jpl-devvax.JPL.NASA.GOV>

[U-Boot-Users] skipping bad blocks when erasing nand

[Joachim Jaeger]

Hi Stefan,

Stefan Roese wrote:
> Perhaps somebody else can jump in here and test the current linux mtd driver 
> behavior on a device with bad blocks. Thanks.

I only can provide the output based on the 2.6.12.5 kernel:

NAND device: Manufacturer ID: 0xec, Chip ID: 0xd3 (Samsung NAND 1GiB
3,3V 8-bit)
Scanning device for bad blocks
Bad eraseblock 4861 at 0x25fa0000
Bad eraseblock 5098 at 0x27d40000
Bad eraseblock 5163 at 0x28560000
Bad eraseblock 6252 at 0x30d80000
Bad eraseblock 7952 at 0x3e200000
Creating 3 MTD partitions on "NAND 1GiB 3,3V 8-bit":
0x00000000-0x00040000 : "u-boot"
0x00040000-0x00300000 : "kernel"
0x00300000-0x40000000 : "rootfs"

/ # mtd_debug erase /dev/mtd/2 0x22f00000 0x3000000
nand_erase: attempt to erase a bad block at page 0x0004bf40
MEMERASE: Input/output error

I think, bad blocks should not prevent U-Boot from erasing a partition,
which is needed to write an OS there, which needs to be booted.


Best regards
Joachim

-- 
Joachim Jaeger

FS Forth-Systeme GmbH
A DIGI International Company
Kueferstrasse 8
79206 Breisach
Germany
Phone: +49-7667-908-0
Fax: +49-7667-908-200
mailto:joachim_jaeger at digi.com
web: www.fsforth.de, www.digi.com

[U-Boot-Users] skipping bad blocks when erasing nand

[Wolfgang Denk]

In message <44B76ABA.3000607@fsforth.de> you wrote:
> 
> / # mtd_debug erase /dev/mtd/2 0x22f00000 0x3000000
> nand_erase: attempt to erase a bad block at page 0x0004bf40
> MEMERASE: Input/output error

That's the behaviour I would expect to see from looking at the code.

And what you will see in U-Boot, too - same code, same behaviour.

> I think, bad blocks should not prevent U-Boot from erasing a partition,
> which is needed to write an OS there, which needs to be booted.

I tend to agree here, which was the reason that I said I was  willing
to  accept  the patch, but that at least the printf() shoould be kept
so that the user gets the warning.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Hello! I'm from outer space,  and I've made myself look like a signa-
ture.  While  you  are reading this, I'm having sex with your eyes. I
know it feels good to you, because you're smiling. I'm very horny, so
send me to someone else when you've had enough. Thanks!
                              Sincerely, A Stranger in a Strange Land

[U-Boot-Users] skipping bad blocks when erasing nand

[David Byron]

On Friday, July 14th, Wolfgang Denk wrote:	 

> I tend to agree here, which was the reason that I said I was  willing
> to  accept  the patch, but that at least the printf() shoould be kept
> so that the user gets the warning.

Sorry for the delay.  Here's a patch that lets the erase continue, but does
print a message.

-DB
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nand_base.c.patch.2
Type: application/octet-stream
Size: 939 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20060717/eca54814/attachment.obj 

[U-Boot-Users] skipping bad blocks when erasing nand

[Tolunay Orkun]

David Byron wrote:
> On Friday, July 14th, Wolfgang Denk wrote:	 
> 
>> I tend to agree here, which was the reason that I said I was  willing
>> to  accept  the patch, but that at least the printf() shoould be kept
>> so that the user gets the warning.
> 
> Sorry for the delay.  Here's a patch that lets the erase continue, but does
> print a message.

Instead of printing a message for each block, I think it would be neater 
to give a summary at the end like:

x blocks erased successfully. y blocks ignored.

nand bad command gives the list anyway if someone is more inclined to 
find out what blocks.

What do you (and Wolfgang) think about my proposal?

Tolunay

[U-Boot-Users] skipping bad blocks when erasing nand

[Stefan Roese]

Hi Tolunay,

On Friday 21 July 2006 01:22, Tolunay Orkun wrote:
> Instead of printing a message for each block, I think it would be neater
> to give a summary at the end like:
>
> x blocks erased successfully. y blocks ignored.

Good idea.

> nand bad command gives the list anyway if someone is more inclined to
> find out what blocks.
>
> What do you (and Wolfgang) think about my proposal?

I would also prefer this kind of implementation. Just my $0.02.

Best regards,
Stefan

[U-Boot-Users] skipping bad blocks when erasing nand

[Ladislav Michl]

Dear Wolfgang,

On Fri, Jul 14, 2006 at 01:19:23PM +0200, Wolfgang Denk wrote:
> In message <44B76ABA.3000607@fsforth.de> you wrote:
> > 
> > / # mtd_debug erase /dev/mtd/2 0x22f00000 0x3000000
> > nand_erase: attempt to erase a bad block at page 0x0004bf40
> > MEMERASE: Input/output error
> 
> That's the behaviour I would expect to see from looking at the code.
> 
> And what you will see in U-Boot, too - same code, same behaviour.

Indeed, but MTD code in U-Boot is invoked different way (that's my bad
and I apologize for late reply). Most Linux users are probably using
mtd-utils to deal with erasing NAND. flash_erase will issue MEMERASE
ioctl directly and that will fail on attempt to erase bad block. However
flash_eraseall will first ask for bad block using MEMGETBADBLOCK ioctl
and eventually skip it, printing info message "Skipping bad block at 0x%08x"
Average U-Boot user probably wants flash_eraseall behaviour...

> > I think, bad blocks should not prevent U-Boot from erasing a partition,
> > which is needed to write an OS there, which needs to be booted.
> 
> I tend to agree here, which was the reason that I said I was  willing
> to  accept  the patch, but that at least the printf() shoould be kept
> so that the user gets the warning.

So, it seems the only unanswered question is implementation. You can
either accept second version of proposed patch or ask for different
implementation which will be similar to flash_eraseall (ie. bad block
checking done outside MTD code, so it can remain unmodified). Not being
U-Boot maintainer I trade off decision :-)

Best regards,
	ladis