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

[Shilimkar, Santosh]

On Tue, Jan 17, 2012 at 9:45 PM, Nicolas Pitre <nico at fluxnic.net> wrote:
> On Tue, 17 Jan 2012, Shilimkar, Santosh wrote:
>
>> On Tue, Jan 17, 2012 at 8:39 PM, Nicolas Pitre <nico at fluxnic.net> wrote:
>> > On Tue, 17 Jan 2012, Shilimkar, Santosh wrote:
>> >
>> >> How about allowing platform hooks for single SOC builds. I mean having
>> >> this code under !single_zImage or something like that. That way we don't
>> >> impact the single zImage efforts and also allow socs to have all those
>> >> critical, vital bits enabled for the SOC specific builds.
>> >
>> > Absolutely not!  Because if we start doing that, people will get lazy
>> > and no platform will ever work in a multi-SOC kernel.
>> >
>> > If your SOC require some fancy setup that is not shared by other
>> > platforms then please abstract that into the bootloader, or make sure it
>> > can be deferred later on.
>> >
>> There is nothing fancy here. It's an ARM security architecture feature which
>> OMAP implements. Have given enough reason about boot-loaders issues.
>
> I was not convinced by those reasons. Just push harder on the bootloader
> side.  There is _no_ reason for the bootloader not to take care of this
> very platform specific issue.  You can even do it into a standalone
> uImage that returns to u-Boot after it is done with its magic.
>
>> Is OMAP getting beaten up here just because it uses ARM security
>> feature and implements it's mechanics?
>
> I don't care if this is OMAP, UX500 or i.MX.  There is a line to be
> drawn and this is just too bad if you are trying to cross it.
>
Well I was trying to get a solution for a genuine problem.
Let's take an example.

#ifdef CONFIG_ARM_ERRATA_742230
        cmp     r6, #0x22                       @ only present up to r2p2
        mrcle   p15, 0, r10, c15, c0, 1         @ read diagnostic register
        orrle   r10, r10, #1 << 4               @ set bit #4
        mcrle   p15, 0, r10, c15, c0, 1         @ write diagnostic register
#endif

The SoC's which doesn't have security restriction and the kernel
is in secure mode, above errata is applied in it's right place. Before
MMU is enabled. There are many bits like this which are patched
in kernel.

On OMAP, all these can't be set-up in kernel since kernel is
in non-secure mode. To set such bit's we need to call some
pre-defined security calls.

Regards
santosh