From: Josh Wu <josh.wu@atmel.com>
To: <linux-mtd@lists.infradead.org>
Subject: Re: Does UBIFS NAND ECC info get stored in OOB?
Date: Wed, 31 Dec 2014 10:04:30 +0800 [thread overview]
Message-ID: <54A359AE.3080105@atmel.com> (raw)
In-Reply-To: <CALupW3Dv=OvY-5y_ScG1St8HUBYfXYpTnYAWDt_GJ+3+7KmC9Q@mail.gmail.com>
Hi, Steve
On 12/31/2014 3:44 AM, Steve deRosier wrote:
> Hi All,
>
> Sorry if this is a stupid question, but I found a number of old
> archived messages that explicitly state that UBIFS (actually, probably
> UBI) doesn't utilize the OOB of a NAND flash at all for storing the
> ECC information.
Could you list out these UBI/UBIFS messages so that people can help?
> And as near as I can tell from behavior and code, it
> does certainly store ECC info in the OOB area.
>
> So, does UBIFS utilize the OOB area to store ECC bits? And if not,
> where/how does it store this information?
>
> I'm starting to assume that you're simply saying that UBIFS itself
> doesn't use the OOB area, nor even handles the ECC itself, but that's
> up to the chip driver layer. And that the driver will handle the ECC
> and OOB as appropriate. Am I correct?
yes. I think you are correct.
>
> Details of my question:
>
> We're having some trouble with filesystem corruption on a Linux 3.8
> kernel based on an Atmel SAM9g25 controller. The controller does have
> the PMECC unit.
Does your system can boot up correctly and work sometime? or you cannot
mount your UBI filesystem at all?
Could get me a system boot log about your corruption, and another boot
log without corruption?
>
> It utilizes the mtd/nand/atmel_nand.c driver. This driver has the
> PMECC bits in it and does appear to write/read/correct-via ECC bits in
> the OOB area of the NAND.
>
> We're using UBIFS for our rootfs.
>
> And yes, I understand the 3.8 kernel is old, and we're upgrading, but
> I'm trying to figure out why we're having the problems as I'm assuming
> it's not a bug in the code but more of a configuration or process or
> hardware issu
So could give me some configuration about your PMECC?
4 bits correction in 512 bytes or else? What is your nand flash ecc
minimal requirement?
Best Regards,
Josh Wu
>
> One example of finding that UBI & UBIFS doesn't use the OOB area is "
> this is not a problem for UBI/UBIFS, because neither UBIFS nor UBI use
> OOB area;" from http://www.linux-mtd.infradead.org/doc/ubifs.html
>
> Thanks any help,
> - Steve
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2014-12-31 2:05 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-30 19:44 Does UBIFS NAND ECC info get stored in OOB? Steve deRosier
2014-12-31 2:04 ` Josh Wu [this message]
2015-01-02 18:06 ` Steve deRosier
2015-01-04 3:52 ` Josh Wu
2015-01-09 5:05 ` Steve deRosier
2015-01-12 8:33 ` Josh Wu
2014-12-31 2:15 ` hujianyang
2015-01-02 18:12 ` Steve deRosier
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=54A359AE.3080105@atmel.com \
--to=josh.wu@atmel.com \
--cc=linux-mtd@lists.infradead.org \
/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).