From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8ACEBC282C0 for ; Wed, 23 Jan 2019 11:25:29 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 5ACFB217F5 for ; Wed, 23 Jan 2019 11:25:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="IOvxYepb"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="SFoBxCGK" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5ACFB217F5 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=FMhSSlearj/fPZ/KJ2V9aVKbNwl1349skrRLxoRpoxA=; b=IOvxYepbu0bsAU 7rRBkEtc4XC6k5K0sn4sGs5qlaKdfXWTOEmuAvvclHlP3DrUpmf5ekJuyM5JSCQ9kHGhHMob/3oYt 556ueFXUu5s98MU/aoaGWsi/1r3eGSeO6hZeE4Cftvx0jIIXZyZ1ondy/TRpJ4so860SQInEZa1L+ sPp8BBTjAFU/4DaV20TJfRy5t2MKaDHEmNaYY/uH6yRZQw28qQcpZ+dIP91CNmzLCHATyvw9gK5Xi D0f+aHT7KI4/2TD+ojULTcSInoFbW65jWNjCgW8/VsFSb70ol4vgwJcSuiCYE71qoAv8mEW3UhlwI D6lX6VSqk6UPMdgJwT2w==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1gmGes-0005qo-DZ; Wed, 23 Jan 2019 11:25:26 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1gmGeo-0005qR-RP for linux-mtd@lists.infradead.org; Wed, 23 Jan 2019 11:25:24 +0000 Received: from bbrezillon (unknown [91.160.177.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id CB86F21726; Wed, 23 Jan 2019 11:25:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1548242722; bh=d8NX1lJJmLJ9uVyDXB7zy+EoqHCeHqPZQXfPBmr2Pxw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=SFoBxCGKN7oiKlvoIRkBNdV0eHRaFX0n8AFl8Y1oMB/FdfvtfwZsfXtI9QDVwpPSg U47coEt4h3UxP4RzlClSpXceqw3nLI60pBCpoNG5F007aLWjQ9VXdqVDx3QEQxGHWG JCEKfrFQrQBJVwQ3iYdRwGUYbpe7+iWRwlp4QXFg= Date: Wed, 23 Jan 2019 12:25:14 +0100 From: Boris Brezillon To: Stefan Roese Subject: Re: [PATCH] mtd: spinand: Add support for GigaDevice GD5F1GQ4UC Message-ID: <20190123122514.0db87887@bbrezillon> In-Reply-To: References: <20190122145632.17547-1-sr@denx.de> <20190122175346.602894e4@bbrezillon> <263cbd32-b7d4-e440-c92d-4f24f5af27a0@denx.de> <20190123085202.0db528ac@bbrezillon> <870af691-e8d3-cd91-5a55-6478ef885446@denx.de> <20190123095504.7857ca34@bbrezillon> <20190123103512.722095cd@bbrezillon> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190123_032522_922500_1E9FA4FF X-CRM114-Status: GOOD ( 18.90 ) X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-mtd@lists.infradead.org, Chuanhong Guo , Frieder Schrempf , Miquel Raynal Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org On Wed, 23 Jan 2019 11:04:36 +0100 Stefan Roese wrote: > On 23.01.19 10:35, Boris Brezillon wrote: > > On Wed, 23 Jan 2019 10:06:59 +0100 > > Stefan Roese wrote: > > > >> On 23.01.19 09:55, Boris Brezillon wrote: > >>> On Wed, 23 Jan 2019 09:23:47 +0100 > >>> Stefan Roese wrote: > >>> > >>>>> This one doesn't, incremental mode (-i) should. > >>>> > >>>> Here you go: > >>>> > >>>> # ./nandbiterrs /dev/mtd5 -k -i > >>>> incremental biterrors test > >>>> Failed to recover 1 bitflips > >>>> Read error after 0 bit errors per page > >>>> > >>>> I'm still unsure how this helps here. > >>> > >>> It helps, it tells us the ECC doesn't work properly (fails to recover > >>> one bitflip), or maybe it's the raw accessors that don't don't work. > >>> > >>>> Is there anything else I should test? > >>> > >>> Add traces to the get_ecc_status() func and print the status value. > >> > >> # ./nandbiterrs /dev/mtd5 -k -i > >> [ 22.098436] gd5f1gq4u_ecc_get_status (124): status=0x00 status2=0x00 > >> [ 22.117184] gd5f1gq4u_ecc_get_status (124): status=0x00 status2=0x00 > >> > >> > >> > >> [ 23.085412] gd5f1gq4u_ecc_get_status (124): status=0x00 status2=0x00 > >> incremental biterrors test > >> [ 23.102973] gd5f1gq4u_ecc_get_status (124): status=0x20 status2=0x00 > >> Failed to recover 1 bitflips > > > > Hm, looks like the ECC reports error as soon as you start writing to > > the NAND. Maybe we have a problem in the write path... > > > >> Read error after 0 bit errors per page > >> > >> Strange, this does not seem to match what the datasheet tells us. Any > >> further ideas what I should test? > > > > Erase a block (save data before if you need to), write random data with > > the ECC enabled and dump it back (once in raw mode, once with ECC > > enabled): > > > > # flash_erase /dev/mtdX 0 1 > > # nandwrite --input-size= /dev/mtdX /dev/urandom > > # nanddump -f /tmp/dump-ecc -l -o /dev/mtdX > > # nanddump -f /tmp/dump-raw -l -o -n /dev/mtdX > > > > Send me both dumps (plus the console output), and we'll see how it > > looks. > > Here you go: > > root@mt7688:~# flash_erase /dev/mtd5 0 1 > Erasing 128 Kibyte @ 0 -- 100 % complete > root@mt7688:~# nandwrite --input-size=2048 /dev/mtd5 /dev/urandom > Writing data to block 0 at offset 0x0 > root@mt7688:~# nanddump -f /tmp/dump-ecc -l 2048 -o /dev/mtd5 > ECC failed: 0 > ECC corrected:[ 100.171120] gd5f1gq4u_ecc_get_status (124): status=0x00 status2=0x00 > 0 > Number of ba[ 100.178436] gd5f1gq4u_ecc_get_status (124): status=0x00 status2=0x00 > d blocks: 2 > Number of bbt blocks: 0 > Block size 131072, page size 2048, OOB size 128 > Dumping data starting at 0x00000000 and ending at 0x00000800... > root@mt7688:~# dmesg -c > [ 100.171120] gd5f1gq4u_ecc_get_status (124): status=0x00 status2=0x00 > [ 100.178436] gd5f1gq4u_ecc_get_status (124): status=0x00 status2=0x00 > root@mt7688:~# nanddump -f /tmp/dump-raw -l 2048 -o -n /dev/mtd5 > Block size 131072, page size 2048, OOB size 128 > Dumping data starting at 0x00000000 and ending at 0x00000800... > root@mt7688:~# dmesg -c > root@mt7688:~# > > The attached files are identical. Thanks for looking into this. First weird thing, the first portion of OOB (bytes 0x800 to 0x83F) are set to 0x0, and I'd expect to have 0xff in there. BTW, can you try nandbiterrs again without the '-k'? ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/