Thread (17 messages) 17 messages, 5 authors, 2012-02-02

OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)?

From: catalin.marinas@arm.com (Catalin Marinas)
Date: 2012-01-31 07:31:10
Also in: linux-omap

Possibly related (same subject, not in this thread)

On 31 January 2012 05:21, Aneesh V [off-list ref] wrote:
On Friday 27 January 2012 11:00 PM, Catalin Marinas wrote:
quoted
On Fri, Jan 20, 2012 at 08:57:11AM +0000, Joe Woodward wrote:
quoted
quoted
So I re-iterate that we need to have solution to this problem.
... I don't want to be a pain, but it seems to me that this dicussion
didn't reach a full conclussion?
Probably not, because it depends on many variables. See below my take on
this.
quoted
I think it was left with the open options being:
1) Leave the L2/outer cache enabled in the bootloader (not ideal and
may cause problems with future devices)
This depends on whether the L2 is inner or outer:

L2 inner - leave it enabled in the boot loader
L2 outer - leave it disabled in the boot loader
quoted
2) Turn the L2/outer cache on for OMAP3 later in the kernel boot when
the device is known
Same as above:

L2 inner - don't do anything, it gets used when SCTLR.M is enabled
L2 outer - enabled at boot time via the platform code (later, after MMU
? ? ? ?was enabled).
What is the reasoning behind this recommendation? Why the distinction
between L2 being inner or outer. I don't see anything to this effect in
the Cortex-A8 TRM? In fact the only recommendation I could find(section
8.3) is asking to set L2EN to 1 before setting C bit to 1 irrespective
of inner/outer?
Actually you have a good point. I was thinking about outer caches like
PL310 or L220 that Linux enables later during platform initialisation.
They could be left enabled or disabled at boot time but they must be
cleaned/invalidated (you would need to flush after disabling just to
make sure there are no further lines fetched; alternatively, there
shouldn't be any cacheable mappings).

So I would say in the context of A8, just leave the L2 enabled in the
boot loader. As long as the MMU is disabled, it won't be used. The
alternative is to enable L2 slightly later in Linux in the platform
code to avoid SoC-dependent code in proc-v7.S.

So in summary, either option is possible. You could take the approach
of the cache-l2x0.c - check whether it is already enabled and, if not,
issue an SMC from the platform code to enable the L2 cache.

-- 
Catalin
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help