F2FS is a brand new file system developed by Samsung. The F2FS acronym stands for Flash Friendly File System. It creates an additional layer that improves the performance and life of the flash memory and the overall performance of any system with flash storage. Almost all the Android phones today still come with the old linux ext4 filesystem. This type of file system is not hardware optimized so it is a baseline for performance. There are plenty of benchmarks and tests throughout the web providing evidence of the overall performance improvement of F2FS over ext4 in Android phones. New flagship devices from Huawei, One Plus and many Motorola phones are now using F2FS as stock filesystem. The flagship Moto Z comes with F2FS, sporting a fabulous 1/10 of lag compared to the Pixel XL. However mind that it is a new technology with barely 3 years of development and you might encounter some issues if you try different configurations. But, we are here testing unofficial things, so risk is a known partner. Just keep a safe backup, that is all you need.
Migrating /system has no sense since it is a read only partition (most of the times) and ext4 is faster for pure readings. On the other hand /cache is formatted to ext4 at boot by the kernel. So patching the kernel is the only way to migrate that partition.
Data partition along with the internal storage can be upgraded to F2FS with visible results. Here I share a method to migrate your system without losing any information. The procedure is reversible, so you can return back to the traditional ext4 in case you are not satisfied with the result. The procedure only requires TWRP recovery 3.0.3 and an external sdcard with enough free space to do at least a backup of the data partition. Since we are not modifying boot or system, this procedure is compatible with unrooted systems with locked bootloaders. It is compatible with all the AXON 7 ROMs.
INSTALLATION
1. Reboot to TWRP and perform a backup of your data partition to your external sd (you can't use internal storage since it will be wiped during the process along with the data partition).
2. Backing up your Internal SD card requires a different way. Here I propose 2 options:
2a. If you have an External SD card with enough free space (check that first), you can use it to temporary store the content of the internal sdcard. While in TWRP root menu, go to Advanced / File Manager and browse into the sdcard (You will see the contents of your internal storage). Tap on the checked folder icon on lower right corner. Select Copy Folder. Now browse into the external_sd folder (you will see the contents of yout external SD) and tap the checked folder icon again. Upon confirmation, it will create a folder named sdcard into the external sd with all the contents inside.
2b. If you do not have a micro SD card with enough space then you can use your computer as backup location. From your computer type adb pull /sdcard and all the content of the internal sdcard will be transferred into a folder named sdcard under you current directory in your computer.
3. Now we can safely change the format of the data filesystem. Go back to the root menu of TWRP, go to Wipe / Advanced Wipe and select only the Data partition. Go to Repair or Change File System / Change File System / F2FS. Upon confirmation, the Data and internal sdcard will use the improved F2FS filesystem. If you have an AOSP based ROM such as LOS, RR or AEX among others, then you can do the same to format the Cache partition as F2FS. But do not reboot yet!
4. Go back to the root menu of TWRP and go to Settings. Ensure "Use rm -rf instead of formatting" is set. This will avoid future restores to change the type of filesystem.
5. We can't restore the data at this time since the system won't boot properly with all kernels, the Stock kernel is one of them. At this point it is safer to reboot the system and wait until the Android welcome wizard shows up on the screen. This will setup everything internally.
6. Now reboot to TWRP, go to Advanced > Terminal and enter the commands (you can bypass these commands only if you are using TWRP 3.0.4 or above):
Code:
mount -o remount,discard,nosuid,nodev,noatime,nodiratime,nobarrier,inline_xattr,inline_data /data
mount -o remount,discard,nosuid,nodev,noatime,nodiratime,nobarrier,inline_xattr,inline_data /sdcard
and then without leaving TWRP restore the backup you created in step 1. This will restore your data partition but this time applying an optimized F2FS structure. Do not leave TWRP yet, there is one more step left before booting into the system.
7. depending on the option you used in step 2 you have to follow one of the following options to restore your internal sdcard:
7a. If you used your External SD card for the internal sdcard backup then while in TWRP root menu, go to Advanced / File Manager and browse into the external_sd/sdcard folder. Tap on the checked folder icon on lower right corner. Select Copy Folder. Now while the root directory is listed tap the checked folder icon again. Upon confirmation, it will restore all the backup into the external sdcard back into the Axon 7 internal memory.
7b. From your computer type the following commands:
Code:
adb push sdcard /
adb shell chmod -R 777 /sdcard
This will restore all the backup of the internal sdcard back into the Axon 7 internal memory. All but the empty directories.
You are done!!!! just reboot into the system with the new state of the art F2FS filesystem.
Sometimes the lockscreen information gets corrupted after restoring a backup. Since this process relies on restoring a TWRP backup, chances are that you are experiencing this issue too. In such case please follow the guide for clearing the lockscreen security settings in the AXON 7.
UNINSTALL
In case you want to go back to the initial state with ext4 filesystem in the Data and internal storage just follow these steps:
1. Reboot to TWRP and go to Settings. Ensure "Use rm -rf instead of formatting" is NOT set. This will allow to restore the data partition to the original filesystem of the backup.
2. Follow steps 6 and 7 of the installation instructions, exactly the same way, to restore the Data and internal storage to ext4 with the same contents.
I hope you find this interesting since it is a performance improving method that drains less battery, doesn't involve rooting, doesn't overheat the processors and provides noticeable results. Just let me know if this guide has been useful for you.
NOTE: If you delete Dlavik/cache in the process, please note that rebuilding it is quite fast, less than 5 seconds. This is caused by the cache of the F2FS filesystem, but all processing has to be done. The system will boot after a quick apps initialization but you will see the system somehow a little slow. Leave it for some minutes until all the apps had been completely processed. It is done in the background, but al least you have your system up and running quite fast even after deleting dalvik/cache partitions.
UPDATE (2017-01-20)
If you have already switched to F2FS filesystem without the optimization parameters for TWRP (using TWRP 3.0.3-2 or below with the initial version of this guide), then you just have to enter in TWRP and follow all the steps without leaving recovery:
STEP 1: reboot to recovery and go to advanced / terminal. Type the command df. This will give you the current usage of the partitions. Write down the total 1K blocks, used and available statistics for the /dev/block/dm-0, the partition shared by data and sdcard. You will use these statistics to compare before and after.
STEP 2: Backup of your system (Boot, system and Data) to external SD.
STEP 3: Backup your internal storage (either way of those detailed in the guide)
STEP 4: Format Data and internal storage.
STEP 5: If you are using TWRP 3.0.4 or above then you can bypass this step. Otherwise open the terminal under advanced menu and type
Code:
mount -o remount,discard,nosuid,nodev,noatime,nodiratime,nobarrier,inline_xattr,inline_data /data
mount -o remount,discard,nosuid,nodev,noatime,nodiratime,nobarrier,inline_xattr,inline_data /sdcard
STEP 6: Restore your Data partition.
STEP 7: Restore your internal storage.
STEP 8: Go again to the terminal inside TWRP and type df again to see the difference in the data and sdcard shared partition.
Please let us know your statistics before and after.
Soon this guide will include the final F2FS optimization patch to be used within your system, it will require root, but is that a problem? On the other hand @jcadduono is working on a new version of TWRP using the backported f2fs drivers from Android kernel 4.10 (our stock kernels still use Android 3.18) with the correct optimized mount options. It is still under development but as soon as it was finished, I will update this guide on how to use the new features. Stay tuned!
That's all folks!
Switching to most F2FS doesn't make sense for anything other /cache (which is rarely even used, so probably not worth it) and /data (probably very worth it). The benefits that F2FS related to writing to the partition a lot over time.
There is no benefit to using F2FS for /system over ext4, in fact there are probably downsides. You aren't generally writing to /system very often, so no need to worry about write speeds to it. Read speeds are going to be similar anyway. And unless all the more recent F2FS development is backported into the kernel, you'd be running a very old version of F2FS as well.
I got almost 5000 more score in Antutu just by migrating the data partition from ext4 to F2FS. Writes are slower than reads for almost all the storage systems, and a flash memory is not different. An increase in the write performance is more noticeable than the reduction in read performance. That combination provides an overall increase in performance to the system.
I have been using it in my previous phone for more than 1 year without any issue, however having a stable and updated implementation is in the hands of the kernel developers. recently the Moto-Z uses the F2FS in its data partition with a very effective mount options. Probably this mix of mount options are the trick that makes the Moto-Z the fastest phone regarding filesystem.
jcadduono said:
you can enable it by opening the zip file for the kernel installer and editing patch.d/*-f2fs-fstab
all you have to do is remove the # in front of the partitions you want f2fs added for near the bottom, just below the comment telling you what to do
Click to expand...
Click to collapse
I do not find those files inside the patch.d folder inside the zip file (the minimal kernel patch). I will take the file from the full kernel and I will insert into the minimal patch.
I would like to enable F2FS for the cache partition as well as using the mount options: rw,seclabel,nosuid,nodev,noatime,nodiratime,background_gc=on,discard,user_xattr,inline_xattr,acl,inline_data,nobarrier,extent_cache,active_logs=6 for the data partition. It should increase the performance over the current options set. System partition has no reason to be migrated.
I will modify fs_data_opts string definition in the 06-f2fs-fstab file as well as trying to configure cache as a F2FS. If Motorola is using F2FS with successful results, then probably it worths it. I am trying to test whether the solution Motorola did with the Moto Z also works in our device. A deep analysis can be found here.
Oki said:
I do not find those files inside the patch.d folder inside the zip file (the minimal kernel patch). I will take the file from the full kernel and I will insert into the minimal patch.
I would like to enable F2FS for the cache partition as well as using the mount options: rw,seclabel,nosuid,nodev,noatime,nodiratime,background_gc=on,discard,user_xattr,inline_xattr,acl,inline_data,nobarrier,extent_cache,active_logs=6 for the data partition. It should increase the performance over the current options set. System partition has no reason to be migrated.
I will modify fs_data_opts string definition in the 06-f2fs-fstab file as well as trying to configure cache as a F2FS. If Motorola is using F2FS with successful results, then probably it worths it.
Click to expand...
Click to collapse
https://raw.githubusercontent.com/o...er/marshmallow/ailsa_ii/patch.d/06-f2fs-fstab
add it to the patch.d folder then. change the data mount flags to whatever you want.
i highly advise against uncommenting system/cache, f2fs is nothing but downsides for them. (incompatibilities for cache, which is unused by OS anyways), system is going to be read only all the time and ext4 has much better inode access/index times than f2fs so clearly better for read only, ex. $PATH reading to find locations of binaries to run, so please don't use f2fs on /system.
rw - lol all filesystems are rw by default
seclabel - this isn't a flag for you to use
nosuid/nodev - somewhat of a safety mechanism, unrelated to performance
noatime - very tiny write performance increase that won't be noticeable
nodiratime - same as noatime, but even less so
discard - i don't believe discard mount option is supported on Axon 7.
acl - acl will reduce performance (that's just extra access control/permission management)
nobarrier - this will increase the performance, yes, and it's probably a good idea because you don't have to worry at all about power outages other than severe kernel panics
extent_cache - this is on by default, so no need to specify it
inline_data - this is also on by default, no need to specify it
inline_xattr - no noticeable changes in performance, but normally specified on android i'd keep it
active_logs=6 - the default is 6, so no need to specify it, and there's no need to change this value (6 is optimal)
background_gc=on - the default is on, so need to specify it....
user_xattr - this isn't actually a valid f2fs flag, it is the default though, and don't specify nouser_xattr on android, it will cause bad things to happen
so....nobarrier is the only flag you should care about adding. no, it won't make a noticeable difference.
read: https://www.kernel.org/doc/Documentation/filesystems/f2fs.txt
You can Only go in TWRP then format Data to F2FS and then install the Rom .Have No Problem and all works fine.But cache not work.Every time i Boot android he write it back to Ext4.But data work
jcadduono said:
https://raw.githubusercontent.com/o...er/marshmallow/ailsa_ii/patch.d/06-f2fs-fstab
add it to the patch.d folder then. change the data mount flags to whatever you want.
i highly advise against uncommenting system/cache, f2fs is nothing but downsides for them. (incompatibilities for cache, which is unused by OS anyways), system is going to be read only all the time and ext4 has much better inode access/index times than f2fs so clearly better for read only, ex. $PATH reading to find locations of binaries to run, so please don't use f2fs on /system.
rw - lol all filesystems are rw by default
seclabel - this isn't a flag for you to use
nosuid/nodev - somewhat of a safety mechanism, unrelated to performance
noatime - very tiny write performance increase that won't be noticeable
nodiratime - same as noatime, but even less so
discard - i don't believe discard mount option is supported on Axon 7.
acl - acl will reduce performance (that's just extra access control/permission management)
nobarrier - this will increase the performance, yes, and it's probably a good idea because you don't have to worry at all about power outages other than severe kernel panics
extent_cache - this is on by default, so no need to specify it
inline_data - this is also on by default, no need to specify it
inline_xattr - no noticeable changes in performance, but normally specified on android i'd keep it
active_logs=6 - the default is 6, so no need to specify it, and there's no need to change this value (6 is optimal)
background_gc=on - the default is on, so need to specify it....
user_xattr - this isn't actually a valid f2fs flag, it is the default though, and don't specify nouser_xattr on android, it will cause bad things to happen
so....nobarrier is the only flag you should care about adding. no, it won't make a noticeable difference.
read: https://www.kernel.org/doc/Documentation/filesystems/f2fs.txt
Click to expand...
Click to collapse
BIG FAT thanks for the resource. I have a safe backup of the whole system. and I am willing to play the guinea pig role in testing all these options. I already had moved the 06-f2fs-fstab patch into the patch.d folder. But it was late and got some error while flashing. Today I will try again.
Kevinkuensken said:
You can Only go in TWRP then format Data to F2FS and then install the Rom .Have No Problem and all works fine.But cache not work.Every time i Boot android he write it back to Ext4.But data work
Click to expand...
Click to collapse
I have tried to format F2FS and then restore the data and the system doesn't boot. What ROM are you using? So fat I only have tested stock and Z.A.D. ROMs and both exhibit the same behavior.
Im on ZAD Rom and have no Problem to change data to f2fs in TWRP.And Im on Beast Kernel
@jcadduono, I have been trying to add the patched 06-f2fs-ftab file into patch.d folder of your ailsa_ii_xda_safetynet_kcal-1.0 file. But recovery log always returns an error while flashing:
- Executing: 06-f2fs-fstabpatch.d/06-f2fs-fstab: line 2: : not found
patch.d/06-f2fs-fstab: .: line 3: can't open '/tmp/kernel-flasher/patch.d-env '
- Error: Script failed: 06-f2fs-fstab!- Aborting...
Failed to patch boot image!Updater process ended with ERROR: 1
Any clue on what could the problem be?
BTW, I look forward to see your Nougat Kernel!!!!
Thanks for all your help.
Oki said:
@jcadduono, I have been trying to add the patched 06-f2fs-ftab file into patch.d folder of your ailsa_ii_xda_safetynet_kcal-1.0 file. But recovery log always returns an error while flashing:
- Executing: 06-f2fs-fstabpatch.d/06-f2fs-fstab: line 2: : not found
patch.d/06-f2fs-fstab: .: line 3: can't open '/tmp/kernel-flasher/patch.d-env '
- Error: Script failed: 06-f2fs-fstab!- Aborting...
Failed to patch boot image!Updater process ended with ERROR: 1
Any clue on what could the problem be?
BTW, I look forward to see your Nougat Kernel!!!!
Thanks for all your help.
Click to expand...
Click to collapse
You must have somehow removed patch.d-env from the zip at some point, or added a space inside the quotes of . "$env"? I don't know why that error would happen otherwise.
Also, I told you seclabel and user_xattr are not valid f2fs flags, they are display flags only, you won't be able to boot with them.
jcadduono said:
You must have somehow removed patch.d-env from the zip at some point, or added a space inside the quotes of . "$env"? I don't know why that error would happen otherwise.
Also, I told you seclabel and user_xattr are not valid f2fs flags, they are display flags only, you won't be able to boot with them.
Click to expand...
Click to collapse
Finally I was able to flash it. Notepad++ caused the issue. It changed the line end control character and replaced CF by CR+CF. So I just edited it using Sublime and everything went as expected. It flashed properly and the options are in place after reboot. By the way, I removed also seclabel and user_xattr, they are applied by default. I will start doing tests tomorrow.
Happy new year!!!
Cache partition still boot as ext4 after the patched F2FS patch.
I have run AnTuTu v6.2.7 without any overclock at all after applying the F2FS options of the Moto Z. I used my daily drive data with the stock ROM and the repatched patch of @jcadduono to allow F2FS with the extra options.
The AnTuTu score is 152937 Wich makes it the third Android phone in the top 5 list. Adding this patch to an optimized kernel configuration could be close to the iPhone 7 score.
Wow! This phone is a S7 killer!!!
Oki said:
Cache partition still boot as ext4 after the patched F2FS patch.
I have run AnTuTu v6.2.7 without any overclock at all after applying the F2FS options of the Moto Z. I used my daily drive data with the stock ROM and the repatched patch of @jcadduono to allow F2FS with the extra options.
The AnTuTu score is 152937 Wich makes it the third Android phone in the top 5 list. Adding this patch to an optimized kernel configuration could be close to the iPhone 7 score.
Wow! This phone is a S7 killer!!!
Click to expand...
Click to collapse
Dude, I get 152K with B29 stock OS
XblackdemonX said:
Dude, I get 152K with B29 stock OS
Click to expand...
Click to collapse
Even when using the same device, there will be people with more and less performance with stock OS using ext4. It will depend of the bin of the processor, the temperature (thermal throttling), the set of apps you have installed running in background, etc. The important number is the score difference between ext4 and F2FS, in my case it was 7657 points after the F2FS options patch.
Thanks for sharing this. I was under the impression that the stock kernel didn't support f2fs fully for some reason.
I am trying to optimize the filesystem even more. The next step is to provide specific parameters for the geometry with the fs geometry options in the mkfs.f2fs -s- z: these options control number of segments per section and number of sections per zone. Sizes that match chip parameters may speed up FLASH write operations. I assume this should have been taken care of, but I am just trying to find more optimization opportunities within the options.
Does anyone know these two geometry parameters for our eMMC?
@jcadduono Do you know what is the default geometry for mkfs.f2fs partitions in TWRP?
On the options part, I am also considering inline_data and inline_dentry.
Thanks
@Oki
Have you shared with ZTE for inclusion in future updates?
puremind said:
@Oki
Have you shared with ZTE for inclusion in future updates?
Click to expand...
Click to collapse
Nope, I hanven't. But feel free to share this with them if you wish!!!
Happy new year.
I have updated STEP 6 to optimize the initial F2FS structure when restoring the backup. I have also modified jcadduono kernel patch to inject these options also in the kernel to make them permanent. This results in about 3000 extra score in Antutu.
Related
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?
Q&A for [TOOL][NABI2] NabiLab - Root, Play, Recovery
Some developers prefer that questions remain separate from their main development thread to help keep things organized. Placing your question within this thread will increase its chances of being answered by a member of the community or by the developer.
Before posting, please use the forum search and read through the discussion thread for [TOOL][NABI2] NabiLab - Root, Play, Recovery. If you can't find an answer, post it here, being sure to give as much information as possible (firmware version, steps to reproduce, logcat if available) so that you can get help.
Thanks for understanding and for helping to keep XDA neat and tidy!
State of Nabi 2 Root as of 12/14?
So I have admittedly been out of the loop on the state of rooting my two Nabi 2s since after I restored them to stock and all back last year when they released the update that included the Gapps. So I've been running stock since then and am on the latest firmware (2.4.6 I believe). All is mostly fine, but I would really like to get the external SD cards to be writable again, and from what I can tell, I need root again to do that.
So...as of today...what is the state (and best procedure) of rooting the Nabi 2 on the latest OTA update? Is Nabi Lab still the best tool? From what I've pieced together from scattered threads, it's looking like possibly use Nabi Lab to install TWRP, and then use that to install the SuperSU (http://forum.xda-developers.com/showthread.php?t=1538053). However, I could likely be wrong...hence why I'm asking.
Eyebolt said:
So I have admittedly been out of the loop on the state of rooting my two Nabi 2s since after I restored them to stock and all back last year when they released the update that included the Gapps. So I've been running stock since then and am on the latest firmware (2.4.6 I believe). All is mostly fine, but I would really like to get the external SD cards to be writable again, and from what I can tell, I need root again to do that.
So...as of today...what is the state (and best procedure) of rooting the Nabi 2 on the latest OTA update? Is Nabi Lab still the best tool? From what I've pieced together from scattered threads, it's looking like possibly use Nabi Lab to install TWRP, and then use that to install the SuperSU (http://forum.xda-developers.com/showthread.php?t=1538053). However, I could likely be wrong...hence why I'm asking.
Click to expand...
Click to collapse
Nabilab will still work as long as you use a version with a Jellybean TWRP(since you are on 2.4.6).
katinatez repackaged it for jellybean here:
http://forum.xda-developers.com/showpost.php?p=48987089&postcount=2088
I've searched high and low and can't find anything. I have nabi2S running KitKat. Every rooting guide I've found is for JB. Is there any way to root the 2S?
Sent from my Nexus 5 using XDA Free mobile app
jaxbierley said:
I've searched high and low and can't find anything. I have nabi2S running KitKat. Every rooting guide I've found is for JB. Is there any way to root the 2S?
Sent from my Nexus 5 using XDA Free mobile app
Click to expand...
Click to collapse
For the sake of anyone else looking for this information we are discussing it at the main Nabi thread starting at post #2477
http://forum.xda-developers.com/showthread.php?t=1905674&page=248
Stock Restore
Hi
I have downloaded NabiLab, as I am having wifi issues on my updated Nabi2. I unzipped, ran the .bat and chose option 3 (with my nab connected via USB). Nothing happened, no errors etc, the screen flashed up and shut down. Do I need to do something with the Nabi (recovery mode etc), do I need to install anything from NabiLab before trying this? Any help would be appreciated
Firepants said:
Hi
I have downloaded NabiLab, as I am having wifi issues on my updated Nabi2. I unzipped, ran the .bat and chose option 3 (with my nab connected via USB). Nothing happened, no errors etc, the screen flashed up and shut down. Do I need to do something with the Nabi (recovery mode etc), do I need to install anything from NabiLab before trying this? Any help would be appreciated
Click to expand...
Click to collapse
What version of software? Use Nabilab2015 http://forum.xda-developers.com/showpost.php?p=59073456&postcount=2544
It has more diagnostic info. Just be in Android or TWRP with ADb enabled. It also can see if drivers are loaded.
Hacking Nabi2 to Allow Data2SD
I managed today to hack my kids Nabi2 to enable Data2SD. I was to frustrated by the limited space in the tab. My kids were complaining about not being able to add more games. Thus, I decided to take the risk of modifying the mount points of the tab to allow the data partition to point to a partition in a large sdcard, instead of the limited 4.5 GB space in the internal storage.
Warning: I am not responsible of any damage as a result of following the next steps. Always make backups
Note: I have the last update (KitKat) installed in the Nabi2
1- Dump the boot image from an adb shell:
Code:
su
cat /dev/block/platform/sdhci-tegra.3/by-name/LNX > /sdcard/boot.img
2- Open this url http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images
to see the instructions of how to unpack and repack the boot image. Note that, the splitimage script mentioned in the page can be found at https://gist.github.com/jberkel/1087743
Warning: do not do anything in the tutorial, just wait
3- Format an sdcard as one partition of ext4 type
4- Insert the sdcard in the nabi2
5- Use the tutorial in step 2 to extract the ramdisk contents from the boot image and then Modify the file "fstab.mt799" in the ramdisk folder by replacing the line
Code:
/dev/block/platform/sdhci-tegra.3/by-name/UDA /data ext4 noatime,nosuid,nodev,journal_async_commit,data=writeback,nodelalloc,errors=panic wait,check,encryptable=/dev/block/platform/sdhci-tegra.3/by-name/MDA
with
Code:
/dev/block/platform/sdhci-tegra.0/by-num/p1 /data ext4 noatime,nosuid,nodev,journal_async_commit,data=writeback,nodelalloc,errors=panic wait,check,encryptable=/dev/block/platform/sdhci-tegra.3/by-name/MDA
which switches the data partition mount point to be on the sdcard
and the line
Code:
/devices/platform/sdhci-tegra.0/mmc_host/mmc2 auto vfat defaults voldmanaged=sdcard1:auto
with
Code:
/devices/platform/sdhci-tegra.3/mmc_host/mmc0 auto vfat defaults voldmanaged=sdcard1:12
which mount your old data partition into the directory of the external sdcard
6- Repack the boot image as mentioned in the url in step 2
7- Copy the new boot image to the nabi2 sdcard
8- Once you copied the new boot image (e.g. new_boot.img), replace the current boot image with the new one using adb shell:
Code:
su
cat /sdcard/new_boot.img > /dev/block/platform/sdhci-tegra.3/by-name/LNX
9- Now the kernel is replaced and once you rebooted your external sdcard would be in use, but note that your device is now having an empty data partition on the external sdcard, so you have to setup everything from the beginning. Note also that your previous data partition is now mounted as an sdcard, however, you have to format it from ext4 to fat32 to work as an sdcard (you can do the format from setings->storage->sdcard format)
ashahin1 said:
I managed today to hack my kids Nabi2 to enable Data2SD. I was to frustrated by the limited space in the tab. My kids were complaining about not being able to add more games. Thus, I decided to take the risk of modifying the mount points of the tab to allow the data partition to point to a partition in a large sdcard, instead of the limited 4.5 GB space in the internal storage.
Warning: I am not responsible of any damage as a result of following the next steps. Always make backups
Note: I have the last update (KitKat) installed in the Nabi2
1- Dump the boot image from an adb shell:
Code:
su
cat /dev/block/platform/sdhci-tegra.3/by-name/LNX > /sdcard/boot.img
2- Open this url http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images
to see the instructions of how to unpack and repack the boot image. Note that, the splitimage script mentioned in the page can be found at https://gist.github.com/jberkel/1087743
Warning: do not do anything in the tutorial, just wait
3- Format an sdcard as one partition of ext4 type
4- Insert the sdcard in the nabi2
5- Use the tutorial in step 2 to extract the ramdisk contents from the boot image and then Modify the file "fstab.mt799" in the ramdisk folder by replacing the line
Code:
/dev/block/platform/sdhci-tegra.3/by-name/UDA /data ext4 noatime,nosuid,nodev,journal_async_commit,data=writeback,nodelalloc,errors=panic wait,check,encryptable=/dev/block/platform/sdhci-tegra.3/by-name/MDA
with
Code:
/dev/block/platform/sdhci-tegra.0/by-num/p1 /data ext4 noatime,nosuid,nodev,journal_async_commit,data=writeback,nodelalloc,errors=panic wait,check,encryptable=/dev/block/platform/sdhci-tegra.3/by-name/MDA
which switches the data partition mount point to be on the sdcard
and the line
Code:
/devices/platform/sdhci-tegra.0/mmc_host/mmc2 auto vfat defaults voldmanaged=sdcard1:auto
with
Code:
/devices/platform/sdhci-tegra.3/mmc_host/mmc0 auto vfat defaults voldmanaged=sdcard1:12
which mount your old data partition into the directory of the external sdcard
6- Repack the boot image as mentioned in the url in step 2
7- Copy the new boot image to the nabi2 sdcard
8- Once you copied the new boot image (e.g. new_boot.img), replace the current boot image with the new one using adb shell:
Code:
su
cat /sdcard/new_boot.img > /dev/block/platform/sdhci-tegra.3/by-name/LNX
9- Now the kernel is replaced and once you rebooted your external sdcard would be in use, but note that your device is now having an empty data partition on the external sdcard, so you have to setup everything from the beginning. Note also that your previous data partition is now mounted as an sdcard, however, you have to format it from ext4 to fat32 to work as an sdcard (you can do the format from setings->storage->sdcard format)
Click to expand...
Click to collapse
If you are not sure which line to change, I have the fstab.mt799 file attached with this post. You can simply replace your file with this one.
ashahin1 said:
I managed today to hack my kids Nabi2 to enable Data2SD. I was to frustrated by the limited space in the tab. My kids were complaining about not being able to add more games. Thus, I decided to take the risk of modifying the mount points of the tab to allow the data partition to point to a partition in a large sdcard, instead of the limited 4.5 GB space in the internal storage.
Warning: I am not responsible of any damage as a result of following the next steps. Always make backups
Note: I have the last update (KitKat) installed in the Nabi2
1- Dump the boot image from an adb shell:
Code:
su
cat /dev/block/platform/sdhci-tegra.3/by-name/LNX > /sdcard/boot.img
2- Open this url http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images
to see the instructions of how to unpack and repack the boot image. Note that, the splitimage script mentioned in the page can be found at https://gist.github.com/jberkel/1087743
Warning: do not do anything in the tutorial, just wait
3- Format an sdcard as one partition of ext4 type
4- Insert the sdcard in the nabi2
5- Use the tutorial in step 2 to extract the ramdisk contents from the boot image and then Modify the file "fstab.mt799" in the ramdisk folder by replacing the line
Code:
/dev/block/platform/sdhci-tegra.3/by-name/UDA /data ext4 noatime,nosuid,nodev,journal_async_commit,data=writeback,nodelalloc,errors=panic wait,check,encryptable=/dev/block/platform/sdhci-tegra.3/by-name/MDA
with
Code:
/dev/block/platform/sdhci-tegra.0/by-num/p1 /data ext4 noatime,nosuid,nodev,journal_async_commit,data=writeback,nodelalloc,errors=panic wait,check,encryptable=/dev/block/platform/sdhci-tegra.3/by-name/MDA
which switches the data partition mount point to be on the sdcard
and the line
Code:
/devices/platform/sdhci-tegra.0/mmc_host/mmc2 auto vfat defaults voldmanaged=sdcard1:auto
with
Code:
/devices/platform/sdhci-tegra.3/mmc_host/mmc0 auto vfat defaults voldmanaged=sdcard1:12
which mount your old data partition into the directory of the external sdcard
6- Repack the boot image as mentioned in the url in step 2
7- Copy the new boot image to the nabi2 sdcard
8- Once you copied the new boot image (e.g. new_boot.img), replace the current boot image with the new one using adb shell:
Code:
su
cat /sdcard/new_boot.img > /dev/block/platform/sdhci-tegra.3/by-name/LNX
9- Now the kernel is replaced and once you rebooted your external sdcard would be in use, but note that your device is now having an empty data partition on the external sdcard, so you have to setup everything from the beginning. Note also that your previous data partition is now mounted as an sdcard, however, you have to format it from ext4 to fat32 to work as an sdcard (you can do the format from setings->storage->sdcard format)
Click to expand...
Click to collapse
If you don't have the time to do all these steps, I have the modified boot file attached here.
Yo can either follow steps 7 and 8 above to write it, or use the fastboot command as follows:
Code:
fastboot flash boot new_boot.img
Nabi2 not found
Hi, I purchased a reconditioned Nabi, which was reset back to stock. The wifi worked fine, until I updated it through the tablet. I am now on version 2.0 with no wifi. I have tried various options through NabiLab , however my Nabi is not recognised as being connected (although windows picks it up). Please help!
Swipe to restore
I am trying to return my nabi to stock, i can get to the screen that asks you to 'swipe to restore' but the screen is not responding. I dont have issues with the touchscreen normally
Aytul said:
I am trying to return my nabi to stock, i can get to the screen that asks you to 'swipe to restore' but the screen is not responding. I dont have issues with the touchscreen normally
Click to expand...
Click to collapse
That's weird...if you keep messing with it you may find a spot a little left, right, higher, or lower where you can grab the button to swipe....or you try to re-flash TWRP or maybe there's a new version of TWRP for your particular nabi software version.
did you ever get nabilab to see it? did you check the device manager to see if it was totally recognized? Are developer options enabled?
n3wt said:
That's weird...if you keep messing with it you may find a spot a little left, right, higher, or lower where you can grab the button to swipe....or you try to re-flash TWRP or maybe there's a new version of TWRP for your particular nabi software version.
did you ever get nabilab to see it? did you check the device manager to see if it was totally recognized? Are developer options enabled?
Click to expand...
Click to collapse
The Nabi is showing as a device, it's responds as it should up to the point of TWRP. I had to repeatedly press buttons to get to the restore swipe and have tried many times, unsuccessfully. Where do I enable developer options?
I am on version 2 (Nabi) and using the most up-to-date version of NabiLab. I am trying to restore to stock so that the software version goes back, as the update has stopped my wifi working. Even a factory reset doesn't take the Nabi software back further than v2.0
Aytul said:
The Nabi is showing as a device, it's responds as it should up to the point of TWRP. I had to repeatedly press buttons to get to the restore swipe and have tried many times, unsuccessfully. Where do I enable developer options?
I am on version 2 (Nabi) and using the most up-to-date version of NabiLab. I am trying to restore to stock so that the software version goes back, as the update has stopped my wifi working. Even a factory reset doesn't take the Nabi software back further than v2.0
Click to expand...
Click to collapse
For developer options you go to settings, scroll all the way down, if you don't see "Developer options" there, press About tablet, then repeatedly tap build number until it pops up and says "You are now a developer!", then go back and now you should see the Developer options menu item, press it and then make sure it's on at the top and that the USB Debugging option is checked.....then try nabilab again.
n3wt said:
For developer options you go to settings, scroll all the way down, if you don't see "Developer options" there, press About tablet, then repeatedly tap build number until it pops up and says "You are now a developer!", then go back and now you should see the Developer options menu item, press it and then make sure it's on at the top and that the USB Debugging option is checked.....then try nabilab again.
Click to expand...
Click to collapse
Yes this is enabled, as without it I am unable to run nabilab etc. The problem is TWRP & the version of software I am running on the tablet?
Aytul said:
Yes this is enabled, as without it I am unable to run nabilab etc. The problem is TWRP & the version of software I am running on the tablet?
Click to expand...
Click to collapse
Well, the touch issues are probably due to a bad build of TWRP but not necessarily the wrong one. The problem with nabilab not being able to see the tablet I think has to be drivers. Have you checked device manager to make sure there are no unrecognized things? 'cause the tablet show up as two separate things in there and it sounds like the USB storage part is working but not the adb and/or fastboot part(s).
n3wt said:
Well, the touch issues are probably due to a bad build of TWRP but not necessarily the wrong one. The problem with nabilab not being able to see the tablet I think has to be drivers. Have you checked device manager to make sure there are no unrecognized things? 'cause the tablet show up as two separate things in there and it sounds like the USB storage part is working but not the adb and/or fastboot part(s).
Click to expand...
Click to collapse
I've managed to sort the drivers by installing PDANet, then managed to sort TWRP by installing an older version. I've now updated to 2.1 on the Nabi but no luck with the wifi issue..i'm guessing it's really broken and it happening whilst updating may have been a coincidence?!
Aytul said:
I've managed to sort the drivers by installing PDANet, then managed to sort TWRP by installing an older version. I've now updated to 2.1 on the Nabi but no luck with the wifi issue..i'm guessing it's really broken and it happening whilst updating may have been a coincidence?!
Click to expand...
Click to collapse
It might just be broken but that's a heck of a coincidence... Do you have a backup from before the wifi issue started? If so, I'd try to thoroughly wipe everything but your external sd card and then restoring your backup and see if that helps.
n3wt said:
It might just be broken but that's a heck of a coincidence... Do you have a backup from before the wifi issue started? If so, I'd try to thoroughly wipe everything but your external sd card and then restoring your backup and see if that helps.
Click to expand...
Click to collapse
Hi, I bought it as a reconditioned did unit. Turned it on, updates it (wifi worked) and then had this problem, so no backup to go back to unfortunately
MultiSystem is a powerful tool for locked- and unlocked-bootloader Android devices with many features that at least includes the following:
Keeps stock system partition safe/rooted
Permenant root survival with proper use
MultiROM support via virtual ROMs
Unlimited number of virtual ROMs
Booting options to choose stock, primary, or secondary virtual ROM
Any of the virtual ROMs can work as a recovery replacement
Flashing multiple ROMs at the same time without a reboot
Ability to create/install ROMs on Linux to microSD card
Great performance & battery life on virtual ROMs
Recovery solution to install ROMs or Mods
Easy upgrade to newer versions of Android
Ability to safely apply OTA updates to virtual system
Permissive SELinux and other kernel tweaks
Safe flashing that doesn't trip KNOX flag on Samsung devices
Wrapper script runs via ADB or a Terminal Emulator on device
APK to manage all MultiSystem functions with a nice UI and extra options
Management for the best performance & user experience
Support for all Android devices with microSD card
Portability to almost all devices
Compatibility with all Android versions
Click to expand...
Click to collapse
Q&A
What is the concept behind MultiSystem?
It runs virtual Android ROMs on microSD, like booting multiple systems on a PC from different partitions/disks. So, your stock system partition is kept safe/rooted. It won't affect performance or anything (might even be better on the virtual system if you've high quality microSD & the device supports its speed). Also, you can freely modify any of the virtual systems & in the worst case, reboot the safe stock system or another working virtual system to recover. So, no root loss or potential damage to the original device partitions.
Click to expand...
Click to collapse
Is it a recovery or an APK tool?
It's a shell script that hijacks system at early boot & force Android to boot from the stock system partition or a virtual system IMG & an APK that manages all booting options, virtual ROMs, and works as a recovery replacement + extra features...
Click to expand...
Click to collapse
Does it work as a recovery replacement?
It IS a POWERFUL recovery replacement. You can do whatever you do in recovery with the APK. HOW? recovery does its magic b/c it doesn't depend on the system & has its own kernel/ramdisk. In MultiSystem, you can boot a virtual ROM from extSD that sure doesn't depend on stock system partition or any of the other virtual ROMs (it does depend on the kernel, which you can't flash on locked devcies anyway). Hence, install, backup, restore, ... & all recovery functions are all possible +++ more features since you're running a full ROM not just a recovery ramdisk like Safestrap.
Bottom Line: I think it's the best & most convenient recovery replacement ever for locked devices & it can also attract unlocked devices for the powerful features, MultiROM, and recovery from within ROM.
Click to expand...
Click to collapse
Can I use FlashFire along with MultiSystem?
Yes. MultiSystem is compatible with FlashFire & fully supports it on stock & virtual ROMs. So, you can use both/any of them for flashing to either a stock or virtual ROM. However, it's recommended to use MultiSystem when flashing to the stock system partition (shouldn't be needed anyway since you can always be safe & flash to your old/new virtual ROMs).
Click to expand...
Click to collapse
Does MultiSystem require FlashFire?
No, MultiSystem doesn't require FlashFire. They're fully combatible though.
Click to expand...
Click to collapse
Would the virtual ROM we install be exactly the one in the stock slot?
In MultiSystem APK, you can create a virtual ROM from stock system, a copy from other virtual ROM, a new IMG, a dev-provided ROM, a flashable .ZIP, ... etc. Literally, your virtual ROMs can be any stock or custom ROM that's compatible with your firmware/kernel.
Click to expand...
Click to collapse
How can it run virtual ROMs from external microSD card?
External MicroSD will be formated into 2 partitions:
exFAT or FAT32 for the 1st partition (your new external storage)
EXT4 for the 2nd partition (your MultiSystem partition)
It'll hijack the system & boot a virtual system from the 2nd partition. The 1st partition will be automatically detected as your extSD.
Click to expand...
Click to collapse
Can I run unrooted virtual ROM for work apps or any other reason?
Yes. You can add unrooted virtual ROM & reboot to it via MultiSystem APK.
Click to expand...
Click to collapse
How do you boot back into a different ROM?
MultiSystem APK manages all functions including ROM activation & reboot to current system, another stock/virtual system, download mode, recovery, ... etc.
Click to expand...
Click to collapse
Will it be OK to still store media like movies/photos/music to extSD?
100% OK; That's my setup a few months ago. 2 virtual ROMs in the SECOND extSD partition in EXT4 format while all personal data are stored on the FIRST extSD partition in exFAT or FAT32 format... TWO COMPLETELY DIFFERET PARTITIONS.
Click to expand...
Click to collapse
How much space are we going to have for virtual ROMs?
The size of the 2nd partition is optional (> 4GB) for your ROMs, but here is an estimated sizes:
1 Virtual ROM Uncompressed = ~2.7 GB ---> ready for running
1 Virtual ROM Compressed = ~1.5 GB ---> for full ROM backups
I'd say better allocate 4 GB for each ROM you plan to run. If you just need one virtual ROM to keep stock system safe, 4 GB 2nd extSD partition is enough; The remaining space is allocated for the 1st extSD partition as your external storage.
For me, I run Linux too from extSD via MultiSystem. So, I've 64 GB extSD card with two partitions 32 GB each.
Click to expand...
Click to collapse
Can I clear up space on an existing SD card and partition it while full or will the entire card need to be wiped and partitioned from scratch?
You need to backup all your files; it'll be wiped & repartitioned.
Click to expand...
Click to collapse
How can I swap microSD cards & be able to run virtual ROMs?
You can swap microSD cards as you wish provided that the device is powered off; don't remove the microSD card when running a virtual ROM. If the new microSD card doesn't include a 2nd parition of available virtual ROMs, the device will boot directly to the stock system.
Click to expand...
Click to collapse
Is there a specific sd card you recommended for this?
I personally have two microSD cards:
SanDisk Extreme Plus 64GB (Up to 80MB/s read speed)
Samsung 64GB PRO (Up to 90MB/s read speed)
You don't have to change your microSD card for MultiSystem; any card you use on your device should work just fine. The need for more speed is relevant when the device supports that speed & if you're going to buy a new card anyway that you may use with a newer device later.
Click to expand...
Click to collapse
Can I copy virtual ROMs to a new microSD card?
Yes. I'll add a feature for swapping microSD cards so that you can backup/restore virtual ROMs from/to the current extSD to/from internal storage as follows:
power off device
use MultiSystem APK to backup your virtual ROMs
insert the new properly formatted microSD,
power on device (it'll boot to stock system)
use MultiSystem APK to restore your virtual ROMs
use MultiSystem APK to activate one of your virtual ROMs
use MultiSystem APK to reboot to any of your ROMs
Click to expand...
Click to collapse
What about other data/cache partitions and internal storage?
Only system img's are in the extSD. All ROMs share all other partitions. This substantially improves the performance & you won't notice any difference between your stock & virtual ROMs. The reason for performance improvement is that EXT4 loop devices are very fast in reading but not in writing. Your system partition is read-only while data (for example) is read write & cache IMGs cause problems like Safestrap issues on ROM slots. Also, you don't have to worry about switching data/settings between ROMs (they're shared), but you just need to regularly backup your important data (which is healthy anyway).
Click to expand...
Click to collapse
Can your elaborate where data is stored?
The userdata partition is also shared; so, you'll have access to all your FULL storage partitions & all apps/data similarly on either stock or virtual ROMs. This also solves the Safestrap issue of having less storage on ROM slots...
Click to expand...
Click to collapse
Will mSDcard incur a significant performance penalty on some devices?
there's no diffrerence between virtual & stock ROMs in terms of performance & battery life. The reason is simple: loop devices associated with the READ-ONLY system IMG mounted from EXT4 partition using a high-quality microSD card IS very fast more than enough.
The read speed is faster than the device can operate anyway + the exact same device should perform on the lowest speed when reading/writing from/to the FAT/FAT32/ExFAT extSD card (where you store your files or even move apps!!!) anyway, which is much slower than the read speed of a loop device mounted from EXT4 partition.
That's why data partition is shared for many reasons, including the poor READ/WRITE performance.
Click to expand...
Click to collapse
If virtual systems are read only, how do we modify them? Do we have to boot to another multisystem rom to modify a virtual rom?
The stock system partition is mounted by default read only & so are the virtual systems. To modify a stock/virtual system, the MultiSystem APK remounts them read/write. You can modify the currently running virtual system, copy it & modify the copy, modify another stock/virtual system.
Click to expand...
Click to collapse
How is a corrupted virtual rom handled? Does it see it's bad and default to stock system?
At early boot, MultiSystem checks for the microSD & active virtual ROM to boot it. There's a boot menu that gives you options to select a stock/virtual system, but it crashes on LP. I'm debugging it, but all functions won't be affected if I removed it. To fail safe, you can remove the microSD card to boot to stock system & restore/repair your virtual ROMs.
UPDATE1: MultiSystem v1.0.1 now allows you to also switch to stock system on boot to repair corrupted virtual IMGs or any other reasons. More options will be added during boot to ultimately select another virtual system if the active IMG is not booting normally (e.g., bootloop after applying a mod or flashing a bad .ZIP).
UPDATE2: Now, on boot, you can choose from two primary/secondary virtual ROM or stock ROM. Flashing multiple ROMs at the same time without a reboot is now possible.
Click to expand...
Click to collapse
How to check if an IMG is corrupted using MultiSystem status?
Code:
Current System IMG: Test_Rom.img
Current System DEV: [B][COLOR="Red"]/dev/block/mmcblk0p23[/COLOR][/B]
When you see "/dev/block/mmcblk0p23"; it's the original system partition; so MultiSystem failed to boot Test_Rom.img, but it should be your current system.
So, the check is simple based on "Current System Device":
/dev/block/mmcblk0p23 = Stock System Partition
/dev/block/loop0 = Virtual System IMG
Note: The block device number (mmcblk0p23) may vary per device & per variant !
Click to expand...
Click to collapse
Does android do any maintenance whatsoever on stored data within /data or external sd? So if I have an app installed on 1 system and not on another system will android see it and clear the data?
No, all storage partitions are shared between ROMs. If you installed an app, it'll be availabe for all of them. Since on locked devcies we're limited to stock manufacturer-based ROMs, this makes the switch between ROMs very convinient (you don't have to worry about your changes/data/setup & storage space on the another ROM; all ROMs share everything except system). However, you should make regular backups in case a virtual ROM (probably with unsafe mods) results in bootloop due to your user data. In this case, it's safe to wipe data & selectively restore apps/data from backup(s). Another advantage of sharing all storage partitions is that your messages/emails/etc received on a virtual ROM are immediated synced (actually shared) to the other ROMs.
Click to expand...
Click to collapse
Will anything like Xposed modify the virtual ROM system IMG as opposed to the stock system IMG?
When you run a Virtual System, everything incldung kernel & apps are hijacked to speak to it as the original system.
Click to expand...
Click to collapse
Can we install AOSP ROMs on locked devices?
You can only install stock/manufacturer-based ROMs on locked devices while unlocked devices can use kexec or flash the required kernel to boot any AOSP/Stock ROMs. I've got a Note 4 Developer Edition & a lot of development is planned to go there (thanks to the unlocked bootloader!) More devices will get supported including unlocked TMO & international variants after adding more features untilizing the unlocked bootloader with kexec'd kernels.
Click to expand...
Click to collapse
Are there limitations to the combinations of ROMs that can be loaded on the "stock" and "virtual" slots? Can you mix KK and LP?
Yes, if they can run on the same kernel. LP won't run on KK kernels & so, you'd have to upgrade the firmware anyway. As for running mixed compatible Android versions, this is possible but your'd have to backup your data before switching ROMs; if it cause no issues, enjoy smooth switch & if it doesn't, do factory reset in recovery & restore your data backup. Backups via MultiSystem are painless.
Click to expand...
Click to collapse
Are applications installed once for each ROM slot that has that applicaiton installed, or can I share a game across ROMs (for instance?)
Everything is shared between ROMs, which is very good for storage & for easy switching. Just make regular backups of your sensitive data.
Click to expand...
Click to collapse
How there are no performance hits while internal storage memory was much faster than any microSD technology?
Read speeds from microSD is very fast compared to write speeds & since virtual ROMs are actually a virtual read-only systems (hence, MultiSystem), they provide a high performance. Moreover, again, read speeds from EXT4 loop devices are higher compared to physical partitions. They're very bad in writing, which we don't need for the read-only "system".
Click to expand...
Click to collapse
Is there a preferred "daily driver" ROM that should be installed in the stock slot?
Uses a stock ODEXED ROM on stock slot for better stability!
Click to expand...
Click to collapse
Is it based off of Safestrap?
Short answer NO. I've been working on MultiSystem & Safestrap for ~7 months. Earlier versions of MultiSystem (called, JasmineREC) was based on Safestrap, but it failed to support newer versions of Android mainly due to TWRP changes in the graphics/UI libraries that cause segmentation fault & the stock kernel framebuffer issues. Then, I decided to find another solution. However, the basic idea of system hijack is powered by Safestrap (or 2nd-init recoveries in general) & all the work done by @Hashcode is GREATLY appreciated.
Click to expand...
Click to collapse
How can it overwrite system files while running?
MultiSystem allows you to install safe mod's or a ROM in full or OTA-like update. It's strongly recommended to install .ZIP files NOT to the current system, b/c some files can not be overwritten while running. So, you can use backup function to copy the current system & install to the new img or any of your other virtual systems. You'll have several options to activate a virtual img & reboot directly to stock system, any virtual img you've activated, quick reboot, Download/bootloader, recovery,... etc.
Click to expand...
Click to collapse
How would I benefit from it if I'm only running Stock ROM or would there be no point for me to install it?
If you run a ROM on stock system, you're vulnerable to root loss unless/untill a new rooting method for LP comes out. MultiSystem gives you the option to run safe-to-mod virtual ROMs + recovery replacement + extra features.
Click to expand...
Click to collapse
Is there a way to convert a normal ROM .ZIP into MultiSystem .IMG?
Create or copy any of your IMGs, activate it & reboot to the active IMG! Then, use FlashFire to flash the ZIP file. However, the updater-script should be safe/compatible. Some devs mount the phyical partition, which will redirect everything to it!!
For example:
Code:
mount(“ext4″, “EMMC”, “/dev/block/mmcblk0p23″, “/system”);
will mount the original system partition; while
Code:
run_program("/sbin/mount", "-t", "auto", "/system");
will mount the current system (stock or virtual). This is recommended/safe.
Click to expand...
Click to collapse
Would a KitKat ROM work with multisystem even though my stock is Lollipop?
Any ROM requires a compatible kernel & modem. So, running KK ROMs requires flashing KK firmware (namely, kernel & modem). This may work with MultiSystem on other devices, especially if the bootlpoader is unlocked. For example, I plan to add features for Note 4 DevED to allow different Android versions (including AOSP, manufacturer-based, & probably Linux systems) by utilizing kernel swapping or execution.
Click to expand...
Click to collapse
When MultiSystem comes out will it be open sourced?
Most probably, haven't decided yet!
Anyway, here's the repository on GitHub: https://github.com/hsbadr/MultiSystem
Click to expand...
Click to collapse
Click to expand...
Click to collapse
Video Tutorials
A quick preview of MultiSystem v1.0 tested on Lollipop for VZW Note 3. The video has been captured on a stable virtual ROM of JasmineROM v5.0.1. It's FULLY compatible with FlashFire on virtual/stock systems. More devices will get supported as well, after required testing.
Facebook: https://www.facebook.com/hsbadr/videos/vb.331488823689599/428178174020663
How to check if you are running a Stock/Virtual System?
There're many ways to check whether you're running a Stock or Virtual system. MultiSystem app should include this simple check at some point. That's important to avoint ruining the Stock system & keep it safe. To make it clear to NOOBZ & anyone who's requesting "another" proof even though I owe hime nothing. Very weird!
Anyway, BusyBox mountpoint applet can print the current block/device mounted to /system mountpoint by running the following command:
Code:
busybox mountpoint -n /system
The stock system is mounts the original system partition:
Code:
[B][COLOR="Red"]/dev/block/mmcblk0p23[/COLOR][/B]
while the virtual system mounts a loop device associated with a system IMG:
Code:
[B][COLOR="Blue"]/dev/block/loop0[/COLOR][/B]
Here're two videos for both stock & virtual systems...
UPDATE:
Now, you could run the following command to print the current system (stock or virtual) and the system device (physical partition or loop device):
Code:
MultiSystem status
Note: The block device number (mmcblk0p23) may vary per device & per variant !
How to repartition microSD card for MultiSystem?
You can use any tool/program for partitioning on Android, Linux, Mac, or Windows. For example, MiniTool Partition Wizard is a good partitioning tool for Windows. So, let's use it for this task. Simply, you need to follow this PDF tutorial (thanks to @carl1961). In sum:
Step 1: delete old partitions on SD card
Step 2: create FAT32 PRIMARY partition
Step 3: create EXT4 PRIMARY partition
Then, apply changes (note that the program UI may get changed in newer versions).
Notes:
This partitioning tutorial doesn't create PRIMARY partitions (it creates logical partitions). So, you need to change "Create As" from "Logical" to "Primary" when creatig a partition.
The sizes of the two partitions are arbitrary depending on number of ROMs you plan to install on the 2nd EXT4 partition.
The 1st partition (check size) is automatically detected as your external storage
In Terminal Emulator or ADB shell, check the existence of the two partitions by running the following command (in red):
Code:
[email protected]:/ # [COLOR="Red"]ls -l /dev/block/platform/msm_sdcc.3/[/COLOR]
drwxr-xr-x root root 2015-05-02 21:08 by-num
lrwxrwxrwx root root 2015-05-02 21:08 mmcblk1 -> /dev/block/mmcblk1
lrwxrwxrwx root root 2015-05-02 21:08 mmcblk1p1 -> [COLOR="Blue"]/dev/block/mmcblk1p1[/COLOR]
lrwxrwxrwx root root 2015-05-02 21:08 mmcblk1p2 -> [COLOR="Blue"]/dev/block/mmcblk1p2[/COLOR]
/dev/block/mmcblk1p1 is mounted by Android as your external storage.
/dev/block/mmcblk1p2 is NOT mounted & will be your MultiSystem partition.
Click to expand...
Click to collapse
How to check microSD card partitions for MultiSystem?
You need to correctly repartition microSD card into two partitions:
exFAT or FAT32 for the 1st partition (your new external storage)
EXT4 for the 2nd partition (your MultiSystem partition)
Use the directions in this post!
You should check your 2nd SD partition in EXT4 format mounted to /MultiSystem:
check that the /MultiSystem directory exists after a reboot
check that the 2nd SD partition (/dev/block/mmcblk1p2) is mounted to /MultiSystem by running the following command in Terminal Emulator or ADB shell:
Code:
mount | grep /MultiSystem
The output should be:
Code:
/dev/block/mmcblk1p2 /MultiSystem ext4 rw,seclabel,relatime,data=ordered 0 0
How to check MultiSystem Installation?
The 1st thing to do after installing MultiSystem is to check the /MultiSystem directory & its contents (it shouldn't be empty!). Then, check usage by running the following commands in Terminal Emulator or ADB shell:
Code:
su
bash
MultiSystem
If it retuns "MultiSystem not found" or permission denied, try to use open MultiSystem app to Update Configurations & try again. If this does't fix it, try the following command:
Code:
/MultiSystem/bin/MultiSystem
This should work if you've MultiSystem binaries installed in (extracted to) /MultiSystem directory. If so, you can create a symlink in /system/xbin as follows:
Code:
mount -o remount,rw /system
ln -sv /MultiSystem/bin/MultiSystem /system/xbin/MultiSystem
Then, test it by running:
Code:
MultiSystem
The last thing before using it is to check the boot options: reboot & monitor the GREEN LED indicator for 3 seconds (change in the app) , which give you the following options:
Volume UP = Primary virtual ROM
Volume DOWN = Secondary virtual ROM
HOME KEY = Stock System
Pressing nothing will boot the active system: stock or primary virtual system. Sure, you should have installed one or more virtual ROMs.
Backup & restore or creating/installing a virtual ROM are easy as copy & paste: all img's will be at
Code:
/MultiSystem/img/system
To backup a virtual/stock system, you have many options:
Use create function to create from stock system
Use copy function to copy the IMG
Copy & paste with a new name
Use FlashFire (fully supported on virtual/stock ROMs)
...
If you've IMG mounting issues, run the following commands:
Code:
mount -o remount,rw /system
busybox ln -sv /proc/self/mounts /system/etc/mtab
If this doesn't help, try mounting from Terminal Emulator or ADB shell after selecting the IMG in MultiSystem app, by running the following command:
Code:
MultiSystem mount virtual
Will this work on the s5 active version?
jasonj711 said:
Will this work on the s5 active version?
Click to expand...
Click to collapse
Maybe; it works on ARM-based Android devices with microSD card. Howerver, it's currently tested on the devices listed here. You may test it (backup all your files/ROM!) & report back.
Looking forward to trying this out. I've been waiting for a solid MultiBoot solution for some time. Kudos.
Sent from my SM-N910P using XDA Premium 4 mobile app
Sorry, I'm a bit confused as to how one installs a ROM into an img. Whenever I mount an img and try selecting a flashable zip file it returns "file selected: null"
Am I doing something incorrectly?
U kind Sir a genius and a god-send.
Quick Question:
I plan to add features for Note 4 DevED to allow different Android versions (including AOSP, manufacturer-based, & probably Linux systems) by utilizing kernel swapping or execution.
Click to expand...
Click to collapse
Does it mean that we have to wait for this functionality yet or can I use SimplRom or Dr Ketan's Rom as Primary ROM and CM12 as secondary ROM.
Also the MiniTool Partition does not see the phone's SD card. I have a Note 4 International version (N910F).
Thank U and plz forgive the noob question (if the answer is obvious), I have just recently started using Android.
Alright, so whenever I try flashing a ROM the red LED turns on and then quickly off again. Here's my log http://pastebin.com/txN8mSjq
ok a dumb question. do you recommend a special tutorial to show how to convert a zip rom to img rom
Yeah. Support for this is terrible so i gave up.
from my Samsung Galaxy S5 SM-G900T on AT&T, Android 5.0. DOB1 with twi5ted lollipop 5.0 ROM v6
So I installed this and read the Q&A (which tells you what it does) . Now is there instructions somewhere on how to use it?
Dhs92 said:
Sorry, I'm a bit confused as to how one installs a ROM into an img. Whenever I mount an img and try selecting a flashable zip file it returns "file selected: null"
Am I doing something incorrectly?
Click to expand...
Click to collapse
Anubis22666 said:
U kind Sir a genius and a god-send.
Does it mean that we have to wait for this functionality yet or can I use SimplRom or Dr Ketan's Rom as Primary ROM and CM12 as secondary ROM.
Also the MiniTool Partition does not see the phone's SD card. I have a Note 4 International version (N910F).
Thank U and plz forgive the noob question (if the answer is obvious), I have just recently started using Android.
Click to expand...
Click to collapse
Dhs92 said:
Alright, so whenever I try flashing a ROM the red LED turns on and then quickly off again. Here's my log http://pastebin.com/txN8mSjq
Click to expand...
Click to collapse
BACARDILIMON said:
ok a dumb question. do you recommend a special tutorial to show how to convert a zip rom to img rom
Click to expand...
Click to collapse
jt1998 said:
Yeah. Support for this is terrible so i gave up.
Click to expand...
Click to collapse
jir591 said:
So I installed this and read the Q&A (which tells you what it does) . Now is there instructions somewhere on how to use it?
Click to expand...
Click to collapse
Click to expand...
Click to collapse
I'm working with Rootjunky to create a full video tutorial that describes everything to make it easier for you.
As for kexec support for unlocked devices, this has not been implemented yet. MultiSystem supports many devices & so, there'll be delays in responding to all questions in all threads.
thanks for making the video. I think it will help a lot of people.
jt1998 said:
Yeah. Support for this is terrible so i gave up.
from my Samsung Galaxy S5 SM-G900T on AT&T, Android 5.0. DOB1 with twi5ted lollipop 5.0 ROM v6
Click to expand...
Click to collapse
It a work in progress and I am willing to bet when he gives us video we flash junkies will love this . changing rom to fit our mood. I will take it.
---------- Post added at 01:36 AM ---------- Previous post was at 01:35 AM ----------
hsbadr said:
I'm working with Rootjunky to create a full video tutorial that describes everything to make it easier for you.
As for kexec support for unlocked devices, this has not been implemented yet. MultiSystem supports many devices & so, there'll be delays in responding to all questions in all threads.
Click to expand...
Click to collapse
Thank you for all your hard work.
I have a question. I know you recommend a good base but lets say I keep stock image a odex . most roms are deodex will that cause any issues?
BACARDILIMON said:
I have a question. I know you recommend a good base but lets say I keep stock image a odex . most roms are deodex will that cause any issues?
Click to expand...
Click to collapse
It doesn't matter! I like the ODEXED ROMs for stability & memory while DEODEXED ROMs are great for customizations... So, basicly, I use the stock ODEXED on Stock partition & DEODEXED ROMs for the virtual systems.
This is a CyanogenMod 12.1 ROM for the Exynos3470 based Samsung Galaxy Tab 4 7.0 LTE (T235/T235Y).
DO NOT USE IT FOR T230(NU)/T231 OR YOU WILL BRICK YOUR DEVICE
Although T235 and T230(NU)/T231 (T230:WiFi / T231:3G) share the "Galaxy Tab 4 7.0" name they are not related in terms of hardware due to the different SoCs used (Samsung Exynos3470 vs. Marvell PXA1088).
Hence please do not ask for support or ROMs for the T230(NU)/T231.
Working features
Receiving and making calls
Hardware sensors (Acceleration)
Audio
Bluetooth
Wifi
HW accelerated GUI
MTP storage
GPS
USB-OTG (Mass-Storage, Keyboard, Mouse working, USB-Audio untested)
Camera (pictures+video: Back+Front)
Non-working features:
SELinux
Known issues:
See the Bug Report section of this thread
Disclaimer:
You flash this image at your own responsibility. I am not responsible for any damage that might be caused by flashing this image (bricked device, lost data, ...)
Flashing this kernel image will trigger the KNOX counter, so your warranty will be void.
Applications that use KNOX (e.g. "Private Mode") might not work anymore when returning to the stock ROM, as the device is regarded as compromised. Do not flash this ROM if you need those applications.
The image is only for Tab 4 7.0 SM-T235 and SM-T235Y (Exynos)
It might be instable, crash your device, drain your battery, or even might damage your smartphone
Backup your data before flashing and check if the original firmware is present (e.g. at SamMobile)
Click to expand...
Click to collapse
Before you start:
Backup your data, like call history, contacts, sms, WhatsApp messages, favourite app settings that are on internal and external sd (by using Titanium Backup or other apps available on PlayStore). At least all internal data will be lost in any case. If you have bad luck you might also loose data from your external sd card.
Download:
Odin3-v1.85
TWRP 2.8.7.0 recovery image [09/08/2015] (AndroidFileHost Mirror)
CM 12.1 ROM (AndroidFileHost Mirror)
Google Apps (contains Google Play, ...) for Android 5.1.1 from Jajb (Recommended) or the one that suits you best from Consolidated GApps.
Install recovery:
Reboot your device into Odin mode: turn off your device, then press Volume-Down + Home + Power button at the same time and release them.
Confirm the following warning message with the Volume-Up button.
Connect your device to your PC via USB
Make sure the device driver's are installed on your PC
Start Odin
In Odin select PDA and select the recovery image (recovery.tar.md5)
Check that only "Auto Reboot" and "F. Reset Time" is set
Click on "Start": the kernel image should be flashed now and the device should reboot afterwards. By flashing the recovery, your warranty will be void.
After the recovery flashing process was successful, power of your device. If not restart into Download mode and flash again or flash the stock rom.
Before you flash:
You need the latest TWRP recovery (see links above). Otherwise TWRP might not be able to flash the ROM.
Wipe the device to avoid problems with remaining files from the old installation (see instructions below). This also applies if you already installed an older version of CM 12.1.
Flash CyanogenMod:
Reboot into recovery mode (Press Volume-Up + Home + Power button)
If you come from a stock ROM, this is your opportunity to make a Backup of your phone(Backup, then select Boot, System, Data, then swipe to backup). Note that the recovery might fail to restore the backup when you want to go back to the stock ROM (for me it got stuck after a restore during boot. But the backup was made with a different version of TWRP, so it might work in general) - simply do not expect too much of it at the moment.
If you haven't copied the installation files yet, you can now copy the GApps and CyanogenMod zip to your internal sd or external sd (be careful not to put the files into the data directory of the internal sd card as this will be deleted in the next step). Be sure that MTP is enabled (inside Mounts, click on Enable MTP), then, from your pc, copy the files. If MTP does not work from recovery, try it directly from Android or remove the external sd card from the phone and put it into your PC.
Wipe Dalvik Cache, Cache, System and Data (inside Wipe -> Advanced Wipe). Do not report problems if you did not wipe those partitions as the problems are most probably related to this!
Install the CM 12.1 ROM zip-package
Install the GApps zip-package
Reboot the system and enjoy a Lollipop
How to root:
No SuperSu is needed as CyanogenMod already comes with integrated root support. Root access is disabled by default.
You normally do not need root access. If you want to activate root access for apps, do the following:
Open the Settings menu, select "About Phone"
Tap on the "Build number" entry seven times. You should be notified, that the developer settings are now active.
Open the Settings menu, select "Developer options". Enable root access by selecting "Apps" in the "Root-Access" setting.
In case you want to go back to the stock ROM:
lf you do not have the latest stock ROM you can download it from SamMobile
Reboot your phone into Odin mode
Open Odin on your PC and connect your smartphone with your PC via USB
If you have a zip-file unzip it so that you have a .tar.md5 file
In Odin click on the PDA button and select the .tar.md5 file. Then press "Start".
Normally the stock rom fails to boot as the data from CM12 is still on the data partition. So after flashing the stock rom, reboot into recovery mode (it looks a bit different now). First wipe the data partition, then wipe the cache.
Reboot
Changelog
Code:
09/08/2015:
*Update kernel to T235XXU1AOD1
*Synchronize with newest CM 12.1 sources (contains stagefright patches)
*Fixed black screen on minimal brightness
12/07/2015:
* Charging animation in standby-mode fixed
11/07/2015:
* Update to newest CyanogenMod sources (LMY48G)
* Left touchkey working now (configured as App-Switch button)
* Camera Preview working (saving a picture might still crash)
30/06/2015:
* Image sizes reduced to fix "unable to mount /system" problems
28/06/2015:
* Initial test-build
This section is for developers:
A README file with build instructions can be found here:
https://github.com/cm-3470/patcher_degaslte
Sources:
Code:
https://github.com/cm-3470/android_device_samsung_degaslte
https://github.com/cm-3470/android_vendor_samsung_degaslte
https://github.com/cm-3470/android_kernel_samsung_degaslte
https://github.com/cm-3470/android_device_samsung_smdk3470-common
Developers welcome
Help from other developers is always welcome. See the bug/feature section and this thread to see what is missing. Just give some short info (here in this thread or PM) that you want to work on some issue or feature so that work can be synchronized. Maybe there are also other devs that want to work with you on the same issue.
Knowledge in how the kernel works and good programming skills in C, C++ and Java would be nice but not necessary for all problems. At least you should be able to build the ROM and test your changes yourself but you do not need experience in porting ROMs.
XDA:DevDB Information
[T235][ROM][5.1.1][LMY48G] CyanogenMod 12.1 for T235(Y) [Alpha 09/08/2015], ROM for the Samsung Galaxy Tab 4
Contributors
hennymcc
Source Code: https://github.com/cm-3470
ROM OS Version: 5.1.x Lollipop
ROM Kernel: Linux 3.4.x
ROM Firmware Required: TWRP Recovery [version from 09/08/2015]
Based On: CyanogenMod
Version Information
Status: Alpha
Created 2015-06-29
Last Updated 2015-09-24
i've tried to test the rom but i can't install so far... i've wiped all but it said it can't mount system again...
http://www.mobosdata.com/samsung-galaxy-tab-4-7-0-lte-sm-t235y
According to this the SM-T235Y is based on Marvel cpu vs exynos on the sm-t235
Does anyone really know the differences ? On another page i read the sm-t235y has a snapdragon 400 ...
Hectic confusing samsung numbering + different devices with same model name .
@hennymcc
do you have included selinux_defconfig in your twrp kernel?
androidboot.selinux=disabled at twrps kernel cmd line should be removed
i wiped system and all partitions using your new twrp but when i install the zip file then /system becomes unmountable
/system is formated ext4
should i try to format it f2fs ?
interstellar22 said:
i wiped system and all partitions using your new twrp but when i install the zip file then /system becomes unmountable
/system is formated ext4
should i try to format it f2fs ?
Click to expand...
Click to collapse
any marvell devices will not work with this or any other custom rom.
sub77 said:
any marvell devices will not work with this or any other custom rom.
Click to expand...
Click to collapse
this is an exynos device not marvell
and now for some reason i cant restore the backup i made
i tryed restorng the backup with twrp 2.8.6.0 recovery from this thread and the 2.8.1.0 from the other.
one gives boot animation loop and the other is stuck at boot
hennymcc said:
In case you want to go back to the stock ROM:
lf you do not have the latest stock ROM you can download it from SamMobile
Click to expand...
Click to collapse
Stock Roms on Android File Host (quicker, free-er host site than Sammobile)
@interstellar22 did you try wiping cache after you restored, before you booted?
thisisapoorusernamechoice said:
Stock Roms on Android File Host (quicker, free-er host site than Sammobile)
@interstellar22 did you try wiping cache after you restored, before you booted?
Click to expand...
Click to collapse
i tryed once without wiping cache, but i had cache backed up also
then i tryed to do a factory reset
still stuck at bootlogo
and adb logcat and adb devices shows nothing
sub77 said:
@hennymcc
do you have included selinux_defconfig in your twrp kernel?
androidboot.selinux=disabled at twrps kernel cmd line should be removed
Click to expand...
Click to collapse
The default selinux setting is enforced. As the selinux configuration files are not complete, Android would not boot.
Setting androidboot.selinux=permissive might work, but when I tested this setting on my S5 mini, it was rather unstable for some reason.
interstellar22 said:
http://www.mobosdata.com/samsung-galaxy-tab-4-7-0-lte-sm-t235y
According to this the SM-T235Y is based on Marvel cpu vs exynos on the sm-t235
Does anyone really know the differences ? On another page i read the sm-t235y has a snapdragon 400 ...
Hectic confusing samsung numbering + different devices with same model name .
Click to expand...
Click to collapse
sub77 said:
any marvell devices will not work with this or any other custom rom.
Click to expand...
Click to collapse
interstellar22 said:
this is an exynos device not marvell
Click to expand...
Click to collapse
T235 and T235Y definitely use Exynos 3470 SoCs. Here an extract from the T235Y default.prop:
Code:
ro.product.model=SM-T235Y
ro.product.name=degasltezt
ro.product.device=degaslte
ro.product.board=universal3470
ro.chipname=exynos3470
The default.prop file of the T235 is similar, only that the product name is degasltexx.
Marvell's PXA1088 SoC is used in the T230/NU which is the non-LTE (WiFi-only) variant of the Tab 4 7.0.
Marvell's PXA1088 and Samsung's Exynos3470 are totally different and have nothing in common (except an ARM core), the same applies to Qualcomm's Snapdragon. There are many websites that mention wrong SoC names as Samsung's naming scheme is rather confusing.
The same applies to the S5 Mini: G800F/M/Y -> Exynos3470, G800H -> Qualcomm Snapdragon.
corneo said:
i've tried to test the rom but i can't install so far... i've wiped all but it said it can't mount system again...
Click to expand...
Click to collapse
Code:
Info: format successful
I:mkfs.f2fs -t 1 /dev/block/mmcblk0p18 process ended with RC=0
Done.
Why was the system partition formatted with f2fs? The default file system is ext4.
The TWRP partition table is hardcoded to ext4 so that's probably the reason for these lines:
Code:
E:Unable to mount '/system'
I:Actual block device: '/dev/block/mmcblk0p18', current file system: 'ext4'
Could you reformat it with ext4?
interstellar22 said:
i tryed once without wiping cache, but i had cache backed up also
then i tryed to do a factory reset
still stuck at bootlogo
and adb logcat and adb devices shows nothing
Click to expand...
Click to collapse
Did you flash the stock ROM with Odin?
And afterwards wipe the data partition and then the cache with the _stock_ recovery (as TWRP is not available after flashing the stock ROM)?
interstellar22 said:
i wiped system and all partitions using your new twrp but when i install the zip file then /system becomes unmountable
/system is formated ext4
should i try to format it f2fs ?
Click to expand...
Click to collapse
Short summary:
interstellar22 and corneo tried it so far and both got the error message "/system unmountable"
Strange that corneo was able to generate an error log.
@corneo: did you create the log with adb?
At least according to corneo's log, it seams that after the F2FS format the partition is reformatted with EXT4 afterwards:
Code:
Formatting system using make_ext4fs function.
It also says:
Code:
erasing 588800 blocks
blkdiscard failed: Invalid argument
writing 134395 blocks of new data
lseek64 failed: Invalid argument
I:Legacy property environment disabled.
E:Error executing updater binary in zip '/external_sd/cm-12.1-20150627-UNOFFICIAL-degaslte.zip'
Error flashing zip '/external_sd/cm-12.1-20150627-UNOFFICIAL-degaslte.zip'
Not that sure about what causes this error. Maybe the partition sizes have to be changed.
hennymcc said:
Short summary:
interstellar22 and corneo tried it so far and both got the error message "/system unmountable"
Strange that corneo was able to generate an error log.
@corneo: did you create the log with adb?
At least according to corneo's log, it seams that after the F2FS format the partition is reformatted with EXT4 afterwards:
Code:
Formatting system using make_ext4fs function.
It also says:
Code:
erasing 588800 blocks
blkdiscard failed: Invalid argument
writing 134395 blocks of new data
lseek64 failed: Invalid argument
I:Legacy property environment disabled.
E:Error executing updater binary in zip '/external_sd/cm-12.1-20150627-UNOFFICIAL-degaslte.zip'
Error flashing zip '/external_sd/cm-12.1-20150627-UNOFFICIAL-degaslte.zip'
Not that sure about what causes this error. Maybe the partition sizes have to be changed.
Click to expand...
Click to collapse
i've created the log in recovery and copied it to sd.
now i flashed the tab again with odin and try it again. same issue...
Gesendet von meinem One M8
i managed to get the original firmware back with odin
could it be that the system.new.dat file is corrupted ?
i had formated system with ext4 then did the update and was still getting unable to mount /system afterwards
so most probably the system.new.dat file has some problems or i have no idea why i cant mount /system afterwards
Maybe it is caused by wrong BOARD_...IMAGE_PARTITION_SIZE values in BoardConfig.mk.
Could you please post the contents of /proc/mounts and /proc/partitions:
Code:
cat /proc/mounts
cat /proc/partitions
The above should be performed from the stock ROM. The device must be rooted.
Hmm, the problem might be here:
Code:
Patching system image unconditionally...
blockimg version is 2
erasing 588800 blocks
blkdiscard failed: Invalid argument
writing 134395 blocks of new data
lseek64 failed: Invalid argument
588800 * 4096 = 2411724800 bytes (2,2GB)
This is the value of the BoardConfig.mk taken from the S5 Mini (BOARD_SYSTEMIMAGE_PARTITION_SIZE := 2411724800).
But the system partition is only 2233466880 bytes:
Code:
/system | /dev/block/mmcblk0p18 | Size: 2096MB Used: 1828MB Free: 268MB Backup Size: 1828MB
Code:
I:wipe_path '/system'
Formatting System using make_ext4fs function.
Creating filesystem with parameters:
Size: 2233466880
The system.img itself is only 500MB in size. So I guess reducing the image size should fix the problem.
An updated ROM is available. The image sizes have been reduced. I hope this fixes the problems with the system-partition.
Also use the new TWRP recovery as the partition sizes might be hardcoded in the old one.
good news! new recovery and system image works! very smooth so far, searching for bugs now. the only one i found are the extended settings option. it doesn't work but thats no problem for me. thank you very much!
Gesendet von meinem One M8
HP Touchpad Universal Optimize Swap Settings for All Android ROMs
MAX 1GB RAM - MAX 1836 Frequency
Click HERE for detail Memory and Frequency information for each ROM
Click HERE to dual boot all listed Android ROMs and LuneOS
Click HERE for PowerOFF - Prevents Battery Drain
Upated: November 12, 2020: Added HP TOUCHPAD DEBRICK Linux Live CD
Upated: November 12, 2019: Added PowerOFF
Upated: November 07, 2019: Rom_Reducer to Evervolv, Kitkat by Milaq and LuneOS
Upated: October 09, 2019: HpTp_MaXtreme (Max Extreme Kernel Settings for All ROMs)
Upated: October 01, 2019: Added ROM: LineageOS 11 Kitkat by Milaq build October 01, 2019
Upated: September 28, 2019: All_Files for Lollipop got updated to fix WiFi
Upated: September 25, 2019: Added ROM LineageOS 14.1, HpTp_MAX_Settings, 1GB Swap
Upated: September 2, 2019: Fix Evervolv 7.1.2 Frequencies, Created: Universal Authority, Added: Evervolv Pie, Posted: Universal Settings
Upated: August 24, 2019: HP Touchpad Novacom Repair Android
Upated: August 2, 2019: New Improved Settings: HpTp_Universal_Optimized_Swap
Added ROM_Reducer; Removed support for Lineage 11
Upated: July 12, 2019: Flash ToolBox v42 by jcsullins to /boot
Upated: July 8, 2019: /System Partition is 2.2 GB:/ Improved Settings to All ROMs
________________________________________________________________
HP TOUCHPAD DEBRICK Linux Live CD
Built in with all the tools to properly run TP Debrick v005 by jcsullins and also novacom drivers.
Click HERE for the Guide
Click HERE to Download ISO File
________________________________________________________________
HP Touchpad Novacom Repair Android
Built in Novacom Driver, Repair non bootable Tablet, Flash ToolBox, Modify Ramdisk and more !
Click HERE for the Guide
Click HERE to Download ISO File
________________________________________________________________
Back up any data before making any changes to the Tablet, follow this guide:
Click here on how to backup ROM to PC and restore
Important, do not restore the /boot partition
________________________________________________________________
For WebOS users
WebOS has the swap partition and it can be share with Android.
There is no need to Flash the file Automatic_Wipe_All_and_Create_Android_with_Swap.
But to use Android PIE, Oreo and Nougat the Android /system partition must be 1400 MB.
There are two options to resize the Android /system partition.
Inside webOS using Tailor:
Click here for Tailor
Using the ToolBox:
Click here to download the ToolBox
After the Android /system partition have been resize Flash any listed ROM.
________________________________________________________________
The Automatic_Wipe_All_and_Create_Android_with _Swap can be flash using any Recovery.
It is best to use TWRP Recovery Version 3.1 or 3.2
Click here to download TWRP Recovery 3.1 by Flintman
Click here to download TWRP Recovery 3.2 by Flintman
________________________________________________________________
Easy Automatic process to Wipe All and Create Android partitions with Swap 1GB or 500MB
Click Here to Download Automatic_Wipe_All_and_Create_Android_with _Swap, choose 1GB or 500MB
This file MUST BE FLASH to create the swap partition to be use by the listed ROMs
A complete Data RESET of all the internal storage.
All partitions are deleted, is a total fresh start as if the Tablet came from factory with only Android install.
The Android partitions are created and formatted ready for use:
/system 2.2 GB ( Allows to install any ROM plus the maximum size of Open Gapps Variant Super )
/cache 200 MB ( Standard size )
/media 1GB or 500MB ( USB Media in Android, use it to save the ROM, Gapps and Universal Settings to Flash )
HpTp_MAX provides more RAM available and Android can use over 750 MB of swap space.
/swap 1GB or 500MB ( It allows Android to store temporally Data from RAM to allocate more Memory for Apps. )
/data depends on the model 16, 32 or 64 GB ( The free space available for Android Apps and user Data )
/boot 32 MB ( Is a fixed sized ) Moboot will be created and also TWRP Recovey 3.2.
The Tablet will boot as always, with Recovery in the Moboot Menu ready to Flash any ROM.
________________________________________________________________
Flash all listed ROMs in the order to download:
1. First the ROM ( Only the specific ROM by the built date will work )
2. HpTp MAX Universal Optimize Swap Settings ( Enables swap partition and provide the best settings for Android )
All_Files (name of the ROM) zip contains everything. Uncompress on PC first then flash the selected frequency.
2_A Optional -- HpTp_MaXtreme (Max Extreme Kernel for All ROMs)
Click HERE to Download HpTp_MaXtreme for All ROMs
If you do not know the maximum CPU speed of your Tablet flash 1674 first to set up.
All Kernels are the same, the speed is preset to avoid installing any Kernel App in Android.
Do not install any Apps in Android to make the Tablet work faster, it will be the opposite.
It will use more RAM and cause reboots, there is nothing to change.
This is a laptop with a touch screen keyboard not a phone.
3. Optional -- ROM Reducer Click HERE for ROM Reducer
4. Flash the Open Gapps according to the ROM version, is best to install Pico and build the system as need it.
5. Optional -- All listed ROMs have /system Read and Write enabled, Click HERE for Root access using SuperSu v2.82
6. Optional -- Universal Authority Click HERE for Universal Auhority
7. Important: Read the section on this guide -- Flash the ToolBox 2015-01-08-v42 by jcsullins into /boot
Flash the files in the listed order in TWRP all at one time.
The Tablet will boot into the Welcome setup screen as a brand new Device.
________________________________________________________________
Root access with SuperSu v2.82 for all the ROMs
5. Click Here to Download SR5-SuperSU-v2.82
________________________________________________________________
Evervolv v9 Android PIE by Elginsk8r
1. Click Here to Download the ROM
2. Click Here to Download HpTp_MAX, select All Files for this ROM
4. Click Here to download Google Open Apps
Select Platform ARM, Android 9 and the Variant you want, Pico is recommended
Click Here for detail information about the Pie ROM
________________________________________________________________
Dirty Unicorns v13 Android PIE by Flintman
1. Click Here to Download the ROM
2. Click Here to Download HpTp_MAX, select All Files for this ROM
4. Click Here to download Google Open Apps
Select Platform ARM, Android 9 and the Variant you want, Pico is recommended
Click Here for detail information about the Pie ROM
________________________________________________________________
Dirty Unicorns v8.1 Android Oreo by Flintman
1. Click Here to Download the ROM
2. Click Here to Download HpTp_MAX, select All Files for this ROM
4. Click Here to download Google Open Apps
Select Platform ARM, Android 8.1 and the Variant you want, Pico is recommended
Click Here for detail information about the Oreo ROM
________________________________________________________________
Evervolv 7.1.2 Android Nougat
1. Click Here to Download the ROM
2. Click Here to Download HpTp_MAX, select All Files for this ROM
4. Click Here to download Google Open Apps
Select Platform ARM, Android 7.1 and the Variant you want, Pico is recommended
Click Here for detail information about the Nougat ROM
________________________________________________________________
LineageOS 14.1 Android Nougat 7.1.2 by invisiblek
1. Click Here to Download the ROM
2. Click Here to Download HpTp_MAX, select All Files for this ROM
4. Click Here to download Google Open Apps
Select Platform ARM, Android 7.1 and the Variant you want, Pico is recommended
________________________________________________________________
CyanogenMod 12.1 Android Lollipop by Jcsullins
1. Click Here to Download the ROM
2. Click Here to Download HpTp_MAX, select All Files for this ROM
4. Click Here to download Google Open Apps
Select Platform ARM, Android 5.1 and only Pico
Click Here for detail information about the Lollipop ROM
________________________________________________________________
CyanogenMod 11 Android KitKat by Jcsullins
1. Click Here to Download the ROM
2. Click Here to Download HpTp_MAX, select All Files for this ROM
4. Click Here to download Google Open Apps
Select Platform ARM, Android 4.4 and only Pico
Click Here for detail information about the Kitkat ROM
________________________________________________________________
LineageOS 11 Android KitKat by Milaq November, 01 of 2019 Build
1. Click Here to Download the ROM
2. Click Here to Download HpTp_MAX, select All Files for this ROM
4. Click Here to download Google Open Apps
Select Platform ARM, Android 4.4 and only Pico
Click Here for detail information about the Kitkat ROM
________________________________________________________________
ROM Reducer
Click HERE for the Guide
2.Click HERE to Download, ROM Reducer is included in the All Files for each ROM.
________________________________________________________________
Universal Authority
Click HERE for the Guide
6. Click HERE for the Flash Files
________________________________________________________________
Flash the ToolBox 2015-01-08-v42 by jcsullins into /boot
________________________________________________________________
After successfully flashing any of the listed ROM the ToolBox can be flash into boot to maintain the battery.
Do NOT use the ToolBox to Resize or Repair Android Volumes.
If done it will corrupt all the Volumes ( Partitions ) and a PC with the Novacom driver must be use.
The ToolBox does not display the /swap partition, it was not created for that purpose.
Only after flashing all files from this guide the /boot partition has just enough space for the ToolBox.
7. Click Here to download all the files to flash the ToolBox to boot/
Flash_TPToolBox_v42_to_Boot.zip ( delete any splash *.tga images files and copy ToolBox into /boot )
Remove_TPToolBox_v42_from_Boot.zip ( delete the ToolBox from /boot )
If more than one ROM got flash and the ToolBox was not successfully copied to /boot then use this file:
Clean_Boot_Remove_All_ROM_Files.zip
It will create a back up of the boot files and clean /boot preserving the basic files, MoBoot and TWRP.
Then the Flash_TPToolBox_v42_to_Boot.zip can be flash.
Plus the Universal Optimize Swap Settings for the ROM installed in the Tablet.
The Universal Optimize Swap Settings copies the boot uImage for the ROM into /boot.
Keep all the downloaded files in the Micro SD card (USB Media) /external_sd ( it goes by all those names )
Any of the listed files can be flash any time and a PC is not required to maintain the battery of the Tablet.
Special Thanks to Jcsullins "The God Father of the HP Touchpad" for all the unique and great software that made it
possible to transition easily from WebOS to Android.
Click Here for my guide on How to unpack and repack the ToolBox
________________________________________________________________
/boot Partition Detail Information
________________________________________________________________
Code:
The boot partition was created with the basics to get everything working and provide
enough storage to accommodate:
TWRP/Recovery 3.2, each of the listed ROMs from Kitkat to Pie and the ToolBox.
The size of /boot is 32MB, is a fix size and can not be expanded.
Boot partition details after Automatic_Wipe_All:
Directories: size file name
bin 647.5k busybox
etc 16.1k lvm.conf
lib
lost+found
usr 1.2M lvm.static
Files: size
android.default.recovery 9 bytes
uImage 13 bytes (link to uImage.moboot )
uImage.moboot 63.8 K
uImage.Recovery 10.6 M
Total:
/dev/block/mmcblk0p13 size used available Use %
32.0M 14.1M 17.9M 44% /boot
A clean /boot has 17.9M of free space
Free Space After Pie ROM
/dev/block/mmcblk0p13
32.0M 20.8M 11.2M 65% /boot
The ToolBox is 11.2M
After flashing the ToolBox
/dev/block/mmcblk0p13
32.0M 31.6M 395.0K 99% /boot
There is only 395.0k available.
________________________________________________________________
HpTp Universal Optimize Swap Settings
________________________________________________________________
The following settings are applied to all listed ROMs and makes the Tablet work as a Laptop, not a phone.
All Developers have done a great job building the ROMs, if the same settings are apply then all performs very similar.
The hardware does not change and the basic requirements must be apply to all Android version.
There is nothing to add, but removed all the modules and only use the swap option.
The following features must be disable and can not be use:
Disable KSM, Low Memory Killer, CPU Boost, mpdecision
Changes in the Ramdisk:
The changes can be permanently modified using:
Click HERE to modify the Ramdisk
Not Permanent, Inside Android:
Click HERE to modify inside Android
File in the Ramdisk:fstab.tenderloin
Code:
/dev/store/swap none swap defaults swapprio=0, 0 0
File in the Ramdisk:init.rc
TCP Buffer increase to 6MB
Code:
on boot
# Define TCP buffer sizes for various networks
# ReadMin, ReadInitial, ReadMax, WriteMin, WriteInitial, WriteMax,
setprop net.tcp.buffersize.default 4194304,5242880,6291456,4194304,5242880,6291456
setprop net.tcp.buffersize.wifi 4194304,5242880,6291456,4194304,5242880,6291456
# Assign TCP buffer thresholds to be ceiling value of technology maximums
# Increased technology maximums should be reflected here.
write /proc/sys/net/core/rmem_max 6291456
write /proc/sys/net/core/wmem_max 6291456
extra_free_kbytes 20480
Code:
# system server cannot write to /proc/sys files,
# and chown/chmod does not work for /proc/sys/ entries.
# So proxy writes through init.
on property:sys.sysctl.extra_free_kbytes=*
write /proc/sys/vm/extra_free_kbytes 20480
# write /proc/sys/vm/extra_free_kbytes ${sys.sysctl.extra_free_kbytes}
File in the Ramdisk:Init.tenderloin.rc
Code:
on fs
# Enable swap partition
swapon_all /fstab.tenderloin
on property:sys.boot_completed=1
# Swap Partition Settings
write /proc/sys/vm/block_dump 0
write /proc/sys/vm/dirty_background_bytes 0
write /proc/sys/vm/dirty_background_ratio 10
write /proc/sys/vm/dirty_bytes 0
write /proc/sys/vm/dirty_expire_centisecs 600
write /proc/sys/vm/dirty_ratio 20
write /proc/sys/vm/dirty_writeback_centisecs 600
write /proc/sys/vm/drop_caches 3
# change in ramdisk init.rc write /proc/sys/vm/extra_free_kbytes 20480
write /proc/sys/vm/highmem_is_dirtyable 0
write /proc/sys/vm/laptop_mode 0
write /proc/sys/vm/legacy_va_layout 0
# write /proc/sys/vm/lowmem_reserve_ratio 32 32
write /proc/sys/vm/max_map_count 65530
write /proc/sys/vm/min_free_kbytes 40960
write /proc/sys/vm/min_free_order_shift 4
write /proc/sys/vm/mmap_min_addr 32768
write /proc/sys/vm/mmap_rnd_bits 16
write /proc/sys/vm/nr_pdflush_threads 0
write /proc/sys/vm/oom_dump_tasks 0
write /proc/sys/vm/oom_kill_allocating_task 1
write /proc/sys/vm/overcommit_memory 1
write /proc/sys/vm/overcommit_ratio 50
write /proc/sys/vm/page-cluster 8
write /proc/sys/vm/panic_on_oom 0
write /proc/sys/vm/percpu_pagelist_fraction 0
write /proc/sys/vm/scan_unevictable_pages 0
write /proc/sys/vm/stat_interval 1
write /proc/sys/vm/swappiness 100
write /proc/sys/vm/vfs_cache_pressure 100
# Increase readahead buffers on MMC devices
write /sys/block/mmcblk0/bdi/read_ahead_kb 0
# CPU Scaling
write /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq 384000
write /sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq 384000
write /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq 1674000
write /sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq 1674000
# Configure Performance
write /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor performance
write /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor performance
# Entropy
write /proc/sys/kernel/random/write_wakeup_threshold 2048
write /proc/sys/kernel/random/read_wakeup_threshold 1195
# I/O
write /sys/block/mmcblk0/queue/rq_affinity "0"
write /sys/block/mmcblk0/queue/scheduler "bfq"
________________________________________________________________
Disclaimer: I am not a developer, just a regular user like YOU that have found a way to improve the Tablet and would like others to benefit by sharing the information.
I am not the creator of any ROM, Recovery or App mentioned or used. All credits goes to the developers than have worked and provided the best ROMs there is for our Tablet and there are way too many to mentioned, but everyone know who they are! Thanks a lot to all of YOU (Developers for the HP Touchpad)!
Special Thanks:
@flintman for all his work creating TWRP Recovery and the many customs ROMs with the latest PIE.
@elginsk8r for developing and maintaining Evervolv ROMs, currently PIE.
* The stock Kernel has been modified to provide more RAM and a higher frequency.
Does seem pretty responsive, even though i have been downloading apps etc, to get it set up. I downloaded the Gapps as well not sure if that was mentioned in your post, but it will be necessary if you go with a clean install. With the DU 11/16 kernel couldnt get the play store to work. went back to the 6/18 and it worked but no videos would play...... so updated again to 11/16 and now both seem to be working ok. I think that could have been a problem with the initial ROMS, its been awhile so i cant remember but there were a few bugs there to work out as well. I will keep checking it out...
Thanks very much....much simpler
@ Touchie Pad,
Thanks for trying it out!
It will only work as intended by downloading the "Skz Kernel Optimize and Swap Partition enable" links provided.
It will not work at all by only downloading the ROM. The Dirty Unicorn ROM Kernel does not provide support for the swap file or optimized Android.
The proper Installation is:
1. Flash DU ROM "du_tenderloin-v12.5.3-20181116-0140-RC.zip" ( It has to be that in specific)
2. Flash one of the SKZ Kernel speed provided ( Without it, no optimization or use of the swap partition will happen"
3. You can install any Google Open Gapps, I have installed all version , please provide a link to the one that does not work for you and I will try it out!
4. If you want Root access you must install SuperSu and the SKZ Kernel allows System read and write ( is a complete open system)
Let me know if those were the steps you followed otherwise I will try to explain my instructions better!
Did the swap partition with the 2017.11.03 Evervolv build with nano Gapps and my tablet confuses me because it is so quick and responsive. Thank you HP_TOUCHPAD, shumash and everyone involved in making this happen.
Gborg3 said:
Did the swap partition with the 2017.11.03 Evervolv build with nano Gapps and my tablet confuses me because it is so quick and responsive. Thank you HP_TOUCHPAD, shumash and everyone involved in making this happen.
Click to expand...
Click to collapse
It is FAST and you can do a lot on it, mostly is all about the settings apply in Kernel and Ramdisk that makes the magic and giving Android OS room to breath by placing in swap unnecessary services not need it at the moment, instead of killing it and been limited to only 1GB of RAM, it can expand allocating a lot of memory to the active application. Once you close the App Android will clean up the RAM and load it from the swap file and everything goes back to normal. Android is the perfect OS for swapping.
Can you share which Kernel speed worked for you?
HP_TOUCHPAD said:
It is FAST and you can do a lot on it, mostly is all about the settings apply in Kernel and Ramdisk that makes the magic and giving Android OS room to breath by placing in swap unnecessary services not need it at the moment, instead of killing it and been limited to only 1GB of RAM, it can expand allocating a lot of memory to the active application. Once you close the App Android will clean up the RAM and load it from the swap file and everything goes back to normal. Android is the perfect OS for swapping.
Can you share which Kernel speed worked for you?
Click to expand...
Click to collapse
1782000 is what I flashed of the swap enabled kernel. That speed has been working well for me so I stuck with it. I am still using a few options in the L Speed app also. Nothing that contradicts the changes you have made. Just a few extra boosts and streamlining. The battery seems to drain more slowly also. I have not reflashed the A6 battery firmware since enabling swap and I expected the higher speed to drain more but everything is working great. No problems, no worries.
Gborg3 said:
1782000 is what I flashed of the swap enabled kernel. That speed has been working well for me so I stuck with it. I am still using a few options in the L Speed app also. Nothing that contradicts the changes you have made. Just a few extra boosts and streamlining. The battery seems to drain more slowly also. I have not reflashed the A6 battery firmware since enabling swap and I expected the higher speed to drain more but everything is working great. No problems, no worries.
Click to expand...
Click to collapse
Contrary to believe a higher speed will not drain your battery. By using this settings the Tablet will have an extremely power efficiency. A higher speed only means if the CPU needs power to run an App is not going to be limited by the governor, but when idle does not consume much power. The modules on the Kernel have been remove so there is no kernel workers checking on how much memory to clean and all that extra task that is not need it. If your tablet will run at 1836 you will see the big difference, but if you are using any App to improve anything you are not going to see the full potential benefit. All those apps are only setting things up that are already set and working in the background slowing things down. None of them are need it, this is been run as a Tablet mode setting not a Phone.
HP_TOUCHPAD said:
@ Touchie Pad,
Thanks for trying it out!
It will only work as intended by downloading the "Skz Kernel Optimize and Swap Partition enable" links provided.
It will not work at all by only downloading the ROM. The Dirty Unicorn ROM Kernel does not provide support for the swap file or optimized Android.
The proper Installation is:
1. Flash DU ROM "du_tenderloin-v12.5.3-20181116-0140-RC.zip" ( It has to be that in specific)
2. Flash one of the SKZ Kernel speed provided ( Without it, no optimization or use of the swap partition will happen"
3. You can install any Google Open Gapps, I have installed all version , please provide a link to the one that does not work for you and I will try it out!
4. If you want Root access you must install SuperSu and the SKZ Kernel allows System read and write ( is a complete open system)
Let me know if those were the steps you followed otherwise I will try to explain my instructions better![/QUOTE
I did it in that order...used pico and micro, also had the problem with the AOSP keyboard stopping which i remember having when i first flashed the ROMS. I flashed the 183 kernel..... works fast but i did have a reboot on the second day and the screen was just dark, rebooted a couple times and then reflashed the rom, and optimize, and super su files ......and all is up and running again. I was seeing -220ma drain up until i reflashed it. I will give it some more time to sort it all out, and play around with it a bit. The video playing is 1,000,000,000 times better, i love it, thanks a lot
Click to expand...
Click to collapse
Touchie Pad said:
HP_TOUCHPAD said:
@ Touchie Pad,
Thanks for trying it out!
It will only work as intended by downloading the "Skz Kernel Optimize and Swap Partition enable" links provided.
It will not work at all by only downloading the ROM. The Dirty Unicorn ROM Kernel does not provide support for the swap file or optimized Android.
The proper Installation is:
1. Flash DU ROM "du_tenderloin-v12.5.3-20181116-0140-RC.zip" ( It has to be that in specific)
All the testing that I have done and prove to be stable is on that version, I can only recommend what I have tested.
2. Flash one of the SKZ Kernel speed provided ( Without it, no optimization or use of the swap partition will happen"
All the settings are on the Kernel and Ramdisk (the boot image) no settings are on any ROM. If that Kernel is not apply no performance will happen it will be worse.
3. You can install any Google Open Gapps, I have installed all version , please provide a link to the one that does not work for you and I will try it out!
4. If you want Root access you must install SuperSu and the SKZ Kernel allows System read and write ( is a complete open system)
Let me know if those were the steps you followed otherwise I will try to explain my instructions better![/QUOTE
I did it in that order...used pico and micro, also had the problem with the AOSP keyboard stopping
Yes you are correct the Keyboard stops working in most of the ROM that is why I recommend it to install the FULL Google open Apps because, it will replace the stock Keyboard with the one original from google.
The issues has been around for as long as I can remember. The only way around is to flash another keyboard after installing pico and micro or you can do it manually. I do not know if I am allow to distribute google keyboard as a separte flash-able zip file, that will resolve the issue and all open gapps will work.
which i
remember having when i first flashed the ROMS. I flashed the 183 kernel..... works fast but i did have a reboot on the second day and the screen was just dark, rebooted a couple times and then reflashed the rom, and optimize, and super su files ......and all is up and running again. I was seeing -220ma drain up until i reflashed it.
If your tablet reboots at 1836, it may not be able to sustain that speed and it will be better to go for 1782, you will still be able to do the same. The CPU does not work at that speed all the time, only if it needs to and the cap is at 1836, but if stays that high and your CPU can not handle it then it will reboot, but others can maintain it.
I will give it some more time to sort it all out, and play around with it a bit. The video playing is 1,000,000,000 times better, i love it, thanks a lot
Click to expand...
Click to collapse
You will be able to play videos in HD 720 using youtube app and also the web browser. I use Opera as is easy to change to desktop mode and play music with the screen off. It can play for days none stop and no reboots, you can watch movies back to back a HD 720 no issues and will never close down or reboots, that is why the use of the swap file as an extra space to allocate memory resources.
But the most important do not install any app to optimize anything, it will make it worse, all the Kernel modules have been removed, there is nothing an app can do, just work in the background and make things worse.
It is set up to run as your PC or Laptop not as your Phone, that is the difference!
Click to expand...
Click to collapse
@HP_TOUCHPAD I have flashed the 1836000 swap optimized kernel and left things as they are. Interactive BFQ the preferred setup for best performance? In the Toolbox I have set it just below performance with dynamic scaling as well. This TouchPad functions like a tesseract now. Speed of light? Bwahahaha, that is nothing compared to this.
I did it in that order...used pico and micro, also had the problem with the AOSP keyboard stopping which i remember having when i first flashed the ROMS. I flashed the 183 kernel..... works fast but i did have a reboot on the second day and the screen was just dark, rebooted a couple times and then reflashed the rom, and optimize, and super su files ......and all is up and running again. I was seeing -220ma drain up until i reflashed it. I will give it some more time to sort it all out, and play around with it a bit. The video playing is 1,000,000,000 times better, i love it, thanks a lot[/QUOTE]
I updated the guide and added the Keyboard Flash file to be use with Pico and Micro and the others. My advice, if you want the Tablet to run smooth fast and stable, flash all those files in that specific order and everything will work as a brand new device.
Gborg3 said:
@HP_TOUCHPAD I have flashed the 1836000 swap optimized kernel and left things as they are. Interactive BFQ the preferred setup for best performance? In the Toolbox I have set it just below performance with dynamic scaling as well. This TouchPad functions like a tesseract now. Speed of light? Bwahahaha, that is nothing compared to this.
Click to expand...
Click to collapse
I know that is very contradicting after been accustom to use apps to get better performance, but with this set up none can be use.
The Kernel modules have been removed, there is nothing an app can do, it may even make the system unstable and worse.
The best is to disable the ToolBox in Evervolv. Is best to completely disable any background tune performance app. There is only two Governors Interactive and performance.
Is set to interactive by default it scales perfectly, no app is need it for that to happen is control my a kernel module.
Keep the system lean and simple you will get the best performance and efficiency. There is nothing to do, just don't install bloatware that will use resources without you knowing and creating lag.
HP_TOUCHPAD said:
I know that is very contradicting after been accustom to use apps to get better performance, but with this set up none can be use.
The Kernel modules have been removed, there is nothing an app can do, it may even make the system unstable and worse.
The best is to disable the ToolBox in Evervolv. Is best to completely disable any background tune performance app. There is only two Governors Interactive and performance.
Is set to interactive by default it scales perfectly, no app is need it for that to happen is control my a kernel module.
Keep the system lean and simple you will get the best performance and efficiency. There is nothing to do, just don't install bloatware that will use resources without you knowing and creating lag.
Click to expand...
Click to collapse
I am following your advice and doing as you say. Lean, simple and set to run fast has Android N running as well as kitkat did. Thank you very much @HP_TOUCHPAD
hello everyone! how does this swap thing influence flash storage? Will it degrade much faster using this way?
[/COLOR]
HepCat86 said:
hello everyone! how does this swap thing influence flash storage? Will it degrade much faster using this way?
Click to expand...
Click to collapse
With this age device and a swap partition in the flash memory being used often, it will likely degrade somewhat faster. No guarantee or prediction of how much faster because all devices behave differently. Think along the line how different TouchPads can functionally use different max processor speeds. You can have a quick and functional TouchPad that will degrade faster or one that is usable for almost nothing.
Great tutorial dude. Thanks !
Waiting to reboot after flashing rom/gapps/keyboard/kernel/su right now..
HepCat86 said:
hello everyone! how does this swap thing influence flash storage? Will it degrade much faster using this way?
Click to expand...
Click to collapse
I updated the guide with a short statement. I want to make things very easy and quick to follow but the problem is that there are more Taboo to dismantle than the settings itself.
I will try to explain in in here:
A swap file is created by default in all modern Linux installation. There is nothing new about this and everyone that has ever owned a PC knows about it.
Swapping only takes place when the system requires more memory than is physically available.
Any time you would like to see how much memory Android is using type this in on PC using adb shell or in terminal in Android:
free -h
This is Dirty Unicorns with basic ROM installed:
Code:
[email protected]:~$ adb shell
[email protected]:/ # free -h
total used free shared buffers
Mem: 828M 574M 254M 0 5.4M
-/+ buffers/cache: 568M 260M
Swap: 504M 0 504M
Is the basic ROM nothing installed.
This is Dirty Unicorn installed with Micro gapps as the guide:
Code:
[email protected]:/ # free -h
total used free shared buffers
Mem: 828M 804M 24M 0 8.9M
-/+ buffers/cache: 795M 33M
Swap: 504M 16M 488M
There is 16MB used in swap, because the system is set up to 60% swapping.
Android is the King of swapping, it does it all the time. Is not a true multitasking OS, it places background Apps in hibernation, temporally storage. Then when active it pick ups where it was left, it gets awake. The swap file is the perfect place to place anything that the user is not using at the moment and then load it later. It is not going to be use to be running the OS, it will be extremely slow to run Android or any App directly from swap space. Is only use to free RAM to run Apps and make the system stable instead of killing services and process.
The swap will help all the components by making the CPU, RAM and storage work less. To keep Android alive with only 1 GB or RAM the CPU has a lot of overhead and the RAM is been constantly in use. For example zRAM, compress Memory for swapping. The CPU has to compress and uncompressed everything that is going into zRAM plus the RAM is constantly been used with read and writes, none stop.
Is the other way around with swap, what is not need it is place there, nothing else is working , all at rest!
Hopefully this explain a little is the basic!
Steelskinz said:
Great tutorial dude. Thanks !
Waiting to reboot after flashing rom/gapps/keyboard/kernel/su right now..
Click to expand...
Click to collapse
You are welcome, but the only way to find out if the tutorial is set up properly is if the user can achieved the results.
Otherwise something got lost in the translation, hopefully it worked for you with no issues.
Update:
The Keyboard zip files got updated today February 23, to completely removed the LatinIME directory and then recreated again and copy all files the files from google Open Gapps Keyboard.
Pico works great now, it will be best to install the minimum and add Apps as you need.
The computer I used somehow deleted most of what I backed up from my TouchPad. It kept the TWRP backup of /boot in existence. For anyone with ample use and data on theirs this could aggravating but it caused me to do a cleaner clean install. I did not remember which apps I had on mine so I now have less than 80 total apps on mine and after flashing the full wipe zip and the swap partition creation zip I restored my backup of /boot so I had a TouchPad Toolbox uImage available in moboot and a spectacularly quickly performing tablet. Minimizing excess like this made my TouchPad as quick and responsive as the new iPad one of my roommates recently got.
I have one suggestion and one question -
Setup instructions for swap will be more understandable if accompanied by full written step-by-step instructions.
What are your thoughts on the effects of setting the number of background processes maximum to one or two after boot?
Swap allows for more to be done without lagging but these are still 8 year old tablets so I am curious about the expert opinions. @HP_TOUCHPAD and @shumash
It would be helpful to hear both of your thoughts on this matter.
Gborg3 said:
The computer I used somehow deleted most of what I backed up from my TouchPad. It kept the TWRP backup of /boot in existence.
When you back up the tablet using TWRP, you have to select the partitions /System and /Data. Boot is not necessary at all and you do not want to back up or restore boot in this case as it will restore LVM old configuration files. That is the reason that this guides wipes and reformat /boot and places TWRP on it.
For anyone with ample use and data on theirs this could aggravating but it caused me to do a cleaner clean install.
A clean install is the best option to do, there are Apps that will back up only the Apps if you do not use the Play Store
I did not remember which apps I had on mine so I now have less than 80 total apps on mine and after flashing the full wipe zip and the swap partition creation zip I restored my backup of /boot so I had a TouchPad Toolbox uImage available in moboot and a spectacularly quickly performing tablet.
After you do apply the Full wipe zip flash file it is not a good idea at all to restore /boot, and there is no need.
Boot keeps the uImages of the ROM and LVM ( storage partition configuration and size ). It could keep the old partition layout, I have not tried that myself.
Minimizing excess like this made my TouchPad as quick and responsive as the new iPad one of my roommates recently got.
The less Apps you have or keep it to what you really needs, the faster the Tablet will be. This apply to any computer. The worse is to have bloatware, most run in the background or create process that keeps the CPU working most of the time.
I have one suggestion and one question -
Setup instructions for swap will be more understandable if accompanied by full written step-by-step instructions.
What area do you think that must be written better?
1. How to back up and restore.
2. Or the process to flash the Wipe_ALL zip flash file.
What are your thoughts on the effects of setting the number of background processes maximum to one or two after boot?
The background process limit that you can setup under Developers options is how many Apps Android will keep in pause (hibernation), when you open another app, it has nothing to do with process that are launch to collect data or updates. Those are terminal commands to apply to each specifically installed Apps to prevent it from activating its data collection. Keep in mind Android and many Apps are free, but in exchange off data mining.
Swap allows for more to be done without lagging but these are still 8 year old tablets so I am curious about the expert opinions. @HP_TOUCHPAD and @shumash
It would be helpful to hear both of your thoughts on this matter.
Click to expand...
Click to collapse
Can you provide the link to the experts options? """ Corrections , Gborg3 said opinions my brain captured options """" This is a great example when humans interact!
All the flash files on provided on this guide will apply all the settings that any expert can do by entering line y line in a terminal window.
The tablet is old but the basic of streaming HD video, using the Web, running Apps, all that can be done as with any other device. The most important is to have the most current ROM and the open gapps installed.