From: Dan Malek <dan@embeddededge.com>
To: Brian Waite <waite@skycomputers.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
Gary Thomas <gary@mlbassoc.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
linuxppc-dev <linuxppc-dev@lists.linuxppc.org>
Subject: Re: Disable cache on 74xx
Date: Thu, 20 Feb 2003 11:14:03 -0500 [thread overview]
Message-ID: <3E54FECB.5090604@embeddededge.com> (raw)
In-Reply-To: 200302201047.02490.waite@skycomputers.com
Brian Waite wrote:
> .... The memory controller (gt64260) seems to be
> doing something very wrong and it is thought to be a cache coherency issue.
The problem is cache coherency is central to the operation of processor
bus. One possibility, especially in the example you described, is the gt
is generating incorrect cache coherency control cycles on the bus. Disabling
the processor cache isn't going to affect this.
> So to prove this, I was asked to try running without any sort of cache.
Make sure you disable it in the memory controller as well.
> Hopefully between Gary's information and yours, Dan I can convince people
> that it is futile.
Linux is a very poor diagnostic tool. When I run Linux and discover this
type of problem, I reduce it down into a non-Linux diagnostic that can
generate the same type of bus cycles. That way you can just flash it into
rom and let some hardware engineer run it over and over without having to
boot up something as complex as Linux and sorting through millions of
bus cycles for the failure mode. With these types of problems you have
to determine exactly what causes the failure. Since the processor hangs
so completely it should be easy to see the condition of the failure. If
it is a memory controller timing problem, you should see exactly what
failed and it should be clear how to program the controller to correct it.
Of course, like Ben said, check the errata.
Good Luck.
-- Dan
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2003-02-20 16:14 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-19 20:52 Disable cache on 74xx Brian Waite
2003-02-19 21:07 ` Benjamin Herrenschmidt
2003-02-19 22:48 ` Gary Thomas
2003-02-20 13:55 ` Brian Waite
2003-02-20 14:01 ` Gary Thomas
2003-02-20 14:09 ` Geert Uytterhoeven
2003-02-20 15:23 ` Dan Malek
2003-02-20 15:47 ` Brian Waite
2003-02-20 15:54 ` Gary Thomas
2003-02-20 15:55 ` Benjamin Herrenschmidt
2003-02-20 16:14 ` Dan Malek [this message]
2003-02-20 16:51 ` Mark A. Greer
2003-02-20 14:09 ` Brian Waite
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=3E54FECB.5090604@embeddededge.com \
--to=dan@embeddededge.com \
--cc=benh@kernel.crashing.org \
--cc=gary@mlbassoc.com \
--cc=geert@linux-m68k.org \
--cc=linuxppc-dev@lists.linuxppc.org \
--cc=waite@skycomputers.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).