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.
Related
This thread Is a compilation of speed tweaks and mods I have gathered from the forums and used on my Galaxy Player 4.0. I can vouch for all of these tweaks, and all provide at least a modest performance improvement. I claim no credit for any of these mods, the glory goes to the fabulous devs who have created them.
To show you the possible performance increase, I have all of these tweaks installed with the Terrasilent kernel and Klin's R5 ROM, plus an Overclock to 1.5 GHZ, and I have scored over 2750 in Quadrant, as indicated in the screenshot below.
If you have any potential tweaks or suggestions, PM me, and I will check them out!
Note to devs: I believe I have posted this in the right section, as this does not 100% pertain to development.
Now, let's get cracking!
Tweak No. 1: convert RFS filesystem to EXT4.
RFS has been tweaked since it debuted on the galaxy S over two years ago, but still is not quite up to par with today's standards.
Steps:
1. Flash the Terrasilent kernel/ Klin's R3 (basically a kernel with Clockwork recovery 5+ on it)
2. Make a nandroid backup (make sure you have enough free space!)
3.after you reboot, navigate using a file explorer on the Gplayer to the recovery directory and rename all files (excluding boot.img) from .rfs.tar to .ext4.tar.
4. Open up nandroid.md5 and change all filenames (again, excluding boot.img) from .rfs.tar to .ext4.tar
5.Save that, reboot into recovery, perform a full restore, and reboot into download mode.
6. reflash the kernel you were using, and you are done!
The performance improvement is amazing, and I would recommend using this tweak to anyone, since it's safe, and provides a huge boost!
Tweak no.2: Universal Adrenaline shot.
This is an amazing tweak that has provided the biggest improvement for me. It should be pretty risk-free if you follow my directions. Do NOT try to unzip and manually install, as you will have to reflash you rom (bootloop). Additionally, you will have to reinstall any init.d tweaks you have currently, as this script wants to ensure no conflictions, and deletes them all
Steps:
1. Head to this link, read, and download Adrenaline shot v14 (don't worry, our device can handle the two risky tweaks).
2. Boot into recovery, and flash!
3. After flashing, I would optionally format /cache. After reboot, you should see a drastic performance increase!
Tweak no.3: EXT4 Journalism tweaks.
EXT4 is much faster than RFS, but on our Players, the lag is still noticeable, just navigating around the UI.
WARNING:This provides a nice speed increase, especially to large games, but if you have an unclean shutdown, or force restart your Gplayer, YOU WILL HAVE TO RESTORE!
Dire warnings said, This actually increases the smoothness of the Gplayer a decent amount, although for me the risk far outweighs the benefit.
Your partitions are as follows:
System: STL9
Data: mmcblk0p2
Dbdata: stl10
cache (use this partition if you want to test):stl11
Remember, you need su permissions for all of this!
Instructions:
1.First, FSCK the partitions (make sure you answer no to all but the first questions, as that could lead to file corruption! the errors are generated when the partition is accessed during the FSCK, which generates an error, since data is in a different section than it was before. Don't worry, most/all of those errors are flukes. The instruction is: e2fsck -f /dev/block/(partition name)
2. Disable journalism with tune2fs: tune2fs -O ^has_journal /dev/block/(partition name)
Note: tune2fs will not have the capabilities necessary unless you install the one from the one shot adrenaline tweak above.
3.reboot and enjoy!
If you want to reverse this, you will have to restore a nandroid backup, as CWM formats EXT4 with journalism, and a format is required to reset it. On the same note, you will have to reapply this tweak every time you restore a nandroid backup, just something to keep in mind.
Tweak no.4: Supercharge, and apply Loopy smoothness!
I am sure everyone knows about the ubiquitous v6 supercharger script out there, and it provides a big performane increase! Also, Loopy smoothness helps a lot in stabilizing launcher performance, and I view them to be equally valuable.
1. Visit here to download the latest supercharger script, and here to download T2 of loopy smoothness.
2. Launch the supercharger from the /sdcard/download directory, go throught the basic instructions, and the custoomize, reboot, and install nitro lag nullifier. Optionally install for easier access. I would also explore some of the other options especially reindexing.
3. move the loopy smoothness script into the init.d directory, open it, and remove the quotation marks around the launcher name if you are using the touchwiz launcher, or delete the quotations and name and add your launcher's process name (run ps in terminal emulator and find the most likely name, or look it up).
That's it! you should notice a definite performance increase, especially improvements in multitasking thanks to v6 supercharger. The launcher should also be a lot smoother.
Bonus (I have it in R5 rom, but have not actually applied it)
head here, download the latest script, and run it. It should add some extra build.prop tweaks that will greatly boost performance!
Some final suggestions:
1. Move to a custom launcher.
Using touchwiz, I always had about 125+- ram free after using a taskiller, but when I moved to go launcher EX (imho, the best launcher for the gplayer out there, beautiful, not hard on resources, and very customizable), I had over 160+ free after using a taskiller, which resulted in far smoother operation, and excellent multitasking!
2. use ondemand or ondemandx.
All the Gplayer profiles are good, but ondemand, although not the best at power saving, provides the best performance on our aging system, and gives a little extra juice when you need it.
3. use the deadline governor.
None of the other I/O governors come even close to NOOP and Deadline, but deadline is better for everyday use, and noop is better if you have several file transfers occurring at once (eg. hooked up to a computer, updating apps, and browsing the web). It comes down to your usage style, but I prefer Deadline.
4. Disable uneeded /system/app apps.
Fortunately our Gplayer is pretty bloat free, but you can disable more apps if you want. You should rename them to .apk1 instead of deleting them, just in case. Do not delete phone.apk, because for some reason it breaks the default camera app ( you can delete it if you don't use it).
Open up a terminal, run the ps command, and disable any system, apps you recognise in the list (una, fota, etc.).
Beta: Format sdcard as ext2
I had limited success with this mod, and it is definitely worth hassle of converting to ext2. Unfortunately, you must have an init.d script that runs at boot, and there will be the occaisonal permissipn issue, but chmoding the sdcard fixes that.
Steps:
1. Backup all of your /sdcard data
2.connect the gplayer to a linux computer in mtp mode.
3. Open a terminal, and type:
sudo umount /dev/sdx
sudo mkfs.ext2 /dev/sdx
4. Disconnect it from the computer. It will output an error when the media scanner runs, this is okay.
5. Create an init.d script with the following info:
#!/system/bin/sh
mount rw /dev/block/vold/179:1 /mnt/sdcard
chmod 777 /mnt/sdcard
chmod 777 /mnt/sdcard/*
chmod 777 /mnt/sdcard/Android
chmod 777 /mnt/sdcard/Android/*
6. Reboot, and restore your data.
That should be it! I used ext2 because i got permission errors with ext3/4 constantly, and ext2 was stable. The performance improvement is amazing, especially with apps that store data to /sdcard. My performance is at least doubled! Even thouh this is beta, I STRONGLY recommend doing this, as the performance is incredible (as I said)!
Note: after doing this, windows machines will not recognize the player, you will have to do all file transfers via linux.
Note: of app data is not recognized after restore, delete and redownload, after backing up the save file/s. At the moment, it is the only way I have to fix it.
Enjoy the speed!
Dalvik machine: the ULTIMATE speed booster.
I was poking around lately, and I discovered that dalvik settings are really far more powerful than most people give them credit for. Using them on an (unreleased) version of EtherealRom gave me a nice speed increase!
All of these can be added/edited in build.prop, if you so choose, under the variable "dalvik.vm.dexopt-flags=".
The most important one is u=y. This indicates that you want all VM code to be optimized for a single core, and provides a NICE speed boost. The next most important is o=a, as that indicates that you want it to optimize ALL the code, instead of selective batches.
I will update this later, I am exhausted right now, and need some sleep.
I now have my own custom rom that you can flash, that includes most of these amazing features (no ext converting, that has to be manual), plus some more! Note: this rom is ONLY for the 4.0. you will have to restore if you flash it onto the 5.0!
Download
That's it! I will certainly add on as time progresses, but at the moment that is all I can remember/know about, so be sure to pm me with potential tweaks so I can put it up here!
hanthesolo said:
This thread Is a compilation of speed tweaks and mods I have gathered from the forums and used on my Galaxy Player 4.0. I can vouch for all of these tweaks, and all provide at least a modest performance improvement. I claim no credit for any of these mods, the glory goes to the fabulous devs who have created them.
To show you the possible performance increase, I have all of these tweaks installed with the Terrasilent kernel and Klin's R5 ROM, plus an Overclock to 1.5 GHZ, and I have scored over 2750 in Quadrant. If you don't believe me, I will put up a screenshot, as I don't have screen capturing software on my Gplayer right now, and it's too much of a hassle.
If you have any potential tweaks or suggestions, PM me, and I will check them out!
Note to devs: I believe I have posted this in the right section, as this does not 100% pertain to development.
Now, let's get cracking!
Tweak No. 1: convert RFS filesystem to EXT4.
RFS has been tweaked since it debuted on the galaxy S over two years ago, but still is not quite up to par with today's standards.
Steps:
1. Flash the Terrasilent kernel/ Klin's R3 (basically a kernel with Clockwork recovery 5+ on it)
2. Make a nandroid backup (make sure you have enough free space!)
3.after you reboot, navigate using a file explorer on the Gplayer to the recovery directory and rename all files (excluding boot.img) from .rfs.tar to .ext4.tar.
4. Open up nandroid.md5 and change all filenames (again, excluding boot.img) from .rfs.tar to .ext4.tar
5.Save that, reboot into recovery, perform a full restore, and you are done!
Note: after converting, my /data partition is deleted/not recognized when booting into recovery on the terrasilent kernel. I think this may be an isolated incident, but you have been warned!
Tweak no.2: Universal Adrenaline shot.
This is an amazing tweak that has provided the biggest improvement for me. It should be pretty risk-free if you follow my directions. Do NOT try to unzip and manually install, as you will have to reflash you rom (bootloop). Additionally, you will have to reinstall any init.d tweaks you have currently, as this script wants to ensure no conflictions.
Steps:
1. Head to this link, read, and download Adrenaline shot v14 (don't worry, our device can handle the two risky tweaks).
2. Boot into recovery, and flash!
3. After flashing, I would optionally format /cache. After reboot, you should see a drastic performance increase!
Tweak no.3: EXT4 Journalism tweaks.
EXT4 is much faster than RFS, but on our Players, the lag is still noticeable, just navigating around the UI.
WARNING:This provides a nice speed increase, especially to large games, but if you have an unclean shutdown, force restart your Gplayer, YOU WILL HAVE TO RESTORE!
Dire warnings said, This actually increases the smoothness of the Gplayer a decent amount, although for me the risk far outweighs the benefit.
Your partitions are as follows:
System: STL9
Data: mmcblk0p2
Dbdata: stl10
cache (use this partition iuf you want to test):stl11
Remember, you need su permissions for all of this!
Instructions:
1.First, FSCK the partitions (make sure you answer no to all but the first questions, as that could lead to file corruption! the errors are generated when the partition is accessed during the FSCK, which generates an error, since data is in a different section than it was before. Don't worry, most/all of those errors are flukes. The instruction is: e2fsck -f /dev/block/(partition name)
2. Disable journalism with tune2fs: tune2fs -O ^has_journal /dev/block/(partition name)
Note: tune2fs will not have the capabilities necessary unless you install the one from the one shot adrenaline tweak above.
3.reboot and enjoy!
If you want to reverse this, you will have to restore a nandroid backup, as CWM formats EXT4 with journalism, and a format is required to reset it. On the same note, you will have to reapply this tweak every time you restore a nandroid backup, just something to keep in mind.
Tweak no.4: Supercharge, and apply Loopy smoothness!
I am sure everyone knows about the ubiquitous v6 supercharger script out there, and it provides a big performane increase! Also, Loopy smoothness helps a lot in stabilizing launcher performance, and I view them to be equally valuable.
1. Visit here to download the latest supercharger script, and here to download T2 of loopy smoothness.
2. Launch the supercharger from the /sdcard/download directory, go throught the basic instructions, and the custoomize, reboot, and install nitro lag nullifier. Optionally install for easier access. I would also explore some of the other options especially reindexing.
3. move the loopy smoothness script into the init.d directory, open it, and remove the comments around the launcher name if you are using the touchwiz launcher, or delete comments and name and add your launcher's process name (run ps in terminal emulator and find the most likely name, or look it up).
That's it! you should notice a definite performance increase, especially improvements in multitasking thanks to v6 supercharger. The launcher should also be a lot smoother.
Bonus (I have it in R5 rom, but have not actually applied it)
head here, download the latest script, and run it. It should add some extra build.prop tweaks that will greatly boost performance!
Some final suggestions:
1. Move to a custom launcher.
Using touchwiz, I always had about 125+- ram free after using a taskiller, but when I moved to go launcher EX (imho, the best launcher for the gplayer out there, beautiful, not hard on resources, and very customizable), I had over 160+ free after using a taskiller, which resulted in far smoother operation, and excellent multitasking!
2. use ondemand or ondemandx.
All the Gplayer profiles are good, but ondemand, although not the best at power saving, provides the best performance on our aging system, and gives a little extra juice when you need it.
3. use the deadline governor.
None of the other I/O governors come even close to NOOP and Deadline, but deadline is better for everyday use, and noop is better if you have several file transfers occurring at once (eg. hooked up to a computer, updating apps, and browsing the web). It comes down to your usage style, but I prefer Deadline.
4. Disable uneeded /system/app apps.
Fortunately our Gplayer is pretty bloat free, but you can disable more apps if you want. You should rename them to .apk1 instead of deleting them, just in case. Do not delete phone.apk, because for some reason it breaks the default camera app ( you can delete it if you don't use it).
Open up a terminal, run the ps command, and disable any system, apps you recognise in the list (una, fota, etc.).
That's it! I will certainly add on as time progresses, but at the moment that is all I can remember/know about, so be sure to pm me with potential tweaks so I can put it up here!
Click to expand...
Click to collapse
Very nice thread! I'll try it once my device finishes charging. How did you manage to get 1.5 OC?
Thanks! you can tell I am more than a little OCD about my device's performance
I was able to achieve a stable OC by setting the internal voltage to 1.19V, and my core voltage to 1.4V, using Tegrak Overclock. This gives a nice increase to the performance of my player!
hanthesolo said:
Thanks! you can tell I am more than a little OCD about my device's performance
I was able to achieve a stable OC by setting the internal voltage to 1.19V, and my core voltage to 1.4V, using Tegrak Overclock. This gives a nice increase to the performance of my player!
Click to expand...
Click to collapse
I'm not really familiar with OC at all but you just change the voltage and the 1.5 OC option will appear? Didin't you modify your kernel a bit to do this?
As I said in the OP, I have the Terrasilent kernel installed, which allows by default overclocking up to 1.2 GHZ. If you install Tegrak Overclock Ultimate, you can load it's module and overclock up to 2 GHZ with a max internal voltage of 1250mv, and a max core voltage ov 1400MV. Suprisingly easy, actually, and an invaluable tool. You can also change the I/O governor like I suggested from it as well. Attached is A screenshot of my quadrant score (I decided to do it anyway). The score is slightly lower than I said because I have Journalling disabled (to much of a hassle to keep restoring every day).
hanthesolo said:
As I said in the OP, I have the Terrasilent kernel installed, which allows by default overclocking up to 1.2 GHZ. If you install Tegrak Overclock Ultimate, you can load it's module and overclock up to 2 GHZ with a max internal voltage of 1250mv, and a max core voltage ov 1400MV. Suprisingly easy, actually, and an invaluable tool. You can also change the I/O governor like I suggested from it as well. Attached is A screenshot of my quadrant score (I decided to do it anyway). The score is slightly lower than I said because I have Journalling disabled (to much of a hassle to keep restoring every day).
Click to expand...
Click to collapse
Oh ok you have tegrak ultimate. I had tegrak free and the limit was 1.3. Also for the journaling why don't you make a script to execute it at each boot?
Yeah, You can do some crazy stuff in the ultimate version!
I will upload the screenshot in the OP, the way I did it wouldn't work the first time
I didn't make journalism a init.d script because it is a one-time tweak, you apply it, and you have to reformat to go back! I also didn't spell out the instructions verbatim in case someone wants to selectively apply this tweak or use it as reference.
zaclimon said:
Oh ok you have tegrak ultimate. I had tegrak free and the limit was 1.3. Also for the journaling why don't you make a script to execute it at each boot?
Click to expand...
Click to collapse
Also, I have triesd to make an init.d script to disable journaling and putting tune2fs in /system/xbin, but it errors out because you can only disable journaling when the partitions aren't mounted. So what I did was copy tune2fs to a directory, boot into recovery, unmount all the partitions and then disable journaling.
Surprisingly my quadrant score jumped by 400 points.
Sent using Tapatalk
klin1344 said:
Also, I have triesd to make an init.d script to disable journaling and putting tune2fs in /system/xbin, but it errors out because you can only disable journaling when the partitions aren't mounted. So what I did was copy tune2fs to a directory, boot into recovery, unmount all the partitions and then disable journaling.
Surprisingly my quadrant score jumped by 400 points.
Sent using Tapatalk
Click to expand...
Click to collapse
I was able to do it (albeit with warnings during e2fsck) using merely the terminal emulator, and after fixing permissions on tune2fs (I manually placed it). I checked it with tune2fs -l /dev/block/(partition) | grep features, and it claimed that I removed the has_journalism flag. Plus, I got the wonderful benefit of corruption after an unclean shutdown.
Is Rom compatibile with SGP 5.0(International) if not can you please pm me some advice about how to port it on SGP 5.0 ?
Unfortunately, This rom is based soly on the SGP 4.0, and would be very difficult to port onto the 5.0. I am currently working on a flashable zip file that contains most of these tweaks, so you won't have to use the rom.
Ok thanks mate , i try two tweaks and its amazing....its awesome feeling when onecore processor 1.5Ghz defeat dualcore Tegra 2
Which two did you try?
what score did you get?
It DOES feel pretty awesome to see quadrant shoot up past a tegra device
Sneak preview: me and Klin are working together on his next version of his rom, and it will have all of these tweaks, plus some extras (read: ext4 sdcard)!
One thing I am not certain about with the adreneline shot; do I need to manually delete my init.d scripts, or will flashing this delete them?
Sent using Tapatalk
The scipt will delete them for you when you flash, but it shouldn't cause any issues if they are not deleted. If some conflict, it may reduce the overall performance boost, but that's the worst that could happen.
hanthesolo said:
Which two did you try?
what score did you get?
It DOES feel pretty awesome to see quadrant shoot up past a tegra device
Sneak preview: me and Klin are working together on his next version of his rom, and it will have all of these tweaks, plus some extras (read: ext4 sdcard)!
Click to expand...
Click to collapse
I try Ext4 and Adrenaline and i get 2612 points I enjoy for flashable pack of tweaks Nice work mate and good luck with all your projects PS sorry for my bad english
Glad it works! I am almost done testing ext4 sdcard, and I will have the steps up here soon. Additionally, Klin will release an update to his ROM with my tweaks includded in the next couple of days, along with more than one new goody
I don't get how you get such a high io score! My io is around 800!? I installed the adreneline tweak, but nothing noticeable, perhaps even worse performance. I have ext4 (I think, since I installed klin's r5). I use deadline scheduler. I also use v6 supercharger. What are you people's quadrant score with just the adrenaline and supercharger? No overclock.
Sent using Tapatalk
Klin's R5 only formats /system as ext4. to get the full benefit (and the noticeable increase), do it on all partitions using the guide on the OP. I would also use noop, as it seems to be slightly faster than deadline on ext4. Once you do that, you should get the increase.
Well, I just tried to convert to ext4 following your instructions, but following the reboot, it has been on the solid "samsung" (not the pulsing one) screen for several minutes, is this normal, or did something bad happen?
My idea is, get an old ROM CM and put all the new features of versión 4.2, all without the disadvantage of increased consumption of CPU, RAM BATTERY kit kat.
I took this rom: http://forum.xda-developers.com/showpost.php?p=47351443&postcount=1514&nocache=1&z=8687517631333321
And deleted more even more apps to increase performance, and put the current keyboard settings.
https://www.mediafire.com/?s5b5lc24oz0w6jp
Zimage : http://www.multiupload.nl/LV7RPIT01C
FM radio: http://d-h.st/H4x Settings> Audio> Method> Galaxy SL/i9003
Great performance and better batery life before : disable notification led (options>system), close all widgets, disable location, (options>location), me too, in devoloper options 0 process background, and close apps whit end button(last option)
I think, this rom + gps + bigmems kernels + full erase bada = perfect rom for samsung wave
can someone help? I would like to make a tuto.
I want to clarify that this is the work of the devs (volk, rebellos, tigrouzen and many more) to which we are eternally grateful, i just copy paste :laugh:
j-virus said:
My idea is, get an old ROM CM and put all the new features of versión 4.2, all without the disadvantage of increased consumption of CPU, RAM BATTERY kit kat.
I took this rom: http://forum.xda-developers.com/showpost.php?p=47351443&postcount=1514&nocache=1&z=8687517631333321
And deleted more even more apps to increase performance, and put the current keyboard settings.
https://www.mediafire.com/?s5b5lc24oz0w6jp
Great performance and better batery life before : disable notification led (options>system), close all widgets, disable location, (options>location), me too, in devoloper options 0 process background, and close apps whit end button(last option)
I think, this rom + gps + bigmems kernels + full erase bada = perfect rom for samsung wave
can someone help? I would like to make a tuto.
I want to clarify that this is the work of the devs (volk, rebellos, tigrouzen and many more) to which we are eternally grateful, i just copy paste :laugh:
Click to expand...
Click to collapse
Zimage for wave2?
I think u must download the rom from 1st page of this thread,this in there, the final kernel(im not sure)
http://forum.xda-developers.com/showthread.php?t=2400126
Bigmem kernel is quite easy to do (some lines to change in /kernel/arch/arm/s5pv210/mach-wave.c)
Doing multiple bootmode and an interactive menu as in Zendrokat is a bit more work
Installing on NAND require to do changes in the initialisation files in branch kernel and devices. I managed to do it BUT couldn't get usual method of installation working, had to use the dd if= of= linux command, and some issue with Read Write speed.
For GPS, just need to push last GPS commit and it should be fine.
In any case, it need to work from sources
I think, the internal memory of the wave its partitioned.
Maybe only erasing all nand and rename all nand like the partition of android sould be work.
about gps and bigmem kernel, i have no idea :laugh:
U know where are the gps drivers? if put the drivers in this zip or in other rom manually, works?
Indeed, the internal memory is partitioned FAT16 FAT16 FAT16
Easy to repartition it EXT4 EXT4 EXT4 (for /cache, /system and /data) to make it android compatible and get rid of these virtual partition (with some changes in Init files). Problem is that recovery don't want to install and got some speed issue.
I think GPS files are both in libmocha AND kernel, so it need to make changes in sources and recompile kernel. (It just need to identify files on Github and copy paste).
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?
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.
Dirty Unicorns Android 9, PIE by Flintman for HP TouchpadClick HERE for How to Flash the ROM
________________________________________________________________
Work in progress, not workingBluethooth
Camera
Home button________________________________________________________________
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 the ROM or Recovery mentioned.
All credits goes to the developer@flintman and the Dirty Unicorns Team.
________________________________________________________________
Nice Find Thanks!
Touchie Pad said:
Nice Find Thanks!
Click to expand...
Click to collapse
You are welcome!
The following does not work, installing only the ROM.
Camera
Bluetooth
Youtube plays very well
Very smooth
Microphone works.
Wifi works perfectly.
The only problem is that the internal storage is not accessible.
It can not even save screenshots, no access. ( it is fix on the 3-28-2019 version )
I dirty flashed the 13.x over 12.5x and did not do the open gapps, so I will have to sideload them I guess at some point since I cannot get to internal storage like you said.
It boots up, but lots of stuff does not work (like bluetooth). At least the March 2019 security updates are in place!
Thanks
I can't believe we now have Pie on the old work horse. Thank you so much. I wiped everything but internal storage and did a clean install with open pico gapps. I had previously installed the DU swap in the boot directory and booting with it goes to a boot loop. I went back to 8.1 and deleted the DU swap in the boot directory and did another clean install of 9. It came right up and the few apps I have installed work. I tried installing YouTube but the play store says this version is not compatible. It won't even show it as an option. There is no access to storage from either the files app or ES File Explorer. I even tried USB with Windows and android shades out the file transfer option. All my other Pie devices give you an option in setting to set up the SD as either removeable or internal memory. I am wondering if we need to reformat internal memory to get access. I hate to kill it since I have all my install files there as well as TP Toolbox. Any suggestions welcome.
This is the first version of Pie and it boots and works, but the permissions are set for root as the user and it does not allow access to the internal storage. ( is all fixed on version 3-28-2019 )
Flintman is working on it and fixing that issue. Keep in mind it takes time and dedication to do this.
I installed the full version of Google Open gapps that comes with youtube and it works perfectly fine. Pie will be optimize as soon as the access permission is fix.
The Tablet soon will be working better than ever and all updated to the latest software available!
HP_TOUCHPAD said:
This is the first version of Pie and it boots and works, but the permissions are set for root as the user and it does not allow access to the internal storage.
Flintman is working on it and fixing that issue. Keep in mind it takes time and dedication to do this.
I installed the full version of Google Open gapps that comes with youtube and it works perfectly fine. Pie will be optimize as soon as the access permission is fix.
The Tablet soon will be working better than ever and all updated to the latest software available!
Click to expand...
Click to collapse
First
First, A big thank you to Flintman! I went ahead and flashed with mini gapps as the smallest package containing YouTube and it works fine. I will wait for the storage until it is fixed. The only other question I have is on partition sizes. I left them at the recommended sizes for the DU swap. I may be wasting memory but all appears to be working. I have TP Toolbox resident just in case. Thanks again. Also I assume we should not use the SKZ kernel since this looks later.
johnbelloh said:
First
First, A big thank you to Flintman! I went ahead and flashed with mini gapps as the smallest package containing YouTube and it works fine. I will wait for the storage until it is fixed. The only other question I have is on partition sizes.
The partition sizes applied using the following:
HP TOUCHPAD Optimize for Android with Swap Partition and SKZ Kernel_ Flash Files_
Will work with Pie, Q and any future release of Android.
The /system partition is set to 1.8G, which can accommodate a Super variant of the google open gapps.
I left them at the recommended sizes for the DU swap. I may be wasting memory but all appears to be working.
Is storage space not Memory or RAM. It will be about 500MB to 600MB extra of storage space not Memory, it does not affect performance.
I have TP Toolbox resident just in case. Thanks again. Also I assume we should not use the SKZ kernel since this looks later.
Click to expand...
Click to collapse
There is no SKZ kernel for Pie at the moment and it will not work with Pie 9 as it only works with 8.1.
The stock Kernel of Pie 9 is not optimize yet to use the swap partition, as soon as Pie is fix it will be available and the system will improve performance and stability as more RAM (Memory) will be available in Android. (Update Pie is completely optimize more than any other ROM
https://download.dirtyunicorns.com/?device=tenderloin du_tenderloin-v13.0-20190328-1316-RC.zip
28 de marzo de 2019
293.42M
---------- Post added at 05:22 PM ---------- Previous post was at 05:21 PM ----------
du_tenderloin-v13.0-20190328-1316-RC.zip
28 de marzo de 2019 excelent room for TouchPad
larrywilson said:
https://download.dirtyunicorns.com/?device=tenderloin du_tenderloin-v13.0-20190328-1316-RC.zip
28 de marzo de 2019
293.42M
---------- Post added at 05:22 PM ---------- Previous post was at 05:21 PM ----------
du_tenderloin-v13.0-20190328-1316-RC.zip
28 de marzo de 2019 excelent room for TouchPad
Click to expand...
Click to collapse
Thanks for the update ! The direct link now is updated to 03-28-2019 built.
Very impressive. Every app I have installed works including storage. I have 6 touchpads including a brand new 4G model. Is the plan to add swap to the ROM or will it be a separate install? If I can be of any assistance testing just ask. Thank you to all involved.
johnbelloh said:
Very impressive. Every app I have installed works including storage. I have 6 touchpads including a brand new 4G model. Is the plan to add swap to the ROM or will it be a separate install? If I can be of any assistance testing just ask. Thank you to all involved.
Click to expand...
Click to collapse
Android Pie is optimize and is swap enable from the core, all settings are set to be use with the swap partition.
Flintman did a marvelous job incorporating all the changes and making Pie available for the HP Touchpad with more improvement on its way that it could be the best ROM ever. I will update this guide soon.
It is worth it if i'm on 8.1 with swap ? I saw that yesterday we have got a update..
Steelskinz said:
It is worth it if i'm on 8.1 with swap ? I saw that yesterday we have got a update..
Click to expand...
Click to collapse
If you are using 8.1 now and enjoying your setup, then my recommendation is to keep using it that way until Pie which is 100% stable now with more features than 8.1, gets Bluetooth working and any other minor issues resolved. As of now Pie is working as Oreo. Pie is using the swap partition and fully optimized as 8.1 and 7.1.2. The only thing to do is to flash it just like any other ROM.
Hi all,
I keep popping back from time to time, and each time just keeps getting better and better... We're now up to Android 9 Pie ?? WOW !!! Fantastic work guys to all involved...
Couple of questions if you don't mind...
1) I'm currently on Android 8.1 Oreo, not sure which build or when.. without picking it up yet. Is it likely this will already be using SWAP partition, or do I still have to go ahead with it?
2) If I don't have a SWAP partition, and go ahead and create one... If I want to use an older DM rom at a later date. Do I have to remove SWAP, or will it just ignore the partition on older builds?
3) So we can use WebOS and Android 9 side by side, sharing the SWAP ??
4) Is there anyway to make the Boot partition larger than 32mb, or is that set in stone?? - and where can I find the uImage file for ToolBox, so I can have that as one of my selectable boot options.
Thanks, Lister
Lister Of Smeg said:
Hi all,
I keep popping back from time to time, and each time just keeps getting better and better... We're now up to Android 9 Pie ?? WOW !!! Fantastic work guys to all involved...
Yes Flintman still providing support and now has created the best ROM.
Couple of questions if you don't mind...
1) I'm currently on Android 8.1 Oreo, not sure which build or when.. without picking it up yet. Is it likely this will already be using SWAP partition, or do I still have to go ahead with it?
The swap partition must be created as in this guide:
HP TOUCHPAD Optimize for Android with Swap Partition and SKZ Kernel_ Flash Files_
2) If I don't have a SWAP partition, and go ahead and create one... If I want to use an older DM rom at a later date. Do I have to remove SWAP, or will it just ignore the partition on older builds?
WebOS came with a swap partition and all the ROMS were install side by side with WebOS but never implemented the use of SWAP, Android 9 is the first ROM to completely take advantage of swap thanks to Flintman for applying all the changes. And all future version of Android for the HP Touchpad will have support for the swap partition.
3) So we can use WebOS and Android 9 side by side, sharing the SWAP ??
Yes the partition that is created is the original from WebOS dev/store/swap.
In WebOS is a 400 MB
The new partition is 500 MB, it can be change to any size if the user wants to.
If you want to use any new ROM, 7.1.2 ,8.1 and 9 the /system partition must be 1400 MB, it can be resize using the ToolBox.
4) Is there anyway to make the Boot partition larger than 32mb, or is that set in stone?? - and where can I find the uImage file for ToolBox, so I can have that as one of my selectable boot options.
The /boot partition is a fix 32MB can not be change and there is no need for it to be larger.
Download the ToolBox from Here
Unzip the file rename TPToolbox-2015-01-08-v42.bin to uImage.ToolBox
Using TWRP Recovery mount /boot and using the TWRP File Manager copy uImage.ToolBox to /boot.
Using TWRP any boot uImage can be move from /boot to the SDCARD and then can be copy back.
There is no need for /boot to be larger as the boot files can easily be copy to it when need it to be use.
Think of it as a CD or USB disk that you insert into the PC to boot from, is the same concept. If you need to use the ToolBox make some space by removing a boot uImage and then copy the ToolBox in /boot.
Thanks, Lister
Click to expand...
Click to collapse
You are welcome!
Hi @HP_TOUCHPAD,
First of all, thank you for the very prompt and DETAILED reply, this is perfect and contains EXACTLY what I need to know. And apologies for the delay getting back to you, my brothers son has been in hospital last couple of days... So been a bit back and forth.
Thank you for your post, very clearly laid out and full of useful information. I shall follow that guide and re-create a swap partition. Had a quick look last night, and looks like Flintman has re-compiled all his old roms to support SWAP partition too. So should make them smoother still..
Thanks once again...
Lister
HP_TOUCHPAD said:
You are welcome!
Click to expand...
Click to collapse
Hi @HP_TOUCHPAD,
I've just picked up my Touchpad, and I appear to be running a build of Oreo 8.1.0, the Dirty Unicorns 12.5.xx.
However, in TWRP.... I only appear to have around 296k free, and not enough to store the Toolbox uImage (around 10mb) in there?? Any idea's what I can free up??
The largest files I can see are:
uImage.Android 5.4mb (boots my Android install)
uImage.moboot 63.KiB (boot manager)
uImage.TWRP 8.7mb (boots TWRP)
uImage.webOS 3.2mb (boots WebOS)
uImage-2.6.35-palm-tenderlion 3.2mb (no idea??)
System.map-2.6.35-palm-tenderlion 1.4mb (no idea??)
There are many other files and folders in the \boot partition. But not sure what, or if... I can free up any of those files/folders??
Thanks, Lister
Lister Of Smeg said:
Hi @HP_TOUCHPAD,
Thank you for your post, very clearly laid out and full of useful information. I shall follow that guide and re-create a swap partition.
Had a quick look last night, and looks like Flintman has re-compiled all his old roms to support SWAP partition too. So should make them smoother still..
The ROMS Kernels available from my guide for Evervolv 7.1.2 and DU 8.1 are my changes to make use of swap with optimization.
Flintman integrated all the changes posted on my guide to the Kernel, Ramdisk and also to the ROM of Pie (9).
Android Pie (9) is the first ROM to completely take advantage of the swap partition thanks to Flintman for improving and making the extra changes.
Thanks once again...
Lister
Click to expand...
Click to collapse
You are welcome.
Lister Of Smeg said:
Hi @HP_TOUCHPAD,
I've just picked up my Touchpad, and I appear to be running a build of Oreo 8.1.0, the Dirty Unicorns 12.5.xx.
However, in TWRP.... I only appear to have around 296k free, and not enough to store the Toolbox uImage (around 10mb) in there?? Any idea's what I can free up??
The largest files I can see are:
uImage.Android 5.4mb (boots my Android install)
uImage.moboot 63.KiB (boot manager)
uImage.TWRP 8.7mb (boots TWRP)
uImage.webOS 3.2mb (boots WebOS)
uImage-2.6.35-palm-tenderlion 3.2mb (no idea??)
System.map-2.6.35-palm-tenderlion 1.4mb (no idea??)
There are many other files and folders in the \boot partition. But not sure what, or if... I can free up any of those files/folders??
Thanks, Lister
Click to expand...
Click to collapse
The /boot partition is 32MB, It shows that WebOS is also installed. Before moving any files from /boot make sure to do a backup just in case if the wrong file gets removed. The ToolBox does not need to be in the /boot directory to be use . It can be loaded into the memory by placing the Tablet into Recovery Mode and from the PC with the novacom drivers install load it.
novacom boot mem:// <uImage.ToolBox
The ToolBox will be loaded into memory and use for anything need it, there is no need to keep it in the /boot.
The most important file to be in /boot uImage.moboot 63.KiB (boot manager)