All of lore.kernel.org
 help / color / mirror / Atom feed
From: shiraz.hashim@st.com (Shiraz HASHIM)
To: linux-arm-kernel@lists.infradead.org
Subject: facing undefined inconsistent cache issues on cortex-a9
Date: Fri, 04 Jun 2010 19:25:08 +0530	[thread overview]
Message-ID: <4C0905BC.1090301@st.com> (raw)
In-Reply-To: <13B9B4C6EF24D648824FF11BE896716203BB37005A@dlee02.ent.ti.com>

Hello Woodruff,

On 5/26/2010 12:27 AM, Woodruff, Richard wrote:
> 
>> From: linux-arm-kernel-bounces at lists.infradead.org [mailto:linux-arm-kernel-
>> bounces at lists.infradead.org] On Behalf Of Shilimkar, Santosh
> 
>>>> Does this work if disable L1D as well on the processor you are running
>> Linux ??
>>>>
>>> If we disable the L1 DCache we are never able to boot.
>>> But this might be a different problem.
>>>
>>> If we disable ICache and leave DCache on it is much more stable, and
>>> I think it might be related to timing issue in the data path.
>>>
>> For me, it seems that Cache isn't invalidated properly which leads to this
>> issue.
>> May be you can report the complete crash-log which can give more idea on the
>> issue.
> 
> If you are unable to boot with dcache off then maybe your memory controller or memory part has timing issues.  Cache on will trigger burst accesses using different timings.  Such an early failure is more likely an issue outside of the arm unless you are doing something really odd.

thanks for your inputs. We have some updates in this regard.
In our architecture we have 2 ports coming out of the A9SM (multi core cortex)
block to the interconnect matrix and the transfers are distributed between them.

When we used the address filtering option of SCU to divide and mutually exclude
the traffic between port0 and port1 of A9SM(multi core cortex) block. Like, 
assigning 1 half of the address space to port 1 and rest goes through port0.
This solved the problem with the same set of cache and other system
configurations.
We are not using L2 cache and it is kept disabled. The SCU also is only used for
address filtering and its synchronisation function is disabled (as we are not
bringing up the second core)
Now, we are not able to understand what it means. Do we need to divide the
traffic between ports as described and it is normal. Or there is some problem in
the way the transfers are handled in the system.

regards
Shiraz

  reply	other threads:[~2010-06-04 13:55 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-24  3:43 facing undefined inconsistent cache issues on cortex-a9 Shiraz HASHIM
2010-05-25 11:51 ` Shilimkar, Santosh
2010-05-25 12:07   ` Armando VISCONTI
2010-05-25 12:24     ` Shilimkar, Santosh
2010-05-25 18:57       ` Woodruff, Richard
2010-06-04 13:55         ` Shiraz HASHIM [this message]
2010-06-10 21:12           ` Woodruff, Richard

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=4C0905BC.1090301@st.com \
    --to=shiraz.hashim@st.com \
    --cc=linux-arm-kernel@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.