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

[Nicolas Pitre]

On Tue, 17 Jan 2012, Nicolas Pitre 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.

Alternatively, you may leverage all the infrastructure that was 
implemented to support CPU offlining i.e. the creation of a 1:1 mapping 
needed to disable the MMU and so on.  That should be possible for you to 
just have the MMU turned off, then call the secure mode to turn on L2, 
then restore MMU and normal operation of the kernel.  This can be 
accomplished later during boot rather than right at the beginning.


Nicolas