On Fri, May 27, 2011 at 12:38 PM, Kevin Hilman <khilman@xxxxxx> wrote: > "Cousson, Benoit" <b-cousson@xxxxxx> writes: > > [...] > >> In general we do not want to reset nor idle an IP that was potentially >> already properly configured by bootloader or early Linux boot code. > > Actually, the opposite is true. > > The kernel should not make any assumptions about what the bootloader has > or has not done. ÂWe need to have a kernel that can boot from any > bootloader (or none, like using kexec) and be able to start from a known > hardware state. > YES. Bootloaders should only do what is necessary (set clocks, enable memories etc) to load the next stage. Pushing stuff that should be in the kernel into the bootloader (like iniiting gpios and other things) bloats it and makes a developer deal with two entirely different source trees (kernel and booterx) to enable a new feature or to fix bugs. Uboot tends to lag the kernel in capabilities too, probably because fewer developers or something. For instance Beagleboard xm uboot cannot access the ethernet because it is usb based, and uboot cannot access its own environment in flash - because it is running from a new microsd based flash system. U-boot will eventually catch up with these, but by then other new hardware will be available. Does anyone know if 2.6.39 has kexec working again for the kernel? NFS boot is a dream development environment but with both u-boot and kexec not working with nfs, it is slightly more work and less automated. Regards, Steve -- 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
