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

[Catalin Marinas]

On 31 January 2012 09:05, Shilimkar, Santosh <santosh.shilimkar at ti.com> wrote:
> On Tue, Jan 31, 2012 at 2:24 PM, Catalin Marinas
> <catalin.marinas at arm.com> wrote:
>> On 31 January 2012 07:38, Shilimkar, Santosh <santosh.shilimkar at ti.com> wrote:
>>> On Tue, Jan 31, 2012 at 1:01 PM, Catalin Marinas
>>> <catalin.marinas at arm.com> wrote:
>>>> 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.
>>>>
>>> if done late in kernel, wouldn't it violate "set L2EN to 1 before
>>> setting C bit to 1"
>>
>> Not if you write the code sequence in such a way that it also switches
>> the C bit to 0 and back to 1. I think Nicolas suggested that the
>> platform code could go through the power management code. But I think
>> with some carefully coded asm code and cache flushing you could set
>> L2EN without a full MMU reset.
>>
> That would need identity mapping and also correct cache flushing
> as you said above. L2 enabled for A8 is fine but not sure about the
> A15 where L2 is enabled with C bit.

I don't see any problem here - why would you want to treat the L2
separately form the L1 cache? They are both inner caches, just treat
them as such - enabled when the C and M bits are set.

> Then there are some settings for
> ACTLR, L2ACCTRL and L2PFR which needs to be setup before
> MMU is ebabled.

These in general should go in the boot monitor/loader. There isn't
other easy clean solution if we want to keep the kernel booting
generic.

Maybe we could factor out the CPU-specific settings from proc-v*.S
into a separate arch/arm/boot/preload directory. We keep proc-v*.S
entirely generic and the implementation-defined bits setting in the
preload code. You could have an option to link the preload with the
kernel but we could recommend that people run this code from
boot-loader before invoking the kernel. This code would be dependent
on platform and chosen at build-time. But the actual kernel image
would be generic.

> And then the errata's on A9, needing setting up dignostic register,
> changing cache policy etc
> Hopefully we don't get hit by those issues/erratas
> in the window from initial MMU setup to this new sequence code.

We already enable the MMU in the decompressor and it doesn't have any
knowledge of CPU errata. But the preload code could solve this as
well.

-- 
Catalin