On Tue, 2012-07-24 at 11:30 +1000, NeilBrown wrote: > On Mon, 23 Jul 2012 17:24:54 +0300 Tero Kristo <t-kristo@xxxxxx> wrote: > > > 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. > > Yes, I have cpufreq enabled. > CONFIG_ARCH_HAS_CPUFREQ=y > CONFIG_ARM_OMAP2PLUS_CPUFREQ=y > > Interestingly cpufreq thinks the range is 300MHz to 600MHz: > > /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies:300000 600000 Yeah, this is the default setup for omap36xx. You can see current cpu frequency by checking the contents of scaling_cur_freq, it is most likely 300MHz. > > where 600 is that the freq is at boot: > > # dmesg | grep Cryst > [ 0.000000] Clocking rate (Crystal/Core/MPU): 26.0/332/600 MHz > [ 0.056365] Switched to new clocking rate (Crystal/Core/MPU): 26.0/332/800 MHz > > Does that mean the mpurate=800 isn't doing anything at all? It switches it temporarily to 800MHz, maybe for a few seconds or so. > > > > > 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. > > So it looks like you are suggesting that I simply remove the "mpurate=800" > as it isn't doing anything useful anyway. Is that right? > > Might there be some way to get it to scale higher than 600MHz? > The first message from U-boot says: > > OMAP3630/3730-GP ES2.1, CPU-OPP2, L3-165MHz, Max CPU Clock 1 Ghz > > and the board manufacturer thinks it should be capable of 800MHz. You need to enable 800MHz OPP similarly to what is done in beagle_opp_init() in board-omap3beagle.c. I am not sure what your board is detected as, depends on your boot loader (check /proc/cpuinfo.) -Tero > > Thanks, > NeilBrown > > > > > > 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
