Hi Neil, On Mon, 2012-07-23 at 21:06 +1000, NeilBrown wrote: > My GTA04 (mobile phone using OMAP3 and TWL4030 PMIC) has difficulty rebooting > with 3.5. > The first boot (after power on) works fine. But when I reboot it hangs just > before > > Switched to new clocking rate (Crystal/Core/MPU): 26.0/332/800 MHz > > is printed. If I remove "mpurate=800" from the kernel command line the > problem goes away. > > If I boot into 3.5, which works, and then reboot into an older working kernel > it freezes too. So the 3.5 kernel leaves the device in a state which causes > any kernel to hang. TWL chip retains its settings over warm boot which most likely explains this. > > I spent a while bisecting and narrowed it down to > > commit f9d29f1617eb1b2f1fd41622bd1a0fc51658d2f0 > Author: Tero Kristo <t-kristo@xxxxxx> > Date: Mon Feb 20 12:26:06 2012 +0200 > > arm: omap3: voltage: fix channel configuration > > > If I revert this patch then the problem goes away. So that is the fix I'll > go with for now, but if anyone wants me to try something else to help find > out what the real problem is and to find a proper fix, I'm happy to help. Do you have cpufreq enabled in your build? If yes, then most likely the crash occurs because cpufreq scales the used OPP to minimum after boot and the warm reset doesn't switch the voltages properly and crashes as it attempts to raise CPU frequency. Also, if cpufreq is enabled, mpurate command line option doesn't really do much... it will just switch the frequency to the desired target during beginning of boot until cpufreq kicks in and switches the OPP to its own understanding of desired cpu rate. I think the handling of mpurate command line option should probably be ignored in cpufreq builds, or moved within the cpufreq driver. I tried to craft a quick boot time fix for this problem, but it seems the voltage layer is not properly initialized yet when the mpurate setting kicks in and it is not very straightforward to scale voltage during this time without writing a serious hack. If you don't have cpufreq enabled, then the vdd routing on your board might be interesting (I don't think this is the case as the kernel works okay after 1st boot.) -Tero -- 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
