From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from gw1.transmode.se ([213.115.205.20]) by canuck.infradead.org with esmtps (Exim 4.72 #1 (Red Hat Linux)) id 1Pnv5x-0000ON-EL for linux-mtd@lists.infradead.org; Fri, 11 Feb 2011 15:39:42 +0000 In-Reply-To: References: <16826B66-31FE-41AD-A6EF-E668A45AF1FE@prograde.net> <4D4BDD48.6040600@keymile.com> <541E19B8-D428-4F59-B6BB-A3BD8F455AE4@prograde.net> <0488D3BA-7BA3-4E98-B289-3F3D1DB485D4@prograde.net> Subject: Re: Numonyx NOR and chip->mutex bug? To: Michael Cashwell Message-ID: From: Joakim Tjernlund Date: Fri, 11 Feb 2011 16:39:39 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-15 Content-transfer-encoding: quoted-printable Cc: linux-mtd@lists.infradead.org, stefan.bigler@keymile.com, Holger brunck , =?ISO-8859-15?Q?Anders_Grafstr=F6m?= List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Michael Cashwell wrote on 2011/02/11 16:05:54: > > On Feb 10, 2011, at 12:54 PM, Anders Grafstr=F6m wrote: > > > On 2011-02-10 17:43, Michael Cashwell wrote: > >> On Feb 10, 2011, at 10:59 AM, Michael Cashwell wrote: > >> Troublesome 65nm parts: > >> run 1: > >> NOR Flash: block erase suspended and resumed 29 times. > >> buffered write fails. > > > > Buffered write fails with SR[4] set? > > The error messages variously report block locked and Vpp errors but t= hey are not legitimate. I changed them to actually print the status wor= d and it's often 0xffff or other values with set bits in the upper byte= . That tells me the chip is not properly in status-read mode at that po= int. > > So I think the answer to your question is no, not reliably with SR[4]= set because it's reading array data instead of status. > > > Have you configured with CONFIG_MTD_UBI_DEBUG_PARANOID so that UBI = does the all 0xff check after erase? > > I've used some of the debugging modes at the top of cfi_cmdset_0001.c= but I had not used the config option. I will do that and report back. > > > I'm wondering if the blocks being written to are in a properly eras= ed state. > > Yes, it's a possibility. However, I've never seen an erase report any= error. Mike, does this small patch change anything: diff --git a/drivers/mtd/chips/cfi_cmdset_0001.c b/drivers/mtd/chips/cf= i_cmdset_0001.c index 9772a62..bdcd8c1 100644 --- a/drivers/mtd/chips/cfi_cmdset_0001.c +++ b/drivers/mtd/chips/cfi_cmdset_0001.c @@ -808,7 +808,8 @@ static int chip_ready (struct map_info *map, struct= flchip *chip, unsigned long (mode =3D=3D FL_WRITING && (cfip->SuspendCmdSupport & 1)))) goto sleep; - + /* Numonyx Axcell chips needs a Read Status */ + map_write(map, CMD(0x70), adr); /* Erase suspend */ map_write(map, CMD(0xB0), adr); Possibly this u-boot add on would make it easier to test suspend/resume= : http://lists.infradead.org/pipermail/linux-mtd/2008-April/021280.html =