URGENT UPDATE: THIS KERNEL COULD BREAK YOUR ROM. It re-orders the mtd block order, this causes some custom scripts (e.g. in init.d) to break. Please don't use it for the moment unless the ROM is specifically updated to use it. You are free to test it, but be sure to backup first. Please report if the ROM works, and if possible check if there are any init.d/sh scripts with static mtdblock# mounting too (see post #13 for details).
Info For ROM Devs: To make your ROM compatible with this, any scripts you have that (re)mount partitions need to be updated. Please see post #13 for details.
If you use a ROM and want to use this kernel but it doesn't work, feel free to let me know and I'll see if I can make a patch to update it in case the original ROM builder doesn't for some reason.
----------------
Unlocked Bootloader only obviously, don't ask about locked bootloader support. I don't take any credit for this kernel. This is a mod of Championswimmer's kCernel v01 (the new 'test' ones, which are the best kernel yet IMO), I only started a new thread incase this kernel has issues whereas champs' original one doesn't (you can report them here). Additional credits go to DoomLorD (got some code from his old kernel for FXP, i.e. DoomKernel v05) and of course J and the FXP Team.
Hope you guys don't mind Championswimmer and DooMLorD, you are Gods :highfive:
This kernel is made for CosmicUI ROM but it should work with any FXP-CM7 based ROM. If you are not using CosmicUI, be aware of these two warnings:
1) /system only has 190MB. If your ROM installation is bigger, you can't use this. You can check the size of system with apps like Titanium Backup and Link2SD.
2) /cache only has 8MB (it was 4MB but this ran out of space when doing stuff in Recovery) and as such you will need a 'bind-mount script for download cache' which links /cache/download to /data so that large Play Store downloads will work. All good FXP-based ROM's should already have it since it's been built in to Cyanogenmod for a long time. Check init.d for "06mountdl" file to be sure (might be different name, on CosmicUI it's 05mountdl for example).
Tested ROM's working with this kernel (please report if it works but not in the list):
- CM7-FXP125 and later
- CosmicUI v0.6.x and later
Changelog
Code:
Based directly on championswimmer's kCernel "test-release-v01" (the new one after v05)
v03
- Fixed gradual pixel shift bug in Aroma installer
- Changed handset max-gain to 600 (was 1000). I noticed no difference in volume, this also fixes distortion for some X10's
- Unlocked more mhz (1152, 1190, 1228). Be careful with the higher ones, though CM7/CosmicUI will revert to safe clock if it crashes.
- Compiled a second version with a different "safe" partition map for huge ROM's (system @ 285MB, userdata @ 608MB, cache @ 35MB)
- Optimized smartass governor for better sleep and wake (thanks to DooMLorD and FXP)
- Optimized smartassv2 governor for better sleep and wake (thanks to DooMLorD and FXP)
- Default governor changed to smartassv2 (bit more battery friendly than SavagedZen)
v02
- "kcernel" and "cosmicmod" appended to version string
- custom mtdparts config ( system @ 190MB, userdata @ 730MB, cache @ 8mb )
- compiled with O4 optimization
- (over)clock speeds added (up to 1113) and voltages tweaked (thanks to DooMLorD)
- improved in-call volume (thanks to DooMLorD)
- Default governor set to SavagedZen
- Compiled with performance governor available (useful for stress testing max clock)
v01
- Based on kCernel "test" v01
- Changed bootlogo to CosmicUI one with kCernel for FXP branding
- Removed Bootmanager (I don't use it) and replaced with Doom's Touch Recovery (more stable backup/restore than FXP Recovery)
Installation
1) Make a Nandroid backup (if you want to keep your ROM)
2) Flash the kernel in latest FlashTool
3) Boot to recovery and format cache, data and system
4) Restore Nandroid backup
5) Reboot. Let me know if you have any issues.
6) In my experience I've had to perform a Factory Reset and reinstall the ROM when switching from another kernel.
If you are not already using kCernel, you might need to do a factory reset - I don't know.
Requests
If you want some other partition layout or have any other suggestion please let me know and I'll think about it.
Download
v3 MaxMTD (/data = 730MB version) - recommended for CosmicUI
http://www.mediafire.com/?d4fenoosqeeryyk
v3 SafeMTD (/data = 608MB, /system = 285MB) - recommended for large ROM's
http://www.mediafire.com/?tuu7b07kptb32pb
Source
http://www.mediafire.com/download.php?nunrktw96q58eof
Detailed Info (for devs)
I am surprised how easy it was to create a custom partition map and I have no idea why nobody else has done this before. All I had to do was edit the default build config and edit the CONFIG_CMDLINE value:
Code:
CONFIG_CMDLINE="console=ttyMSM0 mtdparts=msm_nand:[email protected](boot),190m(system),730m(userdata),8m(cache),4m(appslog)"
...the other changes were taken from DoomKernel v05 in a basic tree-diff method.
Special thanks for Championswimmer and his guides, tips, kernels, etc. You are the best
Could you make a version without the volume boost mod? Because the boost mod causes my earpiece to crackle, and there's no ULBL kernel that doesn't have the volume boost mod.
Thanks a bunch
Sent from my X10i using XDA
Prodigy said:
Could you make a version without the volume boost mod? Because the boost mod causes my earpiece to crackle, and there's no ULBL kernel that doesn't have the volume boost mod.
Thanks a bunch
Sent from my X10i using XDA
Click to expand...
Click to collapse
I'm not sure I know what you mean. The "in-call volume enhance" in the changelog was taken from DoomKernel v05, it's not there in kCernel. So it's something different and I don't know where to find that. The change raises the minimum gain value, it doesn't actually "boost" volume but stops it from going too low.
I don't get any crackle on mine, I just tested it. Sounds like (no pun intended) your earpiece is damaged....
...I would be willing to do it, but I don't know where to look. Find me a kernel with public sourcecode without this volume boost for me and I'll check it out.
CosmicDan said:
I'm not sure I know what you mean. The "in-call volume enhance" in the changelog was taken from DoomKernel v05, it's not there in kCernel. So it's something different and I don't know where to find that. The change raises the minimum gain value, it doesn't actually "boost" volume but stops it from going too low.
I don't get any crackle on mine, I just tested it. Sounds like (no pun intended) your earpiece is damaged....
...I would be willing to do it, but I don't know where to look. Find me a kernel with public sourcecode without this volume boost for me and I'll check it out.
Click to expand...
Click to collapse
Hi,
The earpiece crackling started back on wolf's v7b6 doomkernel version, and it wasn't just me, a couple of users reported that their earpiece started crackling as a result of using wolf's rom. IDK what caused it, either a problem with the ROM or doomkernel, but DK seemed fine on any other ROM other than wolf's.
Anyway yeah the crackling was almost non-existent with stock kernels, which by the way, did not conyain the mod. Sorry for confusing you, this mod was incorporated in kernels back when kernel development just started. Tkygmr mentions that he forgot to include the volume boost mod here. That kernel is here. Yeah its for locked bl, I'm not sure if thay helps. But the kernels before that, many did not have the volume boost mod.
Hope this helps, and thanks for your time much appreciated.
Sent from my X10i using XDA
Prodigy said:
Hi,
The earpiece crackling started back on wolf's v7b6 doomkernel version, and it wasn't just me, a couple of users reported that their earpiece started crackling as a result of using wolf's rom. IDK what caused it, either a problem with the ROM or doomkernel, but DK seemed fine on any other ROM other than wolf's.
Anyway yeah the crackling was almost non-existent with stock kernels, which by the way, did not conyain the mod. Sorry for confusing you, this mod was incorporated in kernels back when kernel development just started. Tkygmr mentions that he forgot to include the volume boost mod here. That kernel is here. Yeah its for locked bl, I'm not sure if thay helps. But the kernels before that, many did not have the volume boost mod.
Hope this helps, and thanks for your time much appreciated.
Sent from my X10i using XDA
Click to expand...
Click to collapse
Hmm maybe it was xLoud that damaged the earpiece, who knows.
I checked out that post and crawled their GitHub, unfortunately they didn't use GitHub version management until a few months after adding the call-volume hack he mentions. So I won't be able to find it in that source =\
Guess the only thing to do is PM a veteran x10 kernel dev, but I'm not sure who. They all seem to have moved on since. If there is any other custom kernel (even for stock-based or locked bootloader) that you can find without any volume hacks, do let me know.
Although with the minimum-gain tweak I merged into this (which, as a mentioned, was from DoomKernel and not in original kCernel), I could compare the code from that to the stock kernel sources. But that will take a bit of time and I might not be able to find it, depends how much these custom kernels have changed from stock.
EDIT: Hang on, I just found an older repo from that thread "FreeKernel" (before it was 3Kernel). Maybe I'll find it.
EDIT2: Found it. https://github.com/tkymgr/semc-qsd8x50/commit/6c3c316b69ce7177cd08c73895406c94fd72db32 Yeah, I could have guessed that but now I'm sure so it's OK haha. If you look at that page you can see the ".min_gain = -900" which is what I changed to -400, but the max is changed here too.
OK, so the stock kernel (I think) has max set to 600, in this kernel, kCernel and DK though it's on 1000. I will create a version with 600.
This kernel is made for CosmicUI ROM but it should work with any FXP-CM7 based ROM. If you are not using CosmicUI, be aware of these two warnings:
1) /system only has 190MB. If your ROM installation is bigger, you can't use this. You can check the size of system with apps like Titanium Backup and Link2SD.
2) /cache only has 8MB (it was 4MB but this ran out of space when doing stuff in Recovery) and as such you will need a 'bind-mount script for download cache' which links /cache/download to /data so that large Play Store downloads will work. All good FXP-based ROM's should already have it since it's been built in to Cyanogenmod for a long time. Check init.d for "06mountdl" file to be sure (might be different name, on CosmicUI it's 05mountdl for example).
Tested ROM's working with this kernel (please report if it works but not in the list):
- FXP125 CM7 (official)
- CosmicUI v0.5.x and later
Changelog
Code:
Based directly on championswimmer's kCernel "test-release-v01" (the new one after v05)
- "kcernel" and "cosmicmod" appended to version string
- custom mtdparts config ( system @ 190MB, userdata @ 730MB, cache @ 8mb )
- compiled with O4 optimization
- (over)clock speeds added (up to 1113) and voltages tweaked (thanks to DooMLorD)
- improved in-call volume (thanks to DooMLorD)
- Default governor set to SavagedZen
- Compiled with performance governor available (useful for stress testing max clock)
Installation
1) Make a Nandroid backup (if you want to keep your ROM)
2) Flash the kernel in latest FlashTool
3) Boot to recovery and format cache, data and system
4) Restore Nandroid backup
5) Reboot. Let me know if you have any issues.
If you are not already using kCernel, you might need to do a factory reset - I don't know.
Requests
If you want some other partition layout or have any other suggestion please let me know and I'll think about it.
Hello,
That was a Good Idea of yours. Since many roms are quite a bit larger than 190MB; for instance the one I am using is taking up almost 250MB of system, could you make a version with say 285MB for system and 35MB for cache which would still leave about 609MB for data. And 1190MHz as many X10's will handle it. :good:
Prodigy, give this a try. I tested it and noticed no difference at all? Very strange.... either the max-gain 1000 does nothing (or barely anything) or I did something wrong. Please try it though, if it works this will be included in any future releases.
http://www.mediafire.com/download.php?p8pxnlv658y6bdf
EDIT: For some reason when I flashed this, some of my UI fonts (clock, operator text, some others) turned into italic. Wtf? I actually like it but that makes no sense LOL. Last night during testing, winamp would also skip tracks twice when i only pressed it once (a clear data for the app fixed that). I think a factory reset might be needed if things go strange after flashing a kernel.
TAL333 said:
Hello,
That was a Good Idea of yours. Since many roms are quite a bit larger than 190MB; for instance the one I am using is taking up almost 250MB of system, could you make a version with say 285MB for system and 35MB for cache which would still leave about 609MB for data. And 1190MHz as many X10's will handle it. :good:
Click to expand...
Click to collapse
OK, the clock speeds I can do. Would you prefer a version of 260MB on system? There really is no need whatsoever to have space free on /system, unless you want to integrate some apps with TB for example. But even if you have 249MB on /system, it work work fine with 1MB free on a 250MB size. So having ~10MB free on system should be enough?
Is there a reason you want 35MB on cache? There is no need to have more than 8MB, with the CM7 bind-mount script the only thing that uses cache is CWM-Recovery for log files. I guess some custom scripts might use cache... is that why?
CosmicDan said:
Prodigy, give this a try. I tested it and noticed no difference at all? Very strange.... either the max-gain 1000 does nothing (or barely anything) or I did something wrong. Please try it though, if it works this will be included in any future releases.
http://www.mediafire.com/download.php?p8pxnlv658y6bdf
EDIT: For some reason when I flashed this, some of my UI fonts (clock, operator text, some others) turned into italic. Wtf? I actually like it but that makes no sense LOL. Last night during testing, winamp would also skip tracks twice when i only pressed it once (a clear data for the app fixed that). I think a factory reset might be needed if things go strange after flashing a kernel.
OK, the clock speeds I can do. Would you prefer a version of 260MB on system? There really is no need whatsoever to have space free on /system, unless you want to integrate some apps with TB for example. But even if you have 249MB on /system, it work work fine with 1MB free on a 250MB size. So having ~10MB free on system should be enough?
Is there a reason you want 35MB on cache? There is no need to have more than 8MB, with the CM7 bind-mount script the only thing that uses cache is CWM-Recovery for log files. I guess some custom scripts might use cache... is that why?
Click to expand...
Click to collapse
The reason I thought 285MB would be good was that I remember the last CM7 by Achotjan I used was a big ass rom, around 270 installed as I recall and I'm sure its bigger now. Just in case someone wants to try this with a big rom. The cache suggestion was just for extra margin as the most I've seen used on my phone was a little under 6MB. Back in the day, when I built a 550HP Poncho motor, I made sure the bottom end was good for at least 700HP. Gotta have margin.
TAL333 said:
The reason I thought 285MB would be good was that I remember the last CM7 by Achotjan I used was a big ass rom, around 270 installed as I recall and I'm sure its bigger now. Just in case someone wants to try this with a big rom. The cache suggestion was just for extra margin as the most I've seen used on my phone was a little under 6MB. Back in the day, when I built a 550HP Poncho motor, I made sure the bottom end was good for at least 700HP. Gotta have margin.
Click to expand...
Click to collapse
OK, good call. I don't know why 35MB on cache will be needed with the download cache redirected to /data, but OK I'll do one with 285MB on system and 35MB on cache and that'll be marked as the "safest" mod. Then I might make one in-between if asks for it. But there will be a limit to how many I can maintain
Cheers mate thanks heaps for your effort, that was really quick!
Sent from my X10i using Tapatalk 2
Prodigy said:
Cheers mate thanks heaps for your effort, that was really quick!
Sent from my X10i using Tapatalk 2
Click to expand...
Click to collapse
No worries. Let me know if it helps though? Next version will keep it, as I already mentioned that my test showed that it was not quieter at all putting the gain back to 600.
Info for ROM makers
Code like this in any sh scripts (e.g. init.d, hw_config.sh, etc) will not work with this kernel...
Code:
mount -o rw,remount -t yaffs2 /dev/block/mtdblock2 /system;
...because it assumes a standard MTD map. This kernel has however modified the order. We could just change it to mtdblock1, but then that ROM would only work with this kernel. So, we use a function to parse the /dev/mtd file to find the correct mtd device to be mounted.
Add this helper function to the top of your script(s):
Code:
get_mtd() {
local DEV="$(grep "\"$1\"" /proc/mtd | awk -F: '{print $1}')"
local PATH=/dev/mtdblock
DEV="${DEV##mtd}"
echo "${DEV:+$PATH$DEV}"
}
...then later, when you need to assign the right mtdblock, do this...
Code:
mtd_system="$(get_mtd system)"
...changing 'system' to whatever you want to find. This will populate the variable with /dev/mtdblock1 in kCernel-CosmicMod, or in other kernels with /dev/mtdblock2. All good.
So then after that you can use it in a line like this...
Code:
mount -o rw,remount -t yaffs2 $mtd_system /system;
...and that's pretty much it.
...I realize that I could correct the kernel to use the "original" mtd map order, but this is a good habit for a developer to get in to. A developer should not tie themselves down with device-specific habits. Besides, my changes to the mtd order make more sense and other Android devices that I know of seem to follow this same order.
Hi,
First thanks for this Kernel, i've been looking for a partition table like this forever, and now can take it with the overclock as well, this is awesome, and based on your last comment a just figured out out most scripts doesn't seem to work on my init.d
Well as i'm not that good with Linux scripts, (to not say very bad in this area of expertise), can you help me to translate to a working script the script below:
mount -o noatime,nodiratime,barrior=1 -t ext3 /dev/block/mmcblk0p2 /sd-ext;
I understand that this also should be placed:
chown 1000:1000 /sd-ext;
chmod 771 /sd-ext;
#swap mount:
swapon /dev/block/mmcblk0p3;
My mSD card was formatted using the recovery built in and the mapping is correct as in this way the script is already working but i have to run them from inside script manager app and not from init.d, from init so far nothing seems to work, or it's just me that can't figure how to do it.
TheRuan said:
Hi,
First thanks for this Kernel, i've been looking for a partition table like this forever, and now can take it with the overclock as well, this is awesome, and based on your last comment a just figured out out most scripts doesn't seem to work on my init.d
Well as i'm not that good with Linux scripts, (to not say very bad in this area of expertise), can you help me to translate to a working script the script below:
mount -o noatime,nodiratime,barrior=1 -t ext3 /dev/block/mmcblk0p2 /sd-ext;
I understand that this also should be placed:
chown 1000:1000 /sd-ext;
chmod 771 /sd-ext;
#swap mount:
swapon /dev/block/mmcblk0p3;
My mSD card was formatted using the recovery built in and the mapping is correct as in this way the script is already working but i have to run them from inside script manager app and not from init.d, from init so far nothing seems to work, or it's just me that can't figure how to do it.
Click to expand...
Click to collapse
You are saying this script works with other kernels but not with this one? I don't understand why, the mmc blocks are untouched - only the MTD blocks (internal partitions) have a changed order in this kernel.
Try it with original kCernel, I don't know if it has swap support enabled.
CosmicDan said:
You are saying this script works with other kernels but not with this one? I don't understand why, the mmc blocks are untouched - only the MTD blocks (internal partitions) have a changed order in this kernel.
Try it with original kCernel, I don't know if it has swap support enabled.
Click to expand...
Click to collapse
No no, what i'm saying is that this doesn't work with the Kcernel, i couldn't try your modified one since i've been working a lot this week and didn't have the time to format the phone again, the weird thing is that as far as i know the fxp has a default script in which it should always search the sd-ext partition and mount it, not sure about the swap partition, but pretty sure it would mount it too, but so far everything indicates that nothing inside the init.d directory is running, since i've tried many variations i got from the web and none worked.
I'm using the last 125 FXP and the Kcernel test1.
Will try tonight to format the phone in the work, but can't promise anything since i've almost no tools here and also i'm very sick, shouldn't be working neither, hehehe, but I'm workaholic.
TheRuan said:
No no, what i'm saying is that this doesn't work with the Kcernel
Click to expand...
Click to collapse
Well you should probably ask in original kCernel thread or the thread for your ROM... what is the ROM you are using? I could take a look when I have time if you can't give me a logcat.
TheRuan said:
the weird thing is that as far as i know the fxp has a default script in which it should always search the sd-ext partition and mount it
Click to expand...
Click to collapse
No, it doesn't have any function to mount sd-ext. You have to use a third-party method to get sd-ext access such as A2SD scripts (can be buggy) or the Link2SD app (recommended, most stable and more powerful).
TheRuan said:
but so far everything indicates that nothing inside the init.d directory is running, since i've tried many variations i got from the web and none worked.
I'm using the last 125 FXP and the Kcernel test1.
Click to expand...
Click to collapse
Hmm all I can suggest is to reflash kernel with latest flashtool, factory reset, and reinstall the ROM. If no init.d scripts are running it must be a bad kernel flash, which happens fairly often with the X10.
I reflashed now with your kernel and FXP, and no, init.D isn't working, I think this error is on Kcernel or on last builds from FXP kernel, that, being the source for kcernel could be the reason for the errors, and also I'm pretty sure that no start script are running.
Also for some reason on your kernel i can't undervolt the phone anymore, this was available using Kcernel.
tried to flash original fxp 124 kernel, and i get wlods all the time, it wont boot into recovery, anyone has ideas how to fix?? i saw something about flashing the fxp 124 rom and kernel directly from flashtool but i cant find it cause i forgot the threads name, please help as quickly as possible, cause i was thinking of flashing that, i could boot into recovery and restore my fxp 125 rom that i had now..
TheRuan said:
I reflashed now with your kernel and FXP, and no, init.D isn't working, I think this error is on Kcernel or on last builds from FXP kernel, that, being the source for kcernel could be the reason for the errors, and also I'm pretty sure that no start script are running.
Also for some reason on your kernel i can't undervolt the phone anymore, this was available using Kcernel.
Click to expand...
Click to collapse
Well I don't know what to say, init.d executes fine for FXP kernel, kCernel original and this kCernel mod. I find it hard to believe that init.d isn't working at all, because then sysctl wouldn't even be running. It's more likely that it's crashing out because of something you added or changed. You'll need to logcat it.
And sorry, I was wrong - the 05mountsd script handles sd-ext mounting. But that never did anything in my experience, it depends on your configuration. Link2SD works 100% for me and it creates an init.d script when you first run it and select your sd-ext partition type.
I noticed the undervolt thing and it's the only thing holding me off releasing the next version, I think I need to enable that sysfs interface somewhere. Changing clock voltages is done at /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels - same as every other custom kernel for x10 that has it.
[email protected] said:
tried to flash original fxp 124 kernel, and i get wlods all the time, it wont boot into recovery, anyone has ideas how to fix?? i saw something about flashing the fxp 124 rom and kernel directly from flashtool but i cant find it cause i forgot the threads name, please help as quickly as possible, cause i was thinking of flashing that, i could boot into recovery and restore my fxp 125 rom that i had now..
Click to expand...
Click to collapse
Try flashing stock gingerbread FTF, and please take those questions to the Questions forum - this has nothing to do with this kernel.
Related
What this kernel does is provide slightly less voltage to the processor. This should not be dangerous for anyone to try, however it may be unstable or just result in general weirdness on a few phones. If it does, all you have to do is revert back to the kernel you had before.
The upsides to less voltage are less heat as well as less power consumption. That means battery life
Remember, this one is running at stock speeds.
Get it on Koush's RomManager (download RomManager from the market) I'll post changelogs in this thread from now on, but keep the kernel on RomManager.
Changelog 8/29:
Lots of stuff.. I dunno.. Look at the CM6 kernel changelog (I've been working on that).
Biggest thing IMO is the usleep stuff which lowers CPU usage and therefore increases battery life.
Note: only tested on CM6. Let me know if you try it on any other roms.
Link: http://kanged.net/up/files/5/kernels/signed-August26-UV950.zip
Changelog 6/20:
Ermm.. I've been releasing my kernels on twitter.. but I'm finally happy with this one.
-Latest Cyan commits
-Minor voltage tweaking
-erm... yeah I dunno.
Get it here http://kanged.net/kmobs/signed-619UV-34.zip or from RomManager.
Changelog 5/14:
-Reinstated those commits reverted earlier.
-Updated to .33.4
-Only doing a 925mV kernel due to the results from the blind study
Changelog 5/1:
-Reverted the following commits thanks to intersectRaven. I think they were the reason for the excessive battery drain.
27dd25f80402a13f9d5c381eda07b560e5545fcc
1490683fb851b992722cbd175d3df087df833656
f2513498e961966d3209aacfffc43de4f41f2ece
-Updated to latest CM source (minus those commits)
Changelog 4/21:
Fixed the board-mahimahi.c in the 850mV kernel.
OLD updates and changelog:
http://iq0.org/story/yet-another-nexus-one-kernel-now-battery-saving
Note: Now offering a universal update.zip method for flashing the kernel (big thanks to Koush for this one)
Thank you www.tdrevolution.com for hosting my work.
Does it still have the highmem?
GEtting an access denied message, Seems the post doesnt exist
Great job. Will get you a logcat if I get any random weirdness.
Maybe now my battery can last longer then my G1 battery did when I am at work.
Anyone care to make an update.zip for those of us without computers nearby to check this out?
Tested and functional with Enomther 1.61. Thanks a lot
What is the CPU voltage and is the some app that can show it?
Running this new kernel at 576/245 mHz, wifi off, 3G connection, brightness set to automatic. will report back with battery life as soon as it runs out. lol
Off of charger: 11:34AM , Wednesday, February 17, 2010
Battery completely drained: TBA
DocRambone said:
Tested and functional with Enomther 1.61. Thanks a lot
What is the CPU voltage and is the some app that can show it?
Click to expand...
Click to collapse
Hey do report if there is any improvements... meanwhile can someone make it into to an update.zip for us?
mgear356 said:
Hey do report if there is any improvements... meanwhile can someone make it into to an update.zip for us?
Click to expand...
Click to collapse
I will, phone seem ok so far, BenchmarkPi at 2670
No slowdowns or reboots during benchmarks or gameplay. Phone feel cooler tho
I'll give this a shot.
Mi|enko said:
Does it still have the highmem?
Click to expand...
Click to collapse
just flashed it. yes it does. my phone hasnt exploded yet either...
Mi|enko said:
Does it still have the highmem?
Click to expand...
Click to collapse
Yes
To those asking for an update.zip: I don't to package this into something that will be easily flashable by all, including those that may not understand the risks (I don't think there are any with this kernel, but can't be sure). I want there to be some rudimentary knowledge of android before someone goes and flashes this and potentially messes up their phone.
Does that make sense? I feel that there should be a barrier to entry on kernels that OC and the like.
What voltages is it for different MHz?
great job, really need something like this... im trying it out! thanks
DocRambone said:
What voltages is it for different MHz?
Click to expand...
Click to collapse
Its not across the board, and I'm not home right now to tell you, but 245 is at 1.0 vs 1.05 and 998 is at 1.250 instead of 1.275
persiansown said:
Yes
To those asking for an update.zip: I don't to package this into something that will be easily flashable by all, including those that may not understand the risks (I don't think there are any with this kernel, but can't be sure). I want there to be some rudimentary knowledge of android before someone goes and flashes this and potentially messes up their phone.
Does that make sense? I feel that there should be a barrier to entry on kernels that OC and the like.
Click to expand...
Click to collapse
I do understand what your saying, I don't think its that much of a barrier though. There are many instructions throughout these boards that will let anyone who is even remotely interested flash a new kernel and push a .ko to their phone... The only reason why I want an update.zip is so that I can flash this on my phone to test it while I'm at work, it would also be nice to be able to switch quickly between kernels and whatnot. I don't have a computer that I can connect to via USB to run fastboot/adb so the only way I can get these on my phone is via a zip.
I don't think that a developer/hacker can be held responsible for others not knowing what issues can be caused by a voltage/clock tweak - especially with disclaimers up everywhere.
FettsVett said:
I do understand what your saying, I don't think its that much of a barrier though. There are many instructions throughout these boards that will let anyone who is even remotely interested flash a new kernel and push a .ko to their phone... The only reason why I want an update.zip is so that I can flash this on my phone to test it while I'm at work, it would also be nice to be able to switch quickly between kernels and whatnot. I don't have a computer that I can connect to via USB to run fastboot/adb so the only way I can get these on my phone is via a zip.
I don't think that a developer/hacker can be held responsible for others not knowing what issues can be caused by a voltage/clock tweak - especially with disclaimers up everywhere.
Click to expand...
Click to collapse
Oh I understand where you're coming from, and I would make you a private one, but I'm not home at the moment. However, for the general user, if they can't use fastboot, I don't want them anywhere near this. I hope someone makes you an update.zip!
I await the PM's!
Dear lord what am I going to do with this should I get my 2800mah battery? my phone will never die! lol
-Charlie
FettsVett said:
I await the PM's!
Click to expand...
Click to collapse
you can make one yourself.
grab boot.img from cyanogen's rom.
grab split_bootimg.pl from http://android-dls.com/files/linux/split_bootimg.zip
grab persiansown's zImage.
(in linux)
put all three in a folder. let's call it kernel.
while in the kernel folder:
./split_bootimg.pl boot.img
mkbootimg --cmdline 'no_console_suspend=1 console=null' --kernel zImage-persiansown --ramdisk boot.img-ramdisk.gz -o boot-persiansown.img
(in windows)
download this: http://www.sendspace.com/file/kj2wi7
use winrar to open up that up, remove the boot.img in there and replace it with boot-persiansown.img (make sure it is named boot.img)
open up the update-script in META-INF folder (some levels down in there), and remove the format BOOT line (you'll be left with write_raw_image ... line), and save it.
grab this: http://www.relentlessaddictions.com/Androidstuff/signing.zip
unpack to your tools folder in your android-sdk folder distribution, and run autosign.bat. follow the prompts. once setup, you can right click on the .zip file with the boot.img in it to sign it, or you can execute from a cmd prompt: java testsign BOOT-IMG.zip
flash via custom recovery (which can flash .zip's signed with test keys).
you should be all set.
edit: mkbootimg can be found in prebuilt within AOSP distribution, or you can grab this precompiled one: http://forum.xda-developers.com/attachment.php?attachmentid=229872&d=1253485580
NOTE: This will probably no longer be maintained. It was the result of me playing around with the kernel from scratch instead of trying to understand what changes others have made and why they had made them! Now I'm a little more confident I'll probably be using DooMLoRD's kernel as a base for any changes I make to the Ray: [Kernel] [Ray] DooMLoRD's Kernel for Ray
hartej said:
Been playing around with Kernel development and created an overclocked kernel for the 4.0.2.A.0 stock Rom.
There's nothing too speciall in it at the moment, but lets you overclock the Ray to 1.9Ghz using the source released by SE and the modified CPU steps that IF2 posted here: http://forum.xda-developers.com/showthread.php?t=1165355
There's no custom bootloader/Clockwork mod and no additional governers (at the moment) although I may add these in future as I learn more.
It seems to work well enough, and everything seems to be working as standard. I experience random lock-ups at 1.9 and occasionally 1.8Ghz, especially when it goes into/out of sleep when the screen turns off. Lower frequencies seem stable though.
This is released as-is, I'm using it myself but I can't be held responsible for any instabilities or failures you might experience. Just thought it might be of use to some people.
The new .img file can be downloaded from here: http://dl.dropbox.com/u/17615284/4.0.2.A.0-V0.13-2011-12-18.img
Alternatively, I've posted a version of the DooMLoRD kernel for the Ray which has a ton more features. This can be found here: http://forum.xda-developers.com/showthread.php?t=1400121
To install just use fastboot in the usual way. To return to stock, extract kernel.sin from the official update image using WinZip/WinRar etc and flash using fastboot again.
Click to expand...
Click to collapse
I'll post any updates here from now on.
Changelog:
19/12/2011 - V0.13 - As people have quite rightly pointed out, V0.12 boots at 1.8GHz as default, which causes multiple reboots. I hadn't noticed this as I had SetCPU reduce it to 1GHz as soon as the system started. The only change to this version is to have it boot at 1GHz as default, it's up to the user to increase it themselves.
28/10/2011 - V0.12 - Added Clockwork Recovery v5.0.2.6 (Spam Vol[-] when phone starts up, use volume keys to navigate, home to select, back for back)
28/10/2011 - V0.11 - Started playing with the Ramdisk - as a first start I've made it rootable. Things like "Adb remount" work now.
26/10/2011 - V0.1 - intial release
Current version:
~~~~~~~~~
V0.13 can be downloaded here: http://dl.dropbox.com/u/17615284/4.0.2.A.0-V0.13-2011-12-18.img
Older versions:
~~~~~~~~~
V0.12 can be downloaded here: http://dl.dropbox.com/u/17615284/4.0.2.A.0-OverclockV0.12.img
V0.11 can be downloaded here: http://dl.dropbox.com/u/17615284/4.0.2.A.0-OverclockV0.11.img
get new kernel~nice
tested it works really cool
thanks!!!!!
Like it...
thanks
Glad to see the "Recovery option" is available.
I tested v0.11+OC 1.3Ghz -> no problem.
However, v0.12+OC 1.2 or 1.3 -> keep on rebooting.
v0.12+no OC (use default 1Ghz) -> no problem.
im on 012+oc 1.5mhz, still working well....
great works!
great work, thx for your efforts
the included cwm is it dooms latest?
http://forum.xda-developers.com/showthread.php?t=1172885
"[v12 onwards] modified recovery to support /sd-ext backup/restore (remember /sd-ext has to be the 2nd partition on ur sdcard [mmcblk0p2] for this to work)"
if it is not I think that would be usefull with ext support, now you can use a2sd for xperia, bu it is not possible to make nand backup bcs cwm dit not recognize ext partition.
can you add donation possibility, would like to support your work
Thank you a thousand times! :d
2 questions though:
- I have to reroot my phone after this?
- Do I have to rename the download to boot.img?
Thanks 4 sharing!!!
-No
-No
;-)
funiewski said:
great work, thx for your efforts
the included cwm is it dooms latest?
http://forum.xda-developers.com/showthread.php?t=1172885
"[v12 onwards] modified recovery to support /sd-ext backup/restore (remember /sd-ext has to be the 2nd partition on ur sdcard [mmcblk0p2] for this to work)"
if it is not I think that would be usefull with ext support, now you can use a2sd for xperia, bu it is not possible to make nand backup bcs cwm dit not recognize ext partition.
can you add donation possibility, would like to support your work
Click to expand...
Click to collapse
It's not the latest I'm afraid so I doubt the ext backup would work. I'll see what I can do for the next release when I get a chance.
At some point I was also going to see if it's possible to change the MTD partition structure to give more space to /data. At the moment adb reports:
Code:
Filesystem Size Used Available Use% Mounted on
/dev/block/mtdblock0 400.0M 241.8M 158.2M 60% /system
/dev/block/mtdblock3 420.0M 270.3M 149.7M 64% /data
This means that there's over 150MB of 'free' space in system that could be given over to the data partition instead of being effectively lost. May or may not be possible - don't know enough about the system yet.
As for donations - this is as much a learning experience for me than anything else, and at the moment I'm mostly applying things that others have done instead of making any breakthroughs myself so I wouldn't feel happy taking donations, but the thought is appreciated.
Bazonga said:
Thank you a thousand times! :d
2 questions though:
- I have to reroot my phone after this?
- Do I have to rename the download to boot.img?
Click to expand...
Click to collapse
You'll have to put it into fastboot mode by powering on and holding Vol[+], then flash using "Fastboot flash boot <filename>" - you can rename it or not, provided the <filename> part matches. You shouldnt have to reroot.
kkline38 said:
Glad to see the "Recovery option" is available.
I tested v0.11+OC 1.3Ghz -> no problem.
However, v0.12+OC 1.2 or 1.3 -> keep on rebooting.
v0.12+no OC (use default 1Ghz) -> no problem.
Click to expand...
Click to collapse
That's strange, i've got it overclocked to 1.5Ghz and it seems to be really stable. As far as I'm aware the only change I made between the two was adding clockwork - there shouldn't be any other difference... I'll look into it.
Double reboot only 10 min after flashing and without changing frequencies..
Bazonga said:
Double reboot only 10 min after flashing and without changing frequencies..
Click to expand...
Click to collapse
Without having your device in front of me I don't know how much I can do to help, but I'll look into it once I have the time. Unfortunately I have other things on the go at the moment so it probably won't be till next week.
hartej said:
Without having your device in front of me I don't know how much I can do to help, but I'll look into it once I have the time. Unfortunately I have other things on the go at the moment so it probably won't be till next week.
Click to expand...
Click to collapse
Thanks, I flashed the stock kernel back for now, Ray kept rebooting on me for no reason..
hartej said:
That's strange, i've got it overclocked to 1.5Ghz and it seems to be really stable. As far as I'm aware the only change I made between the two was adding clockwork - there shouldn't be any other difference... I'll look into it.
Click to expand...
Click to collapse
Do you use SetCPU ? (I use SetCPU 2.2.4)
What's the parameters did you use to OC 1.5Ghz ?
"ondemand" ? "powersave" ? "performance" ? or ?
Currently I changed back to V0.11. (it's stable for me)
kkline38 said:
Do you use SetCPU ? (I use SetCPU 2.2.4)
What's the parameters did you use to OC 1.5Ghz ?
"ondemand" ? "powersave" ? "performance" ? or ?
Currently I changed back to V0.11. (it's stable for me)
Click to expand...
Click to collapse
Yup, think I'm on 2.14 though - I doubt this would make a difference but its possible I guess.
I leave everything as-is (So ondemand governor) but reduce the min to 122MHz and increase max to 1.5GHz. Still confused as to why the previous version is more stable for some, but I'll have a look at the differences.
hi! thank you for this kernel.
now question. can you include USB_otg into your kernel? it's realised in DooMLorD kernel for arc (link). is it possible to do this feature for our device?
P.S. sorry for my english, i'm from Russia
vdsirotkin said:
hi! thank you for this kernel.
now question. can you include USB_otg into your kernel? it's realised in DooMLorD kernel for arc (link). is it possible to do this feature for our device?
P.S. sorry for my english, i'm from Russia
Click to expand...
Click to collapse
Don't worry about your English - my Russian is much worse!
I'm developing this for my own uses (selfish I know) while I work out how it's all put together. I'll add OTG to my list although I can't promise anything.
thanks
take it
Tried 0.12 and was really happy there´s clockwork for my ray But I have to go back to stock kernel. v0.12 randomly freezes and then reboots (btw. ray gets hot untill reboot).
I didn´t overclock and use rooted 4.0.2.A.0.42.
Due to being a new user, I can't reply in the Development forum, so here goes:
I have a Galaxy Player 5.0 US, and wanted to try WT's ROM (http://forum.xda-developers.com/showthread.php?t=1623529). As noted in the thread, there is a (presumably now fixed) issue with its installation. I had that same mounting issue.
So I modified the install script by commenting out the lines that unmounted, formatted, and remounted /system and uncommented the "delete-recursive" line. This provided a successful installation after making sure that the proper filesystems were mounted in CWM.
The ROM then boots successfully with Entropy's kernel, and Wi-Fi, etc. work properly--I didn't notice any issues.
As a side note to the author: would it be possible to put the kernel as one of the options in the setup?
Mevordel said:
Due to being a new user, I can't reply in the Development forum, so here goes:
I have a Galaxy Player 5.0 US, and wanted to try WT's ROM (http://forum.xda-developers.com/showthread.php?t=1623529). As noted in the thread, there is a (presumably now fixed) issue with its installation. I had that same mounting issue.
So I modified the install script by commenting out the lines that unmounted, formatted, and remounted /system and uncommented the "delete-recursive" line. This provided a successful installation after making sure that the proper filesystems were mounted in CWM.
The ROM then boots successfully with Entropy's kernel, and Wi-Fi, etc. work properly--I didn't notice any issues.
As a side note to the author: would it be possible to put the kernel as one of the options in the setup?
Click to expand...
Click to collapse
Thanks for the feedback. I should be able to upload a new release in a day or so.
As for the kernel installation, I did consider the possibility of adding the option to install kernels but in the end I didn't put it in. My logic is that if you have a working CWM to flash this ROM, very likely you already have the correct kernel (because CWM is part of the kernel) and you rarely need to update the kernel.
If I put an option there for user to flash rj's kernel vs Entropy's kernel, I believe sooner or latter someone will flash the wrong kernel on the device which can be problematic.
If I can figure out some reliable ways to check the device type (US vs Intl), then it will be safe to include the kernel.
WT Ho said:
If I put an option there for user to flash rj's kernel vs Entropy's kernel, I believe sooner or latter someone will flash the wrong kernel on the device which can be problematic.
If I can figure out some reliable ways to check the device type (US vs Intl), then it will be safe to include the kernel.
Click to expand...
Click to collapse
That sounds reasonable - installing this rom won't modify your existing kernel at all, right?
A couple of final things:
1. In your next release, could you please update GO launcher? they made some pretty big improvements
2. me being the ocd neat freak that I am, I like it when there are very few folders in the root of /sdcard. Is there a way to put the "rom-settings" folder inside something like "Android"?
Thanks,
Mevordel
This thread Is a compilation of speed tweaks and mods I have gathered from the forums and used on my Galaxy Player 4.0. I can vouch for all of these tweaks, and all provide at least a modest performance improvement. I claim no credit for any of these mods, the glory goes to the fabulous devs who have created them.
To show you the possible performance increase, I have all of these tweaks installed with the Terrasilent kernel and Klin's R5 ROM, plus an Overclock to 1.5 GHZ, and I have scored over 2750 in Quadrant, as indicated in the screenshot below.
If you have any potential tweaks or suggestions, PM me, and I will check them out!
Note to devs: I believe I have posted this in the right section, as this does not 100% pertain to development.
Now, let's get cracking!
Tweak No. 1: convert RFS filesystem to EXT4.
RFS has been tweaked since it debuted on the galaxy S over two years ago, but still is not quite up to par with today's standards.
Steps:
1. Flash the Terrasilent kernel/ Klin's R3 (basically a kernel with Clockwork recovery 5+ on it)
2. Make a nandroid backup (make sure you have enough free space!)
3.after you reboot, navigate using a file explorer on the Gplayer to the recovery directory and rename all files (excluding boot.img) from .rfs.tar to .ext4.tar.
4. Open up nandroid.md5 and change all filenames (again, excluding boot.img) from .rfs.tar to .ext4.tar
5.Save that, reboot into recovery, perform a full restore, and reboot into download mode.
6. reflash the kernel you were using, and you are done!
The performance improvement is amazing, and I would recommend using this tweak to anyone, since it's safe, and provides a huge boost!
Tweak no.2: Universal Adrenaline shot.
This is an amazing tweak that has provided the biggest improvement for me. It should be pretty risk-free if you follow my directions. Do NOT try to unzip and manually install, as you will have to reflash you rom (bootloop). Additionally, you will have to reinstall any init.d tweaks you have currently, as this script wants to ensure no conflictions, and deletes them all
Steps:
1. Head to this link, read, and download Adrenaline shot v14 (don't worry, our device can handle the two risky tweaks).
2. Boot into recovery, and flash!
3. After flashing, I would optionally format /cache. After reboot, you should see a drastic performance increase!
Tweak no.3: EXT4 Journalism tweaks.
EXT4 is much faster than RFS, but on our Players, the lag is still noticeable, just navigating around the UI.
WARNING:This provides a nice speed increase, especially to large games, but if you have an unclean shutdown, or force restart your Gplayer, YOU WILL HAVE TO RESTORE!
Dire warnings said, This actually increases the smoothness of the Gplayer a decent amount, although for me the risk far outweighs the benefit.
Your partitions are as follows:
System: STL9
Data: mmcblk0p2
Dbdata: stl10
cache (use this partition if you want to test):stl11
Remember, you need su permissions for all of this!
Instructions:
1.First, FSCK the partitions (make sure you answer no to all but the first questions, as that could lead to file corruption! the errors are generated when the partition is accessed during the FSCK, which generates an error, since data is in a different section than it was before. Don't worry, most/all of those errors are flukes. The instruction is: e2fsck -f /dev/block/(partition name)
2. Disable journalism with tune2fs: tune2fs -O ^has_journal /dev/block/(partition name)
Note: tune2fs will not have the capabilities necessary unless you install the one from the one shot adrenaline tweak above.
3.reboot and enjoy!
If you want to reverse this, you will have to restore a nandroid backup, as CWM formats EXT4 with journalism, and a format is required to reset it. On the same note, you will have to reapply this tweak every time you restore a nandroid backup, just something to keep in mind.
Tweak no.4: Supercharge, and apply Loopy smoothness!
I am sure everyone knows about the ubiquitous v6 supercharger script out there, and it provides a big performane increase! Also, Loopy smoothness helps a lot in stabilizing launcher performance, and I view them to be equally valuable.
1. Visit here to download the latest supercharger script, and here to download T2 of loopy smoothness.
2. Launch the supercharger from the /sdcard/download directory, go throught the basic instructions, and the custoomize, reboot, and install nitro lag nullifier. Optionally install for easier access. I would also explore some of the other options especially reindexing.
3. move the loopy smoothness script into the init.d directory, open it, and remove the quotation marks around the launcher name if you are using the touchwiz launcher, or delete the quotations and name and add your launcher's process name (run ps in terminal emulator and find the most likely name, or look it up).
That's it! you should notice a definite performance increase, especially improvements in multitasking thanks to v6 supercharger. The launcher should also be a lot smoother.
Bonus (I have it in R5 rom, but have not actually applied it)
head here, download the latest script, and run it. It should add some extra build.prop tweaks that will greatly boost performance!
Some final suggestions:
1. Move to a custom launcher.
Using touchwiz, I always had about 125+- ram free after using a taskiller, but when I moved to go launcher EX (imho, the best launcher for the gplayer out there, beautiful, not hard on resources, and very customizable), I had over 160+ free after using a taskiller, which resulted in far smoother operation, and excellent multitasking!
2. use ondemand or ondemandx.
All the Gplayer profiles are good, but ondemand, although not the best at power saving, provides the best performance on our aging system, and gives a little extra juice when you need it.
3. use the deadline governor.
None of the other I/O governors come even close to NOOP and Deadline, but deadline is better for everyday use, and noop is better if you have several file transfers occurring at once (eg. hooked up to a computer, updating apps, and browsing the web). It comes down to your usage style, but I prefer Deadline.
4. Disable uneeded /system/app apps.
Fortunately our Gplayer is pretty bloat free, but you can disable more apps if you want. You should rename them to .apk1 instead of deleting them, just in case. Do not delete phone.apk, because for some reason it breaks the default camera app ( you can delete it if you don't use it).
Open up a terminal, run the ps command, and disable any system, apps you recognise in the list (una, fota, etc.).
Beta: Format sdcard as ext2
I had limited success with this mod, and it is definitely worth hassle of converting to ext2. Unfortunately, you must have an init.d script that runs at boot, and there will be the occaisonal permissipn issue, but chmoding the sdcard fixes that.
Steps:
1. Backup all of your /sdcard data
2.connect the gplayer to a linux computer in mtp mode.
3. Open a terminal, and type:
sudo umount /dev/sdx
sudo mkfs.ext2 /dev/sdx
4. Disconnect it from the computer. It will output an error when the media scanner runs, this is okay.
5. Create an init.d script with the following info:
#!/system/bin/sh
mount rw /dev/block/vold/179:1 /mnt/sdcard
chmod 777 /mnt/sdcard
chmod 777 /mnt/sdcard/*
chmod 777 /mnt/sdcard/Android
chmod 777 /mnt/sdcard/Android/*
6. Reboot, and restore your data.
That should be it! I used ext2 because i got permission errors with ext3/4 constantly, and ext2 was stable. The performance improvement is amazing, especially with apps that store data to /sdcard. My performance is at least doubled! Even thouh this is beta, I STRONGLY recommend doing this, as the performance is incredible (as I said)!
Note: after doing this, windows machines will not recognize the player, you will have to do all file transfers via linux.
Note: of app data is not recognized after restore, delete and redownload, after backing up the save file/s. At the moment, it is the only way I have to fix it.
Enjoy the speed!
Dalvik machine: the ULTIMATE speed booster.
I was poking around lately, and I discovered that dalvik settings are really far more powerful than most people give them credit for. Using them on an (unreleased) version of EtherealRom gave me a nice speed increase!
All of these can be added/edited in build.prop, if you so choose, under the variable "dalvik.vm.dexopt-flags=".
The most important one is u=y. This indicates that you want all VM code to be optimized for a single core, and provides a NICE speed boost. The next most important is o=a, as that indicates that you want it to optimize ALL the code, instead of selective batches.
I will update this later, I am exhausted right now, and need some sleep.
I now have my own custom rom that you can flash, that includes most of these amazing features (no ext converting, that has to be manual), plus some more! Note: this rom is ONLY for the 4.0. you will have to restore if you flash it onto the 5.0!
Download
That's it! I will certainly add on as time progresses, but at the moment that is all I can remember/know about, so be sure to pm me with potential tweaks so I can put it up here!
hanthesolo said:
This thread Is a compilation of speed tweaks and mods I have gathered from the forums and used on my Galaxy Player 4.0. I can vouch for all of these tweaks, and all provide at least a modest performance improvement. I claim no credit for any of these mods, the glory goes to the fabulous devs who have created them.
To show you the possible performance increase, I have all of these tweaks installed with the Terrasilent kernel and Klin's R5 ROM, plus an Overclock to 1.5 GHZ, and I have scored over 2750 in Quadrant. If you don't believe me, I will put up a screenshot, as I don't have screen capturing software on my Gplayer right now, and it's too much of a hassle.
If you have any potential tweaks or suggestions, PM me, and I will check them out!
Note to devs: I believe I have posted this in the right section, as this does not 100% pertain to development.
Now, let's get cracking!
Tweak No. 1: convert RFS filesystem to EXT4.
RFS has been tweaked since it debuted on the galaxy S over two years ago, but still is not quite up to par with today's standards.
Steps:
1. Flash the Terrasilent kernel/ Klin's R3 (basically a kernel with Clockwork recovery 5+ on it)
2. Make a nandroid backup (make sure you have enough free space!)
3.after you reboot, navigate using a file explorer on the Gplayer to the recovery directory and rename all files (excluding boot.img) from .rfs.tar to .ext4.tar.
4. Open up nandroid.md5 and change all filenames (again, excluding boot.img) from .rfs.tar to .ext4.tar
5.Save that, reboot into recovery, perform a full restore, and you are done!
Note: after converting, my /data partition is deleted/not recognized when booting into recovery on the terrasilent kernel. I think this may be an isolated incident, but you have been warned!
Tweak no.2: Universal Adrenaline shot.
This is an amazing tweak that has provided the biggest improvement for me. It should be pretty risk-free if you follow my directions. Do NOT try to unzip and manually install, as you will have to reflash you rom (bootloop). Additionally, you will have to reinstall any init.d tweaks you have currently, as this script wants to ensure no conflictions.
Steps:
1. Head to this link, read, and download Adrenaline shot v14 (don't worry, our device can handle the two risky tweaks).
2. Boot into recovery, and flash!
3. After flashing, I would optionally format /cache. After reboot, you should see a drastic performance increase!
Tweak no.3: EXT4 Journalism tweaks.
EXT4 is much faster than RFS, but on our Players, the lag is still noticeable, just navigating around the UI.
WARNING:This provides a nice speed increase, especially to large games, but if you have an unclean shutdown, force restart your Gplayer, YOU WILL HAVE TO RESTORE!
Dire warnings said, This actually increases the smoothness of the Gplayer a decent amount, although for me the risk far outweighs the benefit.
Your partitions are as follows:
System: STL9
Data: mmcblk0p2
Dbdata: stl10
cache (use this partition iuf you want to test):stl11
Remember, you need su permissions for all of this!
Instructions:
1.First, FSCK the partitions (make sure you answer no to all but the first questions, as that could lead to file corruption! the errors are generated when the partition is accessed during the FSCK, which generates an error, since data is in a different section than it was before. Don't worry, most/all of those errors are flukes. The instruction is: e2fsck -f /dev/block/(partition name)
2. Disable journalism with tune2fs: tune2fs -O ^has_journal /dev/block/(partition name)
Note: tune2fs will not have the capabilities necessary unless you install the one from the one shot adrenaline tweak above.
3.reboot and enjoy!
If you want to reverse this, you will have to restore a nandroid backup, as CWM formats EXT4 with journalism, and a format is required to reset it. On the same note, you will have to reapply this tweak every time you restore a nandroid backup, just something to keep in mind.
Tweak no.4: Supercharge, and apply Loopy smoothness!
I am sure everyone knows about the ubiquitous v6 supercharger script out there, and it provides a big performane increase! Also, Loopy smoothness helps a lot in stabilizing launcher performance, and I view them to be equally valuable.
1. Visit here to download the latest supercharger script, and here to download T2 of loopy smoothness.
2. Launch the supercharger from the /sdcard/download directory, go throught the basic instructions, and the custoomize, reboot, and install nitro lag nullifier. Optionally install for easier access. I would also explore some of the other options especially reindexing.
3. move the loopy smoothness script into the init.d directory, open it, and remove the comments around the launcher name if you are using the touchwiz launcher, or delete comments and name and add your launcher's process name (run ps in terminal emulator and find the most likely name, or look it up).
That's it! you should notice a definite performance increase, especially improvements in multitasking thanks to v6 supercharger. The launcher should also be a lot smoother.
Bonus (I have it in R5 rom, but have not actually applied it)
head here, download the latest script, and run it. It should add some extra build.prop tweaks that will greatly boost performance!
Some final suggestions:
1. Move to a custom launcher.
Using touchwiz, I always had about 125+- ram free after using a taskiller, but when I moved to go launcher EX (imho, the best launcher for the gplayer out there, beautiful, not hard on resources, and very customizable), I had over 160+ free after using a taskiller, which resulted in far smoother operation, and excellent multitasking!
2. use ondemand or ondemandx.
All the Gplayer profiles are good, but ondemand, although not the best at power saving, provides the best performance on our aging system, and gives a little extra juice when you need it.
3. use the deadline governor.
None of the other I/O governors come even close to NOOP and Deadline, but deadline is better for everyday use, and noop is better if you have several file transfers occurring at once (eg. hooked up to a computer, updating apps, and browsing the web). It comes down to your usage style, but I prefer Deadline.
4. Disable uneeded /system/app apps.
Fortunately our Gplayer is pretty bloat free, but you can disable more apps if you want. You should rename them to .apk1 instead of deleting them, just in case. Do not delete phone.apk, because for some reason it breaks the default camera app ( you can delete it if you don't use it).
Open up a terminal, run the ps command, and disable any system, apps you recognise in the list (una, fota, etc.).
That's it! I will certainly add on as time progresses, but at the moment that is all I can remember/know about, so be sure to pm me with potential tweaks so I can put it up here!
Click to expand...
Click to collapse
Very nice thread! I'll try it once my device finishes charging. How did you manage to get 1.5 OC?
Thanks! you can tell I am more than a little OCD about my device's performance
I was able to achieve a stable OC by setting the internal voltage to 1.19V, and my core voltage to 1.4V, using Tegrak Overclock. This gives a nice increase to the performance of my player!
hanthesolo said:
Thanks! you can tell I am more than a little OCD about my device's performance
I was able to achieve a stable OC by setting the internal voltage to 1.19V, and my core voltage to 1.4V, using Tegrak Overclock. This gives a nice increase to the performance of my player!
Click to expand...
Click to collapse
I'm not really familiar with OC at all but you just change the voltage and the 1.5 OC option will appear? Didin't you modify your kernel a bit to do this?
As I said in the OP, I have the Terrasilent kernel installed, which allows by default overclocking up to 1.2 GHZ. If you install Tegrak Overclock Ultimate, you can load it's module and overclock up to 2 GHZ with a max internal voltage of 1250mv, and a max core voltage ov 1400MV. Suprisingly easy, actually, and an invaluable tool. You can also change the I/O governor like I suggested from it as well. Attached is A screenshot of my quadrant score (I decided to do it anyway). The score is slightly lower than I said because I have Journalling disabled (to much of a hassle to keep restoring every day).
hanthesolo said:
As I said in the OP, I have the Terrasilent kernel installed, which allows by default overclocking up to 1.2 GHZ. If you install Tegrak Overclock Ultimate, you can load it's module and overclock up to 2 GHZ with a max internal voltage of 1250mv, and a max core voltage ov 1400MV. Suprisingly easy, actually, and an invaluable tool. You can also change the I/O governor like I suggested from it as well. Attached is A screenshot of my quadrant score (I decided to do it anyway). The score is slightly lower than I said because I have Journalling disabled (to much of a hassle to keep restoring every day).
Click to expand...
Click to collapse
Oh ok you have tegrak ultimate. I had tegrak free and the limit was 1.3. Also for the journaling why don't you make a script to execute it at each boot?
Yeah, You can do some crazy stuff in the ultimate version!
I will upload the screenshot in the OP, the way I did it wouldn't work the first time
I didn't make journalism a init.d script because it is a one-time tweak, you apply it, and you have to reformat to go back! I also didn't spell out the instructions verbatim in case someone wants to selectively apply this tweak or use it as reference.
zaclimon said:
Oh ok you have tegrak ultimate. I had tegrak free and the limit was 1.3. Also for the journaling why don't you make a script to execute it at each boot?
Click to expand...
Click to collapse
Also, I have triesd to make an init.d script to disable journaling and putting tune2fs in /system/xbin, but it errors out because you can only disable journaling when the partitions aren't mounted. So what I did was copy tune2fs to a directory, boot into recovery, unmount all the partitions and then disable journaling.
Surprisingly my quadrant score jumped by 400 points.
Sent using Tapatalk
klin1344 said:
Also, I have triesd to make an init.d script to disable journaling and putting tune2fs in /system/xbin, but it errors out because you can only disable journaling when the partitions aren't mounted. So what I did was copy tune2fs to a directory, boot into recovery, unmount all the partitions and then disable journaling.
Surprisingly my quadrant score jumped by 400 points.
Sent using Tapatalk
Click to expand...
Click to collapse
I was able to do it (albeit with warnings during e2fsck) using merely the terminal emulator, and after fixing permissions on tune2fs (I manually placed it). I checked it with tune2fs -l /dev/block/(partition) | grep features, and it claimed that I removed the has_journalism flag. Plus, I got the wonderful benefit of corruption after an unclean shutdown.
Is Rom compatibile with SGP 5.0(International) if not can you please pm me some advice about how to port it on SGP 5.0 ?
Unfortunately, This rom is based soly on the SGP 4.0, and would be very difficult to port onto the 5.0. I am currently working on a flashable zip file that contains most of these tweaks, so you won't have to use the rom.
Ok thanks mate , i try two tweaks and its amazing....its awesome feeling when onecore processor 1.5Ghz defeat dualcore Tegra 2
Which two did you try?
what score did you get?
It DOES feel pretty awesome to see quadrant shoot up past a tegra device
Sneak preview: me and Klin are working together on his next version of his rom, and it will have all of these tweaks, plus some extras (read: ext4 sdcard)!
One thing I am not certain about with the adreneline shot; do I need to manually delete my init.d scripts, or will flashing this delete them?
Sent using Tapatalk
The scipt will delete them for you when you flash, but it shouldn't cause any issues if they are not deleted. If some conflict, it may reduce the overall performance boost, but that's the worst that could happen.
hanthesolo said:
Which two did you try?
what score did you get?
It DOES feel pretty awesome to see quadrant shoot up past a tegra device
Sneak preview: me and Klin are working together on his next version of his rom, and it will have all of these tweaks, plus some extras (read: ext4 sdcard)!
Click to expand...
Click to collapse
I try Ext4 and Adrenaline and i get 2612 points I enjoy for flashable pack of tweaks Nice work mate and good luck with all your projects PS sorry for my bad english
Glad it works! I am almost done testing ext4 sdcard, and I will have the steps up here soon. Additionally, Klin will release an update to his ROM with my tweaks includded in the next couple of days, along with more than one new goody
I don't get how you get such a high io score! My io is around 800!? I installed the adreneline tweak, but nothing noticeable, perhaps even worse performance. I have ext4 (I think, since I installed klin's r5). I use deadline scheduler. I also use v6 supercharger. What are you people's quadrant score with just the adrenaline and supercharger? No overclock.
Sent using Tapatalk
Klin's R5 only formats /system as ext4. to get the full benefit (and the noticeable increase), do it on all partitions using the guide on the OP. I would also use noop, as it seems to be slightly faster than deadline on ext4. Once you do that, you should get the increase.
Well, I just tried to convert to ext4 following your instructions, but following the reboot, it has been on the solid "samsung" (not the pulsing one) screen for several minutes, is this normal, or did something bad happen?
Brickbug Aftermath: Speeding up the Galaxy S2 i9100, S2 AT&T i777, S2 Epic 4G Touch d710 and Note n7000
UPDATE: KERNELS CAN TRIM FAT PARTITIONS
contrary to what has been said in this thread and elsewhere, the S2 TRIM kernels could always trim FAT partitions. the problem is that the FAT file system implementation does not support batch trimming (ie: fstrim), but the fact that the DISCARD mount option has always been supported on FAT has eluded us all. the mainline commit that introduced the option is here, and the corresponding code in CM's repo is here.
this means that it would probably be a good idea to add DISCARD to the default mount options of the internal sdcard in CM. deleting files from internal storage would probably become slower, but the expectation would be that overall performance should increase. the performance issues related to queue flushing that plague non-queued TRIM commands should not be a big problem in this case, since the sdcard is used mostly for media (few big files without multitasking access).
UPDATE: VICTORY !!!
2016-03-02: after two years of tests and discussions, folklore, FUD and evidence, @Lysergic Acid finally took the plunge and merged! TRIM is now part of the official CM 12.1 and CM 13.0 kernels, and this project can at last be retired, yoohoo!!! CM 13 users now enjoy TRIM out of the box, but users of CM 12.1 builds older than Match 2016 as well as CM 11.0 users continue to require a separate TRIM kernel.
this thread is dedicated to Entropy and the brave users who risked their devices to run the very first TRIM tests.
IMPORTANT NOTE FOR USERS
i am tried of lazy users sending private messages to me instead of reading the thread. i am especially tired of users asking over and over on PMs whether TRIM is safe. if you read the threads you would know: TRIM is completely safe on every supported device, stop asking! and please, never PM technical questions to anyone on XDA unless you already know the guy.
DOWNLOAD FROM -> HERE
IMPORTANT NOTE FOR KERNEL DEVELOPERS ONLY
you should not blindly merge these changes into your kernel. doing so can result in unrecoverable bricks!!! you need to check that certain patches are already merged in your kernel before enabling TRIM. please follow these steps; you can get help from this post. please contact me when in doubt, let's not revive the slumbering brickbug monster from hell, thank you!
UPDATE: CM 13.0 kernels are now available!!! (for CM 13.0-supported platforms only: i9100 and i777.)
UPDATE: several enhancements in new kernel batch:
CM 12.1 kernels are now available!!! (for CM 12.1-supported platforms only: i9100 and i777.)
kernels can now be flashed with the official, restricted cyanogen recovery that is bundled with CM 12.1.
rom-independent kernels: kernels are no longer dependent one-to-one on specific official CM builds (they might work with other roms too), and their names no longer reference a specific CM build.
although there are no official CM 11 builds for the i777, thanks to rom independence CM 11-based kernels for that device are now available.
CM 11 i9100-to-i777 cross-flash kernels for the i777 may now work with other i9100 roms besides official CM.
UPDATE: Dic 25, 2014: a holiday present!!! as kernel maintainers swiftly acted to patch PFBug, @Gustavo_s took the plunge and merged TRIM support in his latest kernel. i have verified that his kernel is as safe as mine regarding TRIM. finally a more mainstream kernel is getting this functionality, hopefully i will be able to discontinue my kernels soon!
UPDATE: great news, we have fixed FPBug!!! fixed TRIM kernels are online!
UPDATE: this project now supports all roms and kernels!
if you are not running CyanogenMod M snapshots, please see this post.
this project restores TRIM capability to CyanogenMod kernels for the Galaxy S2 family of 4210-based devices: i9100, i777, d710 and n7000. TRIM is needed to avoid "aging" of the state of the eMMC, the internal flash storage, that eventually slows the device to a crawl. TRIM functionality is built into android 4.3 and later. however, due to historical and safety concerns, TRIM capability was removed from the CM kernels for these devices (and from most if not all other AOSP-based kernels).
an in-depth discussion of this matter, including safety, risks and current state of the kernels for various devices, can be found in the main project thread. you can review that content if you are curious. get the source for this project: patches and patcher script are here (git) and base system here (repo). for instructions on how to recreate my kernels from source, see this post.
STATS: Nov 5: 500+ kernel downloads (latest version only).
Oct 1: 250+ kernel downloads (then-latest version only), top 5th thread in its forum (ThreadRank).
PROJECT STATUS: testing still needed on MAG2GA TRIM bug-affected devices before TRIM patches go mainstream. IMHO, TRIM patches are ready to be merged into mainstream kernels. kernel maintainers please read the warning at the very top of this post!
UPDATE: kernel wifi issues fixed! thanks to invaluable help from @mparus. also, ART works just fine.
What to expect
some users see big changes while others do not. there are many different eMMC models with different firmware versions embedded in these devices, and it is clear that some are faster than others. it is even possible that some eMMCs may have firmwares that completely ignore trim commands. following are some benchmarks and comments submitted by users.
@defecat0r run before-and-after benchmarks and packed it all in this neat graph (thanks so much!):
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
@defecat0r also says: "I've been dicking around copying stuff back and forward, factory resetting and restoring cwm recoveries while on this kernel for a day now, if this fix was going to trigger superbrick i'm sure it would have done it by now. As far as i'm concerned this is safe as houses. [...] This is the biggest thing to happen to these devices since i don't know when!" (post)
@smoke2tun got better results: "My phone is blazing fast". he says: "The phone is really snappy and responsive. [...] After runing Antutu v5.1 the overall score is 17816. On NeatRom the score had an average of 11000." (post)
@Roxxors: "My phone had become so unbearably slow I was about to toss it in the garbage, [...] I'm coming from NeatROM 4.1.2, and let me tell you something, after installing C11 M9 with this kernel, my phone is FLYING." (post)
@|Vyp|: "Nice work, the device is flying now." (post)
@bihslk: "OMG! Installed CM11 M10 and your TRIM. Phone is flying now,,, WoW" (post)
@burninghouse: "i installed it and i can say only one word....."AWESOME"... My s2 is blazingly fast with same battery life" (post)
@dirtyhewr: "Omg... I don't think my device has ever been this fast... No lags at all" (post)
@Dudebowski: "[...] the increase in write ops nearly doubled! Regardless of the numbers for proof, this trim along with the floater fix [ed. note: FPBug] has made this device enjoyable to use again for the first time in years. The change in responsiveness after trim is night and day." (post)
thank you so much for the feedback and benchmarks guys!!
When things do not work
then again, some users do not get big improvements. check out the case of @desvariando.
speculation about these cases can be made. TRIM failing to provide advantages can be attributed to one of two causes:
when the fstrim command is run on some devices, it reports success but runs in zero time instead of taking the usual couple of seconds it takes on most devices. it looks like samsung disabled ERASE/TRIM support in some eMMCs, as a stopgap measure while they researched the issue further and before they output a final fix. if your eMMC trims in zero time, there is probably no realistic way to ever trim it. once your device gets slow, it can never be rejuvenated. if you fall under this group, and you have not yet ever filled the device's internal memory and your device still performs well, i would reduce the internal sdcard partition in size asap and leave a healthy sized area of 2GB inaccessible. this overprovisions the eMMC and ensures that it will never ran out of untrimmed space (assuming that the disk area you are leaving out is in fact still trimmed from factory). UPDATE: so now i know of a way to trim these untrimmable devices. it is extremely dangerous though (unless you have JTAG access to the eMMC). these eMMCs have a command to resize their boot partitions (boot0/boot1). these partitions are treated differently from all others by these modules. you can think of them as separate, safe, small, virtual disks; even if you write all over the main disk, you will never touch these partitions. also, wear leveling on the main disk will never move data around on these partitions. contrary to data on the main disk, once you write something here, it stays written forever (until you write something else). because they are treated differently, the eMMC needs to know their size. for versatility there is a non-standard command that will resize these partitions, and as a side effect it will repurpose the rest of the flash as the "main disk", creating all of its FTL structures from scratch. this full, low-level reformatting will fix a brickbug-damaged eMMC and will also trim an untrimmable device. the trick is to resize the boot partitions to some strange value, then resize them back to original size. all data everywhere will be lost, including the bootloaders, and this is why it is so dangerous. these phones will brick unless there are proper bootloaders and friends in place (though with JTAG access you could restore all this data). so the procedure would go like this: boot into recovery, make backups of all partitions you care about (bootloaders, EFS, etc), resize boot0/boot1, resize them back, and restore the needed partitions. but if anything goes wrong before you finish... you have a brick! because it is so dangerous, AFAIK this procedure has never been attempted to fix a brickbugged S2, much less to just trim one. but it has been carried on successfully on devices that boot from alternative sources when their eMMC is wiped, check it out here.
your device still had a reasonable amount of trimmed space when you installed this kernel and trimmed, and was not in need of trim. this can happen if you never filled the device's internal memory throughout its entire lifetime, or if you trimmed your device recently without knowing it. you could have trimmed by using the stock 4.1.2 kernel (which is TRIM-capable) in two ways: by wiping data from android or recovery, or by using an app such as LagFix.
otherwise, your device should be more responsive and use less battery after trimming. the need for trim is a well established reality that no FTL-based flash storage can escape.
STOP!!! DRAGONS AHEAD!!!
in theory there could be risk of hard-bricking your device forever. i believe this risk to be non-existent, based on reasons i detail in the aforementioned thread, and also based on recent experience: many people are already using these kernels without any kind of incident. however, the standard disclaimer applies: you accept full responsibility for what happens to your device.
READ and FOLLOW the instructions carefully.
Downloads
for the supported devices, you will find IsoRec-compatible CyanogenMod-based kernels here. (old kernels without IsoRec support can be found here. yet older retired kernels without FPBug fix are still available here.) note that for some supported devices, no releases or M snapshots are currently being produced. for those devices i can produce kernels based on known 'stable' nightlies if users ask.
A word about CyanogenMod 10.1.3
UPDATE: great news, we have fixed FPBug!!!
there are no CM stable releases for 4210-based devices after CM 10.1.3. the sad truth is that the kernel for these devices is broken. this affects all roms, not just CM. there seems to be some unidentified defect in the hardware itself, and no workaround for it has been implemented in the kernel so far (if such a thing is even possible). after years, @cgx finally observed the bug in action and now we at least know what we are up against. it is nasty as hell: random stack corruption. in layman's terms, any process can randomly misbehave, crash, be corrupted, corrupt data, etc... all bets are off, anything could happen. and it looks like this might never be fixed.
for whatever reason this was not much of a problem in the CM 10.1.3 days. these days, with a much more advanced and demanding android, the bug is real trouble. most people find that the last reliable CM version for their 4210-based device is 10.1.3 (including the CM team itself). i made kernels for this version, find them in the downloads section.
NOTE: the CM 10.1.3 kernels are untested. do take a nandroid! and please post your results.
Instructions
prerequisites: you need to already be running a fully official version of CyanogenMod supported by this project. (i mean fully official: dual booters, alternative kernel/recovery users, etc are not invited to this party.) you will replace your current official CM kernel with the patched, EXACT SAME VERSION kernel from this project.
download this app and run it to check if your device is affected by hardware bugs. root is requested but not needed for this test. do not trust the app's verdict! instead use the reported eMMC model name and the firmware revision (fwrev) to look up your eMMC in this table.
is your eMMC model an MAG2GA? if so you are affected by TRIM bug. WARNING: this configuration is untested. my kernels should be safe but they have never been tested on this particular eMMC, so risk cannot be completely ruled out. please read this post and decide whether you would like to test. testers are needed! i believe this is the last remaining piece of evidence needed to establish the general safety of trim on this family of devices and start pushing for its inclusion in the standard kernels, which is the ultimate objective of this project. UPDATE: things are looking much better, see this post. testing is still needed though, please help. UPDATE: MAG2GA eMMCs with fwrev 0x0E can be found in d710 devices and were tested to TRIM without problems. i personally believe this configuration to be safe.
are you affected by WL Bug? impossible. according to the available data, no 4210-based device has ever been produced with this eMMC... SO YOU MUST BE MISTAKING. please double check your situation; then post. (in any case, this bug is supposed to involve data corruption only, and not bricking.)
are you affected by Brickbug? my kernels contain samsung's fix for this bug, but samsung's fix was never exercised in practice with TRIM. i will accept ONE volunteer to test. i do not want more than one device to brick if the test fails. know that testing can potentially brick your device beyond repair. i would prefer someone with a compromised S2 (eg: lost IMEI, cracked screen) to do the first test. please post your willingness to test on this thread (include eMMC and fwrev). UPDATE: many people affected by this bug are already using my kernels without incidents. i personally believe this configuration to be safe.
if you are not affected by the previous bugs, you run no special risks by flashing my kernels.
you should start on a supported official CyanogenMod; if you are not already running it, flash it now and test it.
optional: as an extra safety step, back up your EFS and store it OUTSIDE your phone. you should have done this years ago! you never know when you might need that backup.
optional: preferably no apps should be moved to the internal sd card (check 'apps' in settings). this could slow the device a bit, but is no problem otherwise. note that apps moved to the EXTERNAL sdcard can cause BIG SLOWDOWNS.
optional: make sure you have 20% (or at the very least 10%) free space in your internal 2GB /data partition (where apps are normally installed). you will not notice speed improvements unless/until you have free space in /data.
optional: if you have been on official CM (including kernel) for a long time, and this is the first time you are going to trim your device, please contribute benchmarks. install Androbench and run all benchmarks, it takes just a few seconds. in the history section you can see most if not all results in a single screen; please take a snapshot for your before-and-after comparison.
make a nandroid backup. if you need to back out of the change for whatever reason, you will be happy to have it.
download the appropriate kernel for your CM build (includes CWM-based recovery). flash it without wiping. (at any time you can reflash official CM without wiping or upgrade to a newer CM -loosing TRIM support, of course.)
reboot.
install the LagFix (free) app from xda (the market version is declared to be incompatible with the i9100). go to the lagfix tab, check the 3 partitions, and tap on run. grant root access. the 3 fstrim operations should be successful ("partition was trimmed" means success).
UPDATE: there is a replacement app for LagFix called Trimmer that has several advantages over the former: is fully free, can schedule TRIMs, and is compatible with Android 5.
alternatively, instead of using lagfix you can run one of these commands (these are better because they also trim /preload):
# on the phone in the terminal app:
su -c "fstrim -v /system; fstrim -v /data; fstrim -v /cache; fstrim -v /preload"
# on your PC if you are connected to the phone via adb:
adb shell su -c "fstrim -v /system; fstrim -v /data; fstrim -v /cache; fstrim -v /preload"
reboot.
optional: contribute benchmarks if you qualify. run Androbench again to take an 'after' snapshot and share your before-and-after shots below.
your device should now run FAST... profit!
Please donate hardware to test
i do not have any of the supported devices to test, i am developing blind. i would gladly accept an i9100 with a cracked screen as a test bed if you can send it to an address in USA or Argentina (or any other supported device).
But wait, there's more...
Automatic trimming
android 4.3 and later should trim all writable file systems each night during charging automatically (/cache, /efs, /data and /preload). you do not need to invoke fstrim or lagfix manually again. if you want to be extra tidy you can invoke lagfix after each flash of a CM upgrade to trim /system (which is normally read-only).
because of this offline auto trimming, android 4.3 and later should not mount partitions with the discard mount option (which implements online trimming whenever space is freed), but CM does anyway. this is a bug that slows down the device and i have uploaded a patch to CM's gerrit. my kernels fix this as of Sep 14 2014.
if you use CM 10.1.3 (android 4.2.2), you might be thinking that you need to regularly trim the file systems yourself (you could use scripts or lagfix premium for automation). but as of Sep 14 2014 my kernels mount /cache, /data and /preload with the discard option, meaning that freed space on these partitions is immediately trimmed (which, again, slows down the device compared to offline trimming but is better than no trimming at all). so you only need to invoke lagfix after each flash of a CM upgrade to trim /system if you want to obsess about it. (the /efs partition is not mounted with discard; call me superstitious.) btw, i made the /preload partition writable (it is normally read-only in CM 10.1.3) so you can trim it and/or use it for whatever purpose you want. i could create 10.1.3 kernels without the discard mount option for those who wish to roll their own periodic trim feature; just ask.
The internal sdcard partition
the majority of the phone's flash is devoted to the internal sdcard partition which is formatted in a vesion of FAT. unfortunately the linux kernel file system driver for FAT is unable to trim its free space. some people format this partition to ext4 for performance and safety reasons (google). if you do that, you can fstrim it.
The preload partition
these devices have 0.5 GB ext4 /preload partition (also called "hidden"). in CyanogenMod it is unused and should be empty (you can check with the file manager). you can manually fstrim this partition (open a terminal on the phone and type: su -c "fstrim -v /preload" or from the PC via adb: adb shell su -c "fstrim -v /preload") or format it from my recovery to increase the trimmed free space in your eMMC, effectively increasing its over-provisioning by 0.5 GB. this makes the eMMC faster and extends its useful life.
UPDATE: i have removed the trim-on-format functionality (partition wiping) from the kernel patches, and thus all future kernels. there are no safety concerns with the previous kernels, but there can be problems if someone uses my patches to build a complete ROM (as opposed to just a kernel, as i have been doing). please refer to the commit for details. [Oct 3]
Adjusting partition sizes
you can repartition your phone to better distribute available flash space. i recommend vestigial /preload (unless you want to go back to stock roms later), 1 GB /system (the original 0.5 GB /system is too small for android 4.4 and gapps; 0.75 GB is enough, but the Nexus 5 comes with 1 GB, so i guess google expects it to keep growing), 6 GB /data (of which you should always keep 2 or 1 GB free to provide the eMMC with trimmable free space -remember the FAT partition does not trim), and the rest (about 8 GB) used for the internal sdcard. you can format the internal sdcard as some FAT or as ext4. (but windows does not understand ext4, but there is MTP... google!)
you can use ODIN (windows-only) or heimdall to repartition. @Roxxors contributed a nice partitioning how-to that you should read. note that he embedded my M9 kernel in his ODIN files. to create a file with the right kernel for your needs, read this.
here are some PIT files (these files are for the i9100 16 GB only, but you can use PIT Magic to roll your own):
0.5 GB system
0.75 GB system
1 GB system, 3/4/6 GB data
1 GB system, 8 GB data
1 GB system, 4 GB data, small preload
1 GB system, 6 GB data, small preload <-- this PIT is buggy!
(see attached file for a replacement i made; includes a script to repartition from linux using heimdall.)
in general, 2 GB, or even 1, of trimmable free space (ie: free space in the /data partition) will probably be more than enough to speed up your device, with rapidly diminishing gains over that.
UPDATE: due to a bug in CM, the recovery is unable to format the /preload partition. formatting is needed after repartitioning. to manually format, open a terminal on the phone and type: su -c "mkfs.ext2 /dev/block/platform/dw_mmc/by-name/HIDDEN" or from the PC via adb: adb shell su -c "mkfs.ext2 /dev/block/platform/dw_mmc/by-name/HIDDEN" (you can also use other commands such as mke2fs and mkfs.ext2.)
PLEASE NOTE: this is not a partitioning thread!!! please DO NOT seek partitioning help in this thread. please post in an appropriate thread instead. this thread is for KERNEL ISSUES ONLY. thank you!
XDA:DevDB Information
BrickbugAftermath-i9100, Kernel for the Samsung Galaxy S II
Contributors
Lanchon
Source Code: https://github.com/Lanchon/BrickbugAftermath-SGS2
Kernel Special Features: CyanogenMod kernel with TRIM support
Version Information
Status: Stable
Created 2014-08-10
Last Updated 2016-04-17
TRIM On Other Roms And Kernels
TRIM on custom roms
when running any non-trim enabled kernel, significant speed benefits can be obtained by overprovisioning the eMMC. as long as a portion of the eMMC is in the erased state (trimmed) it will perform well, even if the kernel is not able to trim. this can be seen for example when the device is new: non-trim kernel and still the device runs nicely. as time goes on, normal usage causes the eMMC to be written all over, reducing the amount of trimmed space to zero and killing performance. this situation can be avoided in two ways: 1) by using a trim-enabled kernel that will trim space once it is no longer used by files, or 2) by setting aside an area of the eMMC and never write to it, effectively keeping it in the erased state. this second option is called overprovisioning in SSD parlance.
those of you wanting to run official CM kernels, CM nightlies, or other custom roms altogether can still obtain most of the benefits of a trim-enabled kernel without one by overprovisioning your eMMC. the stock partitioning of the 4210-based devices includes an 0.5 GB /preload partition that is just perfect for the job.
Requirements:
you have not repartitioned your device and shrank the /preload partition to enlarge other partitions.
your custom rom does not use the /preload partition. (CM does not, and I do not know of any that does... but google!)
you are not using dual-boot or other mods that use the /preload partition.
NOTE: if you have shrunk /preload and enlarged /system to 1 GB you can still follow these steps to overprovision using the free space in /system, but you will need to redo them every time you flash a new rom. otherwise, if you have an 0.5 GB /preload, you can do these steps once and just forget about the whole thing (until you flash something to the /preload partition, that is).
Instructions:
NOTE: please read step 9 now and decide if you want to use a root file manager to delete everything in /preload before you start or if you want to try to format the partition with your current recovery.
READ THIS POST IN FULL. find out which bugs your eMMC has if any, and decide whether to run the risk of trimming.
download to your device the newest trim-enabled kernel for your particular device from here.
download to your device a recovery-flashable copy of the kernel that you are currently using. (or else make a nandroid backup in step 6.)
if you want, download to your device the recovery trimmer script attached to this post. (see step 11 for more information.)
reboot to recovery.
make a nandroid backup if you do not have a flashable copy of your current kernel on your device. (make sure your nandroid is compatible with CWM-based recoveries.)
flash the trim-enabled kernel.
in the advanced section, choose reboot recovery. now you are temporarily running a trim-enabled kernel.
in the mounts and storage section, choose format /preload. (make a nandroid backup first if unsure of its contents.)
NOTE: it has been reported that format /preload does not work. this is a bug in CM's recovery. you may want to adb shell to the device to delete all files and folders under /preload, including those hidden. free space in this partition will remain trimmed when you later use the phone so it is important that most of the partition be empty after this step. (bug report)
still in the mounts and storage section, mount (if necessary) the following partitions: /system, /cache, /data and /preload.
choose one of these two options:
attach your device via USB to your PC, open a terminal, and type adb devices to verify that your device is reachable and authorized. (if it is not, under linux type adb kill-server; sudo adb devices to troubleshoot the issue; under windows try restarting the adb server from an administrator console.) in the terminal type adb shell "fstrim -v /system; fstrim -v /data; fstrim -v /cache; fstrim -v /preload" to trim. for each partition, fstrim should output a message stating the number of bytes trimmed; this indicates success.
flash the attached recovery trimmer script. you will not have any indication of success using this method. (make sure you have mounted the applicable partitions in the previous step!)
flash your old kernel back or, equivalently, restore your nandroid. (you can advance-restore only the boot partition if you want.)
reboot and profit.
TRIM on rooted stock android 4.1.2
this is beyond the scope of this project, but still some people may be interested.
Instructions:
make sure you are rooted.
WARNING: MAKE SURE YOU ARE RUNNING STOCK ANDROID VERSION 4.1.2 (THE RELEASE, NOT A LEAKED VERSION) OR YOU WILL DESTROY YOUR DEVICE DUE TO BRICKBUG!!!
READ THIS POST IN FULL. find out which bugs your eMMC has if any, and decide whether to run the risk of trimming.
WARNING: MAKE SURE YOUR EMMC IS NOT AFFECTED BY TRIM BUG OR YOU WILL DESTROY YOUR DEVICE!!! if you have trim bug, you must not trim on a stock kernel, end of story.
also, it is assumed that release (not a leak) 4.1.2 stock kernel contains this patch and thus is brickbug safe. but there might be different versions, and there is no way to be sure if the corresponding source code was patched by samsung, so...
WARNING: IF YOUR EMMC IS AFFECTED BY BRICKBUG, THE POSSIBILITY HARD BRICKING YOUR DEVICE CANNOT BE COMPLETELY RULED OUT without access to the kernel source code. proceed at your own peril, or better yet, switch to a custom rom/kernel.
install the LagFix (free) app from xda (the market version is declared to be incompatible with some 4210-based devices). go to the LagFix tab, check the 3 partitions, and tap on run. grant root access. the 3 fstrim operations should be successful ("partition was trimmed" means success). alternatively, those with busybox installed can try issuing the fstrim commands themselves. in particular, you must do this to trim /preload. you can also look for the fstrim command in the private files of LagFix.
UPDATE: there is a replacement app for LagFix called Trimmer that has several advantages over the former: is fully free, can schedule TRIMs, and is compatible with Android 5.
reboot and profit.
NOTE: i assume there is little free space in /system and /preload in stock roms, so most benefits will come from trimmed free space in /data. this space will get overwritten in time so you will need to periodically trim.
Recreating My Kernels From Source
i have been wrongly accused of not providing full source code to my kernels. to counter this accusation i am providing step-by-step instructions on how to exactly recreate any of the kernels published in this project from source. to start, all you need to know is the filename of the kernel you want to recreate. then simply follow these steps:
identify and obtain the CM release that corresponds to the kernel based on the kernel filename. example:
kernel: kernel-cm-11-20140915-NIGHTLY-Lanchon-TRIM-20140916-n7000.zip
CM release: cm-11-20140915-NIGHTLY-n7000.zipnote that nightly releases are not kept for long in CM's download servers. that is why i mirror all relevant nightlies right beside my kernels in the downloads section.
extract the build manifest (/system/etc/build-manifest.xml) from the CM release zip file.
using the manifest, checkout the source code corresponding to the release to ~/android/system by following these instructions.
identify the version of the patches that corresponds to the kernel based on the kernel filename. example:
kernel: kernel-cm-11-20140915-NIGHTLY-Lanchon-TRIM-20140916-n7000.zip
branch: cm-11
date: 20140916
tag to match: cm-11-20140916
identify the corresponding tag in my github repo and checkout its tree to ~/android/brickbug/BrickbugAftermath-SGS2. if no tag matches exactly, use the tag in the same branch that sports the closest earlier date.
run ~/android/brickbug/BrickbugAftermath-SGS2/scripts/repo-patch apply to apply the patches.
(repo-patch apply functionality used to be provided by standalone script apply in old versions.)
build the kernel using these instructions.
finally, you can run ~/android/brickbug/BrickbugAftermath-SGS2/scripts/repo-patch reset to unpatch your source tree.
(repo-patch reset functionality used to be provided by standalone script reset in old versions.)
Sh*t...
erdal67 said:
Sh*t...
Click to expand...
Click to collapse
lol brickbug
well someone will have to the guts to try. if you read the main thread (very long), i argue that it is probably safe to run my build in your phone... but then, there's only one way to know for sure
erdal67 said:
Sh*t...
Click to expand...
Click to collapse
Got the same Revision (19) according to the cm table this Rom could! But not must brick our device?
empulse92 said:
Got the same Revision (19) according to the cm table this Rom could! But not must brick our device?
Click to expand...
Click to collapse
i'm sorry you are affected. i personally think it would not brick (for reasons explained in the main thread, you are invited to chip in).
but i could brick! there's risk.
we will never know until somebody tests...
Lanchon said:
i'm sorry you are affected. i personally think it would not brick (for reasons explained in the main thread, you are invited to chip in).
but i could brick! there's risk.
we will never know until somebody tests...
Click to expand...
Click to collapse
I think i may give it a try... Unsure if i should usw another pit? Got 2gb (stock) for now you suggestet to use 4or 6 GB? I got some Mainboards hat home with destroyed imei chips, seems to be good testers if the chip is the same :highfive:
Another question: is the fw Version of the chip upgradeable via Odin vor heimdall? Is it possible to acces the Software used by this chip?
empulse92 said:
I think i may give it a try... Unsure if i should usw another pit? Got 2gb (stock) for now you suggestet to use 4or 6 GB? I got some Mainboards hat home with destroyed imei chips, seems to be good testers if the chip is the same :highfive:
Click to expand...
Click to collapse
boards with lost IMEIs? that would be great to test!!! no big loss in the worse case.
don't bother with the PIT files. just follow the main instructions. this is to test if it TRIM works without bricking in those chips. if you later want to set up a phone for real use, you can try resizing the partitions (i would for my phone).
exactly the same chip! VYLOOM 0x19 :victory: (date differs , 06/2011 but i guess this wont make a big difference at least )
edit: bootin...:fingers-crossed:
edit 2: succesfully booted,
empulse92 said:
exactly the same chip! VYLOOM 0x19 :victory: (date differs , 06/2011 but i guess this wont make a big difference at least )
edit: bootin...:fingers-crossed:
edit 2: succesfully booted,
Click to expand...
Click to collapse
cool!! thanks!!!
and? did you use lagfix?
did u trim /sdcard?
Lanchon said:
cool!! thanks!!!
and? did you use lagfix?
did u trim /sdcard?
Click to expand...
Click to collapse
i did dont know if there are errors if trim isnt supported or not but for now... see yourself
note : play store says lagfix app is incompatible with this device i got the app from xda
http://forum.xda-developers.com/showthread.php?t=2104326
Click to expand...
Click to collapse
empulse92 said:
i did dont know if there are errors if trim isnt supported or not but for now... see yourself
note : play store says lagfix app is incompatible with this device i got the app from xda
View attachment 2891398
Click to expand...
Click to collapse
thanks! yes i'll update the app link then. those trims were successful, and yes it shows errors when you try to trim and the kernel doesn't support it.
i guess now you should use that phone and see if it bricks... for now its looking like the chances of bricking are going way down.
could you do two more tests?
try to trim /sdcard (steps in my first post)
then enable ART (debugging menu) and and see if it boot loops or not.
thanks!
no error when trimming sdcard... should i wait some more before trying art?
empulse92 said:
no error when trimming sdcard... should i wait some more before trying art?
Click to expand...
Click to collapse
great! did the trim sdcard command took some time, like a second or two? or did it end absolutely immediately, like a no operation would?
no, everything checked ok, you can try ART. i think it should work. if it doesnt, wipe data from recovery (i think you are using an empty phone anyway, right?)
there was no delay after using the command.. just as you said, as if nothing happened. this is why i was wondering^^ but still not sure about this
yep the phone is empty, but i cant get into recovery or download mode .. time to set up adb
edit: device offline-.-'
edit 2: i am retarded and forgot to press the home button :')
edit 3: alrighty, now it boots but after wiping its still dalvik cache vm
empulse92 said:
there was no delay after using the command.. just as you said, as if nothing happened. this is why i was wondering^^
yep the phone is empty, but i cant get into recovery or download mode .. time to set up adb
edit: device offline-.-'
edit 2: i am retarded and forgot to press the home button :')
Click to expand...
Click to collapse
hmmm... i've read somewhere the android shell sends stderr to limbo. i just tried to fstrim /sys on my nexus and not a word, exits immediately. on my linux PC it says "fstrim: /sys: FITRIM ioctl failed: Inappropriate ioctl for device".
i'll look into this further. meanwhile, are u testing ART?
EDIT: i dont know why no error is printed. but on android, if you fstrim with -v option you get text if successful:
[email protected]:/ # fstrim -v /system
/system: 0 bytes trimmed
[email protected]:/ # fstrim -v /data
/data: 2399477760 bytes trimmed
[email protected]:/ # fstrim -v /sys
1|[email protected]:/ #
so if you do fstrim -v /sdcard and you get no output, then the kernel is unable to trim FAT32. if this is the case, it would pay to find a alternate solution to this in the long run.
enabling art forces bootloop, formatting data reverts back to dalvik :silly:
no chance to use art for now^^
edit: here's a logcat but i'm not sure if it shows a normal boot or the art bootloop
https://drive.google.com/file/d/0Bw86veXkn-fiZ2FnU3lqdkFuWVE/edit?usp=sharing
edit 2: another screenshot (dont be confused i didnt change the time zone yet)
empulse92 said:
enabling art forces bootloop, formatting data reverts back to dalvik :silly:
no chance to use art for now^^
edit: here's a logcat but i'm not sure if it shows a normal boot or the art bootloop
https://drive.google.com/file/d/0Bw86veXkn-fiZ2FnU3lqdkFuWVE/edit?usp=sharing
edit 2: another screenshot (dont be confused i didnt change the time zone yet)
View attachment 2891493
Click to expand...
Click to collapse
thanks!
assuming official M9 has working ART, there must be some trouble with my build setup. my OpenPDroid build has the same thing, it is not related to TRIM. oh well...
your screenshot clearly shows there is no TRIM support for FAT32
i will think of what to do next. in any case, if you turn off ART and flash this on your working phone (with 20%+ free space in your internal partition) you should notice a big improvement in responsiveness and diminished lags. (a friend told me "feels like a different phone", but maybe he is exaggerating.) i still warn against doing it! i would exercise the internal storage on this phone for a while, installing big apps then deleting them, flashing the rom a couple more times, and using LagFix to trim all partitions.
or you can make a backup of your current phone and restore it here, then lagfix, and see if the increased speed justifies the risk. its your call...
for now i have nothing else to ask you to test. thank you very much!!! you've been amazing help!!!
using this on my daily phone now :good:
empulse92 said:
using this on my daily phone now :good:
Click to expand...
Click to collapse
oops! are you sure??? i hope nothing bad happens...
after LagFix trimming and rebooting, how do you feel the phone in the way of responsiveness?