From: eric@eukrea.com (Eric Bénard)
To: linux-arm-kernel@lists.infradead.org
Subject: I.MX35 GPIO IRQ + Preempt -> Oops
Date: Sun, 03 Oct 2010 17:25:31 +0200 [thread overview]
Message-ID: <4CA8A06B.3070103@eukrea.com> (raw)
In-Reply-To: <20101003114103.GC32736@n2100.arm.linux.org.uk>
Hi Russell,
Le 03/10/2010 13:41, Russell King - ARM Linux a ?crit :
> The common theme here looks like instruction cache corruption in
> default_idle() - iow, the CPU isn't executing the code which is in
> memory.
>
thanks for the analysis.
This problem seems to be related to the ARM11 bug described in page 4 of
this PDF :
http://cache.freescale.com/files/dsp/doc/errata/IMX35CE.pdf?fpsp=1
ENGcm09472 ARM: WFI and interrupt problems
Description:
There are two issues:
? The behavior of the FIQ signal to the ARM11 core can cause a problem
when exiting WFI mode. The FIQ signal toggles after being initially
asserted, which, as ARM has confirmed, is unexpected behavior to the
ARM11 core. ARM has stated that this is not a fully validated case
for their cores. This behavior occurs when core clocks continue to run
and, along with particular caching and alignment schemes, can result in
a corrupted cache line following a prefetch, as well as unexpected
behavior in code. Also, the core can execute an instruction immediately
following the WFI instruction before servicing the FIQ. This behavior of
FIQ is caused by the design of the interrupt controller in the
synchronization circuit.
? The same extra pulse on the FIQ signal can cause the core to execute
instructions immediately following the WFI, before entering the ISR. If
an ISR executes too quickly, the FIQ/IRQ may not clear by the time the
core returns to main code, and may enter ISR two or more times for the
same interrupt. This situation should only happen if the execution time
of the code in the ISR that follows the initial write to the peripheral
to clear the FIQ/IRQ, can execute in fewer than 25 hclk (AHB clock) cycles.
Projected Impact:
The first issue can result in a corrupted cache line following a
prefetch, and thus unexpected behavior; the second issue can result in
unexpected behavior of ISR execution.
Work Around:
The WFI routine should change the clocking mode to a 1:1 (ARM:AHB)
ratio. This must be ensured by following the programming with dummy
reads. On wake-up, the clocks can then be changed back to the original
ratio.
This completely prevents the toggle on the interrupt line, and this code
can now be located in a
cacheable region.
EXAMPLE:
mov r0, #0
ldr r1, =<clock_control_BASE>
ldr r2, [r1, #OFFSET]
orr r3, r2, #1TO1MODE
str r3, [r1, #OFFSET]
... // Delay while switch to 1:1 occurs
mcr p15, 0, r0, c7, c0, 4 //WFI
str r2, [r1, #OFFSET]
bx lr
Projected Solution:
No fix scheduled.
Eric
next prev parent reply other threads:[~2010-10-03 15:25 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-02 13:55 I.MX35 GPIO IRQ + Preempt -> Oops Eric Bénard
2010-10-03 11:41 ` Russell King - ARM Linux
2010-10-03 15:25 ` Eric Bénard [this message]
2010-10-03 16:20 ` Russell King - ARM Linux
2010-10-03 17:15 ` Eric Bénard
2010-10-04 7:39 ` Uwe Kleine-König
2010-10-04 8:08 ` Eric Bénard
2010-10-04 12:07 ` Eric Bénard
2010-10-05 5:06 ` Marc Reilly
2010-10-05 7:28 ` Eric Bénard
2010-10-05 9:13 ` Eric Bénard
2010-10-05 9:25 ` [PATCH/RFC] i.MX31 and i.MX35 : fix errate TLSbo65953 and ENGcm09472 Eric Bénard
2010-10-05 9:45 ` Sascha Hauer
2010-10-05 12:00 ` [PATCH v2] " Eric Bénard
2010-10-05 18:33 ` Uwe Kleine-König
2010-10-05 19:31 ` Eric Bénard
2010-10-05 19:46 ` Uwe Kleine-König
2010-10-05 20:00 ` Eric Bénard
2010-10-05 20:04 ` Uwe Kleine-König
2010-10-05 20:27 ` Eric Bénard
2010-10-06 2:28 ` Nicolas Pitre
2010-10-06 11:09 ` Eric Bénard
2010-10-08 8:49 ` [PATCH v3] " Eric Bénard
2010-10-07 7:27 ` [PATCH v2] " Russell King - ARM Linux
2010-10-05 16:29 ` [PATCH/RFC] " Uwe Kleine-König
2010-10-05 16:48 ` Eric Bénard
2010-10-05 17:40 ` Uwe Kleine-König
2010-10-06 6:35 ` Daniel Mack
2010-10-06 7:03 ` Uwe Kleine-König
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=4CA8A06B.3070103@eukrea.com \
--to=eric@eukrea.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.