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

[Nicolas Pitre]

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.


Nicolas