From robin@edesix.com Fri May 29 09:05:53 2009 Received: from smtpout.karoo.kcom.com ([212.50.160.34]) by stoneboat.aleph1.co.uk with esmtp (Exim 4.69) (envelope-from ) id 1M9x66-0003zN-Rq for yaffs@lists.aleph1.co.uk; Fri, 29 May 2009 09:05:53 +0100 X-IronPort-AV: E=Sophos;i="4.41,270,1241391600"; d="scan'208";a="102753550" Received: from host67.cbchouse.co.uk (HELO flange.edesix.com) ([81.5.164.67]) by smtpout.karoo.kcom.com with ESMTP; 29 May 2009 09:05:36 +0100 Received: from 93-97-174-104.zone5.bethere.co.uk ([93.97.174.104] helo=[192.168.1.51]) by flange.edesix.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.62) (envelope-from ) id 1M9x5d-0004V7-2N for yaffs@lists.aleph1.co.uk; Fri, 29 May 2009 09:05:26 +0100 Message-ID: <4A1F972E.6020701@edesix.com> Date: Fri, 29 May 2009 09:05:02 +0100 From: Robin Iddon User-Agent: Thunderbird 2.0.0.19 (X11/20090223) MIME-Version: 1.0 To: yaffs@lists.aleph1.co.uk References: <4A1F1BFC.50607@cynigram.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 212.50.160.34 X-SA-Exim-Mail-From: robin@edesix.com X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on stoneboat.aleph1.co.uk X-Spam-Level: X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.2.5 X-SA-Exim-Version: 4.2.1 (built Wed, 25 Jun 2008 17:14:11 +0000) X-SA-Exim-Scanned: Yes (on stoneboat.aleph1.co.uk) Subject: Re: [Yaffs] Bad eraseblocks and NAND / ECC layouts X-BeenThere: yaffs@lists.aleph1.co.uk X-Mailman-Version: 2.1.11 Precedence: list List-Id: Discussion of YAFFS NAND flash filesystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2009 08:05:53 -0000 A word of caution on this: > 1. completely wipe the flash, data and spare area > We found that forcing erasure of bad block markers on Micron MLC FLASH part (29F32G08QAA) left the block in a state where it could not be programmed again (i.e. the bad block marker could not be set again). This is fair enough - there are no guarantees from the manufacturer that bad blocks can be reprogrammed if erased. At the time we did this as we had a h/w problem that was making our s/w think good blocks were bad; having corrected the h/w issue we wanted to recover all the incorrectly marked bad blocks. We ended up replacing the FLASH parts on the afflicted boards. To address this issue properly I think the only choice is to program a bad block table into a working block; I would guess only one block would need to be sacrificed, but deciding which block to use and which layer to implement such a thing at would require more time and effort than it is perhaps worth - just don't erase bad blocks! Hope this helps, Robin