From patchwork Tue Dec 10 03:16:05 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: qi wang X-Patchwork-Id: 299260 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from casper.infradead.org (unknown [IPv6:2001:770:15f::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 2012B2C00BE for ; Tue, 10 Dec 2013 14:16:39 +1100 (EST) Received: from merlin.infradead.org ([2001:4978:20e::2]) by casper.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1VqDoJ-00008F-E1; Tue, 10 Dec 2013 03:16:35 +0000 Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1VqDoH-0002LS-Pj; Tue, 10 Dec 2013 03:16:33 +0000 Received: from mailout.micron.com ([137.201.242.129]) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1VqDoF-0002K8-3Z for linux-mtd@lists.infradead.org; Tue, 10 Dec 2013 03:16:31 +0000 Received: from mail.micron.com (ntxboicas03.micron.com [137.201.84.59]) by mailout.micron.com (8.14.4/8.14.6) with ESMTP id rBA3G96Q027953 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Dec 2013 20:16:09 -0700 Received: from NTXXIACAS02.xacn.micron.com (10.167.69.56) by NTXBOICAS03.micron.com (137.201.84.59) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Dec 2013 20:16:09 -0700 Received: from NTXXIAMBX02.xacn.micron.com ([fe80::e19a:c3ed:119d:6971]) by NTXXIACAS02.xacn.micron.com ([::1]) with mapi id 14.03.0158.001; Tue, 10 Dec 2013 11:16:05 +0800 From: =?gb2312?B?UWkgV2FuZyDN9cbwIChxaXdhbmcp?= To: "dedekind1@gmail.com" , "linux-mtd@lists.infradead.org" Subject: RE: [PATCH 1/1] MTD: UBI: avoid program operation on NOR flash after erasure interrupted Thread-Topic: [PATCH 1/1] MTD: UBI: avoid program operation on NOR flash after erasure interrupted Thread-Index: Ac7bkfL3+Un6Pi2jSbO3yZA9UtDETwNhLovgAa9rO+AAZiFEEAAABJ+gAPpBsUAAAAdJ8A== Date: Tue, 10 Dec 2013 03:16:05 +0000 Message-ID: <71CF8D7F32C5C24C9CD1D0E02D52498A770B79D9@NTXXIAMBX02.xacn.micron.com> References: <71CF8D7F32C5C24C9CD1D0E02D52498A770B54B1@NTXXIAMBX02.xacn.micron.com> <71CF8D7F32C5C24C9CD1D0E02D52498A770B68A8@NTXXIAMBX02.xacn.micron.com> <71CF8D7F32C5C24C9CD1D0E02D52498A770B6F77@NTXXIAMBX02.xacn.micron.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.167.84.5] X-TM-AS-Product-Ver: SMEX-10.0.0.4152-7.000.1014-20348.003 X-TM-AS-Result: No--23.620100-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No x-mt-checkinternalsenderrule: True MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.73 on 137.201.131.43 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20131209_221631_287262_6C9AE85F X-CRM114-Status: GOOD ( 16.44 ) X-Spam-Score: -1.9 (-) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-1.9 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: Adrian Hunter , "linux-kernel@vger.kernel.org" X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-mtd" Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org Hi Artem: As we talked in mail before, please check my patch as below: From: Qi Wang nor_erase_prepare() will be called before erase a NOR flash, it will program '0' into a block to mark this block. But program data into a erasure interrupted block can cause program timtout(several minutes at most) error, could impact other operation on NOR flash. So UBIFS can read this block first to avoid unneeded program operation. This patch try to put read operation at head of write operation in nor_erase_prepare(), read out the data. If the data is already corrupt, then no need to program any data into this block, just go to erase this block. Signed-off-by: Qi Wang --- --- I have tested this patch on Micron NOR flash, part number is：JS28F512M29EWHA. If have any questions, please let me know. Thank you Best Regards, Qi Wang 王起 ESG APAC AE Tel: 86-021-38997158 Mobile: 86-15201958202 Email: qiwang@micron.com Address: No 601 Fasai Rd, Pudong, Shanghai, China, 200131 diff --git a/drivers/mtd/ubi/io.c b/drivers/mtd/ubi/io.c index bf79def..0a6343d 100644 --- a/drivers/mtd/ubi/io.c +++ b/drivers/mtd/ubi/io.c @@ -499,6 +499,7 @@ static int nor_erase_prepare(struct ubi_device *ubi, int pnum) size_t written; loff_t addr; uint32_t data = 0; + struct ubi_ec_hdr ec_hdr; /* * Note, we cannot generally define VID header buffers on stack, * because of the way we deal with these buffers (see the header @@ -509,49 +510,38 @@ static int nor_erase_prepare(struct ubi_device *ubi, int pnum) struct ubi_vid_hdr vid_hdr; /* + * If VID or EC is valid, need to corrupt it before erase operation. * It is important to first invalidate the EC header, and then the VID * header. Otherwise a power cut may lead to valid EC header and * invalid VID header, in which case UBI will treat this PEB as * corrupted and will try to preserve it, and print scary warnings. */ addr = (loff_t)pnum * ubi->peb_size; - err = mtd_write(ubi->mtd, addr, 4, &written, (void *)&data); - if (!err) { - addr += ubi->vid_hdr_aloffset; - err = mtd_write(ubi->mtd, addr, 4, &written, (void *)&data); - if (!err) - return 0; + err = ubi_io_read_ec_hdr(ubi, pnum, &ec_hdr, 0); + if (err != UBI_IO_BAD_HDR_EBADMSG && err != UBI_IO_BAD_HDR && + err != UBI_IO_FF){ + err1 = mtd_write(ubi->mtd, addr, 4, &written, (void *)&data); + if(err1) + goto error; } - /* - * We failed to write to the media. This was observed with Spansion - * S29GL512N NOR flash. Most probably the previously eraseblock erasure - * was interrupted at a very inappropriate moment, so it became - * unwritable. In this case we probably anyway have garbage in this - * PEB. - */ - err1 = ubi_io_read_vid_hdr(ubi, pnum, &vid_hdr, 0); - if (err1 == UBI_IO_BAD_HDR_EBADMSG || err1 == UBI_IO_BAD_HDR || - err1 == UBI_IO_FF) { - struct ubi_ec_hdr ec_hdr; - - err1 = ubi_io_read_ec_hdr(ubi, pnum, &ec_hdr, 0); - if (err1 == UBI_IO_BAD_HDR_EBADMSG || err1 == UBI_IO_BAD_HDR || - err1 == UBI_IO_FF) - /* - * Both VID and EC headers are corrupted, so we can - * safely erase this PEB and not afraid that it will be - * treated as a valid PEB in case of an unclean reboot. - */ - return 0; + err = ubi_io_read_vid_hdr(ubi, pnum, &vid_hdr, 0); + if (err != UBI_IO_BAD_HDR_EBADMSG && err != UBI_IO_BAD_HDR && + err != UBI_IO_FF){ + addr += ubi->vid_hdr_aloffset; + err1 = mtd_write(ubi->mtd, addr, 4, &written, (void *)&data); + if (err1) + goto error; } + return 0; +error: /* - * The PEB contains a valid VID header, but we cannot invalidate it. + * The PEB contains a valid VID or EC header, but we cannot invalidate it. * Supposedly the flash media or the driver is screwed up, so return an * error. */ - ubi_err("cannot invalidate PEB %d, write returned %d read returned %d", + ubi_err("cannot invalidate PEB %d, read returned %d write returned %d", pnum, err, err1); ubi_dump_flash(ubi, pnum, 0, ubi->peb_size); return -EIO;