From: Jamie Lokier <jamie@shareable.org>
To: Duke <ezbonites@gmail.com>
Cc: linux-mtd <linux-mtd@lists.infradead.org>
Subject: Re: JFFS2 filesystem integrity issue
Date: Wed, 19 Mar 2008 15:15:28 +0000 [thread overview]
Message-ID: <20080319151528.GA22758@shareable.org> (raw)
In-Reply-To: <79ac09b60803190635h6935e15aiebad0b2a45dc0ce4@mail.gmail.com>
Duke wrote:
> > > For some reason it either seem to read the file incorrectly or the
> > > file is corrupt some how. When this happens I don't loose the
> > > calibration altogether but it is intermittent and sporadic at times.
> > > Has anyone seen something similar? Does the cause seem realistic?
> > > Has anyone had a possible corruption like this?
> >
> > I have seen similar, and it was due to borderline timing or signal
> > integrity issues, possibly affected by what else the CPU was doing at
> > the time.
>
> Didn't adjusting the timing of the banks help you any?
I'm not sure what you mean by this. The only adjustment that can be
made in software on our device, as far as I know, is to reduce the
clock frequency.
> > It was fixed in our case by improving the PCB design.
>
> I'm doing a rev of the board but as far as improving the design, I
> have no reason to adjust my memory design.
> Perhaps you have something I can look for?
I don't know what fixed our design. A new hardware rev arrived, and
the problem no longer occurred. But my instincts suggest two
possibilities:
- Supply voltage too low, or insufficient stabilisation near the chips.
- Excessive propagation delay between the CPU and flash, failing
to meet timing specs.
Both of these I've observed on our boards, and both of them cause
spurious bit errors when reading flash (or RAM for that matter). I
noticed that these bit errors, in both cases, are dependent on what
other activity the board is doing at a similar time - e.g. reading
from disk, booting, CPU busy or idle, even specific code sequences, etc.
Spurious bit errors results in JFFS2 temporary file corruption on
reads, similar to what you have. Unfortunately, JFFS2 doesn't report
this as an error. Because of the way it works, it can only silently
change the file contents.
If you can reproduce these occasional errors by soak testing, try
lowering the clock frequency. If the errors go away, you know it's
probably a marginal hardware problem.
-- Jamie
prev parent reply other threads:[~2008-03-19 15:15 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-19 3:45 JFFS2 filesystem integrity issue Duke
2008-03-19 4:02 ` Jamie Lokier
2008-03-19 13:35 ` Duke
2008-03-19 15:15 ` Jamie Lokier [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=20080319151528.GA22758@shareable.org \
--to=jamie@shareable.org \
--cc=ezbonites@gmail.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.