[Asus Transformer TF700] lucius.zen:
Please see post #2 for instructions and change log.

BASICS/PREREQUISITES:

To begin you must unlock, install TWRP, and acquire system files and mods.

Unlocking:

Use the Asus unlocking tool from the downloads section on the Asus TF700 support website. Simply install the .apk, run the app, and follow the prompts.

Installing TWRP

:

TWRP can be found here - http://xdaforums.com/showthread.php?t=1797692

Instructions for installing TWRP can be found here - http://xdaforums.com/showthread.php?t=1938129&highlight=root+custom+recovery

NOTE - To boot into TWRP press and hold the power and volume down button until white text appears in the top left corner of your screen. Release both buttons and press volume up.

System Files:

System files and mods can be obtained from the following links. Please thank/donate to the devs for all of their hard work.

CROMi-X [ROM] - http://xdaforums.com/showthread.php?t=2425383

Hundsbuah’s Kernel - http://xdaforums.com/showthread.php?t=2143093&page=80

Data2SD [Mod] - http://xdaforums.com/showthread.php?t=1962507

ROM2SD [Mod] - http://xdaforums.com/showthread.php?t=2501129

CrossBreeder [Mod] - http://xdaforums.com/showthread.php?t=2113150

DATA2SD/ROM2SD:

Data2SD works around poor I/O performance by giving us the ability to utilize a fast microSD card as our primary mode of storage. ROM2SD follows a similar premise as Data2SD; however, it also gives us the ability to dual boot any android ROM compatible with our tablet. The application of these mods results in apps opening faster, faster boot times, faster read/write speeds, and faster downloading/less lag while downloading. Step #1 and Step #2 only need to be followed the first time you apply these mods.

Step #1 - Create GParted Live USB Stick:

In order to run your tablet from a microSD card you will need to reformat it using Gparted (a linux based partition editor) installed on a live USB stick. A live USB stick has the image (.iso file) of a program burnt onto it so that it can be run at boot on a PC.

Find Gparted here - http://gparted.sourceforge.net/livecd.php

Download the live CD/USB image. The easiest tool for burning the image is the LinuxLive USB Creator.

LinuxLive USB Creator can be found here - http://www.linuxliveusb.com/

Download the program and install it. Simply follow the instructions within the program using the Gparted image.

Step#2 - Reformat microSD Card:

This involves booting into Gparted, clearing your microSD of existing partitions, and creating new partitions to store androids /system (ROM, kernel), /data (apps and data), and /media partitions (user data and media files - "sdcard0"), which were previously stored internally.

Boot Into Gparted:

Insert your live USB and microSD card into your PC. To boot into Gparted power on your PC and select one of the "FX" buttons to bring up the boot selection menu (I need to select F9). The live USB will be labelled something like "USB Diskette", or "USB Hard Disk". Select your live USB and follow the prompts to boot into Gparted.

Create Partition for External Storage:

Once Gparted has loaded delete any existing partitions on your microSD card. Next create a primary partition using the Fat32 file system at the very beginning of your card with at least 4Gb of storage (I am using 8Gb). This is recognized and functions as external storage so that we have a place to store flashable (installable) .zips and TWRP backups. It does not contain any data relevant to the functioning of our tablet.

NOTE - Partitions should be aligned to mb and ideally be divisible by 4.

Create Partition for System Storage:

After creating a partition for external storage we need to create partitions for androids /system, /data, and /media partitions. If you plan on using Data2SD you only need to make a second partition. If you plan on using ROM2SD then you need to make 2 additional partitions.

Data2SD - Create a second primary partition using the ext4 file system with the remaining space on your microSD. This partition will contain your /system, /data, and /media partitions. After you have created this partition you will need to flag it to run at boot. Right click the ext4 partition and select “Manage Flags”. Check the box beside “Boot”. You are done reformatting, simply exit Gparted.

ROM2SD - The second partition you need to make will contain your /data and /media partitions. The third partition will contain your /system partition. It only needs enough space to store your ROM and kernel so we will create it first at the very end of the microSD card. Create a primary partition using the ext4 file system with 1Gb of space. After you have created this partition you will need to flag it to run at boot. Right click the ext4 partition and select “Manage Flags". Check the box beside “Boot”. Now create another primary partition using the ext4 file system with the remaining space on your card. You are done reformatting, simply exit Gparted.

Step #3 - Install System Via TWRP:

I do not recommend setting up Data2SD or ROM2SD using old data. Please do a fresh install to avoid issues. I am able to wipe my tablet completely, install my system, set up my apps/data, and apply all of the tweaks in this guide in less than half an hour.

Getting Started:

If using Data2SD please download the "mount-data2sd.zip" file attached to this post (credit [MENTION=1953674]Mistar Muffin[/MENTION]). If using ROM2SD please download the "mount-rom2sd.zip" file attached to this post (credit [MENTION=4878287]_that[/MENTION]). Move this file, your ROM, your kernel, and any applicable mods to the Fat32 partition on your microSD card. Power down your tablet and boot into TWRP (see basics section for details).

Install Using Data2SD:

Boot into TWRP and wipe everything other than external storage (cache, dalvik cache, data, system, internal storage). To begin setting up Data2SD select CROMi-X for installation. Next choose "mount-data2sd.zip". This resets device nodes so that TWRP will install .zips to our microSD card rather than internal storage. Begin installation once the rest of your .zips are selected (ex - themes, mods, etc). During CROMi-X installation you will be presented with a kernel selection page. In the first section select your desired kernel. In the second section choose the Data2SD compatible option. When installation has finished reboot your tablet and set it up as usual.

Install Using ROM2SD:

Before proceeding check out _that`s ROM2SD thread so you understand how ROM2SD works - http://xdaforums.com/showthread.php?t=2501129. CROMi-X or miniCROMi-X users can utilize the following instructions to install ROM2SD, see the following post if you are dual-booting other ROMs - http://xdaforums.com/showpost.php?p=47333729&postcount=31.

Boot into TWRP and wipe everything other than external storage (cache, dalvik cache, data, system, internal storage). We begin by setting up our tablet to run from internal storage. Select CROMi-X or miniCROMi-X for installation. Hundsbuah's kernel and _that's kernel are available through CROMi-X and are ROM2SD compatible. Next choose any other .zips you need to flash (ex - themes, mods, etc). During CROMi-X installation you will be presented with a kernel selection page. In the first section select a ROM2SD compatible kernel, in the second section choose the 4th option. This installs CROMi-X to your internal storage and allows you to boot to an additional system on a microSD card. Once installation has finished reboot your tablet.

When you reboot you will be presented with the android set up wizard. Go through this as usual and set up you tablet. Once you have finished reboot your tablet back to recovery. Next we will set up our microSD. Select CROMi-X or the ROM2SD compatible version of miniCROMi-X for installation. Next choose "mount-rom2sd.zip". This file updates TWRPs device nodes so that .zips are installed to the correct partitions on your microSD card. Select the rest of the .zips you need to flash and begin installation. Once you reach the kernel selection page in the CROMi-X installer select your desired kernel and the third option in the second section. Once installation has finished reboot your tablet. After rebooting you should be presented with the android set up wizard again.

NOTE - To boot using internal storage remove your microSD card from your tablet and power on. To boot to using your microSD simply put it back in and turn on your tablet.

Creating/Restoring Nandroid Backups:

To create or restore a TWRP Nandroid backup you must first install mount-data2sd.zip or mount-rom2sd.zip. This resets device nodes so that TWRP will correctly backup/restore partitions on your microSD card. The "Backup" section allows you to create Nandroid backups. The "Restore" tool in TWRP allows you to restore Nandroid backups.

Wiping Partitions and Factory Reset:

Boot into TWRP and install mount-data2sd.zip or mount-rom2sd.zip. This resets device nodes so that TWRP will correctly wipe partitions stored on your microSD card. The "Wipe" section can be used to do a factory reset or selectively wipe your dalvik cache, cache, /system partition, /data partition, or internal storage.

NOTE - Partitions are mounted differently after implementing Data2SD/ROM2SD. The Fat32 partition on your microsd is recognized as "MicroSD". The media partition is still mounted as "sdcard0". It can be found in the /system/storage/ directory, along with your tablets internal storage, which is mounted as "sdcardi". If using ROM2SD you internal /data partition can be accessed via the/datai directory.

CPU/GPU FREQ CAPS:

With Hundsbuah's kernel you can set freq caps for the CPU and GPU within each of Asus' power modes (power saving, balanced, performance). The parameters we need to edit can be found in the following files:

cpu1.sh (power saving)

cpu2.sh (balanced)

cpu3.sh (performance)

Which are located in the following directory:

/system/etc/cpuX.sh

To apply the following tweaks a text editor is used to edit lines contained in the aforementioned files. I utilize the editor built into AntTek Explorer Ex.

GPU Frequency Cap:

The following lines set GPU voltage:

logi "echo GPU voltage > core_cap_level"

echo GPU voltage > /sys/kernel/tegra_cap/core_cap_level

To modify the GPU freq cap simply fill the red portion of the above lines with your desired GPU voltage. The GPU voltage determines the GPU freq cap. Here is how Hundsbuah's stock voltage table works, if you modify the voltage table these values will be different:

700 mhz - 1425 mV

650 mhz - 1387 mV

600 mhz - 1350 mV

520 mhz - 1300 mV

484 mhz - 1250 mV

446 mhz - 1200 mV

408 mhz - 1150 mV

361 mhz - 1100 mV

247 mhz - 1000 mV

200 mhz - 950 mV

GPU FPS Limit:

To unlock the GPU FPS limit and change it to 90 add the portion in red to the following lines:

logi "setprop persist.tegra.NV_FPSLIMIT 1"

setprop persist.tegra.NV_FPSLIMIT 1

logi "setprop persist.sys.NV_FPSLIMIT 90"

setprop persist.sys.NV_FPSLIMIT 90

CPU Frequency Caps:

To change the frequnecy caps for each CPU core fill the red portion of the following lines with the desired frequency:

logi "echo Core 1 freq cap > pwr_cap_limit_1"

echo Core 1 freq cap > /sys/module/cpu_tegra/parameters/pwr_cap_limit_1

logi "echo Core 2 freq cap > pwr_cap_limit_2"

echo Core 2 freq cap > /sys/module/cpu_tegra/parameters/pwr_cap_limit_2

logi "echo Core 3 freq cap > pwr_cap_limit_3"

echo Core 3 freq cap > /sys/module/cpu_tegra/parameters/pwr_cap_limit_3

logi "echo Core 4 freq cap > pwr_cap_limit_4"

echo Core 4 freq cap > /sys/module/cpu_tegra/parameters/pwr_cap_limit_4

Asus Power Saving Modes:

The following profiles are optimal for specific tasks/uses. They were designed to obtain a lag-free experience based on certain levels of CPU load.

Power Saving - Used for tasks with a moderate to high load for extended periods of time (productivity, browsing heavy websites, streaming video online, heavy multitasking)

- GPU Voltage/Freq = 1425/700

- Core 1/2/3/4 = 1750000

- Quadrant Score - 7400-7500 (Screenshot - https://www.dropbox.com/s/jqdcrwc7t...core - Power Saving Mode (max 1.75Ghz).jpg?m=)

Balanced - Used for tasks with low to moderate load (general use, light browsing, email, media consumption, etc.)

- GPU Voltage/Freq = 1425/700

- Core 1/2/3/4 = 1600000

- Quadrant Score - 6900-7000 (Screenshot - https://www.dropbox.com/s/zlfhnv1jq...ant Score - Balanced Mode (max 1.6Ghz).jpg?m=)

Performance - Used for short intense workloads

- GPU Voltage/Freq = 1425/700

- Core 1/2/3/4 = 1900000

- Quadrant Score - 8000-8100 (Screenshot - https://www.dropbox.com/s/iv5wawq49...ant Score - Performance Mode (max 1.9Ghz).jpg)

INTERACTIVE GOVERNOR TWEAKS:

The CPU governor controls how the CPU scales through frequency steps in response to changes in CPU load. CPU load reflects the difference between our processors current power (increased by freq and voltage - decreased by leakage) and the power needed to effectively process work queued up by the process scheduler. The magnitude and variability of CPU load are important indicators of processor performance. As load increases instances of lag also tend to increase. If we were to graph instances of lag/stuttering and CPU load over time you would see that stuttering happens most when load is high. An unstable, or highly variable CPU load indicates that CPU scaling is not responsive to the demands of the process scheduler; its almost as if scaling is a half-step too late. In this condition scaling is generally erratic, which decreases time spent idling, system stability, and responsiveness. Ideally we want CPU load to be as low and stable as possible as this indicates scaling is working efficiently. The amount of power a CPU can output does not matter; if it is not effectively scaled based on changes in load then lag/unresponsiveness is bound to occur. The following governor tweaks improve the efficiency of CPU scaling. To evaluate their effectiveness Android Tuner was utilized to monitor CPU load, CPU scaling in real-time, total time spent at each frequency step, and core temperature during benchmark tests and actual use. Detailed explanations can be found beneath each tweak.

NOTE - You will need to write an init.d script to apply the following tweaks. See my guide to writing init.d scripts for details - http://xdaforums.com/showthread.php?t=2198510.

NOTE - CROMi-X Users - The following tweaks, aside from max_boost, are applied by default in CROMi-X.

timer_rate - 20000

Sets the rate at which the governor samples cpu load. Lower values result in scaling that is too jumpy. Higher values result in scaling that is not responsive enough.

min_sample_time - 40000

Sets the minimum amount of time spent at a freq step before scaling down. The interactive governor samples CPU load every 2 ms. If the CPU is underpowered core freq is ramped up. Once load decreases the CPU is scaled back down. By default the CPU must spend at least 3 ms at a freq before it can scale down, which does not make sense if the governor is set on a 2 ms timer. A 4 ms minimum downscaling delay makes sense - the timer samples load twice before scaling down. Load tends to fluctuate drastically with touch devices; thus we do not want the CPU to scale down if it is going to have to ramp up again. Having a 2 ms timer allows the CPU to be scaled up quickly, while a 4 ms down scale delay prevents the CPU from downscaling early.

midrange_freq = 760000 - set as close to middle of freq table as possible

Needs to be recalibrated to reflect modified freq caps. If core freq caps are increased midrange freq should be adjusted so that the governor knows how to control the CPU properly.

max_normal_freq = 1300000

Instructs the CPU to jump to this freq when midrange_go_maxspeed_load is reached. For some reason this tweak has had a greater impact on performance than any of my governor tweaks. Before applying this tweak 475 mhz and max frequency are used most while under low/moderate load. After applying this tweak 475 mhz and 1.3 Ghz are utilized more often, as are a wider range of freq steps. Despite spending far less time at max frequency benchmark scores and performance have increased.

max_boost = 1900000 - set to highest freq available

Max boost is a mechanism for clearing a mounting queue as quickly as possible to prevent lag. It will do its job most effectively if we give it as much juice as possible. Controlled by go_maxspeed_load.

NOTE - CROMi-X Users - To apply the above tweak delete or edit the line changing max_boost under "#CPU and VM Tweaks" in sdbags 50CleanTWEAKS init.d script.

midrange_go_maxspeed_load = 65

go_maxspeed_load = 85

Optimal for keeping CPU load low and stable. Through my testing I have found that it is more efficient to adjust freq a little earlier by setting load thresholds lower (65/85) than it is to make adjustments when load has already gotten relatively high. Improves responsiveness without hurting battery life because the CPU spends more time idling.

To implement the above tweaks add the following lines to your init.d script:

echo "20000" > /sys/devices/system/cpu/cpufreq/interactive/timer_rate

echo "40000" > /sys/devices/system/cpu/cpufreq/interactive/min_sample_time

echo "760000" > /sys/devices/system/cpu/cpufreq/interactive/midrange_freq

echo "1300000" > /sys/devices/system/cpu/cpufreq/interactive/max_normal_freq

echo "1900000" > /sys/devices/system/cpu/cpufreq/interactive/max_boost

echo "65" > /sys/devices/system/cpu/cpufreq/interactive/midrange_go_maxspeed_load

echo "85" > /sys/devices/system/cpu/cpufreq/interactive/go_maxspeed_load

NOTE - Detailed descriptions of each governor can be found at the following link - http://xdaforums.com/showthread.php?t=1369817.

HOTPLUG CONFIG:

The hotplug config in Hunds Kernel allows you to control how CPU cores are brought online as threads are processed. A thread is the smallest sequence of instructions that can be managed independently by a process scheduler. Threads are contained within a process. A process is the execution of instructions contained within a program. On a single processor system multi-threading (multitasking) is generally implemented by transmitting/sending signals over a common path; the processor switches between different threads. This switching generally happens frequently enough that the user perceives the threads or tasks as running at the same time. If the CPU is overloaded and a thread is queued up by the process scheduler then lag/stuttering is likely because thread switching does not occur quickly enough to be hidden from the user. On a multi-core system threads can be truly concurrent, with every processor or core executing a separate thread simultaneously, which decreases the potential for lag/stuttering. If core 1 is busy processing a thread and another thread is queued up by the process scheduler we want an additional core to become active so that core 1 does not have to switch between threads. However, we also do not want to bring cores online needlessly. If a core is able to process multiple threads fast enough such that switching is unnoticeable then it would be inefficient to bring another core online.

NOTE - CROMi-X Users - The following tweak is applied by default in CROMi-X.

To change the hotplug config add the following line to your init.d script:

echo "2 4 6" > /sys/kernel/rt_config/rt_config

Instructs the kernel to bring core 2, 3, or 4 online when more than X threads are active. Core 2 is brought online when 3-4 threads are active, core 3 is brought online when 5-6 threads are active, and core 4 is brought online when 7+ threads are active. Through my testing I have found that a single core running at 475 Mhz has enough power to effectively process a constant low load. If hotplugging values are set lower then the kernel tends to unnecessarily bring additional cores online while in a low load state. If the kernel is told to activate cores later then we begin to notice lag/stuttering due to thread switching.

KERNEL TWEAKS:

The following tweaks directly impact how the kernel controls our tablets hardware.

CPU Frequency Table:

The CPU frequency table sets the frequencies that are available to the CPU. The following tweak modifies the minimum freq step that is available to the CPU, to apply it add the following line to your init.d script:

echo "475000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq

Through my testing I have found that if an app is open and generating a very low load we cannot utilize frequencies below 475 mhz. If allowed to drop below 475 mhz core freq bounces between 204 mhz and 475 mhz while in an active low load state; which indicates that freq steps below 475 mhz are incapable of handling the load induced by the activation of a foreground app. Preventing the CPU from dropping below 475 mhz increases responsiveness and stabilizes CPU load as the CPU cannot drop to ineffective frequencies. This does not impact battery life because of the design of the Tegra 3 processor. The Tegra 3 has 5 cores; 4 primary fast-process cores and 1 slow-process battery saving core. If our tablet is asleep or idling/inactive (no foreground app) then processing is handled by the low-powered battery saving core. If any foreground app is open our kernel activates a combination the 4 primary cores. Scaling_min_freq has no impact on the battery saving core. Therefore, increasing scaling_min_freq ensures we utilize effective frequencies while in an active state without preventing the CPU from dropping to lower frequencies while inactive.

CPU Voltage Table:

The CPU voltage table sets the voltages that are supplied to frequencies in the frequency table. Processing power is increased by frequency and voltage; while it is decreased by leakage, which is increased by heat. As voltage increases so does heat. Therefore, voltage has a positive and negative impact on processing power. The optimal voltage table balances the costs of reducing voltage with the benefits of reducing heat. When undervolting we want to drop voltages as low as possible without decreasing the load that a frequency step can handle. If voltages are dropped too low the need to jump to higher frequencies negates the benefit of running lower voltages. At this point, stability is also compromised. In order to change your CPU voltage table add the following line to your init.d script:

echo "1337 1300 1275 1250 1225 1200 1175 1150 1125 1100 1075 1050 1025 1000 975 950 925 900 875 850 825 800 775 750 725 700 687 675" > /sys/devices/system/cpu/cpu0/cpufreq/UV_mV_table

The voltage table above has been rescaled and undervolted such that heat production is decreased while performance and stability are maintained. Battery consumption correspondingly decreases as less voltage is drawn by each freq step. Lower voltages are used across the entire table yet the undervolting is not very severe, if voltages are dropped any lower the load that each freq step can handle begins to decrease and introduce instability. The lowest and highest freq, where CPU utilization is highest, are undervolted the most. The voltages supplied by the table are optimal for the load each freq step needs to process, which is indicated by improved CPU scaling. CPU load is lower and more stable, low to mid range freq are used more, and upper range freq are used less. The CPU responds to changes in load more appropriately; while in a low load state we are much more likely to jump to a midrange feq than an upper range freq.

GPU Voltage Table:

The GPU voltage table sets the voltages that are supplied to freq in the freq table. Hundsbuah's voltage table is nearly optimal. The voltage supplied to 700 mhz (1425 mV) cannot be dropped without negatively impacting performance. That being said, the voltages supplied to lower freq can be dropped and rescaled such that performance is maintained. The following voltage table reduces heat production and battery consumption without impacting performance and stability. To edit your GPU voltage table add the following line to your init.d script:

echo "1425 1375 1325 1275 1225 1175 1125 1075 1025 975 925" > /sys/devices/system/cpu/cpu0/cpufreq/gpu_voltage_control

I/O TWEAKS:

I/O (input/output) refers to the communication between an information processing system and external sources (users, network cards, monitors etc). I/O operations involve an input device, a processing unit, and an output device. Whether or not a device is classified as input or output depends on one's perspective because many devices can serve as an input or produce output. Within computer architecture the CPU is the processing unit and main memory (RAM) is the output device. Any operation involving the transfer of data to/from this combination (ex - from an SSD) is considered I/O. I/O operations utilize both slow-access bulk storage (ROM) and fast-accesss memory (RAM), which prevents the CPU from processing flows of information at the same rate in both directions. The bottleneck introduced by R/W operations on slow-access storage often underlies laggy/unresponsive performance. I/O scheduling is utilized to avoid lag/stuttering that results from disparate rates of information processing.

Scheduler:

I/O schedulers control the flow of information between input devices, processing units, and output devices. Schedulers utilize algorithms to maximize the efficiency of I/O operations. Thus, I/O performance is significantly impacted by the scheduler that we use. To evaluate each scheduler's performance both Quadrant and Android Tuner were used; Quadrant for global I/O performance, Anroid Tuner for specific R/W speeds. I ran all schedulers through 6 trials in Quadrant and 6 trials in Android Tuner to control for variability in test scores and the effects of confounding variables. Following trials I calculated the mean R/W speed of each scheduler for all tested file sizes. Mean memory, I/O and total Quadrant scores were also calculated. Schedulers were then ranked from 1-6 within the previous measures. Finally, schedulers were ranked globally based on the mean of all within measure ranks. Results are as follows:

1)sio

2)deadline

3)row

4)cfq, noop

5)bfq

While the aforementioned ranks accurately reflect global I/O performance schedulers excel in a different areas. I suggest checking out my data at the following link and selecting the scheduler that is optimal for your system - https://www.dropbox.com/s/iie89tn33qe07j8/Lucius.Zen - IO Scheduler Data.xlsx?m=.

NOTE - CROMi-X Users - The following tweak is applied by default in CROMi-X.

To change your scheduler to "sio" add the following line to your init.d script:

echo "sio" > /sys/block/mmcblk0/queue/scheduler

echo "sio" > /sys/block/mmcblk1/queue/scheduler

NOTE - Detailed descriptions of each scheduler can be found at the following link - http://xdaforums.com/show....php?t=1369817.

NOTE - Additional I/O tweaks can be found in the "I/O Scheduler Tweaks" section in post #3.