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$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/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