(sorry, I'm slow at replying, attending some internal ARM conference) On 31 January 2012 18:09, Nicolas Pitre <nico@xxxxxxxxxxx> wrote: > 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. ... > 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. The problem we have with a generic kernel in this context (e.g. errata bits) is that even though we use a read-check-write sequence for setting various bits during __v*_setup, as long as the boot loader did not set them the kernel will try a write access and fail. So with the current scenario, there is no way for an OMAP platform to run a generic kernel in non-secure mode (with all errata workarounds enabled) without modifying the boot loader. > 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. We could do the same and move the bit enabling to separate repository :). An alternative would be to also move those bits setting at a later time in the kernel booting (and re-disabling/enabling the MMU) as we don't have an easy way of figuring out whether the kernel is running in secure or non-secure mode. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
