Changing vsel of lower frequencies with overclock - Defy General

have been pratting about with this over the last day, have found the following.
I am using overclock module to set a custom setting of 900mhz/46vsel
However, when performing a cat /proc/overclock/mpu_opps I get the following
mpu_opps[3] rate=900000000 opp_id=3 vsel=46
mpu_opps[2] rate=600000000 opp_id=2 vsel=48
mpu_opps[1] rate=300000000 opp_id=1 vsel=33
So whilst we are changing the max_freq and max_vsel we are not doing anything to reduce the vsel on the lower frequencies and thus not getting max battery life. The stock vsel at 600mhz is actually more than 900!
So I made a script so as to change the vsel values to lower for the lower frequencies as below:
setscaling.sh
echo 46 > /proc/overclock/max_vsel
echo 900000 > /proc/overclock/max_rate
echo 1 300000000 28 > /proc/overclock/mpu_opps
echo 2 600000000 38 > /proc/overclock/mpu_opps
echo 3 900000000 46 > /proc/overclock/mpu_opps
echo 0 900000 > /proc/overclock/freq_table
echo 1 600000 > /proc/overclock/freq_table
echo 2 300000 > /proc/overclock/freq_table
mpu_opps then read as I want it:
mpu_opps[3] rate=900000000 opp_id=3 vsel=46
mpu_opps[2] rate=600000000 opp_id=2 vsel=38
mpu_opps[1] rate=300000000 opp_id=1 vsel=28
I can run the script manually, and it works a treat, however, on reboot it has to be manually applied. Tried a number of ways to get this to run at boot (scripts and also autostart app in the market) however it doesn't apply and the reason behind this is due to it trying to apply the script before the overclock module has been applied.
I then tried to exclude the Milestone overclock app and use the overclock.ko module directly into /system/lib/modules/overclock.ko. The module itself seems to run ok, however when I then apply my setscaling.sh it cause the phone to reboot.
So a few questions if anyone can help.
1)is there anyway to delay a script from running for a period of time after boot (eg once the overclock module has loaded)
2) Any ideas why the phone is rebooting when using the overclock module directly outside the app, but the script works fine in conunction with the app.
I think I am just missing something obvious thats staring me in the face!

I guess it would be quite simple for whoever coded milestone overclock to just add a setting where we can choose the vsel for multiple frequencies...
Good job though, was wondering also if that was possible!
Will try and find how to contact him

Damool said:
I guess it would be quite simple for whoever coded milestone overclock to just add a setting where we can choose the vsel for multiple frequencies...
Good job though, was wondering also if that was possible!
Will try and find how to contact him
Click to expand...
Click to collapse
I have added my setscaling.sh place it in /system/binx and execute it.
You can ammend it to put your own frequencies in there, be careful though!

Thanks will try when back from skiing

Higgsy, do you know how Android natively sets the frequency and voltage levels? Is there a config file or is it hard coded into the kernel or a module? My googling skills didn't turn up much.

Zaben said:
Higgsy, do you know how Android natively sets the frequency and voltage levels? Is there a config file or is it hard coded into the kernel or a module? My googling skills didn't turn up much.
Click to expand...
Click to collapse
The default levels should be the reset values in the hardware itself. The Milestone Overlock App contains a kernel driver to communicate with the OMAP processors PLL and voltage chip (the TWL5030 chip) using the I2C buss to be able to modify these registers and their reset values. Higsy is communicating with this kernel driver using the /proc to set some of the registers that the kernel driver has mapped out. So it's more a case of being able to set these registers when the kernel module is being loaded to avoid doing it once the driver has been loaded.

Xhit said:
The default levels should be the reset values in the hardware itself. The Milestone Overlock App contains a kernel driver to communicate with the OMAP processors PLL and voltage chip (the TWL5030 chip) using the I2C buss to be able to modify these registers and their reset values. Higsy is communicating with this kernel driver using the /proc to set some of the registers that the kernel driver has mapped out. So it's more a case of being able to set these registers when the kernel module is being loaded to avoid doing it once the driver has been loaded.
Click to expand...
Click to collapse
Yeah thats it, any suggestions then? At the mo I'm still running my script manually on boot after everything is loaded, to be fair I do it without thinking about it now, but would be good to automate it

Higgsy said:
Yeah thats it, any suggestions then? At the mo I'm still running my script manually on boot after everything is loaded, to be fair I do it without thinking about it now, but would be good to automate it
Click to expand...
Click to collapse
Hmmm, seems I was mistaken in my last post. The kernel driver does not write to the TWL5030 directly, some registers in this chip has already been mapped out by and OMAP kernel driver and the overclock kernel driver is just used to be able to get to the OMAP driver parameters and other kernel parameters. All this according to the documentation found in code.google.com/p/milestone-overclock/wiki/KernelModule . And according to the same you can set some parameters when you insmod the kernel driver, "insmod overclock.ko mpu_opps_addr=0xc050a848 max_rate=800000 max_vsel=62". So you could try to set the arguments you want in freq_table and mpu_opps at insmod instead to see if that works?
EDIT: According to the FAQ, changing the freq_table and mpu_opps can only be done using a script writing to /proc.
http://code.google.com/p/milestone-overclock/wiki/FAQ
Edit 2: Checked the source code of overclock kernel driver. And the freq_table and mpu_opps is not a module_param meaning you can not set them during kernel load. However it would be very easy to add a couple of module_params to the source code be able to set them during kernel driver load. However you would need the complete cross-compiler environment to build it once modified, which I guess is the major time consumer to make this change. So kindly asking Tiago Sousa whos written it would maybe be the quickest..

Xhit said:
Hmmm, seems I was mistaken in my last post. The kernel driver does not write to the TWL5030 directly, some registers in this chip has already been mapped out by and OMAP kernel driver and the overclock kernel driver is just used to be able to get to the OMAP driver parameters and other kernel parameters. All this according to the documentation found in code.google.com/p/milestone-overclock/wiki/KernelModule . And according to the same you can set some parameters when you insmod the kernel driver, "insmod overclock.ko mpu_opps_addr=0xc050a848 max_rate=800000 max_vsel=62". So you could try to set the arguments you want in freq_table and mpu_opps at insmod instead to see if that works?
EDIT: According to the FAQ, changing the freq_table and mpu_opps can only be done using a script writing to /proc.
http://code.google.com/p/milestone-overclock/wiki/FAQ
Edit 2: Checked the source code of overclock kernel driver. And the freq_table and mpu_opps is not a module_param meaning you can not set them during kernel load. However it would be very easy to add a couple of module_params to the source code be able to set them during kernel driver load. However you would need the complete cross-compiler environment to build it once modified, which I guess is the major time consumer to make this change. So kindly asking Tiago Sousa whos written it would maybe be the quickest..
Click to expand...
Click to collapse
Right I cracked it!
all I had to do was the following
My setscaling.sh resides in system/xbin
I created an Install-recovery.sh and placed in system/etc
The content of Install-recovery.sh is:
#!/system/bin/sh
sleep 90
setscaling.sh
Hence making the script wait 90 secs before it initialises my setscaling.sh - plenty of time for the overclock module to load.
It may not be the best solution but it works a treat.

Wow that was fast. I've been playing with the voltages and it seems that stability depends on both the starting freq/vsel and also the current battery level. For example I can lower the voltage for 300MHz slowly while staying at 300MHz, but jumping from 600MHz I have to be much more careful so the resulting vsel has be to much more conservative. Milestone-overclock isn't always successful when you hit "apply" (including false read back) and I had to use Quadrant's system info to verify each time. This was much more touchy compared to undervolting a laptop.

Is there an "init.d" directory? Equipment I work on have this directory and all across are run when it resets.
Sent from my MB525 using XDA App

Related

Krazy-Killa's Kernel Release - RLS 5.9.2.2 Released!

CPUFreq Successfully Installed and Running​
Please visit my website for additional information
After receiving alot of positive results from my Kernel and several releases later. We have arrived at RLS 5.9, a prototype build incorporating CPUFreq for CPU Scaling and Idle control, and a modified version of Power Management. We are at a release stage of this Alpha build, and approaching Beta, where it is as follows:
Each build that is released that has an update to CPUFreq will have an update to the first subversion in the build version (eg. RLS5.9.1.0)
Each build that is released that has an update to Power Management will have an update to the second subversion in the build version (eg. RLS 5.9.0.1)
And of course each upgrade to a specific subsystem of the Kernel will up the version number of that specific subversion.
Current Release: RLS 5.9.2.2​
RLS 5.9.2.2 will mark the beginning of the Beta stage out of Alpha stage. This release is showing far more promising results than my initial CPUFreq release.
I just want to personally thank all who have been supporting me and reporting any and all bugs that have been coming in, as I have been squashing them left and right in preparation to improve our Kernel for our phones to make them more feasible for everyday use.
Currently Being Tested:
Power Management - Reverted some old changes to the power management code, switched too Apps Sleep. Made some minor changes to the original pm.c source code and results are promising. Running VanijlEclair RLS11, and in rare cases the phone still crashes while sleeping, which I believe is related to the phone hiccuping when going to sleep, which in theory could completely blow up the timer that Apps Sleep uses for sleeping. I will investigate this part further, but so far, RLS 5.9.2.2 is much more stable than my previous release.
CPUFreq - No changes to the source code, still attempting to modify permissions so Android can modify the files that are required.
HAReT Users - Thanks in large part to V3rt!g(o) HAReT users can now boot the Kernel. I have made a slight modification to the default.txt file provided in the RLS 5.9 HAReT archive that uses Apps Sleep instead of Power Collapse. From what was reported, the Kernel takes about 2 minutes to initialize from WinMo, but after about 1min30sec to 2min, Android should begin loading.
Radio ROM - Currently Testing Radio 1.71.09.01, and so far it seems very stable and provides better battery usage.
Current Release (RLS5.9.2.2):
Kernel - HTC Polaris support re-introduced.
CPUFreq - Has been installed, and working inside the Kernel only. Android does not recognize CPUFreq correctly.
Processor - MSM-7201 processor increased from 384MHz to 528MHz
Stability - Has been improved further. Phone correctly sleeps and wakes properly. Still occasional crash occurs, but is random. Could go a full day without a crash, or could crash every 4hrs. Issue might be related to how much the CPU is being utilized at the time of wake up.
Power Management - Power Management restored to near WinMo states, still not as good as RLS5.7, but within range. Phone will last a full day of occasional use, and about 80% of the day on moderate use.
Initrd - New BootLogo has been made, and inserted into initrd. Unfortunately boot menu is not accessible. Made install scripts to compensate.
YAFFS2 - Exclusively does ECC checking on it's own without any help from the NAND driver. This should help with data corruption, but is not a permanent solution.
YAFFS2 - Disabled Forced erase chunk checking, slight increase in response time and decrease in read-time.
MTD - Disabled Verify NAND Page Writes
MTD - Disabled GPIO NAND Driver
EXT - EXT2 is currently disabled inside the Kernel. EXT4 has been fully enabled, aside from journaling, and is fully supported in the kernel and install scripts.
System - Switched from DG (High Resolution) Timer, to GP (Low Resolution) Timer.
System - Fully disabled High Resolution Timer -- Provided a decrease in kernel size without loss of performance.
sysfs - Enabled configfs. This will unavoidably increase RAM usage, but allow easier access to sysfs.
MSM - Performance Counter Driver enabled.
FrameBuffer Driver - Decreased fake-vsync delay from 10 to 5. Less times snow effect appears.
Known Issues:
Internal CPUFreq coding is unable to scale the processor, but the hacked msm_cpufreq_* functions are able to control the processor speeds. This will explain why CPUTuner and other Android software is reporting the CPU running at max speed. Will continue to investigate and work out problems with the coding.
JIT Compiler causes issues with framework.acore. Avoid using if possible.
CompCache not the cause of untracked PID errors -- Still investigating cause, though now understanding that it is related to data corruption.
Possibly depending on Radio, GPS takes quite awhile to acquire if not at all. -- Will investigate by flashing an older/newer radio.
Standby code not fully working due to being incompatible with clock code changes. Attempting to re-write power management code to be better compatible with the new clocks code.
CPUFreq Specifics:
Governors - Currently CPUFreq supports the following governors and can be changed while in Android using the Terminal: ondemand, conservative, powersave, performance. Userspace is currently disabled inside the Kernel.
Frequencies - Baseline frequencies the CPU will scale to but not limited too are: 81920 (82MHz), 122880 (123MHz), 245760 (246MHz), 384000 (384MHz). These are just placeholders to control where the CPU needs to scale too base on usage, it will go between lets say 82MHz and 123MHz or use one of the two.
Userspace - Until I can verify CPUFreq is fully operational without any issues, I will not enable Userspace Governor at this time.
Kernel Modules
File Attached to this Post, see below.​
This Kernel has been tested with the AT&T Tilt variant of the Kaiser. Using it on any other Kaiser would in theory produce the same results, but due to minor changes in the hardware of each variant of the Kaiser, I'm still going to stress caution when using this Kernel with any other variant of the Kaiser
Things to note about EXT4: This file system will increase read/write cycles to your SD Card. Use with caution as it will decrease the life of your SD Card. Though since Journaling is disabled, read/write cycles will have decreased, but they are still higher than what they would be if EXT2 was used. If you do not feel comfortable having EXT4 on your SD Card, do not use this Kernel as there is no way to use EXT2. You have been warned.
Things to take note with this Kernel: Do not enable JIT compiler under Settings, as this has produced constant FCs with the acore framework. It is recommended that you enable CompCache and set it to the default 18%, as this provides a significant performance boost, and decreases Home screen closures while running other apps.
USE THIS KERNEL AT YOUR OWN RISK. I TAKE NO RESPONSIBILITY FOR ANY DAMAGES DONE TO YOUR PHONE WHILE USING THIS KERNEL.​
Woohoo ! First Post!
Thank you Krazy-Killa! Will definitely try this now will post after testing!
I am liking what I am seeing. Thanks for putting the effort into creating this. I'm just curious about one thing, you said that Scoot's CM7 RLS1 build has the modules for this kernel included. Is there a separate download of the modules for anyone that might not be using this build?
Hello Krazy-Killa,
Appreciate your effort !
I just installed it on my TYTN II and so far going well -edited .ngh to change the key mapping to normal.
3G works fine. yet to see BT,WiFi &GPS and overall otherwise.
I have tried Scoot's CM7 RLS1 build 2 days ago.is there any major changes you did - i feel some audio notification alerts changed w. r. t. Scoots.
how can i use those audio files if reqd-i mean can copy&dump to a specific folder and repack.
but its not really matter..
At the moment 'push' works fine and eager to see any 'server connection' problem will occur later with the email client.
i have radio 1.70.19.09
Thanks once again for the post.
Cheers !
cerebralgenius said:
I am liking what I am seeing. Thanks for putting the effort into creating this. I'm just curious about one thing, you said that Scoot's CM7 RLS1 build has the modules for this kernel included. Is there a separate download of the modules for anyone that might not be using this build?
Click to expand...
Click to collapse
I will release the modules as a seperate androidupdate file this evening.
@chandra_100,
All my testing shows BT, WiFi, and GPS working. This Scoots CM7 build I released is just repackaged with my built modules for easy install.
Sent from my AT&T Tilt using XDA App
“Removed support for HTC Polaris”
That’s too bad,poor Polaris,555555555555555~
The untracked PID errors are related to froyo only (maybe Gingerbread too). And its related to init.rc provided with each build. Not kernel's fault
dark_prince said:
The untracked PID errors are related to froyo only (maybe Gingerbread too). And its related to init.rc provided with each build. Not kernel's fault
Click to expand...
Click to collapse
Interesting... Well, I had a looping untracked PID this morning, had to reinstall, but that's mainly the only problem I'm now having... If I could I would build a new init, but the bootenv isn't updated.
Krazy-Killa said:
Interesting... Well, I had a looping untracked PID this morning, had to reinstall, but that's mainly the only problem I'm now having... If I could I would build a new init, but the bootenv isn't updated.
Click to expand...
Click to collapse
The bootenv is fully up to date The untracked PID's aren't caused by the init.rc, they are caused by corrupt filesystems or files which mean that the paths that sysinit.rc is trying to mount aren't there or it can't change permissions on a file because it is corrupt.
for me kernel can't find data.img
Ive go some kind of problem. Im using fresh froyo and when I installed your modules update than I got hang in boot. Excatly at "adb_open" line. Without update everything is ok except wifi.
Sorry for my poor english
Neo2SHYAlien said:
for me kernel can't find data.img
Click to expand...
Click to collapse
I'll look into it. Though I may know the reason why, so I'll do some more testing, and will release once I have it fixed.
scooter1556 said:
The bootenv is fully up to date The untracked PID's aren't caused by the init.rc, they are caused by corrupt filesystems or files which mean that the paths that sysinit.rc is trying to mount aren't there or it can't change permissions on a file because it is corrupt.
Click to expand...
Click to collapse
I'll update my local bootenv, thanks.
Good release. Slightly slower than Clemsyn's kernel (tested in quadrant), but good stability. One thing drives me crazy - I have to wait 5-10 seconds after pressing power button to wake device
MaRekRM said:
Good release. Slightly slower than Clemsyn's kernel (tested in quadrant), but good stability. One thing drives me crazy - I have to wait 5-10 seconds after pressing power button to wake device
Click to expand...
Click to collapse
That was mentioned in the known issues, don't worry my next release will fix that (currently testing). Plus it'll add full EXT4 support like with clemsyn's kernel but you can format your SD card with the device now as I have updated initrd.
Sent from my AT&T Tilt using XDA App
Flashing
I'll try... flashing right now.
what about ipv6 support?
*EDIT* nevermind, i just saw that ipv6 is implemented.
Cannot restore databackup.img trough install menu...
I think this kernel canot handle the img fs. Mount is failing.
Sent from my CyanogenMod Kaiser/Kaiser using XDA App
It's because of EXT2 support being turned off... I'm currently testing a new kernel that'll be using EXT4. Running into the same problem you are having with img mounting.
I'm working on isolating the issue why img mounting isn't working.. It's possibly an issue with the init scripts. I'll dig more into it and hopefully get it isolated.
Backup FS
Krazy-Killa said:
It's because of EXT2 support being turned off... I'm currently testing a new kernel that'll be using EXT4. Running into the same problem you are having with img mounting.
I'm working on isolating the issue why img mounting isn't working.. It's possibly an issue with the init scripts. I'll dig more into it and hopefully get it isolated.
Click to expand...
Click to collapse
Probably the script that is generating databackup.img still using ext2.
tiagoclc said:
Probably the script that is generating databackup.img still using ext2.
Click to expand...
Click to collapse
Yep, it was exactly that. Just made the necessary changes, and compiled a new kernel. I'll go ahead and throw it out, but for now I'll point out that I haven't tested it so, please let me know the results.
Init itself is already setup to mount all loopback and SDcard partitions as EXT4 where applicable.
Just use atools to configure the kernel to use /system and/or /data on NAND or SDCard.
Why did you remove polaris support? I think that are plenty of polaris users that want to test your kernel
Thanks

[Test][Kernel] -fox 2.6.27 kernel for RHOD Only!

I pulled the latest kernel tarball, fixed and tweaked a few things, then compiled it on my Rhodium. Although it works well on my Rhodium, I cannot guarantee that it will work on yours. In addition, it is guaranteed NOT to work on any other since I disabled support for it in .config.
You can install this kernel just like the one you would off the autobuild. The kernel is named -fox-YYDDMM where the date is when I pulled the tarball. While suggestions and feature request are welcome, it takes me ~2.5hr to go through one compile, so don't expect a new build very often.
You need the patched haret.exe as well as an additional line in startup.txt to boot this kernel. Instructions for that can be found at http://forum.xda-developers.com/showpost.php?p=14519408&postcount=1.
Latest (8/20) at http://db.tt/OeRyLYu
Changelog:
8/20 http://db.tt/OeRyLYu
microp: Upstream version of LED patch from Detule. Please note the requirement of updated lights.msm7k.so still applies.
8/16 http://db.tt/3UWBs3y
microp: Updated microp LED patch from Detule, now with more blinkenlights goodness (and yes, it even blinks). In order to use this, however, you need an updated liblights from http://db.tt/ZUjymT9. The file should be bind-mounted on startup in your froyo.user.conf, ie: mount --bind /sdcard/lights.msm7k.so /system/lib/hw/lights.msm7k.so
8/15
microp: Proposed LED patch from Detule, mailing list has instruction on how to play with the blinkenlights.
.config:
Enabled IP_NF_TARGET_REDIRECT as a module because it's needed for certain app.
Started from clean source to get rid of any residuals.
8/11
Compcache: Included 0.5.4, patched kernel to support the swap notify
clock-wince: Added a debug output that shows freq requested, closest set, and the calc, without needing clock_wince.debug_mask=15.
.config notes:
LZOCOMPRESS/DECOMPRESS is built-in to the kernel. Therefore if you want compcache, you just need to insmod xvmalloc.ko and ramzswap.ko.
8/9
Upstream: htc_headset_microp fix
acpuclock: Changed turbo mode+20mhz only when acpuclock.force_turbo=2 is set. Also, overclock by 20mhz for any bus speed >100MHz.
modules: Use strip --strip-unneeded.
8/6
acpuclock: Change turbo mode t->axiclk_khz from 160000 to 180000. AXI clock control the bus freq, and upping it should make overall performance better.
clock-wince: Add supposed support for 48Mhz SD clock from .35. HOWEVER the kernel claims calc_freq is 61.44Mhz according to clock_wince.debug_mask=15. You also need to add msmsdcc_fmax=48000000 in order to use this clock anyway.
proc_comm_wince: Fix long-standing issue with msm_proc_comm_wince_pending_ints & DEX_INT_VBUS check which clobbered pending_int. You should no longer have a SoD during transition changes to/from suspending while inserting/removing the USB cable.
microp-k*: Got rid of the printk spam of backlight/keyled status changes.
.config changes:
1) Change default I/O scheduler to deadline. Our kernel does not do well with noop.
2) Change default AMSS firmware interface to 6125 which is what I have on my RHOD400. You can check yours (which is in the modem) by running dmesg | grep AMSS.
3) Change kernel default sleep_mode from CONFIG_MSM7X00A_SLEEP_MODE_POWER_COLLAPSE_SUSPEND to POWER_COLLAPSE. This is usually overridden but makes pm.sleep_mode=1 unnecessary.
4) Change CONFIG_MSM_CPU_FREQ_ONDEMAND_MIN from 128MHz to 112Mhz. This meant that the kernel never used the 112MHz clock because it was below the ondemand minimum. No-frills CPU can confirm this.
5) arm6k support enabled. Not sure if it makes a difference but the kernel hasn't complained.
6) Conservative and Powersave governor enabled.
7) CONFIG_INPUT_TABLET disabled, nothing was enabled in there anyway and ours uses TOUCHSCREEN.
8) CONFIG_USB_ANDROID_RNDIS_WCEIS enabled, supposedly makes Windows think it's dealing with a NDIS ICS device.
9) Enabled ext4 and disabled yaffs2. Ted T'so backported fixes for ext4 for .27 release. This contains all the patches available on his ext4 git for the 2.6.27 kernel, but still should be considered EXPERIMENTAL.
GPL availability notice:
kernel source as available from http://gitorious.org/linux-on-qualcomm-s-msm/linux-msm/commits/htc-msm-2.6.27
compcache module+patch from http://code.google.com/p/compcache/downloads/detail?name=compcache-0.5.4.tar.gz
.config used to compile available from within /proc/config.gz
Minor patches to the kernel source can be made against the git tree upon request. Please PM me if you are in need of that.
-- Starfox
Hmm haret freezes with your kernel on my rhod100_de.
(pm.sleep_mode=1 is deleted in startup.txt / no difference with pm.sleep_mode=1 not deleted)
Put sleep_mode back, and if it still doesn't boot, it's possible that the axi bus is too high. I'm looking to make it a kernel parameter in the next compile.
-- Starfox
So far so good.
Couple of things - first, it seems you didn't strip the modules...? There's no way they should be 7+mb .
Second, of all the things you've put in this kernel, one really stood out to me:
Starfox said:
proc_comm_wince: Fix long-standing issue with msm_proc_comm_wince_pending_ints & DEX_INT_VBUS check which clobbered pending_int. You should no longer have a SoD during transition changes to/from suspending while inserting/removing the USB cable.
Click to expand...
Click to collapse
If that's true ^^ (and works) why not submit a patch to mainline? Or is this your testbed for patch submission?
Good work, I'll see what I can make blow up. Only just booted... doesn't seem faster, but it's still settling methinks.
Please use the posted kernel/modules combo from the OP. I support 2 most recent revisions.
-- Starfox
i tried running this. it gets stuck at the HaRET: Booting Linux Dialogue in WinMo. am i suppossed to make any changes to startup.txt because i tried adding msmsdcc_fmax=48000000 to startup.txt and am getting the same response. is there anything I am suppossed to be doing?
anish88 said:
i tried running this. it gets stuck at the HaRET: Booting Linux Dialogue in WinMo. am i suppossed to make any changes to startup.txt because i tried adding msmsdcc_fmax=48000000 to startup.txt and am getting the same response. is there anything I am suppossed to be doing?
Click to expand...
Click to collapse
What device, build?
Rhod400, frx07
maybe a sample of the startup.txt would be appreciated too
also where am i suppossed to put msmsdcc_fmax=48000000 maybe im putting it in the wrong spot?
Running 8/6 here on rhod400. It seems just a tad bit faster/smoother.
anish88 said:
Rhod400, frx07
maybe a sample of the startup.txt would be appreciated too
also where am i suppossed to put msmsdcc_fmax=48000000 maybe im putting it in the wrong spot?
Click to expand...
Click to collapse
Did you just assume where the msmsdcc command goes? lol.
It goes in the "cmdline" between the quotes - where pm.sleep_mode is, etc. Make sure there's at least one space between each entry.
I'd imagine that's your issue, as I have the same phone/build and it works great for me.
arrrghhh said:
Did you just assume where the msmsdcc command goes? lol.
It goes in the "cmdline" between the quotes - where pm.sleep_mode is, etc. Make sure there's at least one space between each entry.
I'd imagine that's your issue, as I have the same phone/build and it works great for me.
Click to expand...
Click to collapse
odd, still no dice for me? what does your startup look like in general?
anish88 said:
odd, still no dice for me? what does your startup look like in general?
Click to expand...
Click to collapse
Did you rename the kernel? Have you updated the kernel before...?
My startup isn't anything special, just FRX07 with some additions for me (rel_path, OC, msmsdcc, no_partitions...)
Code:
set ramsize 0x10000000
set ramaddr 0x10000000
set mtype 2292
set KERNEL zImage
set initrd initrd.gz
set initrd_offset 0x00a00000
set cmdline "msmsdcc_fmax=48000000 acpuclock.oc_freq_khz=714000 lcd.density=240 msmvkeyb_toggle=off gsensor_axis=2,1,3 pm.sleep_mode=1 physkeyboard=rhod400 rel_path=Androids/Stock07 no_partitions"
boot
i didnt have set initrd_offset 0x00a00000. i changed it, booting as we speak.
anish88 said:
i didnt have set initrd_offset 0x00a00000. i changed it, booting as we speak.
Click to expand...
Click to collapse
Shouldn't need it for .27... I forgot to mention that one tho, good catch. That is for .35/.39/3.0... .27 should work without it (and you'll need a new version of HaRET to use .35/.39/3.0 with that initrd_offset...)
anish88 said:
i tried running this. it gets stuck at the HaRET: Booting Linux Dialogue in WinMo. am i suppossed to make any changes to startup.txt because i tried adding msmsdcc_fmax=48000000 to startup.txt and am getting the same response. is there anything I am suppossed to be doing?
Click to expand...
Click to collapse
STOP.
If you are not getting past the boot scroll, then your phone cannot take the changes I made.
Again, let me make this clear. I do not guarantee that your phone will work with this kernel. I also can guarantee you that no mount of fiddling with startup.txt will change the fact that your phone will not boot.
You can try the updated zImage several post past the OP which should allow you to boot. Do not go blindly changing stuff in startup.txt. If you do not know what it does, ASK first.
-- Starfox
Starfox said:
STOP.
If you are not getting past the boot scroll, then your phone cannot take the changes I made.
Click to expand...
Click to collapse
Welcome to the joys of providing patches to the public...
The new zImage doesn't work for me either.
So my phone can't handle your kernel
Perhaps the AMSS firmware or the arm6k?
No Joy with Rhod500
Just tried this on my Rhod500 and I get a couple of Vibs from phone when Haret is launched, but the screen won't even re-paint... Just thought I would let everyone know...
Thanks...
If you need to know the AMSS version, it is shown during the HTC splash screen as [bunch of letters]-6125 or something very similar. From what I see the GSM users are having most of the issues, so it probaby is AMSS related.
-- Starfox
mgross029 said:
Just tried this on my Rhod500 and I get a couple of Vibs from phone when Haret is launched, but the screen won't even re-paint... Just thought I would let everyone know...
Thanks...
Click to expand...
Click to collapse
Ditto to this on a CDMA Rhod400 also. Vibrates on launching Haret, but does not go any further.

[APP][Discontinued] init.d Generator - Siyah Kernel - 2.6.6i SE

Discontinued for now.
-------------------------------------
Okey just did some reorganisation to get this post a little bit cleaner.
I just deleted the unneeded versions, but I have a backup of them, so if you really want to have one of the older versions send me a pm and which one you want, else just stick to my recommendations below.
Most important question first:
Which Version should you take?
Siyah Kernel 2.6.6i and newer: init.d Gen 2.6.6i SE
Siyah Kernel 2.6.2 to 2.6.6: init.d Gen 2.6.2
Siyah Kernel 2.6_S99 to 2.6.1: init.d Gen 2.6
Siyah Kernel 2.5.* (all Versions, also GT): init.d Gen 2.5 SE
Siyah Kernel 2.4.2 to 2.4.*: init.d Gen 2.4.2 SE
Siyah Kernel 2.4.1 and older: init.d Gen 2.2 Beta 16 SE
What does SE and RRW stand for?
SE is for "Second Edition" and should be preferred, but you are free to take the version you like.
RRW is for "Remount Read/Write" and will remount "/system" with rw permissions, use this version if ADB Push fails to push the bootscript to the phone.
If you want to use push, pull or activate function you have to enable USB Debugging Mode else ADB can't recognize the device.
(Can be found under Menu > Settings > Applications > Developement > USB Debugging)
Please tell me if there are any issues with any function.
Known issues:
The function for deep sleep levels is not implemented correctly in the following 4 versions:
-init.d Gen 2.6
-init.d Gen 2.6 RRW
-init.d Gen 2.6.2
-init.d Gen 2.6.2 RRW
Fixed since 2.6.6i!
Thanks to gokhanmoral for the best kernel ever and helping me via pm!
Thanks to droidphile for this epic manual!
http://forum.xda-developers.com/showthread.php?t=1369817
Read it first for a better understanding of the values.
Screenshots (v 2.6.2):
Thanks to D5PiX for free image hosting
Changelog:
2.6.6i SE:
added ignore nice load to ondemand
fixed import function
fixed lazy governor
2.6.6.i:
deep sleep levels fixed
added suspend_freq to ondemand (since ondemandx was merged with it)
updated all values to the new ones from Siyah Kernel 2.6.7
2.6.2:
3 step gpu settings added
lulzactive v2 settings added
2.6:
Excluded charging currents (not needed)
Added a handfull of new options:
- deepsleep cpu and bus level
- second core sample settings (rate 2nd core on, off, screen off)
- smooth scaling parameters
- added AFTR settings
2.5 SE:
Added lulzactive samplerate settings
2.5:
Added touchscreen threshold
2.4.2 SE
Added delay function (the script will delay for a choosen amount of seconds before execution)
Added governordepending settings (sampling rate, up/downscale thresholds etc)
Added function to pull bootscript from phone to hard disk
2.4.2:
Updated to new default values.
Excluded "insmod/non insmod/legacy"-modes, insmodding will be included as needed by 2.4.2 Kernel
2.2 Beta 16 SE:
Exchanged "2.2 Beta 16 mode" with "always insmod mode"
2.2 Beta 16:
Improved including options
Added Siyah 2.2 Beta 16 referring insmod-settings
Added possibility to activate bootscript without restarting the phone
Added possibility to import settings from existing bootscript
Beta 2.2:
Included 2nd core thresholds for screen on and screen off
Included 2nd core loadbalancing (sched_mc)
Included displaysettings (min backlight and max gamma)
Change permission after pushing script to phone
Beta 2.1:
Possibility to include only selected tabs to the created script
Beta 2:
Added ADB to the package
Possibility to push script directly to phone via ADB
Beta:
CPU frequencies and voltages
Minimum/Maximum frequency used by governor
Governor
GPU frequencies and voltages
IO scheduler
Static busspeeds
Charging currents
Possibility to create and save script on harddisk
Beta 2 out now!
Will push your generated script directly to your plugged phone via ADB, just unzip, choose options, press ADB on Save tab and done.
Sources didnt change that much, will provide them later or after implementing the new siyah kernel functions.
Anything that you want me to implement first?
Any issues or errors while using it?
goose2600 said:
Runnig executable open a window where you can choose your preferred settings.
Then the program will generate the script and you have to copy it to device by hand
Click to expand...
Click to collapse
KcDaRookie said:
as goose said ATM you have to copy it by hand to /system/etc/init.d
but I will try to implement adb autopush so that you only have to click a button while the phones connected
Click to expand...
Click to collapse
Getting an old man, but always trying to learn more....
Can you give me (US) more explaination on the basic way to use it ?
CPU OK, GPU don't, IO Scheduler don't, BUS don't, CHARGING OK
Maybe if you could provide a text with your init. Gen
Sorry to be such a newbee...
GREAT JOB !
Kindly yours
Nice one
bvannier said:
getting an old man, but always trying to learn more....
Can you give me (us) more explaination on the basic way to use it ?
Cpu ok, gpu don't, io scheduler don't, bus don't, charging ok
maybe if you could provide a text with your init. Gen
sorry to be such a newbee...
Great job !
Kindly yours
Click to expand...
Click to collapse
think you !
The script generated works fine. ADB push too.
There is just a little mistake, the argument for busfreq_static si "disbled" by default instead of "disabled". But if you enable it then you disable it, it's well written "disabled".
I just add some lines in the script in order to modify the hotplug thresholds and it's perfect !
Thank you
Thank you Reno_kun, will change that asap!
altough the default kernel value is disabled so echoing disbled shouldn't have any effect ^^
will implement hotplugging treshold and brightness settings in next update, i hope i'll have time tomorrow ^^
edit: fixed that and did some rearranging.
Better and better
Incredible work, THINK YOU
Kindly yours
any chance to make phone app from this?
KcDaRookie said:
Thank you Reno_kun, will change that asap!
altough the default kernel value is disabled so echoing disbled shouldn't have any effect ^^
will implement hotplugging treshold and brightness settings in next update, i hope i'll have time tomorrow ^^
edit: fixed that and did some rearranging.
Click to expand...
Click to collapse
I've got an other problem
At boot, the script in init.d is not applied. I need to change permissions from rw-rw-rw- to rwxrw-rw- in order it is used.
What are usual permissions for a script in init.d ?
Thank you for your work KcDaRookie
@bvannier: thank you very much
@lokotus: you are free to use to sources to make an phone app from this, I don't have the knowledge that is needed for this, also i think using SetCPU, nofrills, voltage control or gokhanmorals tool for his kernel once it's released is much more efficient because the changes will take effect on the fly.
with this script you have to reboot at least once...
hmm.. I getting a great idea.. I think I will implement that the new values will directly be echoed via adb to the phone, so that they will immediately take place..
I tested a bit and this isn't impossible, thank you for this idea
Reno_kun said:
I've got an other problem
At boot, the script in init.d is not applied. I need to change permissions from rw-rw-rw- to rwxrw-rw- in order it is used.
What are usual permissions for a script in init.d ?
Thank you for your work KcDaRookie
Click to expand...
Click to collapse
I have mines set to 777 (rwxrwxrwx) but I think 766 (rwxrw-rw-) should be enough
I see if I can change permission via adb directly after push ^^
Thanks for that comment =)
Thank you guy !
I tried several time and I always had 666, it's may be due to the ROM ? Which one do you use ?
You should post some pict in the OP for showing that your soft is very easy to use
Reno_kun said:
Thank you guy !
I tried several time and I always had 666, it's may be due to the ROM ? Which one do you use ?
You should post some pict in the OP for showing that your soft is very easy to use
Click to expand...
Click to collapse
Am still on Stock ROM ^^
Will add pictures as soon as Beta 2.2 is uploaded.
There we go, new version with sources released.
It should set the permissions to 766 and also kill the adb-deamon after pushing the script to the phone.
Just tested and all work fine !
Thank you a lot !
If you have time, could you add an "import" feature in order to use a script already saved ?
@OP: awesome job dude
@Reno_kun: I'll think about it, but I think this will take some more time, will put it on the to do list ^^
@TecQuality: your welcome =)
KcDaRookie said:
@Reno_kun: I'll think about it, but I think this will take some more time, will put it on the to do list ^^
@TecQuality: your welcome =)
Click to expand...
Click to collapse
So with this tool we dont need voltage control anymore right?
Anyways, the intructions are: enable the debug mode, plug the device, generate a script and select the push command correct? We need to start the adb server?
Directly from my SGS II using xda premium
@TecQuality: No, you don't have to start the server manually, the adb push command starts the adb-deamon/adb server automatically but won't stop the deamon afterwards therefor I stop the server after pushing the bootscript and setting the permissions.
So you just start the tool, plug your phone to the pc in usb-debug mode, choose your configs and press ADB Push, after that restart your phone and the bootscript should apply at systemstart.

[KERNEL] [GPL] [4.3] FuguMod kernel (3.0.101) (open, stable, reliable and secure)

FuguMod kernel is now available for the Galaxy Nexus.
It has been reported to work both on GSM and CDMA versions. But I can only test it on GSM version myself.
You can download them at:
http://fugumod.org/galaxy_nexus/
Source and changelog can be found here:
https://github.com/renaudallard/gnexus_kernel
IRC channel:
irc.freenode.net #fugumod
To install, just download the appropriate version for your ROM (4.0.x) and flash it with fastboot (RAW version: fastboot flash boot kernel-$VERSION.img) or flash it with CWM (CWM/zip version).
Please note that not all versions exist in CWM format.
4.0.2 version is based on official google initramfs + init.d support (is now in deprecated state, no future updates will be brought)
4.0.3 version is based on the initramfs of AOSP + init.d support. it is compatible with 4.0.4
4.0.4 version is based on the initramfs of AOSP + init.d support. it is compatible with 4.0.3
4.1.x version is based on the initramfs of AOSP + init.d support.
4.2.x version is based on the initramfs of stock kernel
4.3 version is based on the initramfs of stock kernel (use that one for CM, not reco)
4.3-reco version is based on the initramfs of stock kernel, even with install-recovery.sh enabled (so supersu can work, but if you don't have supersu, don't use it)
for experimental versions, do not flash if you are not ready for big troubles, they may not even boot, burn your phone and eat your cat.
Features:
- stackprotector
- various security enhancements
- RCU boost
- Automatic process grouping
- TUN (compiled in kernel)
- latest 3.0 linux kernel
- newer wifi driver
- gamma/color hack
- CM9 compatibility
- PaX (from r333)
- grsec (from r624)
- TouchWake from Ezekeel (from r778)
Versions
Kernels are based on the below version scheme
kernel_FuguMod_20120111_r20-4.0.3.img
20120111 is the date it has been packaged
r20 is the release number
4.0.3 is the ROM it is compatible with
Color offsets
In CM9, just use the built in function.
For other ROMs, the settings offsets are in
/sys/class/misc/samoled_color/
For example green_v1_offset
Just edit the three green red and blue color settings. Default value is 60.
It can be done on the console with a command like this: echo 55> /sys/class/misc/samoled_color/green_v1_offset
Stable vs Testing
There are sometimes kernels in testing folder. These may be very stable or may not boot at all. Be sure to have an USB cable and fastboot under the hand if you try one of these. That said, in general, if they stay into testing folder for more than 15 min, they should at least boot and work more or less. I tend to remove non booting kernels from testing folder in less than 10 min (depending a little bit on the speed testers take them), and so if you see them one hour later, you should assume they are safe enough to flash.
So, in general Stable is the safest bet, but Testing may be the best. I, myself, generally run testing one.
Deprecated folder
In general, unless you really know what you are doing, you should avoid flashing those, they are mainly there for historical reasons.
Radio drops and blueish/faded screens
Please ensure you are running the correct firmware for bootloader and baseband, like in the matrix in bottom of that page: http://source.android.com/source/building-devices.html
For those where problems persist after flashing recommended versions, try "echo 0 > /sys/kernel/debug/smartreflex/sr_core/autocomp"
OTG unmounting internal SD
Please see http://forum.xda-developers.com/showpost.php?p=24040652&postcount=174
Mirrors
bootloaders: http://fugumod.org/bootloaders-gn/
basebands: http://fugumod.org/modem/galaxy_nexus/
Check for vulnerabilities
http://www.xray.io
Compatibility with hackish style apps
All apps which require direct memory write, access to symbols or memory offsets or modules will NOT work. And, no, don't ask they won't be supported in the future.
Security
If you want good security when your phone is stolen, in addition to encryption, don't forget to turn debugging off. Also, use enpasschanger to change your encryption password, any short PIN encryption can be cracked in a few minutes easily (for example, using my script at http://pastebin.com/Mdu06RZN)
Redistribution
As per GPL, you are authorized to redistribute this kernel with any of your custom ROMs provided you give out the source code like I do. You can link to my github in your distribution site.
However, if you modify the kernel yourself, whatever the modification is (compiling it yourself with a different compiler is a modification), you are not authorized to name it FuguMod, although you can credit me and tell the base comes from FuguMod but you cannot call the kernel itself FuguMod.
Touchwake
to enable it "echo 1 > /sys/devices/virtual/misc/touchwake/enabled"
to make it always on: "echo 1 > /sys/devices/virtual/misc/touchwake/always"
Beware, touchwake is known to sometimes produce screen locks
PGM
See "Compatibility with hackish style apps". Use touchwake instead.
Lost root
Use supersu instead of superuser from chainsDD (superuser from koush seems to work fine too). Change the setting in SuperSU to ignore CM root setting if you are running CM.
Updater app
https://play.google.com/store/apps/details?id=my.zin.rashidi.android.fugumod
root on 4.3
Currently only reco version has support for root access with supersu. Keep in mind that su access is now (as of 4.3) provided by a daemon, which may drain your battery or worse. Please think about your uses for root to see what is better fit for you.
W00t fugumod on the nexus!!
Will try it, thanks for dropping this here.
I'm totally happy
Finally! A kernel we can rely on Thanks alot mate, looking forward to further developments on this. I remember FuguMod fondly on the SGSII
Nitroz said:
Finally! A kernel we can rely on Thanks alot mate, looking forward to further developments on this. I remember FuguMod fondly on the SGSII
Click to expand...
Click to collapse
You probably mean SGS1.
I'm not entirely sure how accurate setcpu is at reading frequencies, but it seems to be stuck at 700mhz after a reboot. Moving the sliders a bit allows the cpu to use the entire range of 350-1200mhz as intended. I'm on AOKP milestone 2 if it matters and using r26.
Haven't yet tried this, but maybe min frequency when booting is set to 700mhz?
when you open setcpu, is the min slider at 350mhz?
What governor are you using? Not sure it matters though, but it might so.
maybe try using cpuspy to read the usage. Also, there may be something in your init.rd limiting the frequencies
Sent from a Nexus
Yes, min and max are set at 350/1200 on the sliders, but the green text says it's at 700/1200. Governor is the default interactive. Right now, I'm only using setcpu as a tool to view my frequencies as everything is "under observation" as I've only had this phone for a week. I did a reboot last night before going to bed. When I woke up 6 hours later, batt was down to 92%. Which is a quite fast considering I only had 5 hours of sleep. That's when I noticed that frequency was pegged at 700mhz the whole time. I tried opening other apps that should ramp up the speed, but as far as I can tell, it was still at 700.
Now, as I said, I'm only using setcpu to check my frequencies so "set at boot" isn't applied. When I apply "set at boot," min/max is at 350/1200 after a reboot and CPU scales up and down properly. So does this mean the default setting of the kernel is 700/1200? The thing is, even with max at 1200. I can't seem to make it scale up to 1200.
EDIT:
nikademus said:
maybe try using cpuspy to read the usage. Also, there may be something in your init.rd limiting the frequencies
Sent from a Nexus
Click to expand...
Click to collapse
I don't seem to have an init.rd file anywhere. I did a search using root explorer.
Edit 2:
CPUSpy says I'm only using 700 and DeepSleep even after running Asphalt 6. This is after a reboot without setting anything at boot with setcpu.
j.go said:
Yes, min and max are set at 350/1200 on the sliders, but the green text says it's at 700/1200. Governor is the default interactive. Right now, I'm only using setcpu as a tool to view my frequencies as everything is "under observation" as I've only had this phone for a week. I did a reboot last night before going to bed. When I woke up 6 hours later, batt was down to 92%. Which is a quite fast considering I only had 5 hours of sleep. That's when I noticed that frequency was pegged at 700mhz the whole time. I tried opening other apps that should ramp up the speed, but as far as I can tell, it was still at 700.
Now, as I said, I'm only using setcpu to check my frequencies so "set at boot" isn't applied. When I apply "set at boot," min/max is at 350/1200 after a reboot and CPU scales up and down properly. So does this mean the default setting of the kernel is 700/1200? The thing is, even with max at 1200. I can't seem to make it scale up to 1200.
EDIT:
I don't seem to have an init.rd file anywhere. I did a search using root explorer.
Edit 2:
CPUSpy says I'm only using 700 and DeepSleep even after running Asphalt 6. This is after a reboot without setting anything at boot with setcpu.
Click to expand...
Click to collapse
OK, 4.0.3 init.rc I have been given is the one from Francisco Franco and it limits the minimum frequency to 700mhz. This will be solved in next build, in a few minutes. Although you should be able to go over 700Mhz
nikademus said:
OK, 4.0.3 init.rc I have been given is the one from Francisco Franco and it limits the minimum frequency to 700mhz. This will be solved in next build, in a few minutes. Although you should be able to go over 700Mhz
Click to expand...
Click to collapse
Ah, well that's good to hear. Maybe the conditions needed to raise the frequency are not being met. Not that I know anything about kernels...
j.go said:
Ah, well that's good to hear. Maybe the conditions needed to raise the frequency are not being met. Not that I know anything about kernels...
Click to expand...
Click to collapse
Try the latest version, I removed all Francisco tweaks.
nikademus said:
Try the latest version, I removed all Francisco tweaks.
Click to expand...
Click to collapse
All right, I'll give it a spin tonight and post how it goes. Thanks!
I think I will be upgrading my phone to 4.0.3. This would mean I would not support 4.0.2 as I would not be able to test it properly. Are there users here who need the 4.0.2 version?
great
R37 für 4.0.3 runs flawless.
I use CM9 kang by fitsnugly.
R40 also flawless on fitsnugglys CM9 kang
r41 is out, probably last release for today
I flashed the latest KANG from today and the 122211 gapps with R41.
Works like a charm so far
aosp kang built today, flashed R43 just now. booted fine first try, wifi/bluetooth are fine, data call as well, rebooted, set scheduler/gov to deadline/ondemand, min/max freq to 1.2ghz, score on antutu maxing out around 5200, 5300. with my modified stock, i hit 6200+ in those conditions.
switch back to cfq/interactive, sd write speed goes up a bit to 10.4mb/s (deadline was just under 9.4mb/s), cpu integer 1304, float 1099, pushes score up a bit but still not reaching 5400 (this is with all tests selected, 2d/3d, database..). tweaked lowmemorykiller, antutu score jumps to 5600+.
but benchmarks mean almost nothing, i know. overall it's pretty smooth, fast on bootup, ocasional "lag" here and there (but that may be Mr. Android's fault).
will report more as the kernel settles in.
thanks nikademus.
edit: just re-installed gta. it seems i have no in-game sounds at all? it's fine until it gets to the main menu though. anybody else seeing this? happening on stock kernel too, wth..
edit2: jumping on r44.
flashed R44 on the latest fitsnugly kang. all is well. as expected, as only unused modules have been removed

[Base 1.80][Root][SCRIPT] 08/07 Butterfly V12/Ghostpepper Inspired Interactive Values

Hey Guys,
I thought while waiting for the first custom kernels that maybe i should have a look at the interactive values and try to tweak them based on this way:
http://forum.xda-developers.com/nexus-5x/general/guide-advanced-interactive-governor-t3269557
So i took a script from @Alcolawl and modified it to work with our device. Many thanks for his scripts.
I adjusted the values to our snapdragon 820 as the original scripts are for the nexus 6p which runs with a snapdragon 810. (octa on the 810 vs quad-core on the 820)
I´d highly recommend to try these values as it gave me a significant boost in battery life. here is a screenshot:
https://drive.google.com/file/d/0BxbxiBXaZVu-N1lsRTMyZ2hsY1k/view?usp=sharing
https://drive.google.com/file/d/0BxbxiBXaZVu-N1MzamRvM2FVZlk/view?usp=sharing
BIG UPDATE: with base 1.80 i´m not able to trick the touch/Input boost from htc´s pnpmgr with a chmod command like i did before. so all versions since Butterfly v11 will disable pnpmgr completely.
that means if you Play high end games and your device overheats like crazy please Report back. i had no Problem until now.
also there are now 2 versions. the oc one is for overclocked cpus with elementalx. without oc is for the default clock speeds.
here are explanations on what the 2 different stragies do:
Butterfly - A culmination of all strategies, provides smoothest performance of all currently published settings, though battery savings are a little more modest. Excellent for light and moderate users; heavy/marathon users might want to check out a different setting profile as it gets battery intense with heavy usage.
GhostPepper - Uses a quantized, frequency-aligned parametric curve to influence low core clock rates while providing extremely smooth transitions from each clock rate and exceptional battery life. Good for light to medium usage and multitasking.
So basically there will be two ways of applying this mod.
First one is via scripts. this allows to set parameters outside of the interactive governor controls like cpu boost, editing of pnpmgr, min/max frequencies etc. so basically there´s more control.
Second one is via EX Kernel Manager. I will upload the profiles and you can apply them directly into the app. This will however only affect the tunables of the interactive governor. Touchboost has to be set manually for the profile to work exactly as intended.
when the phrase "elex" is in the zips name it is for use with ex kernel manager app (loading profile in governor options screen.
so to try the script method follow these steps. (and before do a nandroid as always)
1. download the attched file.
2. unzip the file, choose the correct script (oc if you have overclocked)
3. with a root explorer or terminal copy the file to system/su.d
4. set the correct permissions (rwxr-xr-x)
now you may either choose to change the settings temporary (step 5A) until the next reboot or permanently upon each reboot (step 5B)
5A. rename the file to 50ghostpeppertenv3.sh
use any script manager and run the script from this location (system/su.d)
alternatively use any terminal emulator app with the following commands
su
cd system/su.d
sh 50ghostpeppertenv3.sh
Be advised that the script takes in its current state 60 seconds to be applied. So the changes need a minute to be applied.
now check if the script has applied
- to do this go to sys/devices/system/cpu/cpu0/cpufreq/interactive/target_loads
- if it looks like this: "25 480000:35 652800:45 844800:60 960000:75 1113600:85 1228800:90 1401600:95 1593600:100" the script was applied successfully
- the values changed with each update. what´s important to check is just the generel layout
5B. (-if you did the temporary approach beforehand remove the .sh)
- it should look like 50ghostpeppertenv3 (make sure there are now spaces at the end)
reboot and check if the script has applied
- to do this go to sys/devices/system/cpu/cpu0/cpufreq/interactive/target_loads
- if it looks like this : "25 480000:35 652800:45 844800:60 960000:75 1113600:85 1228800:90 1401600:95 1593600:100" the script was applied successfully.
-- the values changed with each update. what´s important to check is just the generel layout
Important!!!
if you run permissive and run into no signal issue due to this look here
if you should run into a no signal issue where your baseband shows as unknown under software status ( currently on custom roms eg leedroid) you have to put a script to system/su.d that sets selinux to permissive. attached is such a script.
unzip it. copy it to system/su.d
set the same permissions as the ghostpepper script and your good to go.
running in terminal the command "getenforce" should return permissive.
Second method via Elemental App:
1. Download the desired profile from the attachments
2.Extract the Profiles from the zip
3. Choose the Overclocked(oc) version if you overclocked
4.Copy the file to sdcard/ElementalX/gov_profiles
5. Open the app and apply the values
let me know if it brings a little battery boost for you. you may also let me know if you face performance issues.
Thank you and have fun testing it.
Changelog:
Ghostpepper:
v1: Initial Release
v2: Tweaking The Script so the values will get applied properly on all roms
adding a permissive script in case of getting enforced
v3: Removed touchboost so the profile may unleash its full potential <<--- results in overall slower device.
v4: Added back short input boost
v4withtb: Added back original touch boost from htc
v8: New try on getting the interface smooth and disabling touchboost (minimal stutter remains)
v8withtb: same as v8 touchboost is still active
v9: only one version with touchboost now. tweaked target loads (lower freqs are used more), short input boost
there are now two files inside the zip.
v10: try to further improve frequency usage, less aggressive scaling
v11: fix in case Little cores might get stuck at highest clock
Butterfly
v4: Initial Release
v4withtb: Initial Release with original touch boost from htc (extremely smooth)
v6withtb: tuned the values and kept touchboost from pnpmgr, kernel touch boost is disabled, extremely smooth for me
v7: less aggressive scaling, performance should be really good while reducing less power than v6
v9: basically scaling is tuned to respect the crossover effieciency point from big and little cluster
v11: updated to work on base 1.80
- disable pnpmgr completely because the chmod trick for disabling pnpmgr´s touchboost is no longer working
- enable msm_thermal and core_control
v12: tweak some values to work better with the new base
v13: hotfix as i made a mistake in the previous version
credits:
thanks to @Alcolawl for the script template
also thanks to @soniCron for the original thread
reserved
Thanks for this - about to try it out now.
Question, though - Instead of using init.d, which requires a modified ramdisk, why not just use su.d, which only requires SuperSU?
EDIT: It doesn't seem to be loading when using su.d either.
Thanks. I'm using it now. Will let you know if there are any performance problems.
Can you also make a script that makes the phone smoother?
Captain_Throwback said:
Thanks for this - about to try it out now.
Question, though - Instead of using init.d, which requires a modified ramdisk, why not just use su.d, which only requires SuperSU?
EDIT: It doesn't seem to be loading when using su.d either.
Click to expand...
Click to collapse
Yeah it's strange. When flar will Releases his kernel, init.d will be hopefully working.
Seems like we have to apply it manually for now. When exkm gets updated we can switch profiles there so maybe we should just find good values now.
gusoldier said:
Thanks. I'm using it now. Will let you know if there are any performance problems.
Can you also make a script that makes the phone smoother?
Click to expand...
Click to collapse
Did you face a performance loss with these values? For me it's already pretty smooth.
But sure I may trim it more performance oriented yes.
Freak07 said:
Did you face a performance loss with these values? For me it's already pretty smooth.
But sure I may trim it more performance oriented yes.
Click to expand...
Click to collapse
Compared to stock I feel no performance loss, as smooth as stock. What I actually meant was a new script for buttery smooth nexus like experience.
Btw I will also check how hot it will get. On stock the phone gets sometimes hot watching youtube etc. Hopefully it'll better with this script
gusoldier said:
Compared to stock I feel no performance loss, as smooth as stock. What I actually meant was a new script for buttery smooth nexus like experience.
Btw I will also check how hot it will get. On stock the phone gets sometimes hot watching youtube etc. Hopefully it'll better with this script
Click to expand...
Click to collapse
yeah. I can try this later. But compared to my nexus 6 and my pixel c the 10 is about as smooth.
Freak07 said:
Yeah it's strange. When flar will Releases his kernel, init.d will be hopefully working.
Seems like we have to apply it manually for now. When exkm gets updated we can switch profiles there so maybe we should just find good values now.
Click to expand...
Click to collapse
Got it working with su.d. Just needed to add some sleep at the beginning of the script, otherwise it runs too early and the parameters can't be set .
P.S. You didn't answer my question about why you're not using su.d instead of init.d?
Captain_Throwback said:
Got it working with su.d. Just needed to add some sleep at the beginning of the script, otherwise it runs too early and the parameters can't be set .
Click to expand...
Click to collapse
Can you post it? I will add it to op thank you captain!
Edit: didn't think about it I'm not that knowledgeable.
Or is it just like "sleep 30"?
Edit2: it is indeed. thank you again.
Freak07 said:
Can you post it? I will add it to op thank you captain!
Edit: didn't think about it I'm not that knowledgeable.
Click to expand...
Click to collapse
Sure, right now I'm just trying to find the minimum sleep value that works, and once I do, I'll post it.
RE: su.d, see the 2nd paragraph here: http://su.chainfire.eu/#selinux-policies-supolicy
An additional advantage besides the ones listed there is that in a systemless root setup, su.d doesn't require modifying system at all, which is important for being able to take OTA updates in the future. On this device, I try to touch system as little as possible (if at all), so it might be a better alternative, and doesn't require a custom ramdisk.
Captain_Throwback said:
Sure, right now I'm just trying to find the minimum sleep value that works, and once I do, I'll post it.
RE: su.d, see the 2nd paragraph here: http://su.chainfire.eu/#selinux-policies-supolicy
An additional advantage besides the ones listed there is that in a systemless root setup, su.d doesn't require modifying system at all, which is important for being able to take OTA updates in the future. On this device, I try to touch system as little as possible (if at all), so it might be a better alternative, and doesn't require a custom ramdisk.
Click to expand...
Click to collapse
yeah you´re right. thanks for the reference and the hint. i knew about it but didn´t remember i could use this see my edited last post. with sleep 30 it´s working for me. i updated the op.
besides, do you had any luck in finding your pvs bin? i´m extremely intersted in this. i only found my voltage table so far. maybe you may post yours too. i opened a thread here:
http://forum.xda-developers.com/htc-10/how-to/post-voltage-table-chip-t3383494
if we had a way to check our pvs bin it would be even more helpful.
Freak07 said:
yeah you�´re right. thanks for the reference and the hint. i knew about it but didn�´t remember i could use this see my edited last post. with sleep 30 it�´s working for me. i updated the op.
besides, do you had any luck in finding your pvs bin? i�´m extremely intersted in this. i only found my voltage table so far. maybe you may post yours too. i opened a thread here:
http://forum.xda-developers.com/htc-10/how-to/post-voltage-table-chip-t3383494
if we had a way to check our pvs bin it would be even more helpful.
Click to expand...
Click to collapse
sleep 30 didn't work for me, as I have another script running before this one. It's probably safer to go with sleep 60 to make sure it loads for everyone (sleep 45 did work for me too, but 30 was too short - figured it's better to allow more time). Just a suggestion, or you could just tell people that if it doesn't load for them to increase the sleep value. Up to you, really.
EDIT: And I don't know anything about a pvs bin
Captain_Throwback said:
sleep 30 didn't work for me, as I have another script running before this one. It's probably safer to go with sleep 60 to make sure it loads for everyone (sleep 45 did work for me too, but 30 was too short - figured it's better to allow more time). Just a suggestion, or you could just tell people that if it doesn't load for them to increase the sleep value. Up to you, really.
EDIT: And I don't know anything about a pvs bin
Click to expand...
Click to collapse
Okay i'll edit it to 60.
This is what I'm talking about. Every Chip has a pvs bin. The higher the bin the lower the voltage for a certain cpu frequency.
And every bin has its own voltage table.
http://forum.xda-developers.com/htc-one-m8/general/guide-snapdragon-801-clocking-voltage-t2807173
Hey @Freak07,
Wondering if you can help.. Can't seem to get this working?? Please see attachment. I've set permissions and used terminal to get it working but no dice?
Edit: Nevermind.... I can't follow simple instructions to unzip a file (I was renaming the zip rather than unzipping and renaming that to .sh).... #Special
Edit 2: Went straight for option 5b (so it should have worked on reboot). When I rebooted I lost the radio and have had to clean flash my ROM? I was on Leedroid's Rom when it happened.
rav101 said:
Hey @Freak07,
Wondering if you can help.. Can't seem to get this working?? Please see attachment. I've set permissions and used terminal to get it working but no dice?
Edit: Nevermind.... I can't follow simple instructions to unzip a file (I was renaming the zip rather than unzipping and renaming that to .sh).... #Special
Edit 2: Went straight for option 5b (so it should have worked on reboot). When I rebooted I lost the radio and have had to clean flash my ROM? I was on Leedroid's Rom when it happened.
Click to expand...
Click to collapse
Which Kernel were you on?
This morning i had the same issue when flashing tbalden Kernel using leedroid and my Script.
Freak07 said:
Which Kernel were you on?
This morning i had the same issue when flashing tbalden Kernel using leedroid and my Script.
Click to expand...
Click to collapse
Hey buddy,
I was on the kernel built into Leedroid.
Hope that helps.
rav101 said:
Hey buddy,
I was on the kernel built into Leedroid.
Hope that helps.
Click to expand...
Click to collapse
How did you recover? Full Wipe?
Delete
Freak07 said:
How did you recover? Full Wipe?
Click to expand...
Click to collapse
Yeah, I tried a dirty wipe but that didn't work so had to do a full wipe.

Categories

Resources