FORUMS

Galaxy S6 Weekly Shooting Challenge

Over in our forums this weekend, XDA Forum member DevonSloan has started a thread for talented … more

Which Features from Apple Watch Do You Think Android Wear Will Copy?

The Apple Watch and Android Wear are both growing platforms. Now … more

XDA Picks: Best Apps of the Week (May 15 – 22)

Apps are at the front and center of any smartphone experience, and with over a … more

Android 5.1 for the Nvidia Shield Tablet is Out!

Nvidia is quite good at delivering updates in a timely fashion. The producer of famous … more

 View Poll Results: so how's the party going? - I have a device supported by this project and it has...

Brickbug but i'm macho, i use your kernel anyway
 
95 Vote(s)
54.91%
Brickbug and i won't touch your crappy kernel
 
9 Vote(s)
5.20%
Wear Leveling bug but i'm using your kernel anyway
 
2 Vote(s)
1.16%
Wear Leveling bug and i'm a coward, i won't try it
 
3 Vote(s)
1.73%
MAG2GA TRIM bug but i'm using your kernel anyway
 
0 Vote(s)
0%
MAG2GA TRIM bug and your kernel can eat it
 
3 Vote(s)
1.73%
no eMMC bugs and i'm using your fabulous kernel
 
36 Vote(s)
20.81%
no eMMC bugs but i don't care about this trim crap
 
8 Vote(s)
4.62%
your OP is tl;dr, i just flashed the damn thing
 
10 Vote(s)
5.78%
you asswipe!! you bricked my phone!!!
 
7 Vote(s)
4.05%
Post Reply Subscribe to Thread Email Thread

[Kernel] TRIM: Speeding up the Galaxy S2 i9100

10th August 2014, 12:37 AM |#1  
OP Senior Member
Thanks Meter: 1,595
 
More
Brickbug Aftermath: Speeding up the Galaxy S2 i9100, S2 AT&T i777, S2 Epic 4G Touch d710 and Note n7000
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: 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!):



@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 /data partition in size 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).

  • 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 kernels for CyanogenMod releases and M snapshots with FPBug fix here. (old 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.
  1. 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.


  2. you should start on a supported official CyanogenMod; if you are not already running it, flash it now and test it.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

  7. make a nandroid backup. if you need to back out of the change for whatever reason, you will be happy to have it.

  8. 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.)

  9. reboot.

  10. 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).

    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"
  11. reboot.

  12. 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 (try opening a terminal and typing: su -c "fstrim -v /preload" or 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):
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.

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: Beta

Created 2014-08-10
Last Updated 2015-03-16
Attached Thumbnails
Click image for larger version

Name:	trim-1.png
Views:	7131
Size:	209.1 KB
ID:	2954067   Click image for larger version

Name:	trim-2a.png
Views:	7084
Size:	111.4 KB
ID:	2954068   Click image for larger version

Name:	trim-2b.png
Views:	7044
Size:	103.4 KB
ID:	2954069  
Attached Files
File Type: zip i9100-1GBsys-6GBdata-7.5GBsdcard-8MBpreload.zip - [Click for QR Code] (12.1 KB, 388 views)
Last edited by Lanchon; 17th January 2015 at 07:29 AM.
The Following 51 Users Say Thank You to Lanchon For This Useful Post: [ View ]
 
 
10th August 2014, 01:03 AM |#2  
OP Senior Member
Thanks Meter: 1,595
 
More
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.
  1. READ THIS POST IN FULL. find out which bugs your eMMC has if any, and decide whether to run the risk of trimming.
  2. download to your device the newest trim-enabled kernel for your particular device from here.
  3. 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.)
  4. if you want, download to your device the recovery trimmer script attached to this post. (see step 11 for more information.)
  5. reboot to recovery.
  6. 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.)
  7. flash the trim-enabled kernel.
  8. in the advanced section, choose reboot recovery. now you are temporarily running a trim-enabled kernel.
  9. 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)
  10. still in the mounts and storage section, mount (if necessary) the following partitions: /system, /cache, /data and /preload.
  11. choose one of these two options:
    1. 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.
    2. 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!)
  12. flash your old kernel back or, equivalently, restore your nandroid. (you can advance-restore only the boot partition if you want.)
  13. 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:
  1. make sure you are rooted.
  2. 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!!!
  3. 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.
  4. 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.
  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. the premium version of LagFix includes a scheduler that takes care of this. unfortunately LagFix is declared to be incompatible with some 4210-based devices and so you will not be able to purchase and download it. FYI, here is some information about the genuine LagFix premium apk version 1.5.1 on Android Observatory and AndroTotal, including hashes of the file. (i do not know about free space in /preload. maybe there is enough to overprovision but you need to manually trim it; LagFix will not do it.)


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:
  1. 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.zip
    note 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.

  2. extract the build manifest (/system/etc/build-manifest.xml) from the CM release zip file.

  3. using the manifest, checkout the source code corresponding to the release to ~/android/system by following these instructions.

  4. 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
  5. 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.

  6. 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.)

  7. build the kernel using these instructions.

  8. 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.)
Attached Files
File Type: zip lanchon-recovery-trimmer-20141105.zip - [Click for QR Code] (551.1 KB, 1023 views)
Last edited by Lanchon; 14th January 2015 at 04:11 PM.
The Following 12 Users Say Thank You to Lanchon For This Useful Post: [ View ]
10th August 2014, 02:30 AM |#3  
erdal67's Avatar
Senior Member
Flag Venlo
Thanks Meter: 267
 
More
Sh*t...
10th August 2014, 02:47 AM |#4  
OP Senior Member
Thanks Meter: 1,595
 
More
Quote:
Originally Posted by erdal67

Sh*t...

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
10th August 2014, 03:05 AM |#5  
empulse92's Avatar
Senior Member
Flag Berlin
Thanks Meter: 64
 
More
Quote:
Originally Posted by erdal67

Sh*t...

Got the same Revision (19) according to the cm table this Rom could! But not must brick our device?
10th August 2014, 03:21 AM |#6  
OP Senior Member
Thanks Meter: 1,595
 
More
Quote:
Originally Posted by empulse92

Got the same Revision (19) according to the cm table this Rom could! But not must brick our device?

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...
10th August 2014, 03:29 AM |#7  
empulse92's Avatar
Senior Member
Flag Berlin
Thanks Meter: 64
 
More
Quote:
Originally Posted by Lanchon

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...

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
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?
Last edited by empulse92; 10th August 2014 at 03:32 AM.
10th August 2014, 03:36 AM |#8  
OP Senior Member
Thanks Meter: 1,595
 
More
Quote:
Originally Posted by empulse92

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

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).
10th August 2014, 05:02 AM |#9  
empulse92's Avatar
Senior Member
Flag Berlin
Thanks Meter: 64
 
More
exactly the same chip! VYLOOM 0x19 (date differs , 06/2011 but i guess this wont make a big difference at least )

edit: bootin...
edit 2: succesfully booted,
Last edited by empulse92; 10th August 2014 at 05:30 AM.
The Following User Says Thank You to empulse92 For This Useful Post: [ View ]
10th August 2014, 05:52 AM |#10  
OP Senior Member
Thanks Meter: 1,595
 
More
Quote:
Originally Posted by empulse92

exactly the same chip! VYLOOM 0x19 (date differs , 06/2011 but i guess this wont make a big difference at least )

edit: bootin...
edit 2: succesfully booted,

cool!! thanks!!!

and? did you use lagfix?
did u trim /sdcard?
Post Reply Subscribe to Thread
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes