On 31 January 2012 10:10, Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> wrote: > On Tue, Jan 31, 2012 at 09:53:25AM +0000, 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. > > You've seen the resistance from uboot to stuff we do with the kernel, > this will be no different. There's also quite a number of boot loaders > out there which aren't capable of running a binary, returning and then > loading and running the kernel. > > Plus, of course, it's far from friendly towards TFTP setups. For platforms that can't/don't want to modify the boot loader, they could wrap (prepend) the kernel image with the preload code and they just use that to kexec a distro generic kernel. I know it can go to 3-4 stages boot process on some platforms but you have the advantage of a generic kernel image. If SoC vendors don't like the lengthier boot process, they have the option of modifying the boot loader and include the preload code that the kernel provides (or find a way to load it together with the kernel at boot-time). -- 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
