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

[Shilimkar, Santosh]

On Tue, Jan 17, 2012 at 10:02 PM, Nicolas Pitre <nico at fluxnic.net> wrote:
> On Tue, 17 Jan 2012, Shilimkar, Santosh wrote:
>
>> 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.
>
> Absolutely.  Just don't do it in the early kernel boot code where it is
> not convenient to do so.
>
Got it.

Regards
Santosh