OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)?
Catalin Marinas
catalin.marinas at arm.com
Tue Jan 31 02:31:10 EST 2012
On 31 January 2012 05:21, Aneesh V <aneesh at ti.com> wrote:
> On Friday 27 January 2012 11:00 PM, Catalin Marinas wrote:
>> On Fri, Jan 20, 2012 at 08:57:11AM +0000, Joe Woodward wrote:
>>>> 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.
>>
>>> 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
>>
>>> 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
More information about the linux-arm-kernel
mailing list