From patchwork Fri Feb 11 15:39:39 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Joakim Tjernlund X-Patchwork-Id: 82774 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 791BDB715E for ; Sat, 12 Feb 2011 02:41:13 +1100 (EST) Received: from canuck.infradead.org ([2001:4978:20e::1]) by bombadil.infradead.org with esmtps (Exim 4.72 #1 (Red Hat Linux)) id 1Pnv62-0005u1-HC; Fri, 11 Feb 2011 15:39:46 +0000 Received: from localhost ([127.0.0.1] helo=canuck.infradead.org) by canuck.infradead.org with esmtp (Exim 4.72 #1 (Red Hat Linux)) id 1Pnv5z-0000Ov-Pe; Fri, 11 Feb 2011 15:39:43 +0000 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 Received: from sesr04.transmode.se (sesr04.transmode.se [192.168.201.15]) by gw1.transmode.se (Postfix) with ESMTP id 2E0E265000C; Fri, 11 Feb 2011 16:39:40 +0100 (CET) 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? X-KeepSent: 24342672:F4BEF9FA-C1257834:0055AEE1; type=4; name=$KeepSent To: Michael Cashwell X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 Message-ID: From: Joakim Tjernlund Date: Fri, 11 Feb 2011 16:39:39 +0100 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.5.2FP1|November 29, 2010) at 2011-02-11 16:39:40 MIME-Version: 1.0 X-CRM114-Version: 20090807-BlameThorstenAndJenny ( TRE 0.7.6 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20110211_103941_652473_3E101864 X-CRM114-Status: GOOD ( 20.45 ) X-Spam-Score: -0.0 (/) X-Spam-Report: SpamAssassin version 3.3.1 on canuck.infradead.org summary: Content analysis details: (-0.0 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain Cc: linux-mtd@lists.infradead.org, stefan.bigler@keymile.com, Holger brunck , =?ISO-8859-15?Q?Anders_Grafstr=F6m?= X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-mtd-bounces@lists.infradead.org Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org Michael Cashwell wrote on 2011/02/11 16:05:54: > > On Feb 10, 2011, at 12:54 PM, Anders Grafström 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 they are not legitimate. I changed them to actually print the status word 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 point. > > 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 erased state. > > Yes, it's a possibility. However, I've never seen an erase report any error. Mike, does this small patch change anything: 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 diff --git a/drivers/mtd/chips/cfi_cmdset_0001.c b/drivers/mtd/chips/cfi_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 == 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);