From: Artem Bityutskiy <dedekind1@gmail.com>
To: Peter Barada <peter.barada@gmail.com>
Cc: linux-mtd@lists.infradead.org, Peter Barada <peter.barada@logicpd.com>
Subject: Re: Preventing JFFS2 partial page writes?
Date: Tue, 28 Jun 2011 12:39:47 +0300 [thread overview]
Message-ID: <1309253992.23597.62.camel@sauron> (raw)
In-Reply-To: <1309253646.23597.58.camel@sauron>
On Tue, 2011-06-28 at 12:34 +0300, Artem Bityutskiy wrote:
> OK, thanks for explanation. I am not very good in this area as I do not
> have much experience dealing with OOB, but here is what I thing.
>
> 1. Linux MTD code was _not_ designed for "ECC'ed OOB".
> 2. I do not really know what MTD_OOB_RAW is, and the comment in mtd.h
> is not very verbose.
> 3. But in my opinion MTD_OOB_AUTO makes most sense and should be used
> everywhere except for some tricky cases when you want to test things
> by writing incorrect ECC, or you have an image with ECC and you want
> to flash it as is.
> 4. In general, OOB should be considered as belonging to the driver, and
> modern software should not rely on OOB at all.
> 5. So MTD_OOB_AUTO make free bytes in OOB look like a contiguous buffer
> which the _user_ can freely and _independently_ use.
> 6. In your case only this assumption does not work and your ecclayout is
> incorrect because the OOB areas you expose are not independent.
> 7. So in your case your ecclayout should be changed and you should
> expose only independent ECC bytes.
To put it differently, I current model does not distinguish (I think,
correct me if I am wrong) between ECC'd OOB bytes and ECC'less OOB
bytes. BTW, does your flash has the latter?
So MTD would need some work to make it distinguish between those 2 types
of OOB bytes - probably additional info could be added to the ooblayout
structure, and the interfaces could be improved. How exactly - dunno,
I'd first need to figure out what MTD_OOB_RAW is - may be Brian or Ivan
could comment.
--
Best Regards,
Artem Bityutskiy
next prev parent reply other threads:[~2011-06-28 9:39 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-14 16:19 Preventing JFFS2 partial page writes? Peter Barada
2011-06-22 6:04 ` Artem Bityutskiy
2011-06-22 15:28 ` Peter Barada
2011-06-22 17:07 ` Ivan Djelic
2011-06-22 19:17 ` Peter Barada
2011-06-22 20:06 ` Ivan Djelic
2011-06-24 15:09 ` Peter Barada
2011-06-24 19:26 ` Artem Bityutskiy
2011-06-27 14:31 ` Peter Barada
2011-06-28 9:34 ` Artem Bityutskiy
2011-06-28 9:39 ` Artem Bityutskiy [this message]
2011-07-01 20:48 ` Ivan Djelic
2011-07-04 6:27 ` Artem Bityutskiy
2011-06-28 18:56 ` Peter Barada
2011-06-29 6:33 ` Artem Bityutskiy
2011-06-30 18:05 ` Peter Barada
2011-07-01 20:52 ` Ivan Djelic
2011-07-20 15:02 ` Peter Barada
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=1309253992.23597.62.camel@sauron \
--to=dedekind1@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=peter.barada@gmail.com \
--cc=peter.barada@logicpd.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;
as well as URLs for NNTP newsgroup(s).