From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Daniel Palmer <daniel@0x0f.com>
Cc: linux-mtd@lists.infradead.org, richard@nod.at,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v3] mtd: spinand: add support for Foresee FS35ND0*G parts
Date: Mon, 23 Aug 2021 17:03:54 +0200 [thread overview]
Message-ID: <20210823170354.2dccabd5@xps13> (raw)
In-Reply-To: <CAFr9PXkSeeHNn-KVyrVxp6RRdLYExTgWpheWKLLSZqEo_EHvRg@mail.gmail.com>
Hi Daniel,
Daniel Palmer <daniel@0x0f.com> wrote on Mon, 23 Aug 2021 23:54:20
+0900:
> Hi Miquel,
>
> On Mon, 23 Aug 2021 at 23:21, Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > I am not sure to follow, above the software says "3 corrected bf" while
>
> Due to the status being "between 0 and 3 bitflips" I think it'll
> basically report 3 most of the time.
> As a refresher we seem to have a status for 0 - 3 flips but ok, 4 bit
> flips but ok, and >4 flips no go.
> In most cases (0 - 3) the driver is reporting 3.
>
> > I thought the problem was when getting 4 bf, but the dump show many
> > more. Can you show me how it behaves:
> > * erase (like you did)
> > * insert {1, 2, 3, 4, 5} bf and show the dump each time?
>
> Here's a complete log of erasing the page then flipping all the bits
> in the first byte.
>
> # flash_erase /dev/mtd0 0x8000000 1
> Erasing 128 Kibyte @ 8000000 -- 100 % complete
> # nanddump --bb=dumpbad -s 0x8000000 -l 1 -c -p /dev/mtd0 | head -n 10
> ECC failed: 0
> ECC corrected: 6249
> Number of bad blocks: 0
> Number of bbt blocks: 0
> Block size 131072, page size 2048, OOB size 64
> Dumping data starting at 0x08000000 and ending at 0x08000001...
> ECC: 3 corrected bitflip(s) at offset 0x08000000
> 0x08000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000090: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> # nandflipbits /dev/mtd0 0@0x8000000
> # nanddump --bb=dumpbad -s 0x8000000 -l 1 -c -p /dev/mtd0 | head -n 10
> ECC failed: 0
> ECC corrected: 6252
> Number of bad blocks: 0
> Number of bbt blocks: 0
> Block size 131072, page size 2048, OOB size 64
> Dumping data starting at 0x08000000 and ending at 0x08000001...
> ECC: 3 corrected bitflip(s) at offset 0x08000000
> 0x08000000: fe ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
How is this result possible? You are dumping with the ECC engine
enabled, it reports 3 bf (meaning that it is actually running, at least
the software really thinks there is an on-die engine enabled) but the
data has not been corrected. I expect the first byte to be 0xFF after
correction. Only with -n (raw dump) we should see this.
> 0x08000010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000090: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
Thanks,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Daniel Palmer <daniel@0x0f.com>
Cc: linux-mtd@lists.infradead.org, richard@nod.at,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v3] mtd: spinand: add support for Foresee FS35ND0*G parts
Date: Mon, 23 Aug 2021 17:03:54 +0200 [thread overview]
Message-ID: <20210823170354.2dccabd5@xps13> (raw)
In-Reply-To: <CAFr9PXkSeeHNn-KVyrVxp6RRdLYExTgWpheWKLLSZqEo_EHvRg@mail.gmail.com>
Hi Daniel,
Daniel Palmer <daniel@0x0f.com> wrote on Mon, 23 Aug 2021 23:54:20
+0900:
> Hi Miquel,
>
> On Mon, 23 Aug 2021 at 23:21, Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > I am not sure to follow, above the software says "3 corrected bf" while
>
> Due to the status being "between 0 and 3 bitflips" I think it'll
> basically report 3 most of the time.
> As a refresher we seem to have a status for 0 - 3 flips but ok, 4 bit
> flips but ok, and >4 flips no go.
> In most cases (0 - 3) the driver is reporting 3.
>
> > I thought the problem was when getting 4 bf, but the dump show many
> > more. Can you show me how it behaves:
> > * erase (like you did)
> > * insert {1, 2, 3, 4, 5} bf and show the dump each time?
>
> Here's a complete log of erasing the page then flipping all the bits
> in the first byte.
>
> # flash_erase /dev/mtd0 0x8000000 1
> Erasing 128 Kibyte @ 8000000 -- 100 % complete
> # nanddump --bb=dumpbad -s 0x8000000 -l 1 -c -p /dev/mtd0 | head -n 10
> ECC failed: 0
> ECC corrected: 6249
> Number of bad blocks: 0
> Number of bbt blocks: 0
> Block size 131072, page size 2048, OOB size 64
> Dumping data starting at 0x08000000 and ending at 0x08000001...
> ECC: 3 corrected bitflip(s) at offset 0x08000000
> 0x08000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000090: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> # nandflipbits /dev/mtd0 0@0x8000000
> # nanddump --bb=dumpbad -s 0x8000000 -l 1 -c -p /dev/mtd0 | head -n 10
> ECC failed: 0
> ECC corrected: 6252
> Number of bad blocks: 0
> Number of bbt blocks: 0
> Block size 131072, page size 2048, OOB size 64
> Dumping data starting at 0x08000000 and ending at 0x08000001...
> ECC: 3 corrected bitflip(s) at offset 0x08000000
> 0x08000000: fe ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
How is this result possible? You are dumping with the ECC engine
enabled, it reports 3 bf (meaning that it is actually running, at least
the software really thinks there is an on-die engine enabled) but the
data has not been corrected. I expect the first byte to be 0xFF after
correction. Only with -n (raw dump) we should see this.
> 0x08000010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000090: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
Thanks,
Miquèl
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Daniel Palmer <daniel@0x0f.com>
Cc: linux-mtd@lists.infradead.org, richard@nod.at,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v3] mtd: spinand: add support for Foresee FS35ND0*G parts
Date: Mon, 23 Aug 2021 17:03:54 +0200 [thread overview]
Message-ID: <20210823170354.2dccabd5@xps13> (raw)
In-Reply-To: <CAFr9PXkSeeHNn-KVyrVxp6RRdLYExTgWpheWKLLSZqEo_EHvRg@mail.gmail.com>
Hi Daniel,
Daniel Palmer <daniel@0x0f.com> wrote on Mon, 23 Aug 2021 23:54:20
+0900:
> Hi Miquel,
>
> On Mon, 23 Aug 2021 at 23:21, Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > I am not sure to follow, above the software says "3 corrected bf" while
>
> Due to the status being "between 0 and 3 bitflips" I think it'll
> basically report 3 most of the time.
> As a refresher we seem to have a status for 0 - 3 flips but ok, 4 bit
> flips but ok, and >4 flips no go.
> In most cases (0 - 3) the driver is reporting 3.
>
> > I thought the problem was when getting 4 bf, but the dump show many
> > more. Can you show me how it behaves:
> > * erase (like you did)
> > * insert {1, 2, 3, 4, 5} bf and show the dump each time?
>
> Here's a complete log of erasing the page then flipping all the bits
> in the first byte.
>
> # flash_erase /dev/mtd0 0x8000000 1
> Erasing 128 Kibyte @ 8000000 -- 100 % complete
> # nanddump --bb=dumpbad -s 0x8000000 -l 1 -c -p /dev/mtd0 | head -n 10
> ECC failed: 0
> ECC corrected: 6249
> Number of bad blocks: 0
> Number of bbt blocks: 0
> Block size 131072, page size 2048, OOB size 64
> Dumping data starting at 0x08000000 and ending at 0x08000001...
> ECC: 3 corrected bitflip(s) at offset 0x08000000
> 0x08000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000090: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> # nandflipbits /dev/mtd0 0@0x8000000
> # nanddump --bb=dumpbad -s 0x8000000 -l 1 -c -p /dev/mtd0 | head -n 10
> ECC failed: 0
> ECC corrected: 6252
> Number of bad blocks: 0
> Number of bbt blocks: 0
> Block size 131072, page size 2048, OOB size 64
> Dumping data starting at 0x08000000 and ending at 0x08000001...
> ECC: 3 corrected bitflip(s) at offset 0x08000000
> 0x08000000: fe ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
How is this result possible? You are dumping with the ECC engine
enabled, it reports 3 bf (meaning that it is actually running, at least
the software really thinks there is an on-die engine enabled) but the
data has not been corrected. I expect the first byte to be 0xFF after
correction. Only with -n (raw dump) we should see this.
> 0x08000010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
> 0x08000090: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
Thanks,
Miquèl
next prev parent reply other threads:[~2021-08-23 15:05 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-11 8:49 [PATCH v3] mtd: spinand: add support for Foresee FS35ND0*G parts Daniel Palmer
2021-08-11 8:49 ` Daniel Palmer
2021-08-11 8:49 ` Daniel Palmer
2021-08-16 8:11 ` Miquel Raynal
2021-08-16 8:11 ` Miquel Raynal
2021-08-16 8:11 ` Miquel Raynal
2021-08-23 14:19 ` Daniel Palmer
2021-08-23 14:19 ` Daniel Palmer
2021-08-23 14:19 ` Daniel Palmer
2021-08-23 14:21 ` Miquel Raynal
2021-08-23 14:21 ` Miquel Raynal
2021-08-23 14:21 ` Miquel Raynal
2021-08-23 14:54 ` Daniel Palmer
2021-08-23 14:54 ` Daniel Palmer
2021-08-23 14:54 ` Daniel Palmer
2021-08-23 15:03 ` Miquel Raynal [this message]
2021-08-23 15:03 ` Miquel Raynal
2021-08-23 15:03 ` Miquel Raynal
2021-08-23 16:16 ` Daniel Palmer
2021-08-23 16:16 ` Daniel Palmer
2021-08-23 16:16 ` Daniel Palmer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210823170354.2dccabd5@xps13 \
--to=miquel.raynal@bootlin.com \
--cc=daniel@0x0f.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=richard@nod.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.