[KERNEL][GPL][Linaro][WiFi/3G] motley b49 2013-02-24 (added dynamic GPU OC)

Search This thread

_motley

Senior Member
Aug 17, 2010
858
2,360
motley kernel for the Nexus 7 and Jellybean

Disclaimer: You know the gig...I am not responsible for damaging your device or voiding your warranty. Play at your own risk!

ROM devs/cooks: If you want to use this kernel in your ROM, I am fine with that, but please include a "thanks" and a link back to this thread. Thanks!

Requirements (please read carefully and visit the other dev threads as necessary)
  • You must be unlocked and rooted.
  • You must have custom recovery installed (CWM or TWRP) to install the kernel.
  • Busybox is required for init.d support.
  • Do a backup using custom recovery (CWM or TWR) so you can restore your boot.img and ROM if necessary!
  • Have your ROM zip in /sdcard so you can restore your ROM if necessary.
  • System Tuner is recommended for tuning the CPU, especially for voltage control.

Main Features
  • GPL compliant - source is kept up to date at github.com and released at the time the kernel is released to the public for all builds. Ask other devs to do the same!
  • Asus\Nvidia\Google Linux 3.1.10 base. All stock features are supported (camera, OTG, NFC etc.)
  • OC to 1.6GHz (optional)
  • Voltage control - be careful to not save the setting on boot until you are 100% sure!
  • GPU OC from 416 to 520MHz (default is 446, adjust as you wish up to 520MHz)
  • Dynamic EDP - allows EDP to remain enabled (safer), but with an added simple temperature throttle switch (based on Asus Prime)
  • Compiler optimizations (-O2) - using Linaro 4.7 ARM toolchain
  • I/O schedulers - row (default), SIO, V(R), CFQ, NOOP, and deadline
  • TCP Congestion Control - default cubic + several different algos to choose from.
  • ZRAM - must be enabled by a script
  • Governors - Interactive (default), Performance, OnDemand, PowerSave, Conservative
  • initramfs - insecure (your ROM must have busybox)
  • CIFS/UTF8, NFS, NTFS r/w, TUN - built-in, no need for any kernel modules
  • fsync sysfs enable/disable switch (defaults to fsync enabled)
  • kexec with hardboot (for supporting Linux/MultiROM)
  • Many other misc patches and tweaks (see github link below)

Install:
  1. Check the requirements above!
  2. Flash the zip using custom recovery (no need to wipe anything)
  3. See post 2 for performance tweaks and more info

build #249 for Jellybean 4.2.2 - WiFi and 3G 2013-02-24
  • Added ability to change GPU clock speed at runtime (referenced franco, morific, and metallice git repos)
  • Added row io scheduler and set as default (Tatyana Brokhman)
  • Added TCP Congestion Control, several different algos to choose from. Default is cubic (stock).
  • Added optimized ARM RWSEM (Ezekeel)
  • Input patch (Henrik Rydberg)
View attachment motley_anykernel_N7_build_249.zip

build #247 for Jellybean 4.2.2 - WiFi and 3G 2013-02-17
  • Merged 4.2.2 patches
  • Updated Linaro toolchain to 2012.12
View attachment motley_422_nexus7_anykernel_build_247_446GPU.zip

build #246 for Jellybean 4.2.1 - WiFi and 3G
  • kexec\MultiROM support
Download from here since I posted in the MultiROM thread

build #244 for Jellybean 4.2 - WiFi and 3G - Recommended for WiFi and 3G on 4.2.x
  • 446 GPU build (stock + 30MHz). Let's see if this fixes touchscreen issues for those having them. My theory is that after the GPU heats up, this starts to affect touchscreen behavior on some devices. This is likely what happened to me on build 234 when I was testing. The GPU definitely gets hot on this device even with normal usage at 484+. At 446 this doesn't happen. IMHO, we are reducing the life of the device by overheating the GPU repeatedly. My Antutu scores actually tested higher after I flashed the 446 build.
  • Supports Android Jellybean 4.2.x
  • Reverted some commits from 233
  • Removed KSM from config, no ROM is using this AFAIK
  • Panel clock reduced to match Nvida cardhu sources (74180000). Having the panel clock cranked up fakes out scores on some benchmark tests, but adds no real value.
View attachment motley_nexus7_anykernel_build_244_446GPU.zip

Previous builds and release notes

build #234 for Jellybean 4.2 - First properly working 3G build
  • Supports Android Jellybean 4.2.x
  • Only change - added CONFIG_USB_NET_RAW_IP=y to hopefully address any issues with 3G (reported working by DiamondBack)
View attachment motley_nexus7_anykernel_build_234_484GPU.zip


build #233 for Jellybean 4.2 - if you don't have issues with GPU OC @484, this build may work well for you.
  • Supports Android Jellybean 4.2.x
  • Updated to latest Linaro toolchain 2012.10.22 and tweaked some compiler options.
  • Should support 3G as I have merged the Google patches, but I have not tested this.
  • Removed WiFi PM_FAST toggle as I see no need for this (PM_MAX for better battery is already the default in stock)
  • Stopped logging temp warnings until lit gets to 65C near the EDP throttle limit.
  • Quad-core tweaks - referenced showp1984's bricked grouper kernel source
  • See github for other minor details.
View attachment motley_nexus7_anykernel_build_233_484GPU.zip


build #232 - Recommended for WiFi on 4.1.2
  • Added support for Android Jellybean 4.1.2
  • Updated to latest Linaro toolchain 2012.10.22.
View attachment motley_nexus7_anykernel_build_232_484GPU.zip (GPU OC 484MHz)


stable v1.1.1 - builds #218-220 - Recommended for WiFi on 4.1.0 or 4.1.1
  • Supports Android Jellybean 4.1.1 or 4.1.0
  • DVFS tweaks and drop top cpu frequency to 1600, not much is lost and it should now be stable for everyone I hope. We pushed the envelope to 1.7 and 1.624 and now we are back to real world sensible decisions. My Nenamark2 520 GPU scores actually went up.
  • Dynamic EDP temp adjusted from 67 to 68C to catch temp notifier quicker when cooling back down.
  • Other miscellaneous patches
  • Just in case, please note and then unset your saved voltage control settings before using the new version. You may need to clear your System Tuner App data to see the correct frequencies. Remember that the DVFS table and the scaling frequencies are different in some cases (see the second post for details)
View attachment motley_anykernel_nexus7_1.1.1_NoGPUOC_build_220.zip (GPU stock 416GHz)
View attachment motley_anykernel_nexus7_1.1.1_GPU484_build_219.zip (GPU OC 484MHz)
View attachment motley_anykernel_nexus7_1.1.1_GPU520_build_218.zip (GPU OC 520MHz)

alpha v1.1.0 - builds #213-215
  • Added fsync sysfs enable/disable switch (thanks Ezekeel). fsync is still enabled by default. For more info and how to disable, see post 2.
  • Experimental: now forging speedo id 4 and process id 2 so that EDP limits are slightly raised and it narrows everyone down to a common DVFS record for everyone. Raised Dynanic EDP governor to 67C (from 60C) to give a little more room before edp is allowed to enable.
  • Minor cpu voltage table tweaks aiming for slightly better battery for those that don't undervolt.
  • Lowered the cold offsets from 50 to 25 for the top 4 cpu voltage slots. This will give folks a little more breathing room when undervolting and may help cold performance a bit if your voltages are lowered close to their lower limit.
  • Deadline i/o scheduler (morfic's secret 1:1 sauce that I remember back from my Iconia A500 days!). SIO is still the default, but we can try it out and see what we think.
  • OnDemand really wasn't usable in it's stock state since it was so laggy, so I have made some tweaks to the tuneables and it seems to be better now for those that want to give it a spin. Interactive is still the default governor.
  • cpu transtition latency lowered - fairly certain that it only affects OnDemand governor and not Interactive (reference morfic and http://permalink.gmane.org/gmane.linux.ports.tegra/1649)
  • Reverted most of the adjustments to the tegra 3 algorirthim for bringing cpus online and offline. I think it livened it up, but at the expense of battery.
  • Added kernel config option BCMDHD_WIFI_PM (thanks Ezekeel). See post 2 on how to enable it (not recommended unless you have music steaming issues when the screen is off). Not yet tested.
  • Other miscellaneous tweaks
  • Just in case, please note and then unset your saved voltage control settings before using the new version. You may need to clear your System Tuner App data to see the correct frequencies. Remember that the DVFS table and the scaling frequencies are different in some cases (see the second post for details)
View attachment motley_anykernel_nexus7_1.1.0_NoGPUOC_build_214.zip (GPU stock 416GHz)
View attachment motley_anykernel_nexus7_1.1.0_GPU484_build_213.zip (GPU OC 484MHz)
View attachment motley_anykernel_nexus7_1.1.0_GPU520_build_215.zip (GPU OC 520MHz)

stable v1.0.12 - builds #175-177
  • Changed highest frequency back to 1.624GHz and core voltage back to 1200mV. After experimenting with higher core voltages and 1.7GHz probing our limitations, it just doesn't seem right on this tablet. Why fry the butter?
  • CPU voltage is capped at 1237, so don't set it higher than that if tuning.
  • Refresh rate now adjusted with GPU OC clock at compile time. Higher FPS should be realized at 484 and 520 for most (thanks to clemsyn for sharing his research and findings)
  • Adjustments to the tegra 3 algorirthim for bring cpus online and offline, especially for the OC frequencies.
  • Fixed GPU clock compile time switch. Removed 500MHz choice.
  • Set cpu frequency policy to 1.3GHz on startup. This should help with heat build-up on startup and users where the highest OC clock rate is not desired.
  • Lowest brightness setting set back to stock since several users were requesting it (18 back to 13).
  • Minor adjustment to the interactive governor to make it slightly more responsive when demands increase.
  • PowerHAL change so it doesn't mess with a couple other interactive governor tunables on init.
  • All frequencies throughout the power range should be used in a more balanced manner.
  • Just in case, please note and then unset your saved voltage control settings before using the new version. You may need to clear your System Tuner App data to see the correct frequencies. Remember that the DVFS table and the scaling frequencies are different in some cases (see the second post for details)
View attachment motley_anykernel_nexus7_1.0.12_NoGPUOC_build_177.zip (GPU stock 416GHz)
View attachment motley_anykernel_nexus7_1.0.12_GPU484_build_176.zip (GPU OC 484MHz)
View attachment motley_anykernel_nexus7_1.0.12_GPU520_build_175.zip (GPU OC 520MHz)

alpha v1.0.11 - builds #126-128
  • Changed highest frequency from 1.624 to 1.7GHz
  • Increased core voltage for the highest frequency to 1250mV. This should bring some increased stability at the highest two overclock frequencies (thanks to clemsyn and Pinoyto for their help)
  • Tweaked DVFS table for the GPU. It should now scale a bit better and still bring the same performance and the top end.
  • Lowest brightness setting increased from 13 to 18 (thanks to clemsyn). Lets give this a try and we can increase it further if need be. The brightness levels can be tweaked on the ROM side as well in the N7 device tree, at least when you build from scratch, so we don't want to be too limiting here.
  • PowerHAL fix now included /vendor/lib/how/power.grouper.so (thanks to imoseyon). See this post to see the code I changed.
(Removed download links since many were reporting random reboots. I think v1.0.12 is better anyhow;))

stable v1.0.10 - build #110/111
  • CPU frequecies back to 1400, 1500, 1600, and 1624 (leaving the new highest setting)
  • DVFS table tweaks
  • Frequency table fix fix for 1624 (thanks to Clemsyn for bringing to my attention!)
  • Only stock and 484MHz GPU OC version - code switch is still there for those that want to compile and experiment. Moving beyond 484 doesn't show any benefit. My best Nenamark2 score 62.7 was achieved on 484MHz.
  • Just in case, please note and then unset your saved voltage control settings before using the new version. You may need to clear your System Tuner App data to see the correct frequencies. Remember that the DVFS table and the scaling frequencies are different in some cases (see the second post for details)

experimental v1.0.9 - builds #102-105
  • CPU OC to 1.624GHz - higher end CPU frequencies are now at 1408, 1504, 1600, and 1624 (old 1400, 1500, 1600, N/A)
  • DVFS table tweaks - Just in case, please note and then unset your saved voltage control settings before using the new version.
  • GPU versions stock, 484, 500 and 520MHz builds for testing
  • Added a GPU OC kernel config choice switch to allow compile time selection of GPU speed (446, 484, 500, or 520MHz).
  • NTFS r/w enabled
  • PegasusQ governor no longer built in, but code remains if we want to look further into when time allows.
  • Reduce some temp reporting kernel log spam until the temp gets a little higher

stable v1.0.8 - build #77/78
  • Added PegasusQ governor - experimental only, not enabled by default (thanks Samsung SGSIII source and gokhanmoral for tweaks)
  • Revert "HACK: block fbearlysuspend to not break androids crt-off animation"
  • Added LulzActive governor, but not built-in due to issues.

stable v1.0.7 - build #70/71
  • Voltage Control tweak - let's ignore the highest freq slot for show and
    save since it shows 1.6GHz twice in the voltage table in System Tuner.
    We are are only allowing 1200mV for 1.6, so the top slot is not
    currently used. See my notes in post 2 about voltage control.
  • cpu-tegra: let's skip the temporary downclock and kernel log spam if the
    custom Dynamic EDP throttle is not currently enabled.
  • ARM/VFP compiler optimization
  • compilation: fix annoying and serious warnings (thanks faux123!)
  • video: tegra: host: Fix error case memory leaks
    When a submit fails, the related nvhost_job is not freed. Add an
    explicit free. Also, 3D is mapping the save buffer, but it is not
    unmapped (Nvidia)
  • mm: Ensure pte and pmd stores ordering (Nvidia)
  • Get rid of some more kernel log spam.
  • HACK: block fbearlysuspend to not break androids crt-off animation
    (thanks codeworx, drewis (repo) and aaronpoweruser for pointing it out). This is untested (by me), but this may help with ROMs that
    have this functionality (AOKP etc.)
  • cpu-tegra3: modified the hot-plug governor down_delay to be 1s
    instead of 2s

stable v1.0.6 - build #47/48
  • GPU clock increased to 484MHz - Nenamark2 scores of 61+
  • More compiler optimizations (-fmodulo-sched, -fmodulo-sched-allow-regmoves, -funswitch-loops, -fpredictive-commoning, -fgcse-after-reload, -ftree-vectorize, -floop-interchange, -floop-strip-mine, -floop-block, -mfpu=neon )
  • Now using Koush's AnyKernel delivery method. Uses your existing ramdisk so you can easily use with any ROM.

stable v1.0.5 - build #39
  • Honor your max frequency fix - no more spikes

alpha v1.0.4 - build #38
  • Fixes units that can't OC (process_id = 3)
  • Linaro 4.7.1 toolchain -O2 (2012-06-25)
  • Increased panel clock rate - increases fps without further GPU clock Nenamark2 scores 59.6 best score so far for Nexus 7
  • ramdisk added back in boot 1.3GHz, but device still spikes to max allowed CPU freq sometimes (see update below, will be fixed in 1.0.5)
  • Minor clock and voltage adjustments - should run a bit cooler and use less battery.
  • Added GPU OC compile switch in case we want a non-OC GPU build.
  • Added some VPN/networking capabilities for those that need it (L2TP, IP_GRE_DEMUX,INET_AH, INET_XFRM_MODE_BEET)
  • Some unnecessary debugging options turned off. Should save kernel RAM usage.
  • Some say it made wifi signal stronger again for them, but I never had any issues. Might be the toolchain and its effect on the broadcom driver. Reports that it is better are fine with me!

alpha v1.0.3 - build #17
  • UV support, minor voltage adjustments
  • V(R) i/o scheduler added
  • ramdisk removed custom init.rc line...hope this will fix the stock units that weren't booting!

alpha v1.0.2 - build #6
  • Mild GPU OC from 416 to 446MHz - baby steps...its been rock solid so far. NenaMark 2 scores are up from 55 to 57.2fps. A future release may have two versions, one with GPU OC and one without.
  • Upgraded toolchain to GCC v4.6.3 optimized google version by ezterry, see http://xdaforums.com/showthread.php?t=1686310)

alpha v1.0.1 - build #4
  • Limit frequency to 1.3GHz on boot. It can then be OC'ed from there. This should make it safer for those that can't OC or don't want to.
  • Changes to allow OC for Process ID's 0 and 1. Theoretically, these should be earlier release versions like IO and earlier.

alpha v1.0.0 - build #1
  • This initial alpha release is working well on a Nexus 7 16GB (Speedo ID 7/Process ID 2) on JB 4.1.1. There are no open issues that I know about. Looking for some advanced users and testers to give some feedback, and then we can hopefully make it even better!


Thanks to:
  • fordwolden - for his generous donation of a Nexus 7
  • Google and Asus for releasing a nice, open, and inexpensive tablet for the masses.
  • drewis (Andrew Sutherland) - for the base kernel on github
  • paulobrien - thanks for the CWM touch recovery
  • birdman and FadedLite for their Unlock\Rooting instructions
  • clemsyn for his ideas and insight

Git repo:
https://github.com/motley-git/Kernel-Nexus7

gnu-head-sm.jpg
(http://www.gnu.org/copyleft/gpl.html)
 
Last edited:

_motley

Senior Member
Aug 17, 2010
858
2,360
More info

last_kmsg
Please provide the dmesg output or last_kmsg if you experience any issues (random reboot or crashes) that you think are attributed to the kernel. I ask that you please test with the default/stock kernel first for your rom before you blame the issues on this kernel. Wait for the tab to reboot, or if it doesn't wait long enough so you can capture a good log. If you place this on your /sdcard, it will be easy to capture. Boot into recovery, flash this zip, and then flash a known kernel that works. Then reboot, and go grab the last_kmsg in /sdcard.
View attachment LastKMESG.zip (thanks go to CekMTL, I always keep this handy since you gave it to me!)

Voltage Control

What is voltage control?
It is simply allowing for the cpu voltage to be changed on the fly for each frequency step. CPU voltage is typically lowered (undervolting) for certain frequency steps to conserve power. For an overclocked device, some devices need more juice to be stable than others. Voltage control allows others not to pay this penalty and they can lower the voltage as they see fit for their device and usage needs.

Is undervolting safe?
If the lowered voltage values you enter are stable for the tablet, then absolutely it is safe.

What are the benefits?
Better battery life and less heat

Additional Info on voltage control
Only System Tuner is displaying the DVFS table frequency labels correctly and I recommend that you use this if you want to play with voltage control. SetCPU is showing the scaling frequencies when it displays them in the UI, some of which are for the LP core. This is not correct and is misleading, so it is best not to use it for this kernel.

Since the tools available only allow for tweaking one DVFS table (the high powered G cores), voltage control is not currently possible for the LP core. It is not needed anyhow IMO and setting it too low could result in SOD. There is more battery saving to be had with the G cores anyhow if you are into this sort of tweaking.

The frequencies shown may have two values for one frequency. This is how it came with the factory kernel as well and I have only tweaked the top end of the DVFS table. It may seem weird, but this gives us direct access to the DVFS table. I would recommend keeping it as a staircase, just like Nvidia has it even though some frequencies are listed twice.

The freqs shown in the System Tuner display will match the DVFS table for the cpu_process_id for your tablet (seen in the kernel log at startup). All tablets won't display the same frequencies. There are at least two maybe three or four variants we have found so far for the Nexus 7 with Tegra 3 SoC #7.

Also, some may not know, but the tegra3 kernel also has automatic UV using a "cold" zone in where 50mV undervolting is done automatically when the cpu is cool. Take this into consideration when playing around.

GPU OC
Valid max GPU frequency is 416 - 520 MHz. If you try higher or lower clock speeds, it will fail and remain unchanged.

Examples:

Code:
echo 484 > /sys/devices/system/cpu/cpu0/cpufreq/gpu_oc

Code:
echo 520 > /sys/devices/system/cpu/cpu0/cpufreq/gpu_oc

Performance Tweaks
These are a couple of tweaks that many are using for faster benchmarks and better battery performance. Google it and decide for yourself if you like the risk or not. I recommend that you do a full backup in recovery and regularly backup your /data partion or cloud sync if you enable these options. Will many run them daily as I now do, there is some additional risk. These can be added to scripts and automated via init.d or other apps/tools that support them.

To disable fsync for better battery and better disk i/o performance:

Code:
echo 0 > /sys/class/misc/fsynccontrol/fsync_enabled

To enable fsync for better data integrity (default)
Code:
echo 1 > /sys/class/misc/fsynccontrol/fsync_enabled

Faster disk i/o - remount /data partition with noauto_da_alloc option (google it, better battery, less data integrity)

Code:
mount -o remount,noauto_da_alloc /data /data

TCP Congestion Control Algorithms

Only one can be set at a time, so only add one of the lines to your script. Here are some examples:

Code:
echo "reno" > /proc/sys/net/ipv4/tcp_congestion_control

echo "veno" > /proc/sys/net/ipv4/tcp_congestion_control

echo "vegas" > /proc/sys/net/ipv4/tcp_congestion_control

echo "westwood" > /proc/sys/net/ipv4/tcp_congestion_control

zRAM

What is zRAM?
This is a mainline kernel feature for Compressed RAM block device support (CONFIG_ZRAM)
http://en.wikipedia.org/wiki/ZRam

Like many of the other tweaks done in the Android world, ZRAM is another one of them that is controversial, probably because people only think in terms of immediate performance they can measure easily with benchmarks etc. *Here is my take...think I will add this to the Q&A section as well.

But, will it make my device faster? Will I score higher on benchmarks?
It depends, but for normal usage, the answer is no. zRAM is most useful for those that are configuring Android to be a true multitasking workhorse. For example, if I enable zRAM, open an bunch of apps at one time, and actually start to work towards depleting the memory of the system. *For example, say I open system tuner, a browser with several tabs, a word processing app, a game, and perhaps a picture viewing app or a movie. If I don't formally close out of each one by hitting back and just begin switching between apps and the home screen, you will see zRAM start showing benefits.*

If you tweak the Android memory and swappiness settings, this can also be useful in this type of environment.

How do I know it is initialized and working?
You can type "free" from an command line and see the swap space.

Also, you can look at the disksize to see if it is initialized
cat /sys/block/zram0/disksize

To see how much it is being used in your environment, you can look at the output from:
cat /sys/block/zram0/num_writes
cat /sys/block/zram0/num_reads

So, unless you have a heavy workload as stated above, then it won't be of a lot of use for normal Android users.

How do I enable zram?
It must be enabled by a script. Some ROMs may support activating it. If you need to do it yourself you have two choices.

1) Save this to a file and run the script from terminal, Script Manager or System Tuner.
2) Or better yet, save this to a file called 90zram (or whatever you prefer) in /system/etc/init.d and automate it (The ROM's ramdisk needs to supports init.d)

Code:
#!/system/bin/sh
# auto zram activation init script with busybox search
# by show-p1984

echo "[90ZRAM]: Firing up /system/etc/init.d/90zram";

if [ ! -e /sys/block/zram0/disksize ] ; then
        echo "[90ZRAM]: ERROR unable to find /sys/block/zram0/disksize";
        echo "[90ZRAM]: Is this a ZRAM kernel?";
        echo "[90ZRAM]: ZRAM NOT ACTIVATED. (404)";
else
        #find busybox in /system
        bblocation=$(find /system/ -name 'busybox')
        if [ -n "$bblocation" ] && [ -e "$bblocation" ] ; then
                echo "[90ZRAM]: busybox found in:" $bblocation;
                echo "[90ZRAM]: Setting ZRAM disksize.";
                echo $((100*1024*1024)) > /sys/block/zram0/disksize

                echo "[90ZRAM]: Starting ZRAM...";
                bblocation=${bblocation%/*}
                cd $bblocation
                ./busybox mkswap /dev/block/zram0
                ./busybox swapon /dev/block/zram0

                echo "[90ZRAM]: ZRAM activated.";
        else
                echo "[90ZRAM]: ERROR! busybox not found!";
                echo "[90ZRAM]: Is busybox installed? Symlinks set?";
                echo "[90ZRAM]: ZRAM NOT ACTIVATED. (404)";
        fi
fi
 
Last edited:

Clienterror

Senior Member
Jun 21, 2010
2,093
362
Quad Cities, Illinois
Flashed with CWR and it doesn't boot past the Google screen :( Is there something special I need to do?

*Edit*
I am on the new 4.1.1 "D" or whatever but right now I'm using the Atlantis "1.5" kernel and it works so I donno.
 
Last edited:
  • Like
Reactions: inyourfaceyou

cwc3

Senior Member
Oct 17, 2011
531
418
Thanks for another addition to the nexus 7 kernel community, love having different kernels to try.
 

_motley

Senior Member
Aug 17, 2010
858
2,360
Flashed with CWR and it doesn't boot past the Google screen :( Is there something special I need to do?

*Edit*
I am on the new 4.1.1 "D" or whatever but right now I'm using the Atlantis "1.5" kernel and it works so I donno.

Thx, please grab the dmesg output while booting or last_kmsg if you can. Working fine here, but this why I put it out as an alpha. Even if you boot off another kernel, if you can send a dmesg captured right after boot, that would help so I can see your SoC/Process ID numbers. There are two lines written just after boot with the info. On the Prime, we had different CPUs in some models, but it may just be a voltage issue. I have run Antutu and Quadrant several times without issues though. Not sure about the D update...I I have 4.1.1.

Edit: Version 1.0.1 released, please test again and leave feedback when you can. Please let me know when you received your tab. Is it an early IO version? If this doesn't do it, I most likely will need to increase voltages a bit. Hopefully I won't have to do this so we can keep battery life at it's best.
 
Last edited:
  • Like
Reactions: t_007_v2

demandarin

Senior Member
Apr 7, 2010
7,021
2,038
Alexandria, Va
oh s^&*, you developing here also. oh yeah! glad to see you here buddy. so you have your nexus 7 already? now that i see you here also, i will be unlocking my nexus 7, once it arrives, sooner than i thought. welcome aboard...glad to see familiar faces around here :)
 

Sobai

Senior Member
Sep 3, 2009
149
26
Kelowna
I had the same issue. Couldn't pass the boot screen after flashing. On 4.1.1 latest update as of July 15th :(
 

_motley

Senior Member
Aug 17, 2010
858
2,360
I had the same issue. Couldn't pass the boot screen after flashing. On 4.1.1 latest update as of July 15th :(

Thanks, I am dying to take a look at a log to see how I am so lucky to have it working! I've added LastKMSG.zip to the OP. If someone with a booting problem can do the following, I would really appreciate it:

1) Put LastKMSG.zip on your /sdcard along with the newest kernel zip
2) Flash the kernel zip
3) Wait for it to boot, give it a few seconds and then hold power down to reboot if it doesn't do it on its own.
4) Go back into recovery and flash LastKMSG.zip
5) Flash another booting kernel or your current rom to recover.
6) Boot and retrieve the file /sdcard/last_kmsg
7) Attach the log here or PM me with a dropbox link or whatever.

Thanks!
 
  • Like
Reactions: t_007_v2

_motley

Senior Member
Aug 17, 2010
858
2,360
Just got some good news from a gentleman that didn't have enough posts to share with us here yet, so he PM'ed me and said that I can share the details of his experience.

First report was more of the same, sounded familiar, more bad news...
Flashed your kernel and couldn't boot pasted Google screen. Restarted in to boot and couldn't get into recovery. Was stock rooted on the latest 4.11. Went back to stock. Looking forward to trying again, now I'm on Modaco's latest. I'll let you know how it goes.​

Next report was good using the latest version in the OP. Not sure, but this may help others.
Thanks! This kernel is fantastic! Makes this thing a real beast! Sorry I didn't give you the info you asked for! I got it Thursday from GameStop. The problems may have stemmed from the fact that I updated to 4.11 , rooted then side updated the newest little update and then ran a su zip to regain root (Paul o' Brian ROM) . I was also on his first cwm and then updated to his new one after I started from scratch. Loaded up his new ROM, rebooted then applied your 2nd kernel and this thing is hitting 15626 in CF benches!​

Not sure what is going on, but I can't explain it. It may be my 2nd version of the kernel that fixes it, but I am not sure since I haven't seen a log yet. I suppose something may be jacked up with the early versions of recovery or roms, but the I was using the the same early versions when I tested just fine....maybe folks are losing recovery and don't realize it? I did the second step to keep recovery that is now automated in r2. If anyone has any ideas, let me know.
 

danielsf

Senior Member
Oct 29, 2010
732
280
Hull
New version released...see OP. GPU OC to 446MHz (up from stock 416)

Looking for more feedback:cowboy:

View attachment 1204164

Just out of curiously, would you ever try 520mhz for the gpu, to try to get it to t30 speeds? Or maybe would you consider some kind of app interface like extweeks for the galaxy s2 & s3 to control the GPU clock speed and maybe voltages instead of different kernels. As I would personally love to get the GPU to about 460-500mhz :) Anyway when I get my n7 (hopefully in a day or two) I can't wait to try this out :) (I am spoilt by the much more powerful 440mhz mali-400mp in the s3, so I would love to try to narrow the power difference between the devices GPU wise) :D
 
Last edited:

Clienterror

Senior Member
Jun 21, 2010
2,093
362
Quad Cities, Illinois
Nice man! The new versions fixed everything boots great! Now if we can just figure out how to make the Overclock stick after you turn the screen on/off. I'm not sure how to tell if the GPU OC is sticking.

Sent from my Nexus 7 using xda app-developers app
 

_motley

Senior Member
Aug 17, 2010
858
2,360
Just out of curiously, would you ever try 520mhz for the gpu, to try to get it to t30 speeds? Or maybe would you consider some kind of app interface like extweeks for the galaxy s2 & s3 to control the GPU clock speed and maybe voltages instead of different kernels. As I would personally love to get the GPU to about 460-500mhz :) Anyway when I get my n7 (hopefully in a day or two) I can't wait to try this out :) (I am spoilt by the much more powerful 440mhz mali-400mp in the s3, so I would love to try to narrow the power difference between the devices GPU wise) :D

Sure, we may push the GPU OC version a bit, but I always like to walk before we run to see how things go. I would like to monitor heat output, battery usage etc. and then move forward in steps. I am very happy with it right now, but dynamic configuration would also be cool. Let me know what you think once you have it hand.

Nice man! The new versions fixed everything boots great! Now if we can just figure out how to make the Overclock stick after you turn the screen on/off. I'm not sure how to tell if the GPU OC is sticking.

Awesome, glad to hear it! I don't think I see this issue with the OC sticking after you turn the screen off/on, but I will do more checking after work today.
 

Clienterror

Senior Member
Jun 21, 2010
2,093
362
Quad Cities, Illinois
Awesome, glad to hear it! I don't think I see this issue with the OC sticking after you turn the screen off/on, but I will do more checking after work today.

Thanks a ton! Yea if you go into setcpu and make it 1.6 then turn the screen off then on (unlock) set CPU slider still shows 1.6 but if you read under that the smaller text says its actually set at.1.3 again. It seems to be a problem with the Atlantis kernel also something to do with hardcoded CPU freqs I think. Oh I wanted 5k soooo bad rofl got this twice rofl.

Sent from my Nexus 7 using xda app-developers app
 

Attachments

  • uploadfromtaptalk1342533294311.jpg
    uploadfromtaptalk1342533294311.jpg
    93.2 KB · Views: 2,872

evonc

Senior Member
Dec 10, 2011
947
365
Toronto
Thanks a ton! Yea if you go into setcpu and make it 1.6 then turn the screen off then on (unlock) set CPU slider still shows 1.6 but if you read under that the smaller text says its actually set at.1.3 again. It seems to be a problem with the Atlantis kernel also something to do with hardcoded CPU freqs I think. Oh I wanted 5k soooo bad rofl got this twice rofl.

Sent from my Nexus 7 using xda app-developers app

I've just made profiles that automatically set the clock to 1.5 when the screen turns on again and back to 1.5 when the screen turns off.

Edit*

Just tried the newest version and it failed to boot. Got stuck at the Google Logo. Here is the last_kmsg. Hopefully it helps :)
(had to put a .txt extension on it btw. Uploader wont let me upload w/o extension)
 

Attachments

  • last_kmsg.txt
    40.5 KB · Views: 32
Last edited:

MrPhilo

Senior Member
Dec 12, 2010
2,028
654
Sheffield
The Nexus 7 GPU is better than the Transformer Prime due to the faster RAM, so more bandwidth? If I'm correct? Thats why we see a higher Nenamark score at a lower clock?
 

hanthesolo

Senior Member
Jan 23, 2012
1,042
567
This kernel looks very promising, excellent work! How much "play" have you had with upping the voltages, before the battery quits? On my TF, I can only go so far before the battery cannot provide enough juice, and it freezes on me. It would be interesting to know for people who want to OC really high. Does anything above 1.6 GHZ actually boot (heat and battery drainage aside)? It would be nice to OC up to 2.0 GHZ, if only for a proof-of concept. Finally, what are the temps you are getting on the higher clocks? It sounds like overheating may start becoming a real issue, and I was just curious.
 

Kidromulous

Senior Member
Feb 1, 2011
1,106
298
Durham N.C.
The ram disk version rendered my tablet unbootable had to flash the Atlantis kernel from fast boot to get it back up and running.

Sent from my Nexus 7 using Tapatalk 2
 

parcsalooc

Senior Member
May 20, 2008
191
19
Richmond Virginia
I for the life of me can't get this kernel to OC. Tried System Tuner, Setcpu etc. Max only reads 1300mhz nothing shows higher beyond 1300. I have no clue what the deal is. I've tried wiping also. Even tried Atlantis' kernel. on his, it won't allow me to set anything. Max shows 0 and Min shows zero. I am running Pauls Modaco Jr3 and even tried it on EOS' new release. I'm beginning to wonder if its something diff internally. Anyone have any guesses?Also showing root as setcpu requests superuser permissions.
This is what my device shows

Board: grouper
Product: nakasi
Model: Nexus 7
Device: grouper
Build: JRO03D (Modaco Custom ROM Jr3)
google/nakasi/grouper:4.1.1/JRO03D?402395:user/release-keys
Manufacturer:asus
Brand:google
CPU ABI: armeabi-v7a

Kernel
Linux version 3.1.10-motley+(cainm@motleyville) (gcc version 4.6.3 (GCC)) #6 SMP
PREEMPT Tue Jul 17 00:52:59 EDT 2012
 

Top Liked Posts

  • There are no posts matching your filters.
  • 320
    motley kernel for the Nexus 7 and Jellybean

    Disclaimer: You know the gig...I am not responsible for damaging your device or voiding your warranty. Play at your own risk!

    ROM devs/cooks: If you want to use this kernel in your ROM, I am fine with that, but please include a "thanks" and a link back to this thread. Thanks!

    Requirements (please read carefully and visit the other dev threads as necessary)
    • You must be unlocked and rooted.
    • You must have custom recovery installed (CWM or TWRP) to install the kernel.
    • Busybox is required for init.d support.
    • Do a backup using custom recovery (CWM or TWR) so you can restore your boot.img and ROM if necessary!
    • Have your ROM zip in /sdcard so you can restore your ROM if necessary.
    • System Tuner is recommended for tuning the CPU, especially for voltage control.

    Main Features
    • GPL compliant - source is kept up to date at github.com and released at the time the kernel is released to the public for all builds. Ask other devs to do the same!
    • Asus\Nvidia\Google Linux 3.1.10 base. All stock features are supported (camera, OTG, NFC etc.)
    • OC to 1.6GHz (optional)
    • Voltage control - be careful to not save the setting on boot until you are 100% sure!
    • GPU OC from 416 to 520MHz (default is 446, adjust as you wish up to 520MHz)
    • Dynamic EDP - allows EDP to remain enabled (safer), but with an added simple temperature throttle switch (based on Asus Prime)
    • Compiler optimizations (-O2) - using Linaro 4.7 ARM toolchain
    • I/O schedulers - row (default), SIO, V(R), CFQ, NOOP, and deadline
    • TCP Congestion Control - default cubic + several different algos to choose from.
    • ZRAM - must be enabled by a script
    • Governors - Interactive (default), Performance, OnDemand, PowerSave, Conservative
    • initramfs - insecure (your ROM must have busybox)
    • CIFS/UTF8, NFS, NTFS r/w, TUN - built-in, no need for any kernel modules
    • fsync sysfs enable/disable switch (defaults to fsync enabled)
    • kexec with hardboot (for supporting Linux/MultiROM)
    • Many other misc patches and tweaks (see github link below)

    Install:
    1. Check the requirements above!
    2. Flash the zip using custom recovery (no need to wipe anything)
    3. See post 2 for performance tweaks and more info

    build #249 for Jellybean 4.2.2 - WiFi and 3G 2013-02-24
    • Added ability to change GPU clock speed at runtime (referenced franco, morific, and metallice git repos)
    • Added row io scheduler and set as default (Tatyana Brokhman)
    • Added TCP Congestion Control, several different algos to choose from. Default is cubic (stock).
    • Added optimized ARM RWSEM (Ezekeel)
    • Input patch (Henrik Rydberg)
    View attachment motley_anykernel_N7_build_249.zip

    build #247 for Jellybean 4.2.2 - WiFi and 3G 2013-02-17
    • Merged 4.2.2 patches
    • Updated Linaro toolchain to 2012.12
    View attachment motley_422_nexus7_anykernel_build_247_446GPU.zip

    build #246 for Jellybean 4.2.1 - WiFi and 3G
    • kexec\MultiROM support
    Download from here since I posted in the MultiROM thread

    build #244 for Jellybean 4.2 - WiFi and 3G - Recommended for WiFi and 3G on 4.2.x
    • 446 GPU build (stock + 30MHz). Let's see if this fixes touchscreen issues for those having them. My theory is that after the GPU heats up, this starts to affect touchscreen behavior on some devices. This is likely what happened to me on build 234 when I was testing. The GPU definitely gets hot on this device even with normal usage at 484+. At 446 this doesn't happen. IMHO, we are reducing the life of the device by overheating the GPU repeatedly. My Antutu scores actually tested higher after I flashed the 446 build.
    • Supports Android Jellybean 4.2.x
    • Reverted some commits from 233
    • Removed KSM from config, no ROM is using this AFAIK
    • Panel clock reduced to match Nvida cardhu sources (74180000). Having the panel clock cranked up fakes out scores on some benchmark tests, but adds no real value.
    View attachment motley_nexus7_anykernel_build_244_446GPU.zip

    Previous builds and release notes

    build #234 for Jellybean 4.2 - First properly working 3G build
    • Supports Android Jellybean 4.2.x
    • Only change - added CONFIG_USB_NET_RAW_IP=y to hopefully address any issues with 3G (reported working by DiamondBack)
    View attachment motley_nexus7_anykernel_build_234_484GPU.zip


    build #233 for Jellybean 4.2 - if you don't have issues with GPU OC @484, this build may work well for you.
    • Supports Android Jellybean 4.2.x
    • Updated to latest Linaro toolchain 2012.10.22 and tweaked some compiler options.
    • Should support 3G as I have merged the Google patches, but I have not tested this.
    • Removed WiFi PM_FAST toggle as I see no need for this (PM_MAX for better battery is already the default in stock)
    • Stopped logging temp warnings until lit gets to 65C near the EDP throttle limit.
    • Quad-core tweaks - referenced showp1984's bricked grouper kernel source
    • See github for other minor details.
    View attachment motley_nexus7_anykernel_build_233_484GPU.zip


    build #232 - Recommended for WiFi on 4.1.2
    • Added support for Android Jellybean 4.1.2
    • Updated to latest Linaro toolchain 2012.10.22.
    View attachment motley_nexus7_anykernel_build_232_484GPU.zip (GPU OC 484MHz)


    stable v1.1.1 - builds #218-220 - Recommended for WiFi on 4.1.0 or 4.1.1
    • Supports Android Jellybean 4.1.1 or 4.1.0
    • DVFS tweaks and drop top cpu frequency to 1600, not much is lost and it should now be stable for everyone I hope. We pushed the envelope to 1.7 and 1.624 and now we are back to real world sensible decisions. My Nenamark2 520 GPU scores actually went up.
    • Dynamic EDP temp adjusted from 67 to 68C to catch temp notifier quicker when cooling back down.
    • Other miscellaneous patches
    • Just in case, please note and then unset your saved voltage control settings before using the new version. You may need to clear your System Tuner App data to see the correct frequencies. Remember that the DVFS table and the scaling frequencies are different in some cases (see the second post for details)
    View attachment motley_anykernel_nexus7_1.1.1_NoGPUOC_build_220.zip (GPU stock 416GHz)
    View attachment motley_anykernel_nexus7_1.1.1_GPU484_build_219.zip (GPU OC 484MHz)
    View attachment motley_anykernel_nexus7_1.1.1_GPU520_build_218.zip (GPU OC 520MHz)

    alpha v1.1.0 - builds #213-215
    • Added fsync sysfs enable/disable switch (thanks Ezekeel). fsync is still enabled by default. For more info and how to disable, see post 2.
    • Experimental: now forging speedo id 4 and process id 2 so that EDP limits are slightly raised and it narrows everyone down to a common DVFS record for everyone. Raised Dynanic EDP governor to 67C (from 60C) to give a little more room before edp is allowed to enable.
    • Minor cpu voltage table tweaks aiming for slightly better battery for those that don't undervolt.
    • Lowered the cold offsets from 50 to 25 for the top 4 cpu voltage slots. This will give folks a little more breathing room when undervolting and may help cold performance a bit if your voltages are lowered close to their lower limit.
    • Deadline i/o scheduler (morfic's secret 1:1 sauce that I remember back from my Iconia A500 days!). SIO is still the default, but we can try it out and see what we think.
    • OnDemand really wasn't usable in it's stock state since it was so laggy, so I have made some tweaks to the tuneables and it seems to be better now for those that want to give it a spin. Interactive is still the default governor.
    • cpu transtition latency lowered - fairly certain that it only affects OnDemand governor and not Interactive (reference morfic and http://permalink.gmane.org/gmane.linux.ports.tegra/1649)
    • Reverted most of the adjustments to the tegra 3 algorirthim for bringing cpus online and offline. I think it livened it up, but at the expense of battery.
    • Added kernel config option BCMDHD_WIFI_PM (thanks Ezekeel). See post 2 on how to enable it (not recommended unless you have music steaming issues when the screen is off). Not yet tested.
    • Other miscellaneous tweaks
    • Just in case, please note and then unset your saved voltage control settings before using the new version. You may need to clear your System Tuner App data to see the correct frequencies. Remember that the DVFS table and the scaling frequencies are different in some cases (see the second post for details)
    View attachment motley_anykernel_nexus7_1.1.0_NoGPUOC_build_214.zip (GPU stock 416GHz)
    View attachment motley_anykernel_nexus7_1.1.0_GPU484_build_213.zip (GPU OC 484MHz)
    View attachment motley_anykernel_nexus7_1.1.0_GPU520_build_215.zip (GPU OC 520MHz)

    stable v1.0.12 - builds #175-177
    • Changed highest frequency back to 1.624GHz and core voltage back to 1200mV. After experimenting with higher core voltages and 1.7GHz probing our limitations, it just doesn't seem right on this tablet. Why fry the butter?
    • CPU voltage is capped at 1237, so don't set it higher than that if tuning.
    • Refresh rate now adjusted with GPU OC clock at compile time. Higher FPS should be realized at 484 and 520 for most (thanks to clemsyn for sharing his research and findings)
    • Adjustments to the tegra 3 algorirthim for bring cpus online and offline, especially for the OC frequencies.
    • Fixed GPU clock compile time switch. Removed 500MHz choice.
    • Set cpu frequency policy to 1.3GHz on startup. This should help with heat build-up on startup and users where the highest OC clock rate is not desired.
    • Lowest brightness setting set back to stock since several users were requesting it (18 back to 13).
    • Minor adjustment to the interactive governor to make it slightly more responsive when demands increase.
    • PowerHAL change so it doesn't mess with a couple other interactive governor tunables on init.
    • All frequencies throughout the power range should be used in a more balanced manner.
    • Just in case, please note and then unset your saved voltage control settings before using the new version. You may need to clear your System Tuner App data to see the correct frequencies. Remember that the DVFS table and the scaling frequencies are different in some cases (see the second post for details)
    View attachment motley_anykernel_nexus7_1.0.12_NoGPUOC_build_177.zip (GPU stock 416GHz)
    View attachment motley_anykernel_nexus7_1.0.12_GPU484_build_176.zip (GPU OC 484MHz)
    View attachment motley_anykernel_nexus7_1.0.12_GPU520_build_175.zip (GPU OC 520MHz)

    alpha v1.0.11 - builds #126-128
    • Changed highest frequency from 1.624 to 1.7GHz
    • Increased core voltage for the highest frequency to 1250mV. This should bring some increased stability at the highest two overclock frequencies (thanks to clemsyn and Pinoyto for their help)
    • Tweaked DVFS table for the GPU. It should now scale a bit better and still bring the same performance and the top end.
    • Lowest brightness setting increased from 13 to 18 (thanks to clemsyn). Lets give this a try and we can increase it further if need be. The brightness levels can be tweaked on the ROM side as well in the N7 device tree, at least when you build from scratch, so we don't want to be too limiting here.
    • PowerHAL fix now included /vendor/lib/how/power.grouper.so (thanks to imoseyon). See this post to see the code I changed.
    (Removed download links since many were reporting random reboots. I think v1.0.12 is better anyhow;))

    stable v1.0.10 - build #110/111
    • CPU frequecies back to 1400, 1500, 1600, and 1624 (leaving the new highest setting)
    • DVFS table tweaks
    • Frequency table fix fix for 1624 (thanks to Clemsyn for bringing to my attention!)
    • Only stock and 484MHz GPU OC version - code switch is still there for those that want to compile and experiment. Moving beyond 484 doesn't show any benefit. My best Nenamark2 score 62.7 was achieved on 484MHz.
    • Just in case, please note and then unset your saved voltage control settings before using the new version. You may need to clear your System Tuner App data to see the correct frequencies. Remember that the DVFS table and the scaling frequencies are different in some cases (see the second post for details)

    experimental v1.0.9 - builds #102-105
    • CPU OC to 1.624GHz - higher end CPU frequencies are now at 1408, 1504, 1600, and 1624 (old 1400, 1500, 1600, N/A)
    • DVFS table tweaks - Just in case, please note and then unset your saved voltage control settings before using the new version.
    • GPU versions stock, 484, 500 and 520MHz builds for testing
    • Added a GPU OC kernel config choice switch to allow compile time selection of GPU speed (446, 484, 500, or 520MHz).
    • NTFS r/w enabled
    • PegasusQ governor no longer built in, but code remains if we want to look further into when time allows.
    • Reduce some temp reporting kernel log spam until the temp gets a little higher

    stable v1.0.8 - build #77/78
    • Added PegasusQ governor - experimental only, not enabled by default (thanks Samsung SGSIII source and gokhanmoral for tweaks)
    • Revert "HACK: block fbearlysuspend to not break androids crt-off animation"
    • Added LulzActive governor, but not built-in due to issues.

    stable v1.0.7 - build #70/71
    • Voltage Control tweak - let's ignore the highest freq slot for show and
      save since it shows 1.6GHz twice in the voltage table in System Tuner.
      We are are only allowing 1200mV for 1.6, so the top slot is not
      currently used. See my notes in post 2 about voltage control.
    • cpu-tegra: let's skip the temporary downclock and kernel log spam if the
      custom Dynamic EDP throttle is not currently enabled.
    • ARM/VFP compiler optimization
    • compilation: fix annoying and serious warnings (thanks faux123!)
    • video: tegra: host: Fix error case memory leaks
      When a submit fails, the related nvhost_job is not freed. Add an
      explicit free. Also, 3D is mapping the save buffer, but it is not
      unmapped (Nvidia)
    • mm: Ensure pte and pmd stores ordering (Nvidia)
    • Get rid of some more kernel log spam.
    • HACK: block fbearlysuspend to not break androids crt-off animation
      (thanks codeworx, drewis (repo) and aaronpoweruser for pointing it out). This is untested (by me), but this may help with ROMs that
      have this functionality (AOKP etc.)
    • cpu-tegra3: modified the hot-plug governor down_delay to be 1s
      instead of 2s

    stable v1.0.6 - build #47/48
    • GPU clock increased to 484MHz - Nenamark2 scores of 61+
    • More compiler optimizations (-fmodulo-sched, -fmodulo-sched-allow-regmoves, -funswitch-loops, -fpredictive-commoning, -fgcse-after-reload, -ftree-vectorize, -floop-interchange, -floop-strip-mine, -floop-block, -mfpu=neon )
    • Now using Koush's AnyKernel delivery method. Uses your existing ramdisk so you can easily use with any ROM.

    stable v1.0.5 - build #39
    • Honor your max frequency fix - no more spikes

    alpha v1.0.4 - build #38
    • Fixes units that can't OC (process_id = 3)
    • Linaro 4.7.1 toolchain -O2 (2012-06-25)
    • Increased panel clock rate - increases fps without further GPU clock Nenamark2 scores 59.6 best score so far for Nexus 7
    • ramdisk added back in boot 1.3GHz, but device still spikes to max allowed CPU freq sometimes (see update below, will be fixed in 1.0.5)
    • Minor clock and voltage adjustments - should run a bit cooler and use less battery.
    • Added GPU OC compile switch in case we want a non-OC GPU build.
    • Added some VPN/networking capabilities for those that need it (L2TP, IP_GRE_DEMUX,INET_AH, INET_XFRM_MODE_BEET)
    • Some unnecessary debugging options turned off. Should save kernel RAM usage.
    • Some say it made wifi signal stronger again for them, but I never had any issues. Might be the toolchain and its effect on the broadcom driver. Reports that it is better are fine with me!

    alpha v1.0.3 - build #17
    • UV support, minor voltage adjustments
    • V(R) i/o scheduler added
    • ramdisk removed custom init.rc line...hope this will fix the stock units that weren't booting!

    alpha v1.0.2 - build #6
    • Mild GPU OC from 416 to 446MHz - baby steps...its been rock solid so far. NenaMark 2 scores are up from 55 to 57.2fps. A future release may have two versions, one with GPU OC and one without.
    • Upgraded toolchain to GCC v4.6.3 optimized google version by ezterry, see http://xdaforums.com/showthread.php?t=1686310)

    alpha v1.0.1 - build #4
    • Limit frequency to 1.3GHz on boot. It can then be OC'ed from there. This should make it safer for those that can't OC or don't want to.
    • Changes to allow OC for Process ID's 0 and 1. Theoretically, these should be earlier release versions like IO and earlier.

    alpha v1.0.0 - build #1
    • This initial alpha release is working well on a Nexus 7 16GB (Speedo ID 7/Process ID 2) on JB 4.1.1. There are no open issues that I know about. Looking for some advanced users and testers to give some feedback, and then we can hopefully make it even better!


    Thanks to:
    • fordwolden - for his generous donation of a Nexus 7
    • Google and Asus for releasing a nice, open, and inexpensive tablet for the masses.
    • drewis (Andrew Sutherland) - for the base kernel on github
    • paulobrien - thanks for the CWM touch recovery
    • birdman and FadedLite for their Unlock\Rooting instructions
    • clemsyn for his ideas and insight

    Git repo:
    https://github.com/motley-git/Kernel-Nexus7

    gnu-head-sm.jpg
    (http://www.gnu.org/copyleft/gpl.html)
    51
    More info

    last_kmsg
    Please provide the dmesg output or last_kmsg if you experience any issues (random reboot or crashes) that you think are attributed to the kernel. I ask that you please test with the default/stock kernel first for your rom before you blame the issues on this kernel. Wait for the tab to reboot, or if it doesn't wait long enough so you can capture a good log. If you place this on your /sdcard, it will be easy to capture. Boot into recovery, flash this zip, and then flash a known kernel that works. Then reboot, and go grab the last_kmsg in /sdcard.
    View attachment LastKMESG.zip (thanks go to CekMTL, I always keep this handy since you gave it to me!)

    Voltage Control

    What is voltage control?
    It is simply allowing for the cpu voltage to be changed on the fly for each frequency step. CPU voltage is typically lowered (undervolting) for certain frequency steps to conserve power. For an overclocked device, some devices need more juice to be stable than others. Voltage control allows others not to pay this penalty and they can lower the voltage as they see fit for their device and usage needs.

    Is undervolting safe?
    If the lowered voltage values you enter are stable for the tablet, then absolutely it is safe.

    What are the benefits?
    Better battery life and less heat

    Additional Info on voltage control
    Only System Tuner is displaying the DVFS table frequency labels correctly and I recommend that you use this if you want to play with voltage control. SetCPU is showing the scaling frequencies when it displays them in the UI, some of which are for the LP core. This is not correct and is misleading, so it is best not to use it for this kernel.

    Since the tools available only allow for tweaking one DVFS table (the high powered G cores), voltage control is not currently possible for the LP core. It is not needed anyhow IMO and setting it too low could result in SOD. There is more battery saving to be had with the G cores anyhow if you are into this sort of tweaking.

    The frequencies shown may have two values for one frequency. This is how it came with the factory kernel as well and I have only tweaked the top end of the DVFS table. It may seem weird, but this gives us direct access to the DVFS table. I would recommend keeping it as a staircase, just like Nvidia has it even though some frequencies are listed twice.

    The freqs shown in the System Tuner display will match the DVFS table for the cpu_process_id for your tablet (seen in the kernel log at startup). All tablets won't display the same frequencies. There are at least two maybe three or four variants we have found so far for the Nexus 7 with Tegra 3 SoC #7.

    Also, some may not know, but the tegra3 kernel also has automatic UV using a "cold" zone in where 50mV undervolting is done automatically when the cpu is cool. Take this into consideration when playing around.

    GPU OC
    Valid max GPU frequency is 416 - 520 MHz. If you try higher or lower clock speeds, it will fail and remain unchanged.

    Examples:

    Code:
    echo 484 > /sys/devices/system/cpu/cpu0/cpufreq/gpu_oc

    Code:
    echo 520 > /sys/devices/system/cpu/cpu0/cpufreq/gpu_oc

    Performance Tweaks
    These are a couple of tweaks that many are using for faster benchmarks and better battery performance. Google it and decide for yourself if you like the risk or not. I recommend that you do a full backup in recovery and regularly backup your /data partion or cloud sync if you enable these options. Will many run them daily as I now do, there is some additional risk. These can be added to scripts and automated via init.d or other apps/tools that support them.

    To disable fsync for better battery and better disk i/o performance:

    Code:
    echo 0 > /sys/class/misc/fsynccontrol/fsync_enabled

    To enable fsync for better data integrity (default)
    Code:
    echo 1 > /sys/class/misc/fsynccontrol/fsync_enabled

    Faster disk i/o - remount /data partition with noauto_da_alloc option (google it, better battery, less data integrity)

    Code:
    mount -o remount,noauto_da_alloc /data /data

    TCP Congestion Control Algorithms

    Only one can be set at a time, so only add one of the lines to your script. Here are some examples:

    Code:
    echo "reno" > /proc/sys/net/ipv4/tcp_congestion_control
    
    echo "veno" > /proc/sys/net/ipv4/tcp_congestion_control
    
    echo "vegas" > /proc/sys/net/ipv4/tcp_congestion_control
    
    echo "westwood" > /proc/sys/net/ipv4/tcp_congestion_control

    zRAM

    What is zRAM?
    This is a mainline kernel feature for Compressed RAM block device support (CONFIG_ZRAM)
    http://en.wikipedia.org/wiki/ZRam

    Like many of the other tweaks done in the Android world, ZRAM is another one of them that is controversial, probably because people only think in terms of immediate performance they can measure easily with benchmarks etc. *Here is my take...think I will add this to the Q&A section as well.

    But, will it make my device faster? Will I score higher on benchmarks?
    It depends, but for normal usage, the answer is no. zRAM is most useful for those that are configuring Android to be a true multitasking workhorse. For example, if I enable zRAM, open an bunch of apps at one time, and actually start to work towards depleting the memory of the system. *For example, say I open system tuner, a browser with several tabs, a word processing app, a game, and perhaps a picture viewing app or a movie. If I don't formally close out of each one by hitting back and just begin switching between apps and the home screen, you will see zRAM start showing benefits.*

    If you tweak the Android memory and swappiness settings, this can also be useful in this type of environment.

    How do I know it is initialized and working?
    You can type "free" from an command line and see the swap space.

    Also, you can look at the disksize to see if it is initialized
    cat /sys/block/zram0/disksize

    To see how much it is being used in your environment, you can look at the output from:
    cat /sys/block/zram0/num_writes
    cat /sys/block/zram0/num_reads

    So, unless you have a heavy workload as stated above, then it won't be of a lot of use for normal Android users.

    How do I enable zram?
    It must be enabled by a script. Some ROMs may support activating it. If you need to do it yourself you have two choices.

    1) Save this to a file and run the script from terminal, Script Manager or System Tuner.
    2) Or better yet, save this to a file called 90zram (or whatever you prefer) in /system/etc/init.d and automate it (The ROM's ramdisk needs to supports init.d)

    Code:
    #!/system/bin/sh
    # auto zram activation init script with busybox search
    # by show-p1984
    
    echo "[90ZRAM]: Firing up /system/etc/init.d/90zram";
    
    if [ ! -e /sys/block/zram0/disksize ] ; then
            echo "[90ZRAM]: ERROR unable to find /sys/block/zram0/disksize";
            echo "[90ZRAM]: Is this a ZRAM kernel?";
            echo "[90ZRAM]: ZRAM NOT ACTIVATED. (404)";
    else
            #find busybox in /system
            bblocation=$(find /system/ -name 'busybox')
            if [ -n "$bblocation" ] && [ -e "$bblocation" ] ; then
                    echo "[90ZRAM]: busybox found in:" $bblocation;
                    echo "[90ZRAM]: Setting ZRAM disksize.";
                    echo $((100*1024*1024)) > /sys/block/zram0/disksize
    
                    echo "[90ZRAM]: Starting ZRAM...";
                    bblocation=${bblocation%/*}
                    cd $bblocation
                    ./busybox mkswap /dev/block/zram0
                    ./busybox swapon /dev/block/zram0
    
                    echo "[90ZRAM]: ZRAM activated.";
            else
                    echo "[90ZRAM]: ERROR! busybox not found!";
                    echo "[90ZRAM]: Is busybox installed? Symlinks set?";
                    echo "[90ZRAM]: ZRAM NOT ACTIVATED. (404)";
            fi
    fi
    30
    Build 249 posted!

    Ok, got the GPU OC guys covered on build 249 I hope ;) See OP for download and other details about this build.

    You can use Trickster MOD or other compatible programs to set GPU frequency, or you can use an init.d script if you like. Please don't request GPU OC above 520MHz. This is as far as I am willing to go. This is a daily driver kernel, not a benchmark queen. 520MHz is 25% over stock and I can still achieve this without raising core voltage above 1200mV just like my older builds in the past. All SoCs are not equal, not everyone will be able to OC their GPU to 520MHz.

    Note: If you don't want to OC your GPU, you don't need to do anything and it will be the same as always.

    520 sounds good to me. I'm using Franco's kernel justnow to test, and 520 seems fine so far, that's about as far as I feel comfortable pushing a 416mhz chip. The good thing is that with the scaling its not running at that all the time, only when needed.

    3D games look a lot better with this OC. I want to get back to using Motleys kernel, so it would be nice if he could maybe keep 2 versions of build #247, one kept as is, and another with the 520mhz. Even better if it was adjustable like in Franco's, but I'm not too bothered, and I have no idea if it's an easy thing to implement or not.

    BTW, did anyone see the thread where there was a guy who oc'd his GPU to 766mhz and kept it at that permanently, his nexus for a while was refusing to start,, crashing every single night nearly, then finally gave in and died. He blamed it on the ROM he had installed, lol

    Or just how about just opening up the gpu frequency option to let us do whatever damage we want, but suggest 443

    That's what I suggested in the post of mine that you just quoted lol,, like the way it is in Franco's where the option appears in trickster mod and you can do what you like with it. But I don't know if it is too much work to make it like that, maybe its much simpler to just give us a couple of versions with different GPU speeds.

    Sent from my Nexus 7 using Tapatalk HD

    There's a lot of us that would like this great, solid kernel with either a 500-520mhz, or adjustable GPU. I don't know if you can edit it yourself somehow before flashing or what.

    Hopefully motley might help us out here... :)

    God help me. I wouldn't be wondering if motley might be kind and give us a more overclocked kernel, or make it so we can adjust it ourselves if I could just simply adjust it now, would I.

    Franco's allows overcoming the GPU, but not the CPU, if you can't wait on motley, who may or may not have the time to help us out. But personally I'd rather use this kernel, its proven to be the best, in my experience anyway. My opinion.
    22
    Build 247 posted with 4.2.2 patches

    Hi everyone, I just updated the kernel with 4.2.2 patches (see OP).


    Cheers guys, post if you find any other info on the subject..

    A shame though, because I've been using motleys for a good while now.. Guess I'll have to find another kernel, at least until the day when this one gets an update, and if that will happen who knows, I think he got an n4 and is more interested in developing for that instead. I didn't care about the lack of update before cos it worked great :-/

    R.I.P motley kernel, you will be sadly missed. :( lol

    Hi knuckles, I deserved that LOL. Sorry I haven't been around here much:eek: , but I hardly have time for one device let alone two. But, I am going to get better at managing my time between the two. The N4 stuff is hopefully slowing down a bit and I still love the N7 and have some things on the back burner I want to give a try.
    18
    New kernel for 4.2 build 233 posted! (finally)

    Hi guys, I hope everyone is doing well. Had some other life stuff to get done and now I finally have some time away from work and family to catch up the kernel. Thanks to metallice, clemsyn and the rest of you that provided support and being around when I couldn't be.

    I have posted a 484 MHz GPU build for with 4.2 support on the first post. It has been rock solid for me thus far. It should also support 3G models, but I have no way to test that myslef. If this goes well and folks are still interested in this kernel I will post a 446 and 520 GPU builds tomorrow. I also just posted a Nexus 4 kernel over in that forum as well in case anyone is interested. It feels good to get back to fooling around with Android, my mistress! Looks like some of the other kernel devs have been making good progress on the platform.

    Cheers,

    motley