public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Robert Jarzmik <robert.jarzmik@free.fr>
To: Mike Dunn <mikedunn@newsguy.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: [PATCH 1/3] mtd: nand/docg4: add support for writing in reliable mode
Date: Sat, 15 Dec 2012 11:37:43 +0100	[thread overview]
Message-ID: <87ip83ob2g.fsf@free.fr> (raw)
In-Reply-To: <50C638B0.8060007@newsguy.com> (Mike Dunn's message of "Mon, 10 Dec 2012 11:32:00 -0800")

Mike Dunn <mikedunn@newsguy.com> writes:

Hi Mike,

Sorry for the late reply, I was taken over by work.

> 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?
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?
Yes. As a side note, the reliable mode of docg3 write on consecutive 512b pages
(see log in commit c3de8a8a5a28603f8d318245992dbcda2e88a007).

>> 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.
OK, your choice.

As I have now the rootfs (ubifs on /dev/mtd2) on /, I cannot use docg3 as a
module and remove it anymore. Hence my hope somebody comes out with a solution
so that I have :
 - /dev/mtd1 in reliable mode (for the SPL)
 - /dev/mtd2 in normal mode (for root filesystem)

By now, I chose to use the SPL to rewrite itself (ie. barebox overwrites
/dev/mtd2 content). That's a bit sub-optimal as a fully booted kernel would be
able to make more checks (reread written blocks, check OOB signatures, ...).

> 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.
Ah good point, I will check on the docg3 how it worked, to see if they used also
the reliable mode for BBT table.

Cheers.

-- 
Robert

  reply	other threads:[~2012-12-15 10:37 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
2012-12-15 10:37       ` Robert Jarzmik [this message]
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=87ip83ob2g.fsf@free.fr \
    --to=robert.jarzmik@free.fr \
    --cc=linux-mtd@lists.infradead.org \
    --cc=mikedunn@newsguy.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