On 5/29/2011 11:04 PM, Steve Calfee wrote:
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.
I apologize for the confusing message in my answer.
The default behavior of the hwmod fmwk is to reset every IPs in order to
ensure a stable and known state. The HWMOD flags should only be used in
case of broken reset in an IP. That's why hacking the GPIO flag in that
case is wrong.
That being said, you cannot prevent a board manufacturer to do some
hacks in its bootloader, because it is require for proper voltage like
here or because he wants to enable a splash screen and do not want to
have ugly artifact on the screen due to asynchronous reset of the DSS.
In that case, it might be desirable to allow the board file to prevent
such blind reset at boot time. Hence the need for a board level
mechanism to change that default behavior.
Bootloader sucks, but you cannot prevent people to use them:-(
In an ideal world, the bootloader will not do anything, and everything
will be perfectly handled by the kernel...
Benoit
--
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
