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

[Russell King - ARM Linux]

On Tue, Jan 17, 2012 at 09:11:37PM +0100, Shilimkar, Santosh wrote:
> On Tue, Jan 17, 2012 at 8:47 PM, Russell King - ARM Linux
> <linux at arm.linux.org.uk> wrote:
> > On Tue, Jan 17, 2012 at 04:27:21PM +0000, Catalin Marinas wrote:
> >> Anyway, the first step is this API provided by the secure firmware.
> >> Since such API may need to be called before the MMU is initialised,
> >> Linux would need to have knowledge of the platform type early on. Having
> >> some platform hook (asm macro) to call early on wouldn't work with the
> >> single zImage configuration. Stack space is not an issue as we already
> >> have one for ARMv7 for D-cache flushing (XIP kernels would work but they
> >> aren't that many).
> >
> > It _is_ a problem.  How much stack space would these undefined platform
> > specific functions require?  16 words?  32 words?  A page?  Where does
> > this memory come from?  The .data section, or are we going to stuff it
> > into what is supposed to be the read-only text section?
> 
> Stack requirement is limited to saving and restoring the processor
> registers. There is no additional need. If this is an issue, we can
> also use SRAM as a stack for this operation.

How do you know that's all that would be required?

Let's look at another secure monitor API implementation in the kernel.
MSM has one - arch/arm/mach-msm/scm.c.  This requires parameters passed
through memory - a command buffer consisting of at least four words in
memory, followed by a response buffer of at least three words.

So where would this be placed if not on the stack?  Pick some random
address and hope that there's some memory there?

This is what I'm saying: while we may know what the requirement is for
OMAP, that's not what it is for other SoCs.  Every SoC has different
requirements for this, and so we have _no_ idea what so ever how much
stack space would actually be required.  And if we don't know that, we
have a real chance of having some implementation overflow the stack,
thereby overwriting something (eg, maybe your DT data, maybe your
initramfs image) which would be extremely detrimental.