ARCHIVED: [Kernel] Picasticks OC kernel built from LG source for Optimus V

[drezliok]

SetCPU Force Closes if I try to make any adjustments.

 

[picasticks]

SetCPU Force Closes if I try to make any adjustments.

Well, that's definitely weird. Does it show 748 MHz and ondemand when you first start it? If not, what?

Can you just change scaling to "performance" or does even that kill it?

My guess would be this is an incompatibility with the ROM. I don't have a V so don't run Rodimus but just looking at the feature list it mentions "Screenstate scaling added (written by flohimself. this removes the need to have a SetCPU profile for screen-off. saves battery)" and "Fixed processor staying at 100%". So if they are doing things to the scaling on boot it may be something that SetCPU doesn't like. Or they may be changing things that are Xionia-specific. If you could, what is in your init.qcom.post_boot.sh file?

(The next question I would ask is for you to cat out the contents of all the files in /sys/devices/system/cpu/cpu0/cpufreq after the phone boots, if you know how to do that (together it would show the full cpufreq configuration post-boot). If not then hopefully I'll get the info from the other questions.)

 

[drezliok]

That's not a flashable zip. Just unzip it to get the thunder_keypad.kl file (I couldn't attach the .kl file directly since that's not a recognized attachment extension by the board). Remount /system as rw, then put it in /system/usr/keylayout/.

Learned how to adb... RomTools is nice but I should have learned it to do it right from scratch anyways. but I got my buttons fix up and I'm happy.

 

[drezliok]

Well, that's definitely weird. Does it show 748 MHz and ondemand when you first start it? If not, what?

Can you just change scaling to "performance" or does even that kill it?

My guess would be this is an incompatibility with the ROM. I don't have a V so don't run Rodimus but just looking at the feature list it mentions "Screenstate scaling added (written by flohimself. this removes the need to have a SetCPU profile for screen-off. saves battery)" and "Fixed processor staying at 100%". So if they are doing things to the scaling on boot it may be something that SetCPU doesn't like. Or they may be changing things that are Xionia-specific. If you could, what is in your init.qcom.post_boot.sh file?

(The next question I would ask is for you to cat out the contents of all the files in /sys/devices/system/cpu/cpu0/cpufreq after the phone boots, if you know how to do that (together it would show the full cpufreq configuration post-boot). If not then hopefully I'll get the info from the other questions.)

It does boot at 748 MHz but it says interactive. If I try to do anything other than look at it it FC on me. Scale up or down, min or max, change the governor, and also mess with the sampling. I've tried to reset the program by clearing it's data. I've wiped my cache and Dalvik to see if that worked. Nothing!

I have a idea though. It worked before I put the theme on it which I when installing it I wiped the Dalvik and Cache.

 

[picasticks]

It does boot at 748 MHz but it says interactive. If I try to do anything other than look at it it FC on me. Scale up or down, min or max, change the governor, and also mess with the sampling. I've tried to reset the program by clearing it's data. I've wiped my cache and Dalvik to see if that worked. Nothing!

I have a idea though. It worked before I put the theme on it which I when installing it I wiped the Dalvik and Cache.

Thanks, that is already helpful. Since it is interactive, which is not standard, that already tells us the ROM is making changes via the cpufreq interface. If you do "adb pull /init.qcom.post_boot.sh" you can get that file, hopefully it's making the changes in there (you will see it is cat-ing a bunch of values to /sys/devices/system/cpu/cpu0/cpufreq). Please post if you can, it's only like 20 lines.

Or if the other thing makes the problem go away, that's good too. As far as I can guess this isn't a kernel bug anyway. (>200 downloads at this point and most of them probably by people using SetCPU ).

 

[mmarz]

Well, that's definitely weird. Does it show 748 MHz and ondemand when you first start it? If not, what?

Can you just change scaling to "performance" or does even that kill it?

My guess would be this is an incompatibility with the ROM. I don't have a V so don't run Rodimus but just looking at the feature list it mentions "Screenstate scaling added (written by flohimself. this removes the need to have a SetCPU profile for screen-off. saves battery)" and "Fixed processor staying at 100%". So if they are doing things to the scaling on boot it may be something that SetCPU doesn't like. Or they may be changing things that are Xionia-specific. If you could, what is in your init.qcom.post_boot.sh file?

(The next question I would ask is for you to cat out the contents of all the files in /sys/devices/system/cpu/cpu0/cpufreq after the phone boots, if you know how to do that (together it would show the full cpufreq configuration post-boot). If not then hopefully I'll get the info from the other questions.)

I was worried about that too, the "Screenstate scaling", because of the testing I did that showed underclocking hurting performance. You can find the original script mark used here: [INITSCRIPT] screenstate_scaling - switch CPU freq governor on screen state change - xda-developers

But it was dropped from Rodimus in the later releases. I'm not sure if it is an accidental omission or it was left out on purpose because the change log does not state when it was removed. Either way, it shouldn't be an issue with the latest Rodimus.

 

[drezliok]

Thanks, that is already helpful. Since it is interactive, which is not standard, that already tells us the ROM is making changes via the cpufreq interface. If you do "adb pull /init.qcom.post_boot.sh" you can get that file, hopefully it's making the changes in there (you will see it is cat-ing a bunch of values to /sys/devices/system/cpu/cpu0/cpufreq). Please post if you can, it's only like 20 lines.

Or if the other thing makes the problem go away, that's good too. As far as I can guess this isn't a kernel bug anyway. (>200 downloads at this point and most of them probably by people using SetCPU ).

I think this bug was on me.

I pushed the apk from Romtools. Took me a while to dig it out of there. tried the cmd adb way but finally resorted to a "root uninstaller" from the market. wiped my dalvik and then reinstalled from my SDcard and it works fine.

 

[picasticks]

I was worried about that too, the "Screenstate scaling", because of the testing I did that showed underclocking hurting performance. You can find the original script mark used here: [INITSCRIPT] screenstate_scaling - switch CPU freq governor on screen state change - xda-developers

But it was dropped from Rodimus in the later releases. I'm not sure if it is an accidental omission or it was left out on purpose because the change log does not state when it was removed. Either way, it shouldn't be an issue with the latest Rodimus.

Thanks for the info!

I think every kernel/ROM dev (me included) has to relearn these same lessons re: frequency and voltage scaling. This post sums up the situation pretty well:

UV & UC to save battery isn't really feastible as all freq 245mhz to 480mhz use same voltage on any msm7x27 processor (less than 245mhz is too slow for the phone to wake up for calls etc.) 600+ uses the max voltage. Max voltage is level 7 on this processor and voltage level of 3 is the minimum the phone can use to be operational. Voltage levels 3-6 have the same output so no savings there.

Nevertheless people keep clocking down to 122 and rediscovering that it doesn't work.

People need to read up on the MSM7600 chipset and realize this is an older (when I pulled the datasheet it, was (c) 2006) SoC design, that is a phone-specific cpu from Qualcomm, and some of the things that are possible with the general-purpose ARM cpus that are in most higher-end devices are not with the MSM7627, because stuff like voltage levels is hardwired in (and we can't just port some HAVS patch HTC wrote for a different chipset). Or, put another way, some things are "possible" (i.e. clocking from 480 or 245 down to 122) but there's no benefit and/or bad side effects.

The good news is that there are some easy wins, like overclocking, disabling features, enabling JIT or reducing the wifi poll interval to save battery.

I have gone through, built and tested 10x the number of kernel config changes, CFLAGS (fpu-related) and patchsets that I have actually wound up putting into this kernel, and with almost all of it there was either no testable improvement or (usually) a regression of some kind. LG has done a really solid job on the kernel (especially where it really matters for performance, in the cpu-specific MSM arch sections) which I'm sure comes from years of working with this chipset.

And the community has been hacking on it for a long time, too.

 

[jmel]

That's not a flashable zip. Just unzip it to get the thunder_keypad.kl file (I couldn't attach the .kl file directly since that's not a recognized attachment extension by the board). Remount /system as rw, then put it in /system/usr/keylayout/.

This would be great if someone could make it into a flashable zip...

 

[Eollie]

This would be great if someone could make it into a flashable zip...

Yes lets make everything super easy and flashable so, oh I dunno, it takes no knowledge of how or where to put things via root navigation or adb push commands.

 

[mmarz]

Thanks for the info!

I think every kernel/ROM dev (me included) has to relearn these same lessons re: frequency and voltage scaling. This post sums up the situation pretty well:



Nevertheless people keep clocking down to 122 and rediscovering that it doesn't work.

People need to read up on the MSM7600 chipset and realize this is an older (when I pulled the datasheet it, was (c) 2006) SoC design, that is a phone-specific cpu from Qualcomm, and some of the things that are possible with the general-purpose ARM cpus that are in most higher-end devices are not with the MSM7627, because stuff like voltage levels is hardwired in (and we can't just port some HAVS patch HTC wrote for a different chipset). Or, put another way, some things are "possible" (i.e. clocking from 480 or 245 down to 122) but there's no benefit and/or bad side effects.

The good news is that there are some easy wins, like overclocking, disabling features, enabling JIT or reducing the wifi poll interval to save battery.

I have gone through, built and tested 10x the number of kernel config changes, CFLAGS (fpu-related) and patchsets that I have actually wound up putting into this kernel, and with almost all of it there was either no testable improvement or (usually) a regression of some kind. LG has done a really solid job on the kernel (especially where it really matters for performance, in the cpu-specific MSM arch sections) which I'm sure comes from years of working with this chipset.

And the community has been hacking on it for a long time, too.

Does this mean that there are only two voltage levels to choose from 3 or 7? Does this also mean that after 600 MHz, the "choice" is made for you and you cannot force the CPU to level 3 voltage with 806 MHz? Or is the problem that at 806 MHz, the cpu is not stable at the level 3 voltage?

From empirical testing, I found the most efficient CPU clock scaling is your max speed being set one step below the most stable speed for your phone, and the min speed being set to either 600 MHz or the same speed as the max and not scaling at all. What you just wrote explains why this is the case.

Great work btw. This info should be stickied or wiki'ed. You know you are going to be getting an undervolt request every week otherwise.

 

[drezliok]

This would be great if someone could make it into a flashable zip...

It took 15 minutes to get the commands and push the file. Don't fear the keyboard.

 

[jmel]

Yes lets make everything super easy and flashable so, oh I dunno, it takes no knowledge of how or where to put things via root navigation or adb push commands.

That's right, because then noobs won't mess it up and flood the forums. Sigh...

What is the point of your post again???

I've used adb, and have no issues. I'm just making a suggestion.

 

[picasticks]

That's right, because then noobs won't mess it up and flood the forums. Sigh...

What is the point of your post again???

I've used adb, and have no issues. I'm just making a suggestion.

Don't worry, I will just be including this file in the next release of the kernel's zip file, so it will automagically restore everybody's original key map.

At this point looks like I will be putting that out later today or tomorrow.

 

[mmarz]

Don't worry, I will just be including this file in the next release of the kernel's zip file, so it will automagically restore everybody's original key map.

At this point looks like I will be putting that out later today or tomorrow.

Can I request it being placed as a separate zip and not included with the kernel? I have my own key map, and I don't want to replace it every time I test your kernel. Just a suggestion.

 

[picasticks]

Does this mean that there are only two voltage levels to choose from 3 or 7? Does this also mean that after 600 MHz, the "choice" is made for you and you cannot force the CPU to level 3 voltage with 806 MHz? Or is the problem that at 806 MHz, the cpu is not stable at the level 3 voltage?

From empirical testing, I found the most efficient CPU clock scaling is your max speed being set one step below the most stable speed for your phone, and the min speed being set to either 600 MHz or the same speed as the max and not scaling at all. What you just wrote explains why this is the case.

Great work btw. This info should be stickied or wiki'ed. You know you are going to be getting an undervolt request every week otherwise.

Well, I am not the original source of that post, for which drellisdee gets the credit (not to mention doing all the original LS670 hacking work last year ... I haven't read far enough into the Optimus One to know who got all that started).

The way I read it is that yes, you're one voltage level for 245-480 and another (the max) at 600 Mhz or higher. I know zefie found the same thing as you when he did all his OC testing in Nov/Dec, that one freq below max worked the best. Personally I have found the same, my phone breaks at 864, and gets max benchmarks at 825.

I already posted a datasheet link and some of this general info about the 7600 chipset onto an S thread that had gone way deep into to the topic of HD video recording ("we just need some dev to step up and make this, it can't be hard!") without any actual knowledge of anything. It was pretty funny, actually. People seriously wondering why their Corolla wouldn't be able to fly if they just stapled on some cardboard wings.

 

[mmarz]

I already posted a datasheet link and some of this general info about the 7600 chipset onto an S thread that had gone way deep into to the topic of HD video recording ("we just need some dev to step up and make this, it can't be hard!") without any actual knowledge of anything. It was pretty funny, actually. People seriously wondering why their Corolla wouldn't be able to fly if they just stapled on some cardboard wings.

I'm sure you can combine HD video recording with your weekend project to port Adobe Flash to android. Can't be that hard

 

[picasticks]

Can I request it being placed as a separate zip and not included with the kernel? I have my own key map, and I don't want to replace it every time I test your kernel. Just a suggestion.

Yeah, I knew there would be people like you! (see a couple of days ago on the thread, me and obijohn talking about this).

I agree in principle that it is bad for me to be clobbering people's keymaps. I also think it's pretty ironic considering (AFAIK) my kernel is the only V kernel circulating actually built from the V source, with the correct button map (rather than incomplete ports of S kernels) ... but everybody who has flashed something to swap their button map now flashes my kernel and thinks something is wrong.

For right now I think I will include the file because it will fix the issue and only negatively affect a small minority (right now, well, you ... welcome to the minority!), who are probably also smart enough to work around it. Sorry. I would hope that people will fix the other kernel(s) and I can pull this "feature" out at some point.

For sure if I put this in and then everyone says "why are you clobbering my custom keymap!?!?!?!" I will take it back out again.

A better fix would be to just patch the keymap, I don't know if I could run patch or a sed script or similar, but honestly I don't want to make it that complex and have it possibly break for people. The range of commands you can run in the update.zip is very limited because the filesystems aren't mounted, so you basically have to include binaries for every command you want to run.

The "right" fix would be to have an sh script check for the bad keymap, if found then run patch, and then depending on the exit code either exit on success or default to clobbering the file only as a last resort. If somebody wants to make that, it would probably only take a couple hours and it would I think be a great addition to the AnyKernel framework which is used by the entire Android community.

I don't want to get into it (it would be a side project of a side project for a phone I don't own, of a side project of a hobby at that point), but if it's possible/easy to just to a check and not clobber if the keymap is already correct, I might do that.

 

[obijohn]

EDIT: oops, posted in he wrong thread.

 

[Eollie]

That's right, because then noobs won't mess it up and flood the forums. Sigh...

What is the point of your post again???

I've used adb, and have no issues. I'm just making a suggestion.

My point is STOP making everything one click and where brain dead people can do it.

Ask any dev if they like one clicks or would rather people actually have knowledge of basic commands. THAT is your answer.