From: Artem Bityutskiy <dedekind1@gmail.com>
To: Murali N <nalajala.murali@gmail.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: Doubt regarding mtd test ( mtd_oobtest ) interpretation of oob data !
Date: Wed, 16 Sep 2009 13:50:23 +0300 [thread overview]
Message-ID: <1253098223.3778.16.camel@localhost> (raw)
In-Reply-To: <630851df0909160320y1721f8d8m23b0675d57558c28@mail.gmail.com>
On Wed, 2009-09-16 at 15:50 +0530, Murali N wrote:
> Hi Artem, can you please explain me a bit more about OOB_PLACE mode?.
> Also in mtd tests i have seen there is ooboffs field being used in
> OOB_AUTO mode.My doubt here was why AUTO mode cares about ooboffs
> field.ECC layout structure is defined clearly in the AUTO mode? am i
> correct? then what is the significance of ooboffs field?
>
> i am not caring the ooboffs when the AUTO mode is selected in my
> driver? i was bit confused where it is mentioned in the MTD
> specification? can you please point to me if you have any info!!!
I do not remember all the glory details, but in short, OOB_PLACE is
used when you want to put your date to a specific _physical_ offset
withing the OOB. Very simple and straightforward. But I consider this
as legacy and I think no one should ever use this, and this should
be forbidden. I might be wrong, though.
OOB_AUTO is the sanest thing. Your OOB area may contain N small unused
regions of different length. E.g., see OneNAND's onenand_oob_64.
Different flashes have different layout. And OOB_AUTO is about
abstracting this, so all these small regions look like a contiguous
buffer to the applications. Size of this buffer is
mtd->ecclayout->oobavail bytes. You may write data do different offsets
of this buffer, and they will be automatically placed to corresponding
_physical_ offsets within the OOB. So applications do not care about
the OOB fragmentation, and always work with this _logical_ OOB_AUTO
buffer.
In OOB_AUTO case you cannot access the ECC bytes, because they are
hidden from you.
In OOB_PLACE you can, and I think it is a bad idea because it is not
applications' business to deal with ECCs. This should be hidden.
That's all I remember at this point. Nowadays we do not use OOB much.
E.g., UBI/UBIFS does not use it. Using OOB is bad, because modern
flashes may utilize _whole_ OOB for ECCs.
HTH.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
prev parent reply other threads:[~2009-09-16 10:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-16 7:09 Doubt regarding mtd test ( mtd_oobtest ) interpretation of oob data ! Murali N
2009-09-16 7:23 ` Artem Bityutskiy
2009-09-16 9:36 ` Artem Bityutskiy
2009-09-16 10:20 ` Murali N
2009-09-16 10:50 ` Artem Bityutskiy [this message]
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=1253098223.3778.16.camel@localhost \
--to=dedekind1@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=nalajala.murali@gmail.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).