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

[Nicolas Pitre]

On Tue, 31 Jan 2012, Catalin Marinas wrote:

> Maybe we could factor out the CPU-specific settings from proc-v*.S
> into a separate arch/arm/boot/preload directory. We keep proc-v*.S
> entirely generic and the implementation-defined bits setting in the
> preload code. You could have an option to link the preload with the
> kernel but we could recommend that people run this code from
> boot-loader before invoking the kernel. This code would be dependent
> on platform and chosen at build-time. But the actual kernel image
> would be generic.

I'd recommend against that.  Again, the reason is not technical but 
rather has to do with the tendency to laziness of human beings.  So 
please let's not go there or it'll become the de facto standard.

Furthermore, if this is risky to leave a vulnerable window by activating 
some workarounds later during the boot process, then the risk won't go 
away entirely by moving those workarounds a bit earlier.  In which case 
the only real solution is to have them enabled by the bootloader before 
the cache is even turned on for the first time, and this is hardly Linux 
specific anyway.

The whole idea behind having a generic kernel is all about 
distributions.  If a generic kernel has to be distributed with a 
platform specific pre-kernel blob then we've gained nothing.  Same goes 
for the DTB.  Those platform specific blobs must be distributed _with_ 
the hardware and _not_ with the software distribution.  Having the dts 
files in the kernel right now is only a convenience for the transition 
to device tree.  Eventually they all will be removed from the tree when 
we get to a minimum of stability in the device tree implementation and 
the DTB will also have to come with the hardware along with the 
bootloader.


Nicolas