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 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? > > 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. 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 >
Attachment:
signature.asc
Description: PGP signature
