Welcome to XDA

Search to go directly to your device's forum

Register an account

Unlock full posting privileges

Ask a question

No registration required
Post Reply

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

OP _motley

16th July 2012, 07:38 AM   |  #1  
_motley's Avatar
OP Senior Member
Thanks Meter: 2,407
 
858 posts
Join Date:Joined: Aug 2010
Donate to Me
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)
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
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.
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)
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.
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.
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)
motley_anykernel_nexus7_1.1.1_NoGPUOC_build_220.zip (GPU stock 416GHz)
motley_anykernel_nexus7_1.1.1_GPU484_build_219.zip (GPU OC 484MHz)
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)
motley_anykernel_nexus7_1.1.0_NoGPUOC_build_214.zip (GPU stock 416GHz)
motley_anykernel_nexus7_1.1.0_GPU484_build_213.zip (GPU OC 484MHz)
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)
motley_anykernel_nexus7_1.0.12_NoGPUOC_build_177.zip (GPU stock 416GHz)
motley_anykernel_nexus7_1.0.12_GPU484_build_176.zip (GPU OC 484MHz)
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://forum.xda-developers.com/show....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

(http://www.gnu.org/copyleft/gpl.html)
Last edited by _motley; 28th February 2013 at 02:12 PM.
The Following 324 Users Say Thank You to _motley For This Useful Post: [ View ]
16th July 2012, 07:47 AM   |  #2  
_motley's Avatar
OP Senior Member
Thanks Meter: 2,407
 
858 posts
Join Date:Joined: Aug 2010
Donate to Me
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.
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 by _motley; 3rd March 2013 at 01:56 AM.
The Following 52 Users Say Thank You to _motley For This Useful Post: [ View ]
16th July 2012, 07:56 AM   |  #3  
Clienterror's Avatar
Senior Member
Flag Quad Cities, Illinois
Thanks Meter: 306
 
1,893 posts
Join Date:Joined: Jun 2010
More
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 by Clienterror; 16th July 2012 at 07:59 AM.
The Following 2 Users Say Thank You to Clienterror For This Useful Post: [ View ]
16th July 2012, 08:06 AM   |  #4  
cwc3's Avatar
Senior Member
Flag Medford, OR
Thanks Meter: 420
 
526 posts
Join Date:Joined: Oct 2011
More
Thanks for another addition to the nexus 7 kernel community, love having different kernels to try.
16th July 2012, 08:20 AM   |  #5  
_motley's Avatar
OP Senior Member
Thanks Meter: 2,407
 
858 posts
Join Date:Joined: Aug 2010
Donate to Me
Quote:
Originally Posted by Clienterror

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 by _motley; 16th July 2012 at 02:32 PM.
The Following 2 Users Say Thank You to _motley For This Useful Post: [ View ]
16th July 2012, 11:57 PM   |  #6  
demandarin's Avatar
Recognized Contributor
Flag Alexandria, Va
Thanks Meter: 2,046
 
6,980 posts
Join Date:Joined: Apr 2010
More
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
17th July 2012, 01:32 AM   |  #7  
Sobai's Avatar
Senior Member
Flag Kelowna
Thanks Meter: 26
 
149 posts
Join Date:Joined: Sep 2009
More
I had the same issue. Couldn't pass the boot screen after flashing. On 4.1.1 latest update as of July 15th
17th July 2012, 01:51 AM   |  #8  
_motley's Avatar
OP Senior Member
Thanks Meter: 2,407
 
858 posts
Join Date:Joined: Aug 2010
Donate to Me
Quote:
Originally Posted by Sobai

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!
The Following 2 Users Say Thank You to _motley For This Useful Post: [ View ]
17th July 2012, 06:31 AM   |  #9  
_motley's Avatar
OP Senior Member
Thanks Meter: 2,407
 
858 posts
Join Date:Joined: Aug 2010
Donate to Me
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.
The Following 3 Users Say Thank You to _motley For This Useful Post: [ View ]
17th July 2012, 02:34 PM   |  #10  
_motley's Avatar
OP Senior Member
Thanks Meter: 2,407
 
858 posts
Join Date:Joined: Aug 2010
Donate to Me
New version released
New version released...see OP. GPU OC to 446MHz (up from stock 416)

Looking for more feedback

Click image for larger version

Name:	NenaMark2_2012-07-17_0112.jpg
Views:	20599
Size:	31.8 KB
ID:	1204164

The Following 4 Users Say Thank You to _motley For This Useful Post: [ View ]
Post Reply Subscribe to Thread

Tags
epic, nexus
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes