From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Roese Date: Fri, 14 Jul 2006 10:47:07 +0200 Subject: [U-Boot-Users] skipping bad blocks when erasing nand In-Reply-To: <20060714082857.CE206352681@atlas.denx.de> References: <20060714082857.CE206352681@atlas.denx.de> Message-ID: <200607141047.08126.sr@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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