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

[Shilimkar, Santosh]

On Tue, Jan 17, 2012 at 2:39 PM, Catalin Marinas
<catalin.marinas at arm.com> wrote:
> On Tue, Jan 17, 2012 at 12:40:54PM +0000, Shilimkar, Santosh wrote:
>> On Tue, Jan 17, 2012 at 1:27 PM, Aneesh V <aneesh at ti.com> wrote:
>> > Hi Catalin,
>> >
>> >
>> > On Tuesday 17 January 2012 05:41 PM, Catalin Marinas wrote:
>> >>
>> >> On Tue, Jan 17, 2012 at 08:54:44AM +0000, Joe Woodward wrote:
>> >>>
>> >>> So, is the upshot of this that the kernel isn't going to be in a
>> >>> position to enable the L2/outer cache on OMAP3 (due to the need for
>> >>> hacky/unmaintainable code)?
>> >>>
>> >>> Hence the bootloader/uBoot had better leave it enabled...
>> >>
>> >> It could but the Linux decompressor needs to be aware and either flush
>> >> the L2 (more difficult as it doesn't have all the device information) or
>> >
>> > Cortex-A8 is aware of L2$ and can flush it, isn't it?
>> >
>> >> set the page table attributes to outer non-cacheable (TEX[2:0] = 0b100).
>> >
>> > If the above is right, this is not needed right?
>>
>> Well the L2 can be configured as inner or outer, so above
>> alone won't work.
>>
>> Boot-loader disabling L2 cache ( all caches)  is still right thing
>> and that's what kernel expect.
>>
>> Since the early kernel code can't be patches for A8, may be
>> delaying L2 enabled would work.
>
> Ah, I missed the fact that the L2 is an inner cache on OMAP3+A8. In this
> case, I would argue to just leave it enabled since as long as the MMU is
> off it won't be accessed. Why does U-Boot need to disable the L2 (I
> suspect via some auxiliary control register)?
>
>> But then on A15, we are back to square one since there is no
>> control to turn ON/OFF l2 cache.
>
> Well, it's an inner cache, it gets disabled/enabled via the SCTLR.M bit
> as is the L1 cache. It does not need to be disabled independently.
>
>> On A15 infact there are other CP15 registers which needs to be set
>> before MMU is enabled to have best configuration.
>
> Yes, there are, and my view is that it is up to the platform firmware to
> set things right.
>
Firmware is ROM'ed in SOC's and can't be altered without a new silicon spin.
Then we get into situations where Errata A will say turn OFF/ON x bit and
so on. Most of these bits are secure write-only registers hence ROM
code provides few API's to alter these registers in future if needed.

BTW, look at the processor setup functions where we are altering these
bits in kernel today (Diagnostic, RR policy etc) and they work on
ARM SoC's which either don't use trustzone or kernel is in secure mode.

Now same thing if needs to be done for SoC's like OMAP where
these bits are under secure control, we need to use the ROM
secure API's and kernel don't seems to give any flexibility
to patch that.

I don't understand how __only__ these devices needs to be
patches outside the kernel. Firmware point is actually irrelevant for
OMAP since it can't be changed once it is ROMed.

Patching in boot-loaders isn't an option either since every customers
prefers to use there own boot-loader and then controlling
this vital bits is impossible.

So I re-iterate that we need to have solution to this problem.

Regards
Santosh