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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.