Related
[FIXED] FROYO Calibration Error -> open input device: Inappropriate ioctl for device
well, there are several threads about calibration problems ...
but nothing in detail ...
here we go....
basic is froyo 2.2 with haret 1.4 + no "ts-calibrate" file existing on fat32 (sdcard)
in init (startup) the calibration command failed to work ...
as you can see (below) - there in the script the calibration call via:
tssc-calibrate
then i can also see the message for clicking the 5 points, blabla...
(but the "white touch area" like as it is on diamond is not there ... and no time and it is jumping to next procedure in init script. the most users doesn't see that, because it does fast switch/show another lines ....)
then i see an error: (this comes from command "tssc-calibrate")
open input device: Inappropriate ioctl for device
any idea how to fix ?
Code:
for i in /sys/class/input/input* ; do
if [ "`cat $i/name`" = "tssc-manager" ] ; then
touchscreendir=$i
echo "Touchscreen device directory is $i"
fi
done
if [ -f /sdcard/ts-calibration ] ; then
echo "Using Saved Touchscreen Calibration"
echo 128,128,1903,128,128,1907,1903,1907,1024,1024 > $touchscreendir/calibration_screen
cat /sdcard/ts-calibration > $touchscreendir/calibration_points
else
mkdir /dev/graphics
mknod /dev/graphics/fb0 c 29 0
clear
echo; echo; echo; echo; echo; echo; echo; echo "Calibrating Touchscreen:"
echo "Click the Five Targets in order -- Top Left, Top Right, Middle, Bottom Left, Bottom Right"
echo "(Tap lightly. The screen is quite sensitive.)"
tssc-calibrate
echo 0,0,0,0,0,0,0,0,0,0 | cmp -s $touchscreendir/calibration_points # determine if calibration is still null -- means failed calibration
if [ $? -eq 0 ] ; then
echo "Touchscreen Calibration Failed"
else
echo "Touchscreen Calibration Successful; Saving..."
cat $touchscreendir/calibration_points > /sdcard/ts-calibration
fi
fi
EDIT:
FIXED in latest kernel version "htc-msm-linux-20100818_154417-package.tar" and newer ...
for calibration - you must delete the "ts_calibrate" file on your sdcard.
cu camel
hey mate,
any news on this? Wish I could help you but I know nothing about this programming of this sort...as a matter of fact, who is putting this together? I mean, who is putting the versions online, shouldn't they know?
:|
i' now in vacation, but will take care if i'm back ...
this problem is fixed in latest kernel.
if you use kernel "htc-msm-linux-20100818_154417-package.tar" or newer it is fixed.
the touchscreen problem (finger touch does recognize extra touch on left side ..) is not fixed now.
I am new, is it that we have to calibrate before we install?
hktotti said:
I am new, is it that we have to calibrate before we install?
Click to expand...
Click to collapse
On your first boot with the new zimage, it will ask you to calibrate the screen. If you made a mistake (or you did not calibrate at all), delete the ts-calibration file on your sd-card and start android again
Took me a few minutes to figure this out, so I thought to share
This is taken from some scripts I use in CF-Root, you might need to change it slightly for other CWM3 kernels (like prefixing busybox to various commands, etc).
updater-script
Assumptions:
- rootfs is mounted as rw, so we can write temporary files anywhere (ram disk)
- you put a "myscript.sh" in the system folder inside the update
All this script does is extract whatever you have in update.zip/system folder to /tmp/update, and run the myscript.sh file.
Code:
ui_print("Extracting files ...");
package_extract_dir("system", "/tmp/update");
set_perm(0, 0, 0755, "/tmp/update/myscript.sh");
run_program("/tmp/update/myscript.sh");
myscript.sh
Assumptions:
- all busybox commands are symlinked in /sbin, this is usually the case for CWM3 kernels
Code:
#!/sbin/busybox sh
# get file descriptor for output
OUTFD=$(ps | grep -v "grep" | grep -o -E "update_binary(.*)" | cut -d " " -f 3);
# same as progress command in updater-script, for example:
#
# progress 0.25 10
#
# will update the next 25% of the progress bar over a period of 10 seconds
progress() {
if [ $OUTFD != "" ]; then
echo "progress ${1} ${2} " 1>&$OUTFD;
fi;
}
# same as set_progress command in updater-script, for example:
#
# set_progress 0.25
#
# sets progress bar to 25%
set_progress() {
if [ $OUTFD != "" ]; then
echo "set_progress ${1} " 1>&$OUTFD;
fi;
}
# same as ui_print command in updater_script, for example:
#
# ui_print "hello world!"
#
# will output "hello world!" to recovery, while
#
# ui_print
#
# outputs an empty line
ui_print() {
if [ $OUTFD != "" ]; then
echo "ui_print ${1} " 1>&$OUTFD;
echo "ui_print " 1>&$OUTFD;
else
echo "${1}";
fi;
}
# --- example usage ---
# empty line after "Extracting ..." from updater-script
ui_print;
# give the user some status
ui_print "doing something (1 of 4)";
# assume this won't take more than 30 seconds
progress 0.25 30;
# you'd do something useful here
sleep 15s;
# update status
ui_print "- done with something (1 of 4)";
# we're done, make sure the progress bar is at 25%
set_progress 0.25;
# empty line
ui_print;
# repeat this a few times ;)
ui_print "doing something (2 of 4)";
progress 0.25 30;
sleep 15s;
ui_print "- done with something (2 of 4)";
set_progress 0.50;
ui_print;
ui_print "doing something (3 of 4)";
progress 0.25 30;
sleep 15s;
ui_print "- done with something (3 of 4)";
set_progress 0.75;
ui_print;
ui_print "doing something (4 of 4)";
progress 0.25 30;
sleep 15s;
ui_print "- done with something (4 of 4)";
set_progress 1.00;
ui_print;
# done !
ui_print "done! rebooting!";
How, what, why ?
While updater-script is fine for a lot of things, like installing a new ROM and whatnot, anything sufficiently complicated still has to be done through shell scripts, because a great many things just cannot be easily done in edify. It's nice to be able to give the user some status when doing these operations. There are modded versions of CWM that make the same thing possible in other ways, like simply writing to STDOUT or STDERR. This requires either a custom update_binary or recovery binary, though.
This works because communication between recovery and update_binary is through a file descriptor (pipe). Recovery runs update_binary with the FD as command line parameter. Because the shell script is run as a child process of update_binary, it can write the same commands to that FD (commands recovery listens for), because child processes inherited FD numbers and access rights.
So, all the script has to do is figure out which FD to write to, and pass it the right commands. Finding the FD isn't difficult, as it is passed on the command line and so is listed in the output of ps. Some grep and cut magic retrieve it. See the OUTFD=$(...) line. The right commands are defined in the functions at the top.
Note: this is all taken from my rfs<=>ext4 conversion script for CF-Root/ext4. Slightly adjusted, hopefully it still works as expected
Enjoy!
Thank you chainfire
Sent from my GT-I9000 using Tapatalk
Thanks for this chainfire.
Precisely what I was looking for! You're my hero today, man!
Hi Chainfire
Thanks for your tricks, I'm using it for an almost bulletproof MTD flash script.
BTW, i'd like to call some set_perm commands. But set_perm isn't a recognized command for update-binary.
IDK if I'm clear.
Do you have some advise on that?
RolluS said:
BTW, i'd like to call some set_perm commands. But set_perm isn't a recognized command for update-binary.
Click to expand...
Click to collapse
I've sort this writing equivalent functions:
Code:
set_perm() { # same as set_perm command in updater-script, for example:
#
# set_perm 0 3003 02750 "/system/bin/netcfg"
#
# sets user:group to 0:3003 and perm to 02750 for the file /system/bin/netcfg
$CHOWN $1:$2 $4
$CHMOD $3 $4
}
set_perm_recursive() { # same as set_perm command in updater-script, for example:
#
# set_perm_recursive 0 2000 0755 0755 "/system/bin"
#
# sets uid:gid to 0:2000 and perm to 0755 for folders and 0755 for files recursively in /system/bin
$CHOWN -R $1:$2 $5
$CHMOD $3 $5
#chmod recursive of folder
$FIND $5/* -type d |while read folder; do
$CHMOD $3 $folder
done
#chmod recursive of files
$FIND $5/* -type f |while read file; do
$CHMOD $4 $file
done
}
There is no error handling (yet), so be carrefull when calling these functions
no FD, no output
Chainfire said:
This works because communication between recovery and update_binary is through a file descriptor (pipe). Recovery runs update_binary with the FD as command line parameter. Because the shell script is run as a child process of update_binary, it can write the same commands to that FD (commands recovery listens for), because child processes inherited FD numbers and access rights.
So, all the script has to do is figure out which FD to write to, and pass it the right commands. Finding the FD isn't difficult, as it is passed on the command line and so is listed in the output of ps. Some grep and cut magic retrieve it. See the OUTFD=$(...) line.
Click to expand...
Click to collapse
finding the FD is difficult on an SGY phone under MT 2.0 kernel, because is is not passed as command line param and therefore not in the ps output.
can anyone give an example of a working FD ?
the expression returns "" on my SGY, and no output is readable from script.
above zip as one file with the (.*) business removed from FD expression in myscript.sh
I don't see that ps gives me a "FD" in its output. whatever that really is. /tmp/recovery.log says that /sbin/recovery has no command line params either on SGY
from recov.log:
I:Set boot command "boot-recovery"
Command: "/sbin/recovery"
there is no FD in the command line ! where is it then ?
I'll test this in a bit. Nice hack b/w.
any news?
Thanks for this trick. What I wanted to do is to redirect stdout (and stderr) of my script to the UI. I know that you can see this in "show logs", but I wanted it to display right during the installation. Here is what I came up with:
Code:
#!/sbin/busybox ash
OUTFD=$(ps | grep -v "grep" | grep -o -E "update_binary(.*)" | cut -d " " -f 3);
/sbin/busybox ash $* 2>&1 |
while read -r line
do
echo "ui_print $line" >&$OUTFD;
echo "ui_print " >&$OUTFD;
done
If you save this as "scripts/stdoutwrapper.sh", you can do something like this:
Code:
package_extract_dir("scripts", "/tmp/update");
set_perm(0, 0, 0755, "/tmp/update/stdoutwrapper.sh");
run_program("/tmp/update/stdoutwrapper.sh", "/tmp/update/myscript.sh", "param1", "param2");
In myscript.sh, use any shell commands. The output will be redirected to the UI. Therefore, you should be able to write scripts that work both on the command line and in recovery without changes.
Please note: As all output will be printed, the tricks with set_progress etc. don't work. It would probably be possible to use a prefix to identify commands that should be executed, not printed, so you could do e.g. "echo '<#>set_progress 0.25'".
what value does OUTFD have? find out like below:
adb shell
ps
then /sbin/recovery might have PID 2166 on SGY phone
su
ls -l --color=never /proc/2166/fd
may give you e.g.
3 -> /dev/tty0
so 3 is your OUTFD !
now grep it accordingly for the script. use MT kernel 2.0 on SGY for above capability
time saver
edify Scripts may be tested by executing update-binary directly:
update-binary version output package
An example would be:
update-binary 2 stdout /sdcard/update.zip
Just noticed Chainfire's ui_print shell script in the latest SuperSU zip, and that lead me here.
Here are some updated versions (for CWM6?); ui_print and set_perm from SuperSU and the other 2 from my tinkering today:
Code:
OUTFD=$2;
ZIP=$3
ui_print() {
echo -ne "ui_print $1\n" > /proc/self/fd/$OUTFD;
echo -ne "ui_print\n" > /proc/self/fd/$OUTFD;
}
set_perm() {
chown $1.$2 $4
chown $1:$2 $4
chmod $3 $4
}
show_progress() { echo "progress $1 $2" > /proc/self/fd/$OUTFD; }
set_progress() { echo "set_progress $1" > /proc/self/fd/$OUTFD; }
ex:
show_progress 1.34 0;
ui_print "Hello world!";
set_progress 0.5;
ui_print " "; #blank line
set_progress 1.34;
ui_print "Done!";
Also worth noting he just uses busybox unzip to extract files from the flashable zip directly and goes from there.
ex:
ui_print "Extracting files!"
cd /tmp
unzip -o "$ZIP"
mai77 said:
what value does OUTFD have?
Click to expand...
Click to collapse
I put ui_print "Test: $OUTFD" in a script and the value of OUTFD appears to increase with every zip flashed.
Not much use knowing it in that case.
Nice work, I used this in my little zip. However, it doesn't work with TWRP. Is there any way to accomplish that?
sorry to put this here but could anyone direct me towards the cwm or TWRP version for "jxjpb" (asia) baseband pls?
klenamenis said:
Nice work, I used this in my little zip. However, it doesn't work with TWRP. Is there any way to accomplish that?
Click to expand...
Click to collapse
TWRP names the extracted update-binary "updater", so you can add something like this (or modify the regex in the existing line):
Code:
[ $OUTFD != "" ] || OUTFD=$(ps | grep -v "grep" | grep -o -E "updater(.*)" | cut -d " " -f 3)
_that said:
TWRP names the extracted update-binary "updater", so you can add something like this (or modify the regex in the existing line):
Code:
[ $OUTFD != "" ] || OUTFD=$(ps | grep -v "grep" | grep -o -E "updater(.*)" | cut -d " " -f 3)
Click to expand...
Click to collapse
Shouldn't be necessary with any reasonably current recovery. That was just a hack Chainfire wrote to get the FD back in the CWM3 days.
All that should be required (and has always worked for me) is to make the update-binary your shell script, then:
Code:
OUTFD=$2;
See my other updated commands above. And some zips I've made which should provide good references for people: Nexus Louder, Xposed Framework Installer, and Nexus BootUnlocker. All available in my Odds and Ends thread, linked in my sig.
osm0sis said:
Shouldn't be necessary with any reasonably current recovery. That was just a hack Chainfire wrote to get the FD back in the CWM3 days.
All that should be required (and has always worked for me) is to make the update-binary your shell script, then:
Code:
OUTFD=$2;
Click to expand...
Click to collapse
Yes, that works if you replace the whole update-binary with a shell script, but this method is for scripts that are called from the updater-script when using a binary updater.
I've recently switched to a shell script as updater too, but I had to write my own zip signing program because busybox unzip was unable to extract files from a zip signed by SignApk.
osm0sis said:
See my other updated commands above. And some zips I've made which should provide good references for people: Nexus Louder, Xposed Framework Installer, and Nexus BootUnlocker. All available in my Odds and Ends thread, linked in my sig.
Click to expand...
Click to collapse
Wow, nice collection! I remember some other posts from you that were very helpful, thanks!
_that said:
Yes, that works if you replace the whole update-binary with a shell script, but this method is for scripts that are called from the updater-script when using a binary updater.
I've recently switched to a shell script as updater too, but I had to write my own zip signing program because busybox unzip was unable to extract files from a zip signed by SignApk.
Wow, nice collection! I remember some other posts from you that were very helpful, thanks!
Click to expand...
Click to collapse
Nice! My misunderstanding then.
And ah yes, the old "1 and 8" issue with unzip. Might be resolved in the latest busybox 1.22.1 but I'm not 100% about that, and it'll be awhile before that makes it into recoveries.
I'd love to get hold of your zip signer if that'd be okay. I have Chainfire's solution, but I was still running into some verification problems (I think) from the MinSignApk whole file resigning.
osm0sis said:
And ah yes, the old "1 and 8" issue with unzip. Might be resolved in the latest busybox 1.22.1 but I'm not 100% about that, and it'll be awhile before it makes it into recoveries.
Click to expand...
Click to collapse
Exactly! I learned a lot about the zip format while researching this.
osm0sis said:
I'd love to get hold of your zip signer if that'd be okay. I have Chainfire's solution, but I was still running into some verification problems (I think) from the MinSignApk whole file resigning.
Click to expand...
Click to collapse
Argh! I saw your original question in that thread but I never found the solution because there were so many pages in between...
I ended up with a hack that appears to resemble Chainfire's minsignapk, but I didn't need to write my own zipadjust. Basically I simply sign the zip normally with signapk, then I unpack and repack the whole archive using 7zip (bonus: slightly better compression), and then I run the whole-zip-signer on the archive.
Here is my SignWholeFile.jar - the source code is just too ugly to publish. View attachment SignWholeFile.jar If you find that it works better than Chainfire's version, I'll clean the source and release it.
This is the script I use for signing:
Code:
#!/bin/sh
KEYDIR=~/android/aosp/build/target/product/security
SIGNAPK=~/android/aosp/prebuilts/sdk/tools/lib/signapk.jar
SIGNWHOLEFILE=~/android/src/signapk/SignWholeFile.jar
java -jar $SIGNAPK -w $KEYDIR/testkey.x509.pem $KEYDIR/testkey.pk8 "$1" "$1.signed.zip"
mv "$1" "$1.unsigned"
signedzip=$(readlink -f "$1.signed.zip")
[ -d /tmp/signapk2 ] && rm -rf /tmp/signapk2
mkdir /tmp/signapk2
pushd /tmp/signapk2
unzip $signedzip
rm $signedzip
7z a -r -mx=9 $signedzip *
#7z a -r $signedzip *
popd
mv "$1.signed.zip" "$1"
java -jar $SIGNWHOLEFILE $KEYDIR/testkey.x509.pem $KEYDIR/testkey.pk8 "$1" "$1"
I'm trying to tweak my smartass governor settings at boot via an init.d script & sysfs, but everytime I reboot the settings don't take effect. If I run it in the terminal it works fine and sticks, just not at boot. Any ideas why? The permissions are set right. Does the governor get loaded after init.d and overwrite my settings with default? Here's my script.
#!/system/bin/sh
echo "998000" > /sys/devices/system/cpu/cpu0/cpufreq/smartass/sleep_wakeup_freq
echo "614400" > /sys/devices/system/cpu/cpu0/cpufreq/smartass/up_min_freq
echo "384000" > /sys/devices/system/cpu/cpu0/cpufreq/smartass/sleep_max_freq
echo "2" > /sys/devices/system/cpu/cpu0/cpufreq/smartass/sample_rate_jiffies
echo "128000" > /sys/devices/system/cpu/cpu0/cpufreq/smartass/ramp_up_step
echo "0" > /sys/devices/system/cpu/cpu0/cpufreq/smartass/ramp_down_step
echo "40" > /sys/devices/system/cpu/cpu0/cpufreq/smartass/min_cpu_load
echo "65" > /sys/devices/system/cpu/cpu0/cpufreq/smartass/max_cpu_load
echo "30000" > /sys/devices/system/cpu/cpu0/cpufreq/smartass/down_rate_us
echo "0" > /sys/devices/system/cpu/cpu0/cpufreq/smartass/awake_min_freq
Sent from my PC36100 using Tapatalk
Usually the init scripts will set the governor to ondemand after the init.d scripts are ran. You'll have to unpack the boot.img and look through them to see where it is being set.
Damn. So something I can't do from my phone while laying in bed at 6am. I'll rip it from my phone and tear it apart tomorrow and find it. Thanks!!
Sent from my PC36100 using Tapatalk
finadil said:
Damn. So something I can't do from my phone while laying in bed at 6am. I'll rip it from my phone and tear it apart tomorrow and find it. Thanks!!
Sent from my PC36100 using Tapatalk
Click to expand...
Click to collapse
you could have the script spawn another one that waits for it to change the governor and then changes it back, not as clean but it would work without having to modify the boot.img.
Its not so much changing the governor as tweaking its default values. I was feeling lazy so I took the latest sz kernel (which is what I use), extracted it, edited its init scripts so it uses SA as default and my values rezipped and flashed (so it'd mkbootimg). It boots using SA but again its using its own defaults. Guess the only options are recompiling the source with edited values or a post load script?
Sent from my PC36100 using Tapatalk
Try this
Btw, you'll have issues with your rampup step. It has to be a multiple of 38400. So 115200.
Code:
#!/system/bin/sh
if [ -e /sys/devices/system/cpu/cpu0/cpufreq/smartass/sleep_max_freq ];
then
echo "998000" > /sys/devices/system/cpu/cpu0/cpufreq/smartass/sleep_wakeup_freq
echo "614400" > /sys/devices/system/cpu/cpu0/cpufreq/smartass/up_min_freq
echo "384000" > /sys/devices/system/cpu/cpu0/cpufreq/smartass/sleep_max_freq
echo "2" > /sys/devices/system/cpu/cpu0/cpufreq/smartass/sample_rate_jiffies
echo "128000" > /sys/devices/system/cpu/cpu0/cpufreq/smartass/ramp_up_step
echo "0" > /sys/devices/system/cpu/cpu0/cpufreq/smartass/ramp_down_step
echo "40" > /sys/devices/system/cpu/cpu0/cpufreq/smartass/min_cpu_load
echo "65" > /sys/devices/system/cpu/cpu0/cpufreq/smartass/max_cpu_load
echo "30000" > /sys/devices/system/cpu/cpu0/cpufreq/smartass/down_rate_us
echo "0" > /sys/devices/system/cpu/cpu0/cpufreq/smartass/awake_min_freq
fi;
Can I set up an init.d file to ask if it should execute? I plan to have kernel settings in the file, but I may need to change content depending on the kernel I'm running.
ex.
#!/system/bin/sh
read -p "Run script? (y/n) " DOIT
if [ "$DOIT" = "y" ]; then
echo "19200" > /sys/devices/system/cpu/cpu0/cpufreq/screen_on_min_freq
fi
Woops Cant edit title now Lol.
Anyway, with the system img changing thing for BL locked users, would it be possible to modify a system img and create some sort of stock theme?
If you have access to the Send Command tools and you are running LP then you can modify the system.img.
Also on MM is possible to change things on system partition with send command.
ObiDanKenobi said:
Also on MM is possible to change things on system partition with send command.
Click to expand...
Click to collapse
I think i might start learning how and how to modify stock apps and etc, cus i really want a Google Stock theme for our device, on BL lock, like the G2 has a theme (Although its a rom, but its from where i got the idea)
Someone has done exactly that here: http://forum.xda-developers.com/g4/orig-development/bl-lock-ul-android-6-0-marshmallow-t3459260. They used another theme though
Trimis de pe al meu LG-H815 folosind Tapatalk
ObiDanKenobi said:
Someone has done exactly that here: http://forum.xda-developers.com/g4/orig-development/bl-lock-ul-android-6-0-marshmallow-t3459260. They used another theme though
Trimis de pe al meu LG-H815 folosind Tapatalk
Click to expand...
Click to collapse
Yeah, I'm using that lol
it gave me the idea that maybe its possible to bring back one of the best themes on the G2, really, that theme was amazing.
Anyone wants to work with me on this?
Anyway, this is the theme i want to make for the G4:
http://forum.xda-developers.com/lg-g2/development-d802/rom-google-edition-release-thread-t3262929
(Unless someone that is actually good in this and is willing to risk his G4 does it before me lol )
And Crap i realised i cant do this anyway for two reasons:
1. H815L root injecting for 6.0 isn't possilbe
2. even if it were possible i have no Linux on my PC.
So rip this idea ;-;
You do not have to inject root. I changed for instance the parameters of the governor, getting a much smoother and battery friendly device.
I have no Linux machine either, I have a virtual machine running Linux where I do the dirty work.
ObiDanKenobi said:
You do not have to inject root. I changed for instance the parameters of the governor, getting a much smoother and battery friendly device.
I have no Linux machine either, I have a virtual machine running Linux where I do the dirty work.
Click to expand...
Click to collapse
Teach me the ways Sempai, pls.
Ha ha, that was a good one. I will lay out some steps, but you have to do the dirty work yourself:
First and foremost you have to have a linux (virtual) machine. Using that machine you will be able to
1. extract the system.img from your phone
2. you have to mount the img on the linux file system,
3. you copy the /system/init.qcom.post_boot.sh to your machine (or you edit in place with Linux)
4. at the end of the file you put the following code
# Added modifications by Dan
#
# IO for device and msd
# (switch to cfq sched, set read ahead
echo 256 > /sys/block/mmcblk0/bdi/read_ahead_kb
echo "cfq" > /sys/block/mmcblk0/queue/scheduler
echo 16 > /sys/block/mmcblk0/queue/iosched/back_seek_max
echo 512 > /sys/block/mmcblk1/bdi/read_ahead_kb
echo "cfq" > /sys/block/mmcblk1/queue/scheduler
echo 16 > /sys/block/mmcblk1/queue/iosched/back_seek_max
# Tuning Transmission Control Protocols.
echo "cubic" > /proc/sys/net/ipv4/tcp_congestion_control
echo 1 > /proc/sys/net/ipv4/tcp_timestamps
echo 1 > /proc/sys/net/ipv4/tcp_sack
echo 1 > /proc/sys/net/ipv4/tcp_window_scaling
#echo interactive > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo 0 > /sys/devices/system/cpu/cpu0/cpufreq/interactive/above_hispeed_delay
echo 1 > /sys/devices/system/cpu/cpu0/cpufreq/interactive/align_windows
echo 0 > /sys/devices/system/cpu/cpu0/cpufreq/interactive/boost
echo 0 > /sys/devices/system/cpu/cpu0/cpufreq/interactive/boostpulse_duration
echo 90 > /sys/devices/system/cpu/cpu0/cpufreq/interactive/go_hispeed_load
echo 1248000 > /sys/devices/system/cpu/cpu0/cpufreq/interactive/hispeed_freq
echo 0 > /sys/devices/system/cpu/cpu0/cpufreq/interactive/max_freq_hysteresis
echo 0 > /sys/devices/system/cpu/cpu0/cpufreq/interactive/min_sample_time
echo 85 600000:70 > /sys/devices/system/cpu/cpu0/cpufreq/interactive/target_loads
echo 480000 > /sys/devices/system/cpu/cpu0/cpufreq/interactive/timer_rate
echo 480000 > /sys/devices/system/cpu/cpu0/cpufreq/interactive/timer_slack
echo 1 > /sys/devices/system/cpu/cpu0/cpufreq/interactive/use_migration_notif
echo 0> /sys/devices/system/cpu/cpu0/cpufreq/interactive/use_sched_load
echo 384000 > /sys/devices/system/cpu/cpu4/cpufreq/scaling_min_freq
#echo > /sys/devices/system/cpu/cpu4/cpufreq/scaling_governor interactive
echo 0 > /sys/devices/system/cpu/cpu4/cpufreq/interactive/above_hispeed_delay
echo 1 > /sys/devices/system/cpu/cpu4/cpufreq/interactive/align_windows
echo 0 > /sys/devices/system/cpu/cpu4/cpufreq/interactive/boost
echo 0 > /sys/devices/system/cpu/cpu4/cpufreq/interactive/boostpulse_duration
echo 95 > /sys/devices/system/cpu/cpu4/cpufreq/interactive/go_hispeed_load
echo 1824000 > /sys/devices/system/cpu/cpu4/cpufreq/interactive/hispeed_freq
echo 0 > /sys/devices/system/cpu/cpu4/cpufreq/interactive/max_freq_hysteresis
echo 0 > /sys/devices/system/cpu/cpu4/cpufreq/interactive/min_sample_time
#echo 633600 > /sys/devices/system/cpu/cpu4/cpufreq/scaling_min_freq
echo 90 > /sys/devices/system/cpu/cpu4/cpufreq/interactive/target_loads
echo 240000 > /sys/devices/system/cpu/cpu4/cpufreq/interactive/timer_rate
echo 480000 > /sys/devices/system/cpu/cpu4/cpufreq/interactive/timer_slack
echo 1 > /sys/devices/system/cpu/cpu4/cpufreq/interactive/use_migration_notif
echo 0 > /sys/devices/system/cpu/cpu4/cpufreq/interactive/use_sched_load
# Adjust input parameters
echo 1 > /sys/module/cpu_boost/parameters/input_boost_enabled
echo 0:600000 1:600000 2:600000 3:600000 4:0 5:0 > /sys/module/cpu_boost/parameters/input_boost_freq
echo 0 > /sys/module/cpu_boost/parameters/boost_ms
echo 40 > /sys/module/cpu_boost/parameters/input_boost_ms
echo 0 > /sys/module/msm_performance/parameters/touchboost
5. you copy the file back (or you save if you edited in place).
6. you unmount the image from your linux system
7. you copy the system.img to your internal sd on the phone
8. you push the system.img the phone using send_command
9. profit.
that's it. As you can see there is not much to it
ObiDanKenobi said:
Ha ha, that was a good one. I will lay out some steps, but you have to do the dirty work yourself:
First and foremost you have to have a linux (virtual) machine. Using that machine you will be able to
1. extract the system.img from your phone
2. you have to mount the img on the linux file system,
3. you copy the /system/init.qcom.post_boot.sh to your machine (or you edit in place with Linux)
4. at the end of the file you put the following code
# Added modifications by Dan
#
# IO for device and msd
# (switch to cfq sched, set read ahead
echo 256 > /sys/block/mmcblk0/bdi/read_ahead_kb
echo "cfq" > /sys/block/mmcblk0/queue/scheduler
echo 16 > /sys/block/mmcblk0/queue/iosched/back_seek_max
echo 512 > /sys/block/mmcblk1/bdi/read_ahead_kb
echo "cfq" > /sys/block/mmcblk1/queue/scheduler
echo 16 > /sys/block/mmcblk1/queue/iosched/back_seek_max
# Tuning Transmission Control Protocols.
echo "cubic" > /proc/sys/net/ipv4/tcp_congestion_control
echo 1 > /proc/sys/net/ipv4/tcp_timestamps
echo 1 > /proc/sys/net/ipv4/tcp_sack
echo 1 > /proc/sys/net/ipv4/tcp_window_scaling
#echo interactive > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo 0 > /sys/devices/system/cpu/cpu0/cpufreq/interactive/above_hispeed_delay
echo 1 > /sys/devices/system/cpu/cpu0/cpufreq/interactive/align_windows
echo 0 > /sys/devices/system/cpu/cpu0/cpufreq/interactive/boost
echo 0 > /sys/devices/system/cpu/cpu0/cpufreq/interactive/boostpulse_duration
echo 90 > /sys/devices/system/cpu/cpu0/cpufreq/interactive/go_hispeed_load
echo 1248000 > /sys/devices/system/cpu/cpu0/cpufreq/interactive/hispeed_freq
echo 0 > /sys/devices/system/cpu/cpu0/cpufreq/interactive/max_freq_hysteresis
echo 0 > /sys/devices/system/cpu/cpu0/cpufreq/interactive/min_sample_time
echo 85 600000:70 > /sys/devices/system/cpu/cpu0/cpufreq/interactive/target_loads
echo 480000 > /sys/devices/system/cpu/cpu0/cpufreq/interactive/timer_rate
echo 480000 > /sys/devices/system/cpu/cpu0/cpufreq/interactive/timer_slack
echo 1 > /sys/devices/system/cpu/cpu0/cpufreq/interactive/use_migration_notif
echo 0> /sys/devices/system/cpu/cpu0/cpufreq/interactive/use_sched_load
echo 384000 > /sys/devices/system/cpu/cpu4/cpufreq/scaling_min_freq
#echo > /sys/devices/system/cpu/cpu4/cpufreq/scaling_governor interactive
echo 0 > /sys/devices/system/cpu/cpu4/cpufreq/interactive/above_hispeed_delay
echo 1 > /sys/devices/system/cpu/cpu4/cpufreq/interactive/align_windows
echo 0 > /sys/devices/system/cpu/cpu4/cpufreq/interactive/boost
echo 0 > /sys/devices/system/cpu/cpu4/cpufreq/interactive/boostpulse_duration
echo 95 > /sys/devices/system/cpu/cpu4/cpufreq/interactive/go_hispeed_load
echo 1824000 > /sys/devices/system/cpu/cpu4/cpufreq/interactive/hispeed_freq
echo 0 > /sys/devices/system/cpu/cpu4/cpufreq/interactive/max_freq_hysteresis
echo 0 > /sys/devices/system/cpu/cpu4/cpufreq/interactive/min_sample_time
#echo 633600 > /sys/devices/system/cpu/cpu4/cpufreq/scaling_min_freq
echo 90 > /sys/devices/system/cpu/cpu4/cpufreq/interactive/target_loads
echo 240000 > /sys/devices/system/cpu/cpu4/cpufreq/interactive/timer_rate
echo 480000 > /sys/devices/system/cpu/cpu4/cpufreq/interactive/timer_slack
echo 1 > /sys/devices/system/cpu/cpu4/cpufreq/interactive/use_migration_notif
echo 0 > /sys/devices/system/cpu/cpu4/cpufreq/interactive/use_sched_load
# Adjust input parameters
echo 1 > /sys/module/cpu_boost/parameters/input_boost_enabled
echo 0:600000 1:600000 2:600000 3:600000 4:0 5:0 > /sys/module/cpu_boost/parameters/input_boost_freq
echo 0 > /sys/module/cpu_boost/parameters/boost_ms
echo 40 > /sys/module/cpu_boost/parameters/input_boost_ms
echo 0 > /sys/module/msm_performance/parameters/touchboost
5. you copy the file back (or you save if you edited in place).
6. you unmount the image from your linux system
7. you copy the system.img to your internal sd on the phone
8. you push the system.img the phone using send_command
9. profit.
that's it. As you can see there is not much to it
Click to expand...
Click to collapse
Is possible to modify /system/init.qcom.post_boot.sh for disable the 2 big core or keep them to a low frequency on the system.img of MM?
Yes there is: you should add at the end of the file the following:
echo 0 > /sys/devices/system/cpu/cpu4/online
echo 0 > /sys/devices/system/cpu/cpu5/online
I missed the biggest opportunity to test this stuff, I was lazy and did not make a image with the cores disabled. Wednesday the phone went into bootloop, but now I have no way of copying the image into the internal storage to send it via send_command. After a couple of hours of trying to mount the sdcard in download mode, I gave up, and now the courier will pickup the phone to go to LG service center, as I have warranty.
I kept on asking some people how to change/create a tot file for these situations, but until now I got no info, so if the bootloop hits, you have to have the img file already on your internal storage. Even then, when the cores are disabled using post_boot.sh there is no guarantee that it will work, but I missed the chance to test this.