From: armando.visconti@st.com (Armando VISCONTI)
To: linux-arm-kernel@lists.infradead.org
Subject: facing undefined inconsistent cache issues on cortex-a9
Date: Tue, 25 May 2010 14:07:31 +0200 [thread overview]
Message-ID: <4BFBBD83.5080302@st.com> (raw)
In-Reply-To: <EAF47CD23C76F840A9E7FCE10091EFAB02C57001F3@dbde02.ent.ti.com>
Shilimkar, Santosh wrote:
>> -----Original Message-----
>> From: linux-arm-kernel-bounces at lists.infradead.org [mailto:linux-arm-kernel-
>> bounces at lists.infradead.org] On Behalf Of Shiraz HASHIM
>> Sent: Monday, May 24, 2010 9:14 AM
>> To: linux-arm-kernel at lists.infradead.org
>> Cc: 'Armando VISCONTI'; Vipin KUMAR; Viresh KUMAR
>> Subject: facing undefined inconsistent cache issues on cortex-a9
>>
>> Hi,
>> I am using linux-2.6.32 port on spear1300 platform, the port is largely based
>> on realview code.
>>
>> SPEAr1300 has a Cortex A9 dual core, both cores configured as participating in
>> SMP, but we are currently configuring Linux in non SMP mode, running Linux on
>> the first core only, while second core is spinning forever in a tight loop.
>>
>> Linux is running with default configuration w.r.t. cache and other things on
>> core1. Since SMP is not enabled this means that SCU and local timers are off, L2
>> cache is also disabled. While on core2 only instruction cache is on and both
>> MMU and Data cache is off.
>>
>> We observed a crash while booting. Investigating on the crash we found that this
>> was caused by a wrong value read by the core. Strangely enough, the new value
>> was written few instruction before, but the core was still reading the old one.
>>
>> What happens is someting like this:
>>
>> r0 = X ; /* X is the address of a Linux variable */
>>
>> str r5, [r0]; /* write new value */
>> ...
>> ldr r5, [r0]; /* read back value - we get the old one (???) */
>>
>> The value read here, just few lines later the new value was written, is the old
>> one. Obviously we are expecting to find the new one.
>>
>> Moreover, using the jtag debugger it looks clear that the new value is indeed in
>> the memory, but surprisingly NOT in the data-cache.
>> If we put a read of X, before the store in order to avoid the write miss when
>> doing 'str r5, [r0]', we see that the problem doesn't appear.
>>
>>
> 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.
We are using Cortex A9 r2p1.
Any clue?
Arm
--
-- "Every step appears to be the unavoidable consequence of the
-- preceding one." (A. Einstein)
--
Armando Visconti Mobile: (+39) 346 8879146
Senior SW Engineer Fax: (+39) 02 93519290
CPG Work: (+39) 02 93519683
Computer System Division e-mail: armando.visconti at st.com
ST Microelectronics TINA: 051 4683
next prev parent reply other threads:[~2010-05-25 12:07 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 [this message]
2010-05-25 12:24 ` Shilimkar, Santosh
2010-05-25 18:57 ` Woodruff, Richard
2010-06-04 13:55 ` Shiraz HASHIM
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=4BFBBD83.5080302@st.com \
--to=armando.visconti@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.