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

[picasticks]

Hey all!! I was reading through this thread and noticed that majority of the users of this kernel have thunderom in their signature, so is this comnpatible with aosp or scott pilgrim rom

Short answer: Probably!

Long answer: I don't run those so I don't know, maybe somebody else on the thread can help out. This kernel is basically an upgraded version of the LG kernel, so if you have run the LG kernel with those, then yes.

It uses koush's AnyKernel so there should be no problem flashing it over any ROM (the same way zefie's experimental AnyKernel version of Xionia works), because it keeps whatever boot ramdisk image the ROM is already using and changes the kernel only.

Other answer: It would be awesome if you could find out! Here is a .zip of the stock LG VD kernel if you would like it in case something goes wrong.

 

[00_wrath_00]

I have tried it on AOSP and Zefies CM7 and in my opinion i think the kernels that are installed in their roms work better. In like NROM and ThundeROM they work awsome.

 

[jcwxguy]

so far so good

 

[zefie]

I have tried it on AOSP and Zefies CM7 and in my opinion i think the kernels that are installed in their roms work better. In like NROM and ThundeROM they work awsome.

Xionia has many tweaks for CM7.

The current Xionia is designed and required for CM7 and anything based off CM7.

Pixa's kernel is suggested for anything that is still LG based, including nROM, ThundeROM, Stock, and even VCRom. Anything still with LG's framework.

The current Xionia is "compatiblie" with LG Framework ROMs, but some issues occur (namely USB).
The last Xionia designed for both LG Framework and CM7 is v010.
I recommend against using anything higher than v010 on LG Frameworks.

Pixa's kernel is "compatible" with CM7 in the fact that it should boot, but many features required by Gingerbread may be unavailable and may lead to instability.

That's about the gist of it at this point.
Officially I'd recommend kernels as stated above.

 

[picasticks]

What zefie said!

He pretty much said it all. I guess I should add that "officially" as far as the picasticks kernel goes, I'm not supporting CM7. That means that if you're running CM7 and try my kernel and like it, great, and if you find a problem feel free to post about it here (I would be very interested, and it would add to everybody's knowledge), but be sure to mention that you're on Cyanogen not an LG-based ROM so people don't get confused.

If you think you find a bug, but you can't reproduce it on an LG-based ROM, then it's not a bug.

For now, I haven't gotten into CM7 (I would like to, but too many other projects!). If I were to in the future, and build a kernel for it (more hypothetical and unlikely), it would be a different kernel with a different name. Picasticks kernel will stick with the "stock plus" philosophy for LG-based ROMs.

 

[zefie]

What zefie said!

He pretty much said it all. I guess I should add that "officially" as far as the picasticks kernel goes, I'm not supporting CM7. That means that if you're running CM7 and try my kernel and like it, great, and if you find a problem feel free to post about it here (I would be very interested, and it would add to everybody's knowledge), but be sure to mention that you're on Cyanogen not an LG-based ROM so people don't get confused.

If you think you find a bug, but you can't reproduce it on an LG-based ROM, then it's not a bug.

For now, I haven't gotten into CM7 (I would like to, but too many other projects!). If I were to in the future, and build a kernel for it (more hypothetical and unlikely), it would be a different kernel with a different name. Picasticks kernel will stick with the "stock plus" philosophy for LG-based ROMs.

And if you are the rebel and must run Pixa + CM7 don't even bother posting a bug in CM7 Thread

Edit: idk where this habit of calling you Pixa came from, lol.

 

[picasticks]

New version 07 adds Linux ext2/3/4 filesystems as modules

Some Optimus V people wanted Linux ext2/ext3/ext4 filesystem support, so this is added in version 07. No other changes. (Now, I built and tested about a dozen new things, but after testing/benchmarking reverted every last one of them.)

The modules are in /system/lib/modules as always, and you'll notice that if you need ext3 or ext4 support there are separate modules for journaling.

What could you use ext for? Well, Link2SD and various app2sd scripts seem to be the main uses (which of course isn't as important anymore since Froyo has its own Move to SD). But, you could put an ext partition on your SD card and mount any filesystem you want to it ... though mounting /system to SD is going to require a lot more script fu than /data/apps!

picasticks-07.zip

 

[basketthis]

Before I go messing up my boot files, etc, is there an easy way to do this:
# "echo 'interactive' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor" and add this one-liner to any boot script if you want it to happen automatically on boot. [or]
# Unpack the boot.img and edit /init.qcom.post_boot.sh in the ramdisk to use 'interactive', then repack and flash_image the new boot.img. This is what I do, and what you'd do if you were building a ROM with this kernel.

?????
I did search on my own and try to find something on it and just can't seem to find any solid information for the LG Optimus S in particular. Everything seems to be generic Android information and a bunch of coding to see what works for each particular phone... I am lost...

EDIT: Don't want to use SetCPU btw. I know your "easy" suggestion is to do that, but I would like to go for one of the other options you have listed. How does the interactive for you as opposed to the ondemand? Most say it's smoother and improves battery life...

 

[dburg]

I've used this with CM7...haven't noticed any different bugs than current known bugs in CM7 stock kernel. Pretty snappy as well

 

[picasticks]

Before I go messing up my boot files, etc, is there an easy way to do this:
# "echo 'interactive' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor" and add this one-liner to any boot script if you want it to happen automatically on boot. [or]
# Unpack the boot.img and edit /init.qcom.post_boot.sh in the ramdisk to use 'interactive', then repack and flash_image the new boot.img. This is what I do, and what you'd do if you were building a ROM with this kernel.

Well, the first thing is just a one-line command:

echo 'interactive' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

You can do that at any time from an adb shell or any other console shell (like Terminal Emulator). Note that you can also get the current scaling_governor at any time by doing:

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

To change the scaling_governor automatically on boot, you could add it to an .sh script that runs on boot. I put it into init.qcom.post_boot.sh, which requires unpacking/repacking the boot partition ... but you could probably put it someplace else that doesn't require modifying the boot image, such as in /system.

If you ROM has init.d support (and it works) you could make a small script to do this and put it into /system/etc/init.d. i.e. put this into a file:

#!/system/bin/sh
echo 'interactive' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

and save without any extension (i.e. as "interactivecpu"). Then save or adb push that file to /system/etc/init.d and chmod it executable (i.e. "chmod 755 /system/etc/init.d/interactivecpu").

I have not tested this, but it should get you far enough along to get it working.

If you do that, and it doesn't work on boot, you can also just run the script from the shell at any time:

/system/etc/init.d/interactivecpu

What you need to know is that /init.qcom.post_boot.sh is a script that runs on boot and changes the governor to ondemand (unless you modify it). So, depending on the order things are run, a script you add to run on boot, if it's run before init.qcom.post_boot.sh, won't do any good because init.qcom.post_boot.sh will just run and change the governor to ondemand. I haven't tested the init.d script, so it may just work. But if it doesn't, that may be the problem.

EDIT: Don't want to use SetCPU btw. I know your "easy" suggestion is to do that, but I would like to go for one of the other options you have listed. How does the interactive for you as opposed to the ondemand? Most say it's smoother and improves battery life...

Well, you are welcome to do whatever you like! I personally don't see any downside to using SetCPU to do this (it is just going to cat 'interactive' into /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor like any script). I called it the "easy" way but that does not mean the other ways are any better. And remember that if you do it the "hard" way you will have to remember to undo things if you later decide to flash a kernel without interactive support.

The main advantage to interactive is that, coming out of idle, it automatically ramps up to max CPU, so it's going to be more responsive. Ondemand takes longer to ramp up the cpu speed because it uses a weighted average of cpu demand over time. But, we're talking milliseconds here.

Personally I prefer to run interactive and have not had any problems. I would agree that it feels a little smoother. However, I would be skeptical and ask to see real data re: claims about battery life. I have tried to design clean benchmark conditions for my kernel and it is very difficult. You would have to connect a power meter between your phone and battery, boot into airplane mode, and conduct a very precise set of simulated usage of the phone and apps. It's very difficult to simulate real usage in repeatable way. Turn the radio on, and you'd also have to guarantee radio usage (polling for email, whatever the OS does) to be identical between tests.

Sorry if that sounds unhelpful and equivocating. Personally, given my observation of the cpu frequency as I do various things and knowledge of the code of the two governors, I would expect power usage to be similar. No great savings either way.

 

[onyxdroid]

I flashed this kernel, and now the GPS is acting ******ed. It cannot get a lock on my exact location, it just uses cell towers. Is there a fix?

 

[dsstrainer]

Does this kernel not work with Reborn Rom?
I was running Reborn fine but setcpu would keep showing the clock speeds changing from what I set them to.. sometimes 245 to 806, then go back and its 320 to 566, then 245 to 748... all over the place.
So i flashed this rom and rebooted, but after the reborn logo, the phone just shows a blank screen.

 

[tmeader]

Does this kernel not work with Reborn Rom?
I was running Reborn fine but setcpu would keep showing the clock speeds changing from what I set them to.. sometimes 245 to 806, then go back and its 320 to 566, then 245 to 748... all over the place.
So i flashed this rom and rebooted, but after the reborn logo, the phone just shows a blank screen.

Have you updated to Reborn 2.2.3? It appears that 2.2.3 is using the collin_ph battery tweak automatically (I wasn't aware of this. Maybe I just read the release notes wrong, but I THOUGHT they just indicated that 2.2.3 made it so it COULD support that tweak properly, not that it did by default). This does indeed seem to completely override any changes you make via SetCPU. No matter what I set SetCPU to be (245 and 748 - smartass), it would continuously change the speed settings around without me doing anything. Only via alogcat output did I trace it back to that finally. Due to this, I'm reverting back to 2.2.2 for the time being. Perhaps you could try the same?

 

[sblood86]

Does this kernel not work with Reborn Rom?
I was running Reborn fine but setcpu would keep showing the clock speeds changing from what I set them to.. sometimes 245 to 806, then go back and its 320 to 566, then 245 to 748... all over the place.
So i flashed this rom and rebooted, but after the reborn logo, the phone just shows a blank screen.

Most of your questions are answered in the reborn rom change log but since you asked:
-The reason you are seeing the clock speeds jump around is because Nick7 ported the smartass governor to the kernel he is using with that rom. Search the forum for smartass governor if you want more information on that.
-Otherwise Reborn rom is running a modified version of the Picasticks Kernel in the first place. Nick7 optimized that version for Reborn so there is very little need/purpose in flashing this Kernel.
-I'm not certain if the current version of picasticks runs on reborn rom as is but you would have to clear your cache and dalvik cache before trying to flash it (not sure if you did that or not)
-Either way I'd say restore from nandroid, assuming you made one.

Edit: The set cpu method mentioned by tmeader has you change the governor from smartass to ondemand than set profiles to control what speeds your phone is at during different states.

Edit 2: Sorry reread tmeaders post the collin_ph battery tweak is not enabled in reborn 2.2.3, Nick modified the rom slightly to allow the script to survive a reboot if the tweak was applied. As for the functionality/stability of 2.2.3 vs 2.2.2: 2.2.3 is running on the other S in my possession and has been since Nick posted it on G+, I haven't seen any issues with cpu speed, temperature or battery life, all systems seem stable as they were before. - I should note that is without the collin_ph battery tweak enabled, I've been meaning to flash and configure it.

 

[tmeader]

Edit 2: Sorry reread tmeaders post the collin_ph battery tweak is not enabled in reborn 2.2.3, Nick modified the rom slightly to allow the script to survive a reboot if the tweak was applied. As for the functionality/stability of 2.2.3 vs 2.2.2: 2.2.3 is running on the other S in my possession and has been since Nick posted it on G+, I haven't seen any issues with cpu speed, temperature or battery life, all systems seem stable as they were before.

All I can tell you is that the collin_ph tweak WAS running on mine, and constantly changing the speed without my intervention. I would have SetCPU open and while just sitting at the main screen, the max speed readout would jump around to rather odd numbers (like "611" or "589", settings which you can't even do with the sliders). Tailing the logs with alogcat showed constantly running "collin_ph" output lines, along with messages about the CPU speed being modified. Are you currently running 2.2.3 yourself, and can you confirm that you aren't seeing this behavior? Going back to my nandroid backup of 2.2.2 made it completely stop doing this. If I flash 2.2.3 again (after a cache and dalvik wipe), the collin_ph messages pop back up in the log.

 

[dsstrainer]

Whatever the case, let me just say picasticks 0.7 with the "newer display type" does not boot with reborn 2.2.3. Even on a fresh wipe. I switched to Xionia and all things were smooth once again with reborn.

Now I am trying ShellRom now with picasticks 0.7 and it does seem to be running fine