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
next prev parent 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