From: Gerhard Sittig <gsi@denx.de>
To: David Mosberger <davidm@egauge.net>
Cc: Brian Norris <computersforpeace@gmail.com>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
"Gupta, Pekon" <pekon@ti.com>,
Artem Bityutskiy <dedekind1@gmail.com>
Subject: Re: [PATCH v4 1/5] mtd: nand: Detect Micron flash with on-die ECC (aka "internal ECC") enabled.
Date: Thu, 3 Apr 2014 09:10:58 +0200 [thread overview]
Message-ID: <20140403071058.GF11339@book.gsilab.sittig.org> (raw)
In-Reply-To: <CALnQHM3B=-159u1BesCbEN=XQuosG0mkGb-emQUJJFETR7gd=g@mail.gmail.com>
On Wed, 2014-04-02 at 11:02 -0600, David Mosberger wrote:
>
> AFAIK, ECC selection is *per chip* (not per filesystem)
> and is hard-coded by a combination of config-options
> and platform-specific drivers. Isn't that true?
Let's look at the boot stages:
- ROM loader code reads bootloader code
- bootloader code reads bootloader configuration, and boot files
(kernel image, device tree)
- OS kernels read and write the filesystem
So each of those phases run at different times and operate on
different areas of the chip.
- the bootloader need not write nor modify ROM loader data
- the OS kernel need not write nor modify bootloader data or boot
files
Which means that you can perfectly operate those individual areas
with different ECC methods, depending on the capabilities of the
software that is running at this moment, and your preferences or
having access to different levels of hardware support, the will
or capability/incapability to sync among those components, or to
adjust and update these individual boot phases, etc.
I really don't see that enabling on-die-ECC in one stage requires
all other stages to follow. It's one apparent approach, but need
not be the only one. That's what previous messages tried to say.
Does this explanation help answer your question?
virtually yours
Gerhard Sittig
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
next prev parent reply other threads:[~2014-04-03 7:12 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-31 23:28 [PATCH v4 0/5] mtd: nand: Add on-die ECC support David Mosberger
2014-03-31 23:28 ` [PATCH v4 1/5] mtd: nand: Detect Micron flash with on-die ECC (aka "internal ECC") enabled David Mosberger
2014-04-01 6:39 ` Brian Norris
2014-04-01 15:26 ` David Mosberger
2014-04-02 7:27 ` Gupta, Pekon
2014-04-02 15:07 ` David Mosberger-Tang
2014-04-02 16:50 ` Gerhard Sittig
2014-04-02 17:02 ` David Mosberger
2014-04-03 7:10 ` Gerhard Sittig [this message]
[not found] ` <CALnQHM1VLY=t6CaQtHGtp=enNCCj=Xz_QN7sj20hUCd8ZJjKpA@mail.gmail.com>
2014-04-03 15:26 ` David Mosberger
2014-03-31 23:28 ` [PATCH v4 2/5] mtd: nand: Add NAND_ECC_HW_ON_DIE ECC-mode David Mosberger
2014-04-01 6:02 ` Gupta, Pekon
2014-04-01 15:32 ` David Mosberger
2014-04-01 7:24 ` Brian Norris
2014-04-01 15:41 ` David Mosberger
2014-03-31 23:28 ` [PATCH v4 3/5] mtd: nand: Enable subpage-reads on flashes with on-die ECC enabled David Mosberger
2014-03-31 23:28 ` [PATCH v4 4/5] mtd: nand: Allocate extra buffers needed for on-die ECC controller David Mosberger
2014-04-01 7:28 ` Brian Norris
2014-04-01 7:37 ` Gupta, Pekon
2014-04-01 8:24 ` Brian Norris
2014-03-31 23:28 ` [PATCH v4 5/5] mtd: nand: Improve bitflip detection for on-die ECC scheme David Mosberger
2014-04-01 6:29 ` Gupta, Pekon
2014-04-01 15:51 ` David Mosberger
2014-04-01 17:30 ` Brian Norris
2014-04-01 7:50 ` Brian Norris
[not found] ` <CALnQHM2Afp8LD6MtGQTT5jrcb9xJdYXRGD0TZ_s5GASZsbRZeg@mail.gmail.com>
2014-04-01 17:33 ` Brian Norris
2014-04-01 18:01 ` Brian Norris
2014-04-01 18:13 ` David Mosberger-Tang
2014-04-02 7:57 ` Gupta, Pekon
2014-04-01 8:02 ` [PATCH v4 0/5] mtd: nand: Add on-die ECC support Brian Norris
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=20140403071058.GF11339@book.gsilab.sittig.org \
--to=gsi@denx.de \
--cc=computersforpeace@gmail.com \
--cc=davidm@egauge.net \
--cc=dedekind1@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=pekon@ti.com \
/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