OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)?
From: Russell King - ARM Linux <hidden>
Date: 2012-01-17 19:47:24
Also in:
linux-omap
Possibly related (same subject, not in this thread)
- 2012-02-02 · OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)? · catalin.marinas@arm.com (Catalin Marinas)
- 2012-02-02 · OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)? · Russell King - ARM Linux <hidden>
- 2012-02-02 · OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)? · catalin.marinas@arm.com (Catalin Marinas)
- 2012-02-01 · OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)? · Shilimkar, Santosh <hidden>
- 2012-01-31 · OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)? · nico@fluxnic.net (Nicolas Pitre)
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?