From robin@edesix.com Fri May 29 12:42:19 2009
Received: from smtpout.karoo.kcom.com ([212.50.160.34])
	by stoneboat.aleph1.co.uk with esmtp (Exim 4.69)
	(envelope-from <robin@edesix.com>) id 1MA0TY-0003K9-IT
	for yaffs@lists.aleph1.co.uk; Fri, 29 May 2009 12:42:19 +0100
X-IronPort-AV: E=Sophos;i="4.41,270,1241391600"; d="scan'208";a="97791938"
Received: from host67.cbchouse.co.uk (HELO flange.edesix.com) ([81.5.164.67])
	by smtpout.karoo.kcom.com with ESMTP; 29 May 2009 12:42:03 +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 <robin@edesix.com>)
	id 1MA0T9-0001Jb-Aa; Fri, 29 May 2009 12:41:53 +0100
Message-ID: <4A1FC9D9.7070207@edesix.com>
Date: Fri, 29 May 2009 12:41:13 +0100
From: Robin Iddon <robin@edesix.com>
User-Agent: Thunderbird 2.0.0.19 (X11/20090223)
MIME-Version: 1.0
To: Rong Shen <rong1129@gmail.com>
References: <4A1F1BFC.50607@cynigram.com>	
	<d9efa7ce0905281857s3ffbac2ve6d8c5cb9dd02f3c@mail.gmail.com>	
	<4A1F972E.6020701@edesix.com>
	<d9efa7ce0905290429l6f3602e7h9d00dc115fab0c28@mail.gmail.com>
In-Reply-To: <d9efa7ce0905290429l6f3602e7h9d00dc115fab0c28@mail.gmail.com>
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)
Cc: yaffs@lists.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 <yaffs.lists.aleph1.co.uk>
List-Unsubscribe: <http://lists.aleph1.co.uk/cgi-bin/mailman/options/yaffs>,
	<mailto:yaffs-request@lists.aleph1.co.uk?subject=unsubscribe>
List-Archive: <http://lists.aleph1.co.uk/lurker/list/yaffs.html>
List-Post: <mailto:yaffs@lists.aleph1.co.uk>
List-Help: <mailto:yaffs-request@lists.aleph1.co.uk?subject=help>
List-Subscribe: <http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs>,
	<mailto:yaffs-request@lists.aleph1.co.uk?subject=subscribe>
X-List-Received-Date: Fri, 29 May 2009 11:42:19 -0000


Rong Shen wrote:
> On Fri, May 29, 2009 at 6:05 PM, Robin Iddon <robin@edesix.com> wrote:
>   
>> 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
>>     
>
> Bad block marker is just non-FF byte/word in the spare area, if all
> bits are stuck in 1, the manufacturer wouldn't have had been able to
> mark it in the first place. Strange though. I could be wrong but it's
> more like a faulty chip or h/w issue.
>   

In the factory they have more ways than one to program the bits I 
suspect; ways that aren't available to you by the time the die is 
packaged into the chip.

This happened on 6 out of 6 chips that we forcibly erased.

Robin