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 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.