From: Mike Dunn <mikedunn@newsguy.com>
To: Robert Jarzmik <robert.jarzmik@free.fr>
Cc: linux-mtd@lists.infradead.org
Subject: Re: [PATCH 1/3] mtd: nand/docg4: add support for writing in reliable mode
Date: Mon, 10 Dec 2012 11:32:00 -0800 [thread overview]
Message-ID: <50C638B0.8060007@newsguy.com> (raw)
In-Reply-To: <87hanvplmy.fsf@free.fr>
Hi Robert. Nice to hear from you.
On 12/09/2012 02:25 AM, Robert Jarzmik wrote:
> Mike Dunn <mikedunn@newsguy.com> writes:
>
>> The controller on the docg4 has a "reliable" mode, where consecutive 2k pages
>> are used in parallel. The initial program loader (IPL) on my Treo 680 expects
>> the secondary program loader (SPL) to be written in this mode. This patch adds
>> support for writing data in reliable mode, by way of a module parameter.
>> Support for reading in this mode (as the IPL does) is not supported yet, but
>> alternate (even-numbered) 2k pages written in reliable mode can be read normally
>> (odd-numbered pages will contain junk and generate ecc errors).
>
> Hi Mike,
>
> I was considering adding this to the docg3 driver, but I didn't because I was
> afraid what would happen if you change this mode *after* mounting a partition.
Well, it's a module parameter, so the mode can't change unless the module is
reloaded, which means everything must be umounted first, right?
> Imagine you have your rootfs mounted on /dev/mtd2, and u-boot is in /dev/mtd1 :
> wouldn't changing the reliable mode to write "mtd1" corrupt all writes to mtd2 ?
I think this may only apply to docg3 (and docp3). If I'm interpreting your
point correctly and IIRC from working with the docp3... the docg4 doesn't have
"planes". Reliable mode uses *consecutive* 2k pages on the docg4, so the
side-effects of writing in reliable mode are restricted to the adjacent page,
not some far-away offset. The lack of "planes" on the docg4 greatly simplifies
things.
Does this make sense?
>
> The patch I chose to make barebox (instead of u-boot) work was to write the
> barebox part with a special tool which "duplicates" pages, which ends up in the
> same flash writes.
>
> My feeling here is this mode should be "mtd partition bound", not driver bound
> if you want to have it in your driver.
My thinking is that it's a special case, probably limited to writing the SPL, so
making it a module parameter where the user has to explicitly specify it would
make it available to users without too much risk. I also put a scary warning
about it in a comment in the driver source.
BTW, I think that my factory babdblock tables are written in reliable mode, so
it would be useful to add support to the driver for reading in this mode as well
(this patch only writes in reliable mode). Data written in reliable mode can
still be read normally from the even-numbered 2k pages (I don't recall if this
is the case for the docg3), so I can read the factory bbt now, just not as reliably.
Thanks,
Mike
next prev parent reply other threads:[~2012-12-10 19:31 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-07 20:07 [PATCH 0/3] mtd: nand/docg4: set of fixes and enhancements Mike Dunn
2012-12-07 20:07 ` [PATCH 1/3] mtd: nand/docg4: add support for writing in reliable mode Mike Dunn
2012-12-09 10:25 ` Robert Jarzmik
2012-12-09 10:38 ` Robert Jarzmik
2012-12-10 19:34 ` Mike Dunn
2012-12-10 19:32 ` Mike Dunn [this message]
2012-12-15 10:37 ` Robert Jarzmik
2012-12-07 20:07 ` [PATCH 2/3] mtd: nand/docg4: reserve bb marker area in ecclayout Mike Dunn
2012-12-07 20:07 ` [PATCH 3/3] mtd: nand/docg4: fix and improve read of factory bbt Mike Dunn
2012-12-12 15:05 ` [PATCH 0/3] mtd: nand/docg4: set of fixes and enhancements Artem Bityutskiy
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=50C638B0.8060007@newsguy.com \
--to=mikedunn@newsguy.com \
--cc=linux-mtd@lists.infradead.org \
--cc=robert.jarzmik@free.fr \
/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