* David Brownell <david-b@xxxxxxxxxxx> [080829 11:12]: > On Friday 29 August 2008, Igor Stoppa wrote: > > > > I'd like to verify that u-boot is setting things up properly. > > > > > > CONFIG_OMAP_MUX_WARNINGS helps for some definitions of "properly": > > > when Linux needs one setting, but the boot loader leaves a different > > > one, you get a warning. That's usually interpreted as u-boot doing > > > it wrong, except on devboards where the boot loader can't actually > > > know about all external hardware that might be hooked up (and how) > > > > I'm probably a bit off topic, but since Tony started promoting the > > concept of multi-arch binary, well, i see it as a huge limitation the > > fact that the bootloader is expected to the right thing. > > The boot loader knows exactly what it's dealing with. And by the > time it get past very early boot, so does Linux ... > > > > In the multi arch case (but even single-arch, if we would like to > > support multiple boards with one single kernel binary) i see as a much > > more reasonable solution the case where the bootloader passes the board > > id to the kernel and the kernel loads the board-specific configuration > > in the form of a module. > > How the kernel gets that config data doesn't matter. The current > solution is that all supported boards have setup code (board-XYZ.c > object code) statically linked. Most of the board init code runs > at arch_initcall() time ... and it's keyed using the board ID. CPU > setup code runs a bit earlier. > > > > DVFS for example defeats the idea that the bootloader would be enough to > > setup properly the clock tree (of course it will do it, but only for 1 > > OP and the setting can get lost the first time another OP is selected). > > I've not looked at recent clock tree issues. $SUBJECT is about > pinmux, not clock tree. I have no problems with the notion that > Linux not rely on the boot loader to set up esoteric stuff. > > > > Imho the bootloader should just do what the name suggests: load the > > kernel and boot it. In as minimal configuration as possible. > > There's a lot to be said for not relying on boot loaders to do much > more than loading and starting a kernel. Kernel requirements have a > tendancy to evolve over time, while boot loaders tend to never get > upgraded ... so kernels tend to set things up, regardless. > > The whole "rely on boot loader to do ABC" bit can only make sense > in special contexts ... like a Nokia product team which has the > processes in place to clearly define "ABC" and test it. For many > development boards that's often not practical. And of course, the > logical extension of relying on bootloaders is what you see in PCs > with BIOS and ACPI; yeech! Yeah. We should set the pin configuration in board-*.c files. It still does not leave out the option of only setting the pins in bootloader if somebody wants to do that. Tony -- 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
