From: afzal.mohd.ma@gmail.com (Afzal Mohammed)
To: linux-arm-kernel@lists.infradead.org
Subject: Do I need to invalidate caches before enabling (on ARMv7)?
Date: Sun, 7 Dec 2014 02:30:31 +0530 [thread overview]
Message-ID: <20141206210031.GA1758@afzal-ThinkPad-R50e> (raw)
In-Reply-To: <20141204100357.GO2129@pengutronix.de>
Hi Uwe,
On Thu, Dec 04, 2014 at 11:03:57AM +0100, Uwe Kleine-K?nig wrote:
> The breakage I'm currently seeing in barebox might well be explained by
> stale I-cache entries and barebox (as of now) doesn't invalidate the
> i-cache before enabling it. Looking into how Linux enables the I-cache
> in the decompressor for v7[1] revealed that the caches are not cleaned
> there either. (So my plan to copy from Linux failed :-)
>
> Now I wonder if that is only an unlikely (or even theoretical) issue
> that wasn't noticed up to now or if I'm missing something.
> So stale entries in the cache might even hurt before the cache is
> enabled?! This would mean that you want to invalidate/flush the cache at
> disable-time. Still I think doing it before enabling it in Linux would
> be a good idea. And if it's only because bootloaders and (maybe worse)
> boot roms cannot be trusted in this area.
Are you sure that stale I-cache is causing the issue ?, but
D-cache should not have stale data - it is a pre-requisite for
booting the Kernel [1,2] (though not in Booting documentation)
We were troubled by this issue when Kernel was loaded directly w/o
bootloader, since D-cache was not invalidated, upon enabling,
due to stale data Kernel was crashing randomly
Did want to patch it for long time, but then with cash invalidation
and all it never happened ;)
Regards
Afzal
[1] http://www.arm.linux.org.uk/developer/booting.php
[2] http://comments.gmane.org/gmane.linux.ports.arm.kernel/77718
---------------------------------8<--------------------------------------
diff --git a/Documentation/arm/Booting b/Documentation/arm/Booting
index 371814a36719..c4c423164d5e 100644
--- a/Documentation/arm/Booting
+++ b/Documentation/arm/Booting
@@ -193,6 +193,7 @@ In any case, the following conditions must be met:
The MMU must be off.
Instruction cache may be on or off.
Data cache must be off.
+ Data cache should be invalidated.
If the kernel is entered in HYP mode, the above requirements apply to
the HYP mode configuration in addition to the ordinary PL1 (privileged
next prev parent reply other threads:[~2014-12-06 21:00 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-04 10:03 Do I need to invalidate caches before enabling (on ARMv7)? Uwe Kleine-König
2014-12-06 21:00 ` Afzal Mohammed [this message]
2014-12-07 10:01 ` Uwe Kleine-König
2014-12-07 10:58 ` Andrew Lunn
2014-12-07 11:11 ` Uwe Kleine-König
2014-12-07 11:27 ` Andrew Lunn
2014-12-07 11:38 ` Uwe Kleine-König
2014-12-07 11:26 ` Afzal Mohammed
2014-12-08 11:59 ` Catalin Marinas
2014-12-15 14:30 ` Lorenzo Pieralisi
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=20141206210031.GA1758@afzal-ThinkPad-R50e \
--to=afzal.mohd.ma@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox