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/
next prev parent 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$(echo .)com \
--cc=benh@kernel$(echo .)crashing.org \
--cc=dan@embeddededge$(echo .)com \
--cc=gary@mlbassoc$(echo .)com \
--cc=geert@linux-m68k$(echo .)org \
--cc=linuxppc-dev@lists$(echo .)linuxppc.org \
--cc=waite@skycomputers$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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