All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Mark A. Greer" <mgreer@mvista.com>
To: Dan Malek <dan@embeddededge.com>
Cc: Brian Waite <waite@skycomputers.com>,
	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 09:51:23 -0700	[thread overview]
Message-ID: <3E55078B.4040208@mvista.com> (raw)
In-Reply-To: <3E54FECB.5090604@embeddededge.com>


Brian,

I know you are aware of this but I *always* experience cache coherency
problems with the GT64260A when Sysclk/Tclk are anything above 100MHz
and I believe that your board is clocked over that.  Try a 100MHz
crystal and see if the problem goes away.

Mark
--
Dan Malek wrote:

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

  reply	other threads:[~2003-02-20 16:51 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
2003-02-20 16:51                 ` Mark A. Greer [this message]
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=3E55078B.4040208@mvista.com \
    --to=mgreer@mvista.com \
    --cc=benh@kernel.crashing.org \
    --cc=dan@embeddededge.com \
    --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 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.