From: Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
To: "Bean Huo (beanhuo)" <beanhuo-AL4WhLSQfzjQT0dZR+AlfA@public.gmane.org>
Cc: Thomas Petazzoni
<thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"pawel.moll-5wv7dgnIgG8@public.gmane.org"
<pawel.moll-5wv7dgnIgG8@public.gmane.org>,
Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
"richard-/L3Ra7n9ekc@public.gmane.org"
<richard-/L3Ra7n9ekc@public.gmane.org>,
Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
"marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"
<marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
"linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
"galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org"
<galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
Cyrille Pitchen
<cyrille.pitchen-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>,
"computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"
<computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: [PATCH 4/5] mtd: nand: add support for Micron on-die ECC
Date: Tue, 11 Apr 2017 16:49:52 +0200 [thread overview]
Message-ID: <20170411164952.52357b4f@bbrezillon> (raw)
In-Reply-To: <106593e04c494120b323836b8bc54f7f-aBoyCxvc2dBaXkNJqdKpEhSpLNRU/VIH@public.gmane.org>
On Tue, 11 Apr 2017 14:26:02 +0000
"Bean Huo (beanhuo)" <beanhuo-AL4WhLSQfzjQT0dZR+AlfA@public.gmane.org> wrote:
> >
> >Hi Bean,
> >
> >On Mon, 3 Apr 2017 11:31:05 +0000
> >"Bean Huo (beanhuo)" <beanhuo-AL4WhLSQfzjQT0dZR+AlfA@public.gmane.org> wrote:
> >
> >> Hi, Boris and Thomas
> >>
> >> >>
> >> >> Ok, but I recommend that 70s should be the first choice on this
> >> >> single solution, it doesn't need to read twice to detect its bitflips count.
> >> >
> >> >That's exactly why we need to differentiate the 2 chips.
> >>
> >> Sorry for later this response.
> >> Below is the pseudo codes about how to differentiate these 2 series
> >> parallel NAND with on-die ECC:
> >>
> >> if (NAND == SLC ) { // on-die ECC only exists in SLC //check device ID
> >> byte 4
> >> if ((ID.byte4 & 0x02) == 0x02) {// internal ECC level ==10b
> >
> >So here the MT29F1G08ABADAWP datasheet says 0x2 <=> 4bit/512bytes ECC.
> >
> >> if (ID.byte4 & 0x80) {//on-Die ECC enabled
> >
> >Did you read my last reply?
> >Thomas discovered that ID[4].bit7 is actually reflecting the ECC engine state (1 if
> >the engine is enabled, 0 if it's disabled), not whether the NAND supports on-die
> >ECC or not, so no this test is not reliable.
> >
> >> if (ONFI.byte112 == 4)
> >> 60s SLC NAND with on-die ECC
> >> else if (ONFI.byte112 == 8)
> >> 70s SLC NAND with on-die ECC
> >
> >This is completely fucked up! Now the ONFI param page says the NAND requires
> >8bits/512bytes, while the ID bytes advertised an on-die ECC providing
> >4bits/512bytes correctability.
> >So either your algorithm is wrong, or the ID and ONFI param page are contracting
> >(not sure what solution I'd prefer...).
> >
> >> else
> >> Doesn't support on-die ECC
> >
> >Sorry to say that, but I find it worrisome that even someone from Micron is not
> >able to get it right.
> >
>
> Sorry, would you please specify which one is wrong or confuse you?
The initial 'if (ID.byte4 & 0x80)' is wrong, because this bit is only
set when someone enabled the ECC engine using the SET_FEATURE command
(this has been verified by Thomas who tried to disable the feature in
the bootloader and noticed that on-die ECC was reported as
'unsupported' by the kernel).
Maybe I was wrong about your 'if ((ID.byte4 & 0x02) == 0x02)' test,
because you apparently only mask bit 1 and not bits 0 and 1.
Anyway, I can't tell if this is valid because I don't have access to
the M79A datasheets you're referring to.
>
> >I think we'll stick to the model name to detect whether on-die ECC is supported.
> >
> You want one solution that can clearly differentiate two serial SLC NAND, but NAND ONFI table
> and device Id are always changing. It is easy to draw a perfect solution to do that.
> OK, if you like maintain a huge/ugly table in MTD, please do that.
I'm not happy with the big ID table either, but unless I'm missing
something, what you propose does not work for the MT29F1G08ABADAWP, so
I prefer to rely on something I can trust.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-04-11 14:49 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <538805ebf8e64015a8b833de755652b3@SIWEX5A.sing.micron.com>
[not found] ` <538805ebf8e64015a8b833de755652b3-aBoyCxvc2dBaXkNJqdKpEhSpLNRU/VIH@public.gmane.org>
2017-03-22 13:20 ` [PATCH 4/5] mtd: nand: add support for Micron on-die ECC Bean Huo (beanhuo)
[not found] ` <8a171dacd20c45bd8285ecc5dbe8854a-aBoyCxvc2dBaXkNJqdKpEhSpLNRU/VIH@public.gmane.org>
2017-03-22 13:45 ` Boris Brezillon
2017-03-22 14:39 ` Bean Huo (beanhuo)
[not found] ` <0dccc0abcf234e98be6d340027cf1a30-aBoyCxvc2dBaXkNJqdKpEhSpLNRU/VIH@public.gmane.org>
2017-03-22 14:52 ` Boris Brezillon
2017-03-22 17:11 ` Bean Huo (beanhuo)
2017-04-03 11:31 ` Bean Huo (beanhuo)
[not found] ` <414dd35931814ce38381a251917ad79f-aBoyCxvc2dBaXkNJqdKpEhSpLNRU/VIH@public.gmane.org>
2017-04-11 12:51 ` Boris Brezillon
2017-04-11 14:26 ` Bean Huo (beanhuo)
[not found] ` <106593e04c494120b323836b8bc54f7f-aBoyCxvc2dBaXkNJqdKpEhSpLNRU/VIH@public.gmane.org>
2017-04-11 14:49 ` Boris Brezillon [this message]
2017-04-11 15:10 ` Boris Brezillon
2017-04-11 15:28 ` Bean Huo (beanhuo)
2017-04-11 15:02 ` Bean Huo (beanhuo)
[not found] ` <90300f14cd2a4ae6967d8be0f7dff4e9-aBoyCxvc2dBaXkNJqdKpEhSpLNRU/VIH@public.gmane.org>
2017-04-11 15:30 ` Boris Brezillon
2017-04-11 17:01 ` Bean Huo (beanhuo)
[not found] ` <5a96e73ef951414a82c01b67088b24d3-aBoyCxvc2dBaXkNJqdKpEhSpLNRU/VIH@public.gmane.org>
2017-04-12 7:03 ` Boris Brezillon
2017-04-13 14:08 ` Bean Huo (beanhuo)
2017-03-21 10:38 [PATCH 0/5] mtd: nand: add support for " Thomas Petazzoni
[not found] ` <1490092686-16509-1-git-send-email-thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
2017-03-21 10:38 ` [PATCH 4/5] mtd: nand: add support for Micron " Thomas Petazzoni
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=20170411164952.52357b4f@bbrezillon \
--to=boris.brezillon-wi1+55scjutkeb57/3fjtnbpr1lh4cv8@public.gmane.org \
--cc=beanhuo-AL4WhLSQfzjQT0dZR+AlfA@public.gmane.org \
--cc=computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=cyrille.pitchen-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
--cc=ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org \
--cc=linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
--cc=pawel.moll-5wv7dgnIgG8@public.gmane.org \
--cc=richard-/L3Ra7n9ekc@public.gmane.org \
--cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).