[KERNEL][CM7/MIUI][03/01/12] Glitch V13.1 - OC/UV - Voodoo - Glitchy Speed Fascinate

[KERNEL][CM7/MIUI][03/01/12] Glitch V13.1 - OC/UV - Voodoo - Glitchy Speed Fascinate - Fascinate Android Development

{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
These kernels are provided as-is without warranty. I'm not responsible for any problem you can encounter with your phone or if your cat suddenly dies.
Although, don't expect support even if I will eventually help since I love cats.
Note : These kernels are only compatible with CyanogenMod and MIUI roms !
Do you want to discuss on this kernel, get the fresh news on development, or become a kernel tester ?
Join the IRC channel from your web browser herehttp://webchat.freenode.net/?channels=glitchkernel ! No registration needed
Make sure the channel is "#glitchkernel" and you're set.
For those who already have an IRC client,
here is the server : irc.freenode.net
port : 6667
Channel : #glitchkernel
Overview :
- Up to 1.7GHz CPU OC with added bus/GPU OC (Thanks to morfic for the great base of work)
- Undervolting (using third party apps)
- Voodoo Sound & Voodoo Color (Thanks Supercurio & renaudallard)
- FPS uncap (Screen running 68Hz instead of 60Hz, from 56 to 66 FPS max) from JPX source
- Various tweaks for more smoothness and reliability
- LED notifications using Neldar's BLN
CHANGELOGS IN #2 POSTThe frequency/voltage & informative UV settings table is as follow for V13 kernel :
Note that these UV settings will be unstable on many devices. It's only informative.
1700 MHz - [email protected] 243 MHz - 1.500v / -> Most phones will fail here. -25 to -50mV may help to stabilize. Much stabler as unique frequency for benchmarks.
1600 MHz - [email protected] 229 MHz - 1.500V / -> That's high and many devices will fail on this frequency. Find working UV for you if any.
1500 MHz - [email protected] 250 MHz - 1.500V / -25mV
1440 MHz - [email protected] 240 MHz - 1.475V / -50mV
1400 MHz - [email protected] 233 MHz - 1.450V / -50mV
1300 MHz - [email protected] 217 MHz - 1.400V / -50mV
1200 MHz - [email protected] 200 MHz - 1.350V / -50mV
1000 MHz - [email protected] 200 MHz - 1.250V / -50mV - If you have stability issues, try to let this one by default.
800 MHz - [email protected] 200 MHz - 1.200V / -75mV
400 MHz - [email protected] 200 MHz - 1.050V / -100mV
200 MHz - [email protected] 200 MHz - 0.950V / -150mV
100 MHz - [email protected] 100 MHz - 0.950V / -200mV - (can be very different between two devices)
GPU frequency is linked to bus speed
More volts is not always equal to more stability. Try to add more UV (less volts) if the frequency you're trying to achieve is unstable.
Considering all phones will respond differently to OC/UV, to tweak the values to suit your device will be required.
By default, no overclock/undervolt is applied. You'll need to use one of the tools below to adjust the frequencies and voltages.
-Pimp My CPU (recommended if you're using MIUI) : http://forum.xda-developers.com/showthread.php?t=1018411
-Voltage Control : http://forum.xda-developers.com/showthread.php?t=829731
-SetCPU : http://forum.xda-developers.com/showthread.php?t=505419
Downloads
Glitch kernel (CWM flashable only)
Glitch Kernel Updater app now available on the Android market to support us !i9000 :
- 03/01/2012 - V13.1
Captivate:
- 03/01/2012 - V13.1
Vibrant:
- 03/01/2012 - V13.1
Fascinate:
- 03/01/2012 - V13.1
Telus Fascinate:
- 03/01/2012 - V13.1
OLDER RELEASESLIVE OC GUIDEFAQ, Changelogshttp://forum.xda-developers.com/showpost.php?p=13021804&postcount=2http://forum.xda-developers.com/showpost.php?p=13021804&postcount=2
-------------------------
Source :
- Glitch repo : https://github.com/organizations/Glitchkernel
Who is the Glitch team ?
- Kernel developement : ssewk2x & Tk-Glitch.
- Public relations / web hosting : Sixstringsg.
- App developement : Smasher816.
- Beta testers team, with members coming and leaving
Credits :
Codeworkx, Pawitp, Atinm, GuiPerPT, Unhelpful, Coolya, Morfic, Ezekeel, Zacharias.maladroit, Bilboa1, TheEscapist, Netarchy, Supercurio, lippol94, MAMBO04, Galnet, nitr8, Rahulrulez, Chadouming, renaudallard, existz, times_infinity, bearsfan85
Thanks to the donators and everyone bying the Glitch Kernel Updater app from the market, it's much appreciated and encourages us to continue our work !
Thanks to the beta testers team and to everyone helping me to debug and find new useful things to integrate !
Without all of you, this kernel wouldn't be !

Changelog
Changelogs :
V13 - LATEST
03/01/2012 - V13.1
- Cleanup.
- Fixed buttons freezing randomly.
- Fixed media buttons / headset buttons.
- Lots of GPIO fixes which eliminate phantom keypops.
- Added updated sysfs interface for smartass governor.
- Updated screenstate scaling script to use non-deprecated sysfs
interface for smartass2 and other govs.
- Back to CM7 LED Notifications.
- Lots of changes to cypress touchkey driver to guard against phantom
keypops and speed things up.
- Removed CarrierIQ-related virtual serial device. It probably wasn't
used, but now we know for sure.
- Changes to dpram (modem kernel interface) to make the radio a
little more stable.
- slightly more helpful gamma table error message.
- Moved call audio sysfs files from voodoo sound group to their own.
- Integrated 90call_vol into the kernel zip file so people don't
have to mess with it on their own.
- Now possible to choose any governor as sleep governor in the recovery.
- Vandalized bootlogo a bit.
20/11/2011 - V13
- Upstream synced to the latest at release time
- New CFLAGS again
- mfpu switched from neon to vfpv3
- BLN now working correctly, with LED timeout (thanks to Zacharias.maladroit)
- Back to hard float
- Updated toolchain to 4.5-2011.10
- Modified screen colors to look better (ugly gradient fixed, yellowish tint fixed). Don't use Voodoo Color punchy settings with this though (green screen likely to be back)
- Better reactivity under load
- 348MB RAM available
- Better 720p video recording (less buggy)
- Doubled SDCard read cache - Slight speed-up on SDcard read speed
- USB power drain fix
- Better memory management
- Back to 3.0V for the screen - 2.6V said not to give more battery life because of the added amperage
- Bugfixes
- Added Cgroup timer slack to group tasks by timer slack value
- Switched to Tree preempt RCU and added RCU boost
- New rethemed/recolored recovery menu and bootlogo, thanks to Fate-Silver for the blood
- Fixed "GLITCH" menu in recovery not showing for i9000 and Telus Fascinate
- Better handling of the CPU frequency table, + fixes
- Fascinate related fixes and updates from JT1134
- Added Lazy and SmartassV2 governors
- Fixes for SDCard handling
- All leakage settings are now available from a single kernel. Use the GLITCH menu in recovery (recommended way to switch the values)
- Added support of JT's 3-button recovery hack (credit to JT1134)
V12
13/07/2011 -> 29/09/2011 - V12 BETA #3
- BackLightNotifications (BLN) port, thanks to Zacharias.maladroit must use the BLN app. If it doesn't work, try Blinky. Still not fully working though.
- Some cleaning and added tiny fixes
- Fascinate : Now using Yamaha compass driver from ED01
- *Temporary* fix for green flashes/colors on low brightness (reborn/still not fixed in V11 - not yet proper though)
- Modified color multiplier to avoid yellowish tint by default
- Enhanced cleaning script when flashing
- Screen undervolt (from 3.0V to 2.6V) // it should help battery life
- Lowering kernel debugger buffer
- More work on leakage values
- Adding some old-school (V9D) CFLAGS resulting in substantial performance and stability gains
- 800MHz random lock fixed - not fully fixed it seems
- Popping keyboard bug fixed
- Make use of NEON accelerated mfpu
- Slightly more aggressive ondemand governor default settings // searching the best balance for efficiency
- Added a few speed enhancements
- In-call receive audio is much louder across the board. You can now hear your significant other yelling at you if you're in a noisy area. Sorry, guys
- In-call mic gain should see some improvement as well. Meaning your wife can now hear you apologizing better
-- caveat: I've heard conflicting reports about this while using bluetooth. I'm investigating that, so stay tuned.
- Overhauled the screen state scaling feature.
-- governor setting now stays put
-- users can now enable/disable the feature and configure it via the custom recovery listed below
- New recovery. Screenstate scaling is controllable via recovery, and it's themed now.
-Audio output and input controllable via script linked in OP
-Call volume tweaks re-written to be more clean/effecient.
-Screenstate bug fixed, doesn't cause lag anymore.
-Upstream synced (this means you must be on the latest nightly for your device for this to work)
-New drivers
V11
13/07/2011 - V11
- Upstream synced as always (updated recovery...)
- More debug stuff disabled & cleanups/fixes on various things
- Printk disabled to reduce overhead
- Updated to linux kernel 2.6.35.13
- OC implementation fixes and modifications (fixing overvolt in Voltage Control Xtreme as well as some other tiny things)
- Added experimental GPU OC implementation from TheExcapist (for future use / not yet functional)
- 1.7GHz step added - working on some pretty good phones
- Modified touchkey/Led notifications settings from Zacharias.maladroit
- Added SLQB
- Added SIO and BFQ schedulers
- Back to LZO compression for faster boot time
- New voltage settings for more stability
- Trying some new speed tweaks
- Better memory management
- 340MB of RAM available for user without breaking 720p recording
- Preemptible Tiny RCU
- Automated per tty task groups patch
- Added InteractiveX governor
- Two new branches for OC settings adapted to high and low leakage chips
- Toolchain sorcery, thanks to Zacharias.maladroit (RIL is compiled using 4.4.3 toolchain, and everything else is compiled using 4.5.2 toolchain -> more speed and stability)
- Enhanced Voodoo Color settings from renaudallard
- Voodoo Sound V10
- Allow CPU-supported unaligned accesses
- Logcat on/off scripts (built as module)
- Bluetooth HID support
- New, cleaner bootlogo
- Now cleaning old scripts, OC values, cache and dalvik cache on kernel installation - thanks to lippol94
- Green tint on low brightness fixed
- Switched to ondemand governorV10
27/05/2011 - V10A Do not use with CM7 builds older than 23/05 (as well as the 28/05 or newer build) or MIUI -> you'll get no service !
- Now fully compatible with latest CM7 Nightly builds
- Back to 2010.09 toolchain -> slower & less stable but needed to make a working kernel for latest builds
- Upstream sync (bigger radio partition, headset stuff..)
- Int voltage changes to get some stability back on all overclocked frequencies
- A bit faster 1.5 and 1.6GHz steps - Could make these steps unstable for some, please try and report
- Smartass governor tweaked for faster scaling up, and slower scaling down -> better stability and speed
- OC code bugs and inconsistencies introduced in V7B now fixed (it was here to prevent sleep of death issue, now fixed)
- Some fixes and enhancement for compatibility with Xan's Voltage Control app
- Various tweaks for MOAR SPEED
- Black magic
Known issues :
- The reboot recovery command seems broken for some reason on recent builds. Probably rom related.
- Some users still get freeze issue on boot. If you have this issue, please use the "no-optimization" kernel for you device from this post : http://forum.xda-developers.com/showpost.php?p=14180722&postcount=2077
03/06/2011 - V10B To use with newest builds only (equal or newer than 28/05) !
- Upstream sync (FM radio, new Voodoo Sound implementation, etc...)
- Back to 4.4.3 toolchain - needed for new RIL
- Big cleanup - rewrite from scratch
- Many fixes
- New tweaks for speed on 4.4.3 toolchain
- New tweaks for stability on 4.4.3 toolchain
- Black magic
17/06/2011 - V10C (Updated) To use with newest builds, #28+ for i9000 or equivalent
- Upstream sync (cpuidle, updated drivers (wifi etc.), Recovery 4.0.0.x, etc...) (updated as of today 17/06)
- More debug stuff disabled
- Dock audio support (experimental)
- Added DIDLE (Deep Idle) support (removed, buggy)
- New voltage tweaks for added stability on some devicesV9
16/05/2011 - V9A
- Merged with the now dead V8C update because of new added features
- Upstream sync : Calculate battery percentage as percent of max capacity reported when battery full, new wifi driver, etc.
- New PMEM settings for more available RAM (now 331MB)
- 1.54GHz step added with some gentle settings for now.
- New step by step frequency switch when scaling down (part of the Galaxy S II port from Bilboa1) - more stability on highest frequencies
- Corrections and further tweaking on smartass governor + some fixes from Netarchy (Nexus S). 400MHz lock when screen is on removed (not needed anymore -> more power saving)
- Higher cache for faster SDcard read speed
- New sleep settings : Effective lock to 400MHz max when screen is off -> fix long wake up/hiccups when playing music or similar use. Be careful with your UV settings on 200 and 400MHz steps to avoid sleep of death problems ! These were not used on previous versions of my kernel (locked to 100 MHz when screen off and locked to 400MHz when screen on with a buggy gap in smartass governor forcing generally 600+ MHz)
- 600 MHz step removed (it was generating instabilities on some phones when jumping to 800 or down to 400 when using UV)
- Some voltage tweaks for added stability on some devices (as always)
- Cleanups on unused/no more needed stuff
- Little surprise, thanks to Morfic
- Updated to V9A² to fix SOD and some performance issues
21/05/2011 - V9B
- Upstream sync (CWM recovery 3.1.0.1, better screen colors (kills voodoo color for now and looks awful on my 0516 build, but should be good on latest), GPIO fixes, samsung modemctl...) + small changes on my side for official CyanogenMod repository compatibility
- Voodoo Sound updated to V9 / cleaned voodoo color stuff until it works again
- New cleaner bootlogo based on the one in first post, preferred by most users
- Some additional compilation flags from Netarchy and Zacharias.maladroit (better overall performances + NEON)
- Screen refresh frequency bumped to 72Hz (68Hz effective). It'll uncap FPS to 66 again but seems stabler than before on framerate (the divide/2 behavior happens less)
- Added screenstate scaling script from well.heeled.man as a test (with my kernel's smartass default settings). It should give better sleep power consumption as well as better power efficiency on screen off tasks like music playing etc. by switching to conservative governor.
If you want more information, discuss on this or contribute to enhance it, please come here : http://forum.xda-developers.com/showthread.php?t=1087646
- Adding some stuff from Zacharias.madadroit :
- Higher battery charging temperature
- Scheduler tweaks
Alternative version now available (V9B-VC) using old AMOLED panel color/gamma settings and with Voodoo Color V2 added back.
24/05/2011 - V9C TO USE WITH CM7 Nightly build #12 OR HIGHER ONLY
(Updated to fix "no service" issue, but still sucks.. unstable on #12 build, very stable on others but no service)
- Upstream sync (PMEM disabled (gives 339MB RAM now), new RIL, headset fixes...)
- Divider changes for MUCH better stability on 1.2GHz at the cost of a slight decrease on performances
- New branch with Voodoo Color display driver and "old" color settings named "VC"
- Fix for Vibrant no service problem - hopefully
- Small changes on smartass governor for better scalability (reverts some old settings not needed anymore with the screenstate script)
- Glitch logo now in update script too for nanu_x2 to be amazed when installing my kernel
24/05/2011 - V9D TO USE WITH CM7 Nightly build #11 OR LOWER (for i9000, or cappy/vibrant equivalent) AND MIUI ONLY
First "D" revision.. Sound like duty. It's basically a fix of a fix done to make the V9C features available for "stable builds" (considering the i9000 #12 isn't)
- Obviously all the V9C changelog
- Using old RIL to be compatible with builds before #12 for I9000 (--> WON'T WORK with #12 for i9000 or equivalent !)
- Replaced 1.54GHz step by 1.6GHz (1.54GHz step was somewhat useless, too close to 1.5Ghz, and slower overall because of the lower bus speed)
- I can't build Vibrant ATM, the CM7 build system is broken on this device or I'm doing something wrong but I wasn't able to fix it. Any help is appreciated. I'm sorry for Vibrant users I'm screwed.V8
07/05/2011 - V8A - To use with 05062011 or newer CM7 build (useable on MIUI RC8 but you'll lose camera - MIUI needs an update)
- Upstream sync (camera fixes etc.)
- More stability fixes
- Cleanups on OC code (found that 1.2 and 1.3GHz were very unstable compared to earlier releases)
- More work on Vibrant/Captivate. The kernels are now available to download but are untested - for now. Feel free to try and report any problem or if all runs well. If I have enough positive reviews, these kernels will be released in their respective device sections.
11/05/2011 - V8B
Upstream sync only :
- USB switch suspend
- TV out stuff
- Fascinate specifics
- Revert "Got back to previous samsung_modemctl" for 05112011 CM7 build
V7
02/05/2011 - V7A - To use with 05012011 or newer CM7 build and MIUI RC8+ only
- Resurrect Voodoo Color killed by 2.3.4 merge.
- New step for 1.5GHz on top of 1.44GHz (now 9 steps total versus 8 before)
- Forcing 400MHz max when sleeping for added battery life (default = 800). Couldn't detect any side effect.
- New tweaked Smartass governor now default (800MHz min when screen on). Please report your experience
- It seems the smartass governor is not working by default, it will revert to performance >< Please force it to get it to work -> Ok found the problem, I'll update in a min
- Now updated to V7A-2 to fix the governor bug
03/05/2011 - V7B - To use with 05012011 or newer CM7 build and MIUI RC8+ only
- Resurrect Voodoo Color killed by 2.3.4 merge - Again - fully working now
- Fixed sleep of death issue when unplugged
- Switched to LZO compression for better overall speed and reduced boot time
- Tweaked smartass governor more for - hopefully - better battery life and a bit more responsivity
- New voltage and frequency table rewrite as a bonus with now 11 frequencies total
- Stability fixes on 1.5GHz step -> please test and report
- Reverted FPS uncap - at least for now - for two main reasons : more stability on high GPU freqs (1.4GHz and more), and to prevent FPS limit at max/2 (33 when unlocked to 66), limiting overall performances in heavy scenes. I think there's a lack of buffering somewhere.. It will give higher scores on some benchmarks, and lower on others. A better battery life can indeed be expected too.
- Upstream sync
05/05/2011 - V7C - To use with 05032011 or newer CM7 build and MIUI RC8+ only
- Upstream sync (better battery life, reboot recovery, etc.)
- A general stability fix missing from V7 branch added back
- Tiny tweaks on the voltage table
- Big bugfix on the V7 branch (redone from scratch, cleaner)
- Switched to 2011.03 toolchain
- Added some optimization flags, "-mfloat-abi=hard" being one of them (up to 40% performance gains in specific cases)
- Small improvements here and thereV6
WIP
22/04/2011 - V6pre - preview/work in progress of upcoming V6A update *test* :
- Reverted PMEM settings to new CM7 default (317MB - same as V5A)
- Reverted some stability fixes that weren't that stable on some devices, or even prevented some to boot
- New voltage table for a more linear increase, improving stability at default settings
- Switched to Deadline scheduler by default as it appears more stable
- Back to 2010.09 toolchain for speed and efficiency
- Synchronized with last update from SGS CM7 team
Better to use CM7 04212011 update with this kernel and newer.
22/04/2011 - V6pre - update 1 :
- Battery polling bumped to 15 sec (was 1 before), it should help battery to an extent (thanks to Zach for the idea)
- Some internal voltage tweaking to hopefully be more UV friendly
- Bumped USER_HZ for more smoothness
- Another -rare- bootloop fix
22/04/2011 - V6pre - update 2 :
- Added some tweaks from V5A for testing
- Resolved a bug generating fake voltage reading
- Resolved a bug on 400MHz step generating instabilities
- Slight changes to the voltage table
- Fixed a typo
- Trying some toolchain switch - again-
23/04/2011 - V6pre - update 3 :
- Corrected Led Notifications - Now it should work properly again !
- Various bugfixes and typo corrections
- Toolchain change once again
- Added new Interactive governor with aggressive settings for even more speed. You need to change it by app (pimp my cpu/cyanogen settings), it's still on conservative by default.
(thanks Zach for your suggestion)
25/04/2011 - V6pre - update 4
- Cleanups on Led notifications to resolve a bug (buttons stopped working randomly for some users)
- More typo corrections
- Voodoo Sound V8
- Various bugfixes on CPU load and schedulers
- CONFIG_CC_OPTIMIZE_FOR_SIZE disabled for speed
- Lower latency on GPU states switch for stabler performances
- Added a stability fix for voltage change latency when frequency is changing. It should give more stability with high undervolt or big voltage differences between two steps - Please test and report ! (Thanks Zach for pointing that to me)
- Two versions for testing purposes : V6pre-u4 is compiled using GCC 4.5.1 toolchain, and V6pre-u4(alt) is compiled using GCC 4.4.3 one. If you get instabilities on the first one, try the other and vice versa. Please report your findings on that because it was the first stability differences source between my kernel revisions. For information, V6pre-u2 was compiled with 4.4.3, and u3 with 4.5.1.
27/04/2011 - V6pre - update 5 >> 6
- Name changed from "TkGlitch" to "Glitch"
- Cleanups on buttons (Kangsterizer)
- Lower latency on GPU states switch for stabler performances in 3D and/or at high GPU frequency - corrected, thanks to Kangsterizer
- Added a stability fix when frequency changes for cpufreq governors
- Tweaked Interactive and Conservative governors for testing
- New Frequency table : 1.5GHz is now the max selectable frequency, and 800MHz and 400MHz steps are now replaced by a unique 600MHz one.
- Changed initramfs source to remove the annoying "E:no misc partition" error in the recovery
- Now bumped to update 6 to fix an issue with the conservative governor.
27/04/2011 - V6pre - update 7
- New Frequency table : 1.44GHz removed, 800 and 400MHz steps are back.
- Battery polling bumped from 15 to 30 seconds
- GPU power latency bumped from 10 to 60 ms
28/04/2011 - V6A - To use with 04282011 or newer CM7 build only
- New sensors drivers added
- Normalized 1.5GHz bus speed (GPU will now run @ 250MHz versus 247MHz before. It can affect your stability !)
- Int voltage lowered for 1.5GHz step because it did have a bad effect on lower frequencies stability
- GPU power latency back to default - but fixed (100ms)
29/04/2011 - V6B - To use with 04282011 or newer CM7 build only
- New initramfs source to fix compass and update CWM recovery
- 1.5GHz replaced by 1.48GHz for stability
- New voltage table as requested by many users (+25mv on 1200 to 1400MHz steps)
- New interactive governor for better scaling and battery life
- New tweaked smartass governor for testing (pretty bad on CPU benchmarks for some reason, please test how it feels in real world use)
- New ondemand governor from Zacharias.maladroit sources for testing
02/05/2011 - V6C - To use with 05012011 or newer CM7 build only
- Small update to merge with 2.3.4 source, no new feature.
02/05/2011 - V6C² - To use with 05012011 or newer CM7 build only
- Update to repair Voodoo Sound conflicts from 2.3.4 merge.
- Back to 1.44GHz max to prepare 1.5GHz return
V5
19/04/2011 - V5A - Initial release
21/04/2011 - V5B :
- GPU overclock on 1.3 GHz added (217MHz / +8.5% from default)
- New PMEM settings for more available RAM compared to V5A (now 328MB)
- Stability fixes for all frequencies, needing globally less volts. Results may vary depending on the device
- Switched to Conservative governor by default (still switchable by app). It can feel less responsive coming from idle but more battery saving, and plays better with high frequencies.
- New voltage table. Default settings should be stabler for most devices.
- Switched to 4.4.3 toolchain for added stability on some sensitive devices
Captivate and Vibrant support will come later. It will need more time than expected.
21/04/2011 - V5C : Small update to fix a bootloop issue on some devices.

F.A.Q.
Because I got tired of answering these same things 100's of times.
1) Where can I find the latest beta?
They are always in the OP. They are also in my signature, and the root of the FTP.
2) Where is the root of the FTP you ask?
Good question! It’s in the OP as well.
3) How do I install this? / I'm having problems installing
Reboot into recovery
Install zip from SDcard
Choose zip from SDcard
Navigate to the zip you downloaded.
4)What is Leakage (LL,ML,HL) and what one should i use?
Easy explanation: start with HL. If it allows you to OC how much you want,
stay there. If not, move down until you get what you want.
For people who want more: Well, we made different leakages because koflem couldn’t OC, and he felt left out,
so he started compiling on his own, which gave Tk-Glitch the idea to make three different versions.
They have to do with the differences in different phones. Take for example different phones run better
with different OC/UV. The leakages are the same way. They adjust the int voltages, which is something
not configureable (yet) in userspace, so we have to configure them that way when we build. That way both
the voltages that you are used to (the ones controllable via voltage control) are tailored to your device,
as is the int voltages (the ones only we can do). Most people have no idea, but there are dozens of
variables that we play with to make so that all of you can OC and UV as much as possible with as much
stability as possible. Some aren't device specific, some are. We are trying to make the best experience
possible for a wide range in chip quality, therefore we make different leakages, as well as making the kernel
configurable via voltage control. From a stability/performance standpoint, and by extension standpoint,
there is only one leakage right for your device. Different leakages aren't better in some ways for you
and worse in others, there is only one good one for your device. Sorry if that didn't make sense, I tried
to make it as informative as possible without it being overwhelming.
5) Does this work with Gingerbread bootloaders?
Yes
6) What ROM does this kernel work on?
For sure: CM7. Other CM7 based ROM’s may work, but I can’t offer you much support. If it works on CM7,
that’s my goal. This WILL NOT work on Samsung based ROM’s, and I won’t port it. If you still don’t know
what ROM this will work on, then you should read a lot more.
7) How do I enable BLN?
Download either BLN here:
https://market.android.com/details?id=neldar.bln.control.free&feature=search_result
Or Blinky here: https://market.android.com/details?id=com.kin.blinky&feature=search_result
8) How do I overclock?
Xan’s Voltage Control App here:
https://market.android.com/details?id=com.darekxan.voltagecontrol&feature=search_result .
READ THIS GUIDE FIRST: http://forum.xda-developers.com/showthread.php?t=1036020
If you break something while Overclocking, I won’t provide much support. Overclocking is awesome, but very
variable across devices. We try and make a stable experience for everyone, but it is not guaranteed. If
it breaks, I didn’t do it. If it makes your phone fly, I did it.
9) Can I be a beta tester?
Probably not. Unless you do something to make me like you a lot (cough strictlyrude27 cough), then you can’t
have betas. The reason being they are unstable usually, and I already have a big enough team that I can get
the information I need.
10) Why does my screen look ugly? / How do I change the screen color?
Go grab voodoo control from the market here:
https://market.android.com/details?id=org.projectvoodoo.controlapp&feature=search_result ,
then play with the sliders until you like what you
see. If you get really stumped, here are some values that people tend to like. They are from
zacharais.maladroit.
Screen RGB multipliers:
- Red: 321*
- Green: 321*
- Blue: 429*
Screen v1 gamma hack:
- use Alt. settings
- or if you prefer others - use: "Reset to 2.3.3 defaults", "Punchy settings" (punchy could lead to a great
screen while locking the screen and having "screen off" animation disabled)
1)Color Profiles: Voodoo Profile V1
2) Screen v1 gamma hack :
- 50 red
- 53 green
- 44 blue
3) RGB multipliers:
Red ="2300875360"
Green ="2300875360"
Blue ="2709919680"
11) The backlights on my soft keys stay on all the time. Why is that?
Honestly, because I haven’t spent the time to “fix” it. They aren’t that bright, so people can stand it for
a little while. I didn’t intentionally make it that way, it happened when we switched back to BLN instead of
LED notifications. We made that switch because I like Blinky, and I get to pick until Tk-Glitch is back, or I
am convinced otherwise.
12) I’m getting bootloops, why?
Well, the most common issue is that you have mismatched ROM’s and kernel’s. You need the latest ROM for your
device, and the V12B3 kernel for your device. For where to find that, see above. The next is various scripts
and “fixes” that you flash after/before the kernel. Reflash the nightly for your ROM, then the kernel. Let it
boot. If it works and didn’t with the various other zips you may use, then don’t use those zips.
13) WHEN IS THE NEW VERSION OUT?
First Rule of Cyanogenmod... I'm allergic to ETAs so I try to stay away from them if at all possible.
Causes all kinds of nasty problems they do....
14) How do I use the 90_callvolume script?
neh4pres wrote these instructions, if clarification is needed just ask.
There are many ways to apply this patch. But for these instructions i will be using root explorer because it
has all the utilities needed.
After downloading, use root explorer to extract 90call_vol from the .zip. this will place 90call_vol in the
extracted folder of your sd card. Long press and copy that file and paste it in the /etc/init.d folder. Once
it pastes long press the file and open with text editor.
In call boost.. only change the final number in the line you want to adjust and keep that number between 0 and 3
INCALL_BOOST_EARPIECE=2
INCALL_BOOST_BLUETOOTH=2
INCALL_BOOST_SPEAKER=2
INCALL_BOOST_HEADPHONE=2
Mic gain only change the final number in the line you want to adjust and keep that number between 0-31
MIC_GAIN_EARPIECE=19
MIC_GAIN_SPEAKER=31
MIC_GAIN_HEADPHONE=29
MIC_GAIN_HEADPHONE_NO_MIC=18
Save changes when exiting and the editor will append the original file with a .BAK .
You can use 90call_vol.bak to revert back one save. If you change multiple times and want to go to stock you
can use the 90call_vol in /sdcard/extracted.
15) Is the GPU overclocked?
Yes. Can you control it? No. That code hasn't ever worked, and we don't really expect it to. The GPU is so overclocked at 1.5 Ghz that if it went any higher the memory would get corrupted and really bad things happen.

.............................................

Good deal with new thread! It was getting a bit jumbled. This wil help me/us stay up-to-date with current changes and wut-not!!!

I have a question relating to voltage control. I am able to set and apply changes to my voltage settings in both the general and advanced tab. I can apply, save profile, and save boot settings for these parameters.
However when I close voltage control and open it up again, the settings don't seem to be enabled. I can load the profile and apply it to both tabs again, but I just don't know if it's sticking.
Anyone have this situation?

djk21108 said:
I have a question relating to voltage control. I am able to set and apply changes to my voltage settings in both the general and advanced tab. I can apply, save profile, and save boot settings for these parameters.
However when I close voltage control and open it up again, the settings don't seem to be enabled. I can load the profile and apply it to both tabs again, but I just don't know if it's sticking.
Anyone have this situation?
Click to expand...
Click to collapse
After applying settings, they won't show up properly the next time you open it. Exit out and open it again, you should be good then.

I am experiencing some kernel-related random reboots, with v12.
This is with a fresh ROM install v34 and glitch v12, the phone will freeze for 10 seconds (about) then go back to SAMSUNG and effectively reboot.
It virtually always comes back up just fine. I'd say this happens between 5 and 20 times per day (depending how much I use it).
It seems to do it regardless of: governor, scheduler, overclocking (just staying at 1000mhz, same results), undervolting (HL or LL kernel, same success rate), or apps installed (beyond the apps that come with CM7).
The only thing I can do to stop the rebooting is NOT flash the Glitch kernel at all. I can test v11 or other kernels, but any kernel that leaves call volume super low is almost useless to me (which is why I wasn't using cm7 before) as I need the phone for work.
Logcat-on doesn't seem to give me a very good diagnostic of what's happening, but I'm working on getting better information. When it happens with ddms open, I seem to just get a cutoff of data, and the phone disappears from the list (then reappears when it reboots).
As soon as I figure out a specific trigger, I'll edit this post and post it. But it seems 'random' (could be scrolling a widget, could be opening an email, could be in google maps, could be opening the app drawer, could be opening the Dialer).
Thank you for all of your work. Without you, this community doesn't exist. Thank God for developers selflessly dedicating themselves. I love my Fascinate (instead of hating it) as a result.

pkopalek said:
I am experiencing some kernel-related random reboots, with v12.
This is with a fresh ROM install v34 and glitch v12, the phone will freeze for 10 seconds (about) then go back to SAMSUNG and effectively reboot.
It virtually always comes back up just fine. I'd say this happens between 5 and 20 times per day (depending how much I use it).
It seems to do it regardless of: governor, scheduler, overclocking (just staying at 1000mhz, same results), undervolting (HL or LL kernel, same success rate), or apps installed (beyond the apps that come with CM7).
The only thing I can do to stop the rebooting is NOT flash the Glitch kernel at all. I can test v11 or other kernels, but any kernel that leaves call volume super low is almost useless to me (which is why I wasn't using cm7 before) as I need the phone for work.
Logcat-on doesn't seem to give me a very good diagnostic of what's happening, but I'm working on getting better information. When it happens with ddms open, I seem to just get a cutoff of data, and the phone disappears from the list (then reappears when it reboots).
As soon as I figure out a specific trigger, I'll edit this post and post it. But it seems 'random' (could be scrolling a widget, could be opening an email, could be in google maps, could be opening the app drawer, could be opening the Dialer).
Thank you for all of your work. Without you, this community doesn't exist. Thank God for developers selflessly dedicating themselves. I love my Fascinate (instead of hating it) as a result.
Click to expand...
Click to collapse
I have no idea, ill look into it.

Just flashed v12, running omfgb 8/25. Running fast and smooth, I was on v11.1. This is the best rom/kernel combo i've used! Thanks devs for all your work and support. I will report after a couple days.
Sent from my omfgb/glitch fascinate using XDA Premium App

*Luke* said:
I had this issue a couple times after flashing ROMs to my Droid 2. Generally what worked for me was formatting the SDcard. I'm not sure if this would be a viable solution with the fascinate, but I suppose if no other solution is found, it may be worthwhile to try. I seem to remember hearing that restoring apps and data from titanium backup can occasionally cause the random reboot issue as well. If that could potentially be the case, maybe try a fresh install restoring apps from the market instead of with TiBu to see if it clears up?
Sent from my I500 using XDA App
Click to expand...
Click to collapse
Yeah, a factory reset should work.

Any plans to incorporate anything from the eh09 sourced drop?
Sent from my SCH-I500 using XDA App

akellar said:
Any plans to incorporate anything from the eh09 sourced drop?
Sent from my SCH-I500 using XDA App
Click to expand...
Click to collapse
If it is incorporated into upstream CM7, then yes.

sixstringsg said:
If it is incorporated into upstream CM7, then yes.
Click to expand...
Click to collapse
It will be; jt already got sensor fixes but he was having kernel.org issues as well. he should be able to get them up soon.
Sent from my MIUI SCH-i500

sageDieu said:
It will be; jt already got sensor fixes but he was having kernel.org issues as well. he should be able to get them up soon.
Sent from my MIUI SCH-i500
Click to expand...
Click to collapse
Once the repo stuff is fixed, we'll be good to incorporate it.

I apologize if this isn't kernel related but any ideas why android system is holding a wake lock? Obviously this is causing a lot of unnecessary battery drain as well.

akellar said:
I apologize if this isn't kernel related but any ideas why android system is holding a wake lock? Obviously this is causing a lot of unnecessary battery drain as well.
Click to expand...
Click to collapse
I bunch of good people have been working on it, and nobody has come up with a solution. If you reboot when you start to notice it happening, that usually helps. It's a issue with Samsung phones across the board.

sixstringsg said:
I bunch of good people have been working on it, and nobody has come up with a solution. If you reboot when you start to notice it happening, that usually helps. It's a issue with Samsung phones across the board.
Click to expand...
Click to collapse
Ok thanks. Unfortunately this is happening daily so it seems I'll be rebooting pretty frequently if that's the case.

akellar said:
Ok thanks. Unfortunately this is happening daily so it seems I'll be rebooting pretty frequently if that's the case.
Click to expand...
Click to collapse
It happened to me, and it comes and goes. Make a new empty file in /data/media titled .nomedia, that may help.

Related

[Kernel-.33.3][DIET][05/02] CM 5.0.6, 8 MB+ RAM, Hybrid AVS STABLE, Optional OC

Diet Android Kernel 2.6.33.2 by PsyQ
I am releasing the kernel which I use by myself I removed most of the debugging options useful for kernel/driver debugging and maxed-out possible compiler optimizations. It has Hybrid AVS support using IntersectRaven's improved method as well as optional overclocking (see note)
These kernels feature:
* Hybrid Adaptive Voltage Scaling for extra battery life
* Optional 1.1 GHz Overclocking Support
* Extra 8 MB of RAM reclaimed from Camera
* Based on Cyanogen's 5.0.6 kernel
* Maximum possible compiler optimizations (loop unrolling, tree vectorization, NEON, Cortex A8 compiler tuning, armv7a target, and many more)
* Removed all unnecessary features from the kernel configuration, including debugging options (these kernels are not useful for kernel debugging / driver development)
* All cpufreq governors (ondemand, powersave, conservative, ...) for people that want to tweak the CPU frequency scaling
Following kernels are available:
diet_2.6.33.3.hybrid_avs_800mv.zip --> Hybrid AVS support, goes down to 0.8 volts and has stock frequency (998 MHz) as max.
diet_2.6.33.3.hybrid_avs_800mv_OC.zip--> EXPERIMENTAL Hybrid AVS with overclocking to 1.1 GHz (0.8v min voltage)
diet_2.6.33.3.hybrid_avs_925mv.zip --> Hybrid AVS support, goes down to 0.925 volts and has stock frequency (998 MHz) as max.
diet_2.6.33.3.hybrid_avs_925mv_OC.zip--> EXPERIMENTAL Hybrid AVS with overclocking to 1.1 GHz. (0.925v min voltage)
To use it, flash the zimage with fastboot and push the bcm4329.ko to the /system/lib/modules:
Code:
[power off your phone and boot into fastboot]
fastboot flash zimage zImage
[reboot]
adb remount
adb push bcm4329.ko /system/lib/modules/bcm4329.ko
Pushing of the bcm4329.ko is necessary as WiFi support would be broken otherwise. If you don't do it, WiFi will not work.
Changelog:
Code:
V1.11 - Update - May/02nd/2010
- Moved to 2.6.33.3 Kernel
V1.10 - Update - Apr/26th/2010
- Changed floating point model to VFP
- There are two AVS versions with different lowest voltage limits (800/925mv)
V1.09 - Update
- Implemented IntersectRaven's Hybrid AVS method
- Synced with the latest code snapshot of CM kernel
V1.08 - Update
- Non AVS kernel is now undervolted down to 0.925v
- Kernel RCU is now of uniprocessor type, saving memory
- DMA speedup patch from latest CM source
- Removed "loopback" file device (this is not related to network)
- Further compiler optimizations
V1.07 - Update
- 8 MB RAM reclaimed from Camera
- Further kernel trimming
- AVS is now available with 0.925v and 0.850v flavors
- Some attempts to make AVS more stable (still work in progress)
V1.06 - Update
- Moved to kernel 2.6.33.2 from Cyanogen's 5.0.5.6 source
- AVS kernels are capable of undervolting down to 0.925v instead of 1.000v
- Minor cleanups
V1.05 - Update
- Further fixes in AVS Support (thx intersectRaven!)
V1.04 - Update
- Fixed bugs in AVS Support
- More kernel tweaks
- Removed "normal" version of the kernel, as _xtra seems to be stable enough
- Added non-overclocked AVS kernel for maximum battery life
V1.03 - Update
- Added Experimental Adaptive Voltage Support (AVS)
- Currently AVS is "for test only", and this kernel has debug support and no loop unrolling
V1.02 - Update
- Switched to CFQ I/O Scheduler
- Removed some more stuff (e.g. 10 Gbit Ethernet Support)
V1.01 - Update
- Added Conservative Governor
- Fixed table lookup bug (thanks pershoot!)
V1.0 - Initial Release
- Based on CyanogenMod 5.0.5.3 source
- Overclocking Support (1.1 GHz)
- Undervolted
- Optional extra undervolt (see attachments - _xtra is additional UV)
- Added Powersave CPU governor
- Removed most of the debugging stuff from Kernel (which makes this kernel useless for kernel debugging!)
- Even more C compiler optimizations (almost -O3 level + extra stuff, like loop unrolling, etc...)
- Audioboost patch
For other kernel developers - you can find the source code here (note that for AVS support you need AVS sources from ChromeOS):
http://github.com/psyq321/nexus_one_kernel_additions

Do you use the xtra version, if so have you noticed any problems

Nice release, will definitely try sometime.

Grrr!!! checked for updated version right before leaving for work, and just missed it!
I am using the one you posted in the other forum without any issues. Does it possess the same undervolting as the Xtra version?

Yes, _xtra is using same undervolt as the version from yesterday.
Additionally, this version contains more optimizations (loop unrolling) that I managed to cram-in by removing more debug options of the kernel (otherwise it would not fit)

What is loop unrolling?

Awesome, I'll pull the config to see what you have done...

just installed on my device. so far so good, using the extra undervolt. booted fine and everything so will report back later if I notice anything weird.

Hi man, in first thanks for this work...
Now can u tell me how can i use your kernel?
Thanks in advanced

just
[power off your phone and boot into fastboot]
fastboot flash zimage zImage
[reboot]
adb remount
adb push bcm4329.ko system/lib/modules/bcm4329.ko

interesting...I've been experimenting with the compiler optimizations in my own build...it made the kernel bigger although I feel a bit more responsiveness now...almost not noticeable but I think its there...

xPatriicK said:
What is loop unrolling?
Click to expand...
Click to collapse
Loop unrolling is the optimization technique used by modern compilers to potentially speed-up execution by decreasing overhead of the loop passes.
For example, imagine that you have a loop, that does something 4 times:
Code:
for(x=0; x<4; x++) {
do_something;
}
In this case, some % of the execution will be checking if the x is less than 4, and if no - "doing_something" again. This check has to be performed for every step (so, it is done 4 times)
Now, if you unroll this loop, it would look like this:
Code:
do_something; x++;
do_something; x++;
do_something; x++;
do_something; x++;
^ So, in this case, we completely eliminated checks.
Or, if the loop is much bigger (say, x goes up to 800):
Code:
for(x=0; x<800; x+=4) {
do_something;
do_something[x+1];
do_something[x+2];
do_something[x+3];
}
See? In this case, you reduce the number of condition checks for bigger loops.
This can sometimes make code faster - but the downside is that it makes the code bigger (which is obvious even in those examples above).
In Android Kernel 2.6.33.1 case - loop unrolling increases zImage size by ~350K. If I didn't strip debugging stuff out, zImage would be too big to fit on Nexus One.
Fortunately, there was approx. 400K to be saved by just kicking out features that enable kernel debugging. I don't think most of the people need that. These features are useful for kernel and driver developers, but most of others can perfectly live without them

Alright, thank you!
will try _xtra when Paul released the new Desire cam. Thanks for your work

Ivan Dimkovic said:
Loop unrolling is the optimization technique used by modern compilers to potentially speed-up execution by decreasing overhead of the loop passes.
For example, imagine that you have a loop, that does something 4 times:
Code:
for(x=0; x<4; x++) {
do_something;
}
In this case, some % of the execution will be checking if the x is less than 4, and if no - "doing_something" again. This check has to be performed for every step (so, it is done 4 times)
Now, if you unroll this loop, it would look like this:
Code:
do_something; x++;
do_something; x++;
do_something; x++;
do_something; x++;
^ So, in this case, we completely eliminated checks.
Or, if the loop is much bigger (say, x goes up to 800):
Code:
for(x=0; x<800; x+=4) {
do_something;
do_something[x+1];
do_something[x+2];
do_something[x+3];
}
See? In this case, you reduce the number of condition checks for bigger loops.
This can sometimes make code faster - but the downside is that it makes the code bigger (which is obvious even in those examples above).
In Android Kernel 2.6.33.1 case - loop unrolling increases zImage size by ~350K. If I didn't strip debugging stuff out, zImage would be too big to fit on Nexus One.
Fortunately, there was approx. 400K to be saved by just kicking out features that enable kernel debugging. I don't think most of the people need that. These features are useful for kernel and driver developers, but most of others can perfectly live without them
Click to expand...
Click to collapse
on point. i like what i see. i will try this out.

If I use the powersave governor option, SetCPU always show it running at minimum 245MHz. Is it working as expected?

bethedealer said:
If I use the powersave governor option, SetCPU always show it running at minimum 245MHz. Is it working as expected?
Click to expand...
Click to collapse
That's fine since the powersave governor clocks it to the lowest for maximum power savings.

standby 245/245 governor is better than on demand?

xPatriicK said:
standby 245/245 governor is better than on demand?
Click to expand...
Click to collapse
Curious about this too!

xPatriicK said:
standby 245/245 governor is better than on demand?
Click to expand...
Click to collapse
It's not necessarily better. It depends on what you're optimizing for. For example, powersave governor optimizes for power savings in return for slowest clock speed which may be apparent when using CPU intensive apps. Ondemand tries to balance it somewhat while giving more importance to CPU speed since it clocks the CPU back to full speed whenever an app runs and downclocking when appropriate. The conservative governor I use in my kernel also tries to balance this but gives more importance to power savings since when an app runs it slowly ramps up the clock speed until the app finishes. Hope this clears it up!

Note that powersave might actually consume more power at the end if you do some intensive work.
Why? Because it will force CPU to stay at the lower clock, even if the task could be completet much quicker with the higher clock.
At the end - it could very well be that running the task quicker @higher clock speed could consume less power total!
Unfortunately, there is no easy way to test what is better, unless someone writes a script that performs some tasks repeatedly until battery dies, and compares the baterry life between different CPU scaling strategies.
I'd definitely not use powersave governor. Rather, I'd play with the "up threshold" and "profiles" in SetCPU to make the CPU frequency scaling more conservative.

[KERNEL][CM9][1/29/12] Icy Glitch V14 - BETA - LiveOC - Voodoo - DIDLE - USBhost

These kernels are provided as-is without warranty. I'm not responsible for any problem you can encounter with your phone or if your cat suddenly dies.
Although, don't expect support even if I will eventually help since I love cats.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Note : These kernels are only compatible with CyanogenMod 9 based roms.
Use them on any other rom at your own risks.
Overview :
- 3.1.9 linux base
- LiveOC
- Custom Voltage
- Battery Life eXtender
- DIDLE v2
- Voodoo Sound 10
- PMFAST mode for best wifi performance
- USB host mode support
- Various tweaks for more speed and battery saving
CHANGELOGS IN #2 POST
By default, no overclock/undervolt is applied.
You'll need NSTools to use/enable all the features of this kernel. (Available for free on the Android market)

Downloads
Glitch kernel (CWM flashable only)
Glitch Kernel Updater app now available on the Android market to support us !Fascinate
- 03/24/2012 - V14 B6
Other supported devices : Captivate, Vibrant, Telus Fascinate, Verizon Fascinate
OLDER RELEASESLIVE OC GUIDEFAQ, Changelogshttp://forum.xda-developers.com/showpost.php?p=21703700&postcount=2http://forum.xda-developers.com/showpost.php?p=21703700&postcount=2
Do you want to discuss on this kernel, get the fresh news on development, or become a kernel tester ?
Join the IRC channel from your web browser herehttp://webchat.freenode.net/?channels=glitchkernel ! No registration needed
Make sure the channel is "#glitchkernel" and you're set.
For those who already have an IRC client,
here is the server : irc.freenode.net
port : 6667
Channel : #glitchkernel
-------------------------
Source :
- Glitch repo : https://github.com/organizations/Glitchkernel
Who is the Glitch team ?
- Kernel developement : ssewk2x & Tk-Glitch.
- Public relations / web hosting : Sixstringsg.
- Recovery: Stephen.k.spear, Smasher816, sixstringsg
- App developement : Smasher816.
- Extreme overclocking testing : Shaolin95
- Beta testers team, with members coming and leaving
Credits :
Pawitp, jt1134, Morfic, Ezekeel, Zacharias.maladroit, Supercurio, lippol94, sztupy, Eugene373, Franciscofranco
Thanks to the donators and everyone bying the Glitch Kernel Updater app from the market, it's much appreciated and encourages us to continue our work !
Thanks to the beta testers team and to everyone helping me to debug and find new useful things to integrate !
Without all of you, this kernel wouldn't be !

Changelogs :
V14
24/03/2012 - BETA 6 :
- Upstream sync (modemctl, compass fix..)
- Fixed BLN, and added blink support
- Disabled Samsung sleep patches from Teamhacksung to prevent SODs
- Fascinate : Ported ssewk2x phantom keypress filter code from Glitch V13.1
- Vibrant : Merged GPS changes from FaultException
- Moved back to Deadline ioshed as default to fix nandroid
- Added Derteufel's selective LiveOC mod - It will prevent low frequency steps to OC, potentially providing enhanced stability and powersaving
- Fixed potential bug in vfat fs driver
- Fixed bug in ext4 fs driver
- Merged some audio changes from Teamhacksung
- Added touch support in Glitch recovery (incomplete)
- Some cleaning
22/02/2012 - BETA 5 :
- Voice audio through dock, thanks to xcaliburinhand (should fix related issues with Glitch volume boost hack)
- Renamed SmartassV2 governor to "GlitchassV2" to prevent latest NSTools version hanging
- Added FranciscoFranco Conservative governor tweaks for more speed
- Added a DIDLE enabler into screensate scaling script to kill BT in sleep and make DIDLE work with both TOP=ON and TOP=OFF. You'll need to enable screenstate scaling in Glitch menu from recovery in order to get DIDLE to use this (disabled by default). It's mostly for testing purposes - Feel free to report your experience with it.
- Moved back to previous sysinit to prevent the DIDLE enabler script to make the phone hanging on the bootlogo. Also fixes screenstate scaling making the phone unbootable, and some SOD/COD issues for guys using some other tweaking scripts
- Implemented BLN9 port from Derteufel with NSTools compatible sysfs. This way all the unsupported roms will get led notifications, and CMLed haters will hopefully stop to yell..
- The flash-time script has been updated to be able to clean more stuff
- A few fixes on the wifi driver to work better with our devices Please report your experience with DIDLE enabled. It may be required to disable DIDLE on some phones to prevent SOD/COD/softreboots or other instabilities. Also MAKE SURE YOU HAVE A DAMN GB BOOTLOADER !
- Reverted modemctl changes from Teamhacksung - should fix data issues some are having
21/02/2012 - BETA 4.1 :
- Reverted sleep GPIO stuff from THS stock samsung port. Should fix SODs some are encountering.
21/02/2012 - BETA 4 :
- Fixes on LiveOC and custom voltage from Ezekeel
- Fixes + various enhancements on I/O scheduling (up to 50% I/O speed improvement compared to beta 3)
- Fixed touchscreen freezing randomly
- Fixed various bugs here and there
- Back from Eugene's DIDLE to Ezekeel's DIDLE v2 mod (available through NSTools again) -> You may encounter SoD if enabled with wifi ON.
- Load balancing improvements
- Updated FIOPS I/O sched
- Sync with THS latest source
09/02/2012 - BETA 3 :
- LiveOC frequency steps changed again - Now all steps are using a 200MHz bus by default, so pushing liveOC % will give the same bus speed on all steps
- Default Int voltage for 1GHz set to Samsung's default to fix instability on bad overclocker devices
- Fixed recovery not displaying long lists items as well as cosmetic fixes - updated to latest source from Koush
- Fixed init.d support
- Switched to Tiny SHMEM, better on small devices
- Ext4 optimizations for more speed
- Readahead values tweaked a bit - should be better overall
- Fascinate : Use GB driver for i500 to fix prox/light sensors, and updated RIL init (Thanks to Sbrissen)
- Fsync() enabled again to prevent/limit data loss while experimenting with overclocking, and to (probably) fix the reboot->bootloop issue
- Disabled frame pointer, FIQ debugger, and some more debug stuff, Morfic-like
- Some writeback quickfixes
- Updated wifi drivers with added net fixes and optimizations
- GlitchOndemand polling tweaking for more stability
- Misc tweaks
29/01/2012 - BETA 2 :
- Updated to linux 3.1.10
- A few fixes on LiveOC (Thanks Ezekeel)
- GPU load affecting CPU frequency scaling (200 vs 100MHz) is back
- Removed CFQ and BFQ, and added SIO & the all new flash oriented FIOPS i/o schedulers - FIOPS is now default
- Better VM tweaks
- Fixed GlitchOndemand polling to fix stability issues some are encountering
- i/o-less dirty throttling backport from linux 3.2 (thanks to Franciscofranco)
- Added dynamic writeback & various writeback fixes
- Proportional rate reduction for TCP (thanks Google )
- Small fix on Lazy gov from Ezekeel
- Captivate : Port battery charging/fuel gauge code from stock --> Improves (but does not completely fix) phone turning off while
charging for some users (charging death). (Thanks to Pawitp)
- Vibrant : Headset buttons fix (Thanks to FaultException)
- Fixed and now built-in CIFS
- Changed OC steps (1152 step is now 1160, with 200MHz bus, 1440MHz step removed, added 1400 and 1500 MHz steps)
- Moved back to "old" DIDLE implementation for now
- Glitch call volume hack is back
- Various optimization and CPU load reduction in some typical cases
- Verizon Fascinate : fix for boot issue on preview 5 and BETA 1
- Updated USB host driver to build 5
23/01/2012 - BETA 1 :
- Dock audio support.
- Added gamma V1 hack and MDNIE bypass mode.
- Added more governors to play with & tweaked interactive and ondemand.
- DIDLE V2 added back for people who want to mod their framework (It may/will cause sleep of death on some devices, as always)
- Battery charging calculation fix (BLX will now show 100% as default).
- Changed overclocked steps for more stability and easier setup.
- Dm-cache support.
- Updated linux base to 3.1.9.
- Improved memory management and cache handling.
- General speed enhancements.
- Fsync disabled.
- Added an entry in the GLITCH menu (in recovery) to choose between mtp and mass storage USB mode.
- USB host mode (OTG) - updated to build 4, from sztupy - thanks to him and everyone involved in this !
- Bootmode injection fix from pawitp.
- Optimized RWSEM algorithm.
- VM and I/O performance enhancements.
- Added BFQ i/o scheduler.
- More cleaning, various optimizations and power management tweaks.
PREVIEW #5 : (For build 13+)
- Even better 720p video recording.
- Fixed Vibrant GPS.
- Added back various governors.
- New colors from Samsung stock.
- Toolchain sorcery with linaro 4.4.5, and using NEON and hardfloat optimizations.
- Bootmode injection support.
- Various speed enhancements.
PREVIEW #4 :
- Fixed softkeys on Captivate and Fascinate.
- Refresh rate back to 60Hz as the uncap breaks colors (it'll help to get better smoothness on heavy games too).
- Better 720p video recording.
- Tweaked governors and schedulers for testing.
- Big cleanup.
- Removed DIDLE for now - useless anyway, the rom prevents it to work correctly.
PREVIEW #3 :
- Added color adjustments to Nexus S framebuffer.
- Dock audio stuff back in.
- Cleanup.
PREVIEW #2 :
- Fixed GPS issues.
- Moved to Nexus S Framebuffer (stock colors, no more color adjustment available).
25/12/2011 - V14 Preview #1
- Compatible with Teamhacksung's ICS/CM9 builds 10 or higher.
- Now using linux 3.0.8 base from the Nexus S drop
- Upstream synced to the latest from THS (TVout, cleanup, 3.0 port..)
- Reverted to stock CM LED Notifications (fixing all the previous problems some users encountered with BLN) / No more BLN app needed, enabled by default.
- Removed Voodoo Color, and back to stock implementation.
- Added support for a new low power mode on wifi chipset, enhancing signal reception and stability, at the cost of a bit higher power consumption.
- Back to NEON mfpu for now
- Full support for init.d scripts
- Readahead value back to 1024 for better results (SDcard read Cache)
- Fixed headset buttons
- Fixed randomly freezing softkeys
- Big cleanup and rewrite of some stuff
- Removed the 200MHz lock when the GPU is active for battery life. Depending on your launcher and/or widgets, you'll get some slowdowns. Change min freq to 200 to fix it.
Major additions, ported from Ezekeel's work on the Nexus S (thanks Morfic !) :
You will need NSTools app, available for free on the market, or here : http://forum.xda-developers.com/showthread.php?t=1333696
- Added "LiveOC" system, giving access to GPU/bus overclocking on the fly, per 1% step.
- Added "Custom Voltage" control, giving access to ARM and Internal voltage undervoling and overvolting. (This makes the previous leakage system obsolete, which is now removed.)
- Added "Battery life eXtender" mod, allowing the user to limit the maximum charge percentage to preserve the battery life (not the battery runtime obviously)
- Added support for DIDLE V2, a very low power mode that will help battery life in many idle/semi-idle cases.
- Lazy governor sysfs, to enable or disable the frequency ramping up when screen is off (to end tasks quicker to sleep faster).
Keep in mind CM9 is at early stages of development and contains many bugs still.

****FAQ****

I don't really understand the LiveOC system. Does using voltage control to set the different stops still work?
I like just setting min = 200 and max = 1300 and letting everything else stay the same.

djk21108 said:
I don't really understand the LiveOC system. Does using voltage control to set the different stops still work?
I like just setting min = 200 and max = 1300 and letting everything else stay the same.
Click to expand...
Click to collapse
Half a scroll up is the guide man.
~~~~There is no spoon~~~~

So this work with build 6 or 6.1?
Sent from my SCH-I500 using XDA App

shag_on_e said:
Half a scroll up is the guide man.
~~~~There is no spoon~~~~
Click to expand...
Click to collapse
Yes yes, I looked over the guide. I just don't feel the need to go through all that customization. My question is, if "Voltage Control" still works the same way it always has?

godofwar762 said:
So this work with build 6 or 6.1?
Sent from my SCH-I500 using XDA App
Click to expand...
Click to collapse
After wiping cache and dalvik on THS build 6 and installing Icy B3, I no longer have 3G data.

godofwar762 said:
So this work with build 6 or 6.1?
Sent from my SCH-I500 using XDA App
Click to expand...
Click to collapse
6.1. A 6.0 version will probably be released soon due to popular control.
djk21108 said:
Yes yes, I looked over the guide. I just don't feel the need to go through all that customization. My question is, if "Voltage Control" still works the same way it always has?
Click to expand...
Click to collapse
Personally, I have found bus overclocking to be so much more beneficial in ICS than CPU overclocking on it's own. If you still use Voltage Control, it will work, but won't provide near the impact that NStools does. Otherwise we wouldn't have implemented LiveOC. You don't have to tweak voltages for a small LiveOC.

I'm posting again instead of editing so everyone will see. The OP has been updated with kernels available for both THS 6.0 and 6.1. Other than that, they are identical.

So, am I to assume that 6.1 issues have been squashed?

Azuma73 said:
So, am I to assume that 6.1 issues have been squashed?
Click to expand...
Click to collapse
ANy 6.1 issues that there are are ROM-side, which is why we made a 6.0 version as well. A lot of people even on stock kernel are having problems with 6.1.

Is this only for THS CM9 roms. Or does this work on the ports from the nexus s? Like AOKP?

tonu42 said:
Is this only for THS CM9 roms. Or does this work on the ports from the nexus s? Like AOKP?
Click to expand...
Click to collapse
The version for build 6.0 should work on AOKP.

Everything working on AOKP here, thnx Tk.
Sent from my Hot Cream Sandwich

Eris _2.1_2010 said:
Everything working on AOKP here, thnx Tk.
Same here
Sent from my Hot Cream Sandwich
Click to expand...
Click to collapse
Sent from my SCH-I500 using XDA App

Thank I glitch everything is perfect
Sent from my SCH-I500 using XDA App

Glitch 14 Beta 3 is causing bootloops for me. One question, say I liveOC to 120%, does that mean my bus speed is being increased by 120% as well?

I dunno what smoothass governor does but holy **** my phone has never been snappier. Great job guys.
Sent in an Ice Cream Sandwich from my SCH-I500.

Thanks as always guys. Running V14 B3 on AOKP with build.prop 6 from THS. SO AMAZING.
Sent from my SCH-I500 using XDA App

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

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:
Check the requirements above!
Flash the zip using custom recovery (no need to wipe anything)
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://forum.xda-developers.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
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
(http://www.gnu.org/copyleft/gpl.html)

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

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.

Thanks for another addition to the nexus 7 kernel community, love having different kernels to try.

Clienterror said:
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.
Click to expand...
Click to collapse
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.

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

I had the same issue. Couldn't pass the boot screen after flashing. On 4.1.1 latest update as of July 15th

Sobai said:
I had the same issue. Couldn't pass the boot screen after flashing. On 4.1.1 latest update as of July 15th
Click to expand...
Click to collapse
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!

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.

New version released
New version released...see OP. GPU OC to 446MHz (up from stock 416)
Looking for more feedback

_motley said:
New version released...see OP. GPU OC to 446MHz (up from stock 416)
Looking for more feedback
View attachment 1204164
Click to expand...
Click to collapse
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)

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

danielsf said:
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)
Click to expand...
Click to collapse
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.
Clienterror said:
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.
Click to expand...
Click to collapse
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.

_motley said:
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.
Click to expand...
Click to collapse
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

Clienterror said:
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
Click to expand...
Click to collapse
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)

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?

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.

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

Good work there, I would suggest adding Smartassv2 as well since it has been a good choice for many dev

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+([email protected]) (gcc version 4.6.3 (GCC)) #6 SMP
PREEMPT Tue Jul 17 00:52:59 EDT 2012

[KERNEL][RAY][JB 4.1 & 4.2] LuPuS-JBv9 [LINARO 4.7.3][UPDATED 08-06-13]

LuPuS JellyBean Kernel
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
This kernel can be used on any JB CM BASED JB 4.1 or 4.2
Disclaimer
Code:
[COLOR="DarkOrchid"]#include[/COLOR] [COLOR="Magenta"][/COLOR]
[COLOR="Blue"]/*
* Your warranty is now void.. LOL I guess you knew it already.
*
* I am not responsible for bricked devices, dead SD cards,
* thermonuclear war, you getting dumped or you getting fired because your phone
* bootloops and alarm does not go off. Please do some research if you have any
* concerns about features included in my kernel before using it! YOU and only
* YOU are choosing to make these modifications.
*/
[COLOR="Magenta"]#ifdef[/COLOR]
You have a [COLOR="DarkGreen"]question[/COLOR] post it in the [COLOR="DarkRed"]thread[/COLOR],
Instead of [COLOR="DarkGreen"]Pm'ing me[/COLOR], as other users may
experience you [COLOR="DarkRed"]problems[/COLOR]
[COLOR="Magenta"]#endif[/COLOR][/COLOR]
What Works --
Wifi - (flash modules)
Bluetooth
Everything Else that works on FXP and any other JB kernel
What doesn't work --
Anything that doesn't work on FXP and any other JB kernel
Added Io-schedulers --
- Noop
- Anticipatory
- Deadline
- CFQ
- BFQ
- SIO
- ZEN
Added Governors --
- lagfree
- brazillianwax
- smoothass
- scary
- savagedzen
- smartass
- smartassv2
- smartassH3
- interactivex
- minmax
- + the 5or6 that are there with FXP
Lulzactive - Thanks to Tegrak
Based on Interactive and Smartass. When workload is greater than or equal to 60%, the governor scales up
CPU to next higher step. When workload is less than 60%, governor scales down CPU to next lower step.
When screen is off, frequency is locked to global scaling minimum frequency
Virtuous
Virtuous is a modded smartassV2 which gives even more battery time then smartassV2
Intellidemand - Thanks to faux123
This is an intelligent ondemand that enters browsing mode to limit max frequency when GPU is idling,
and (exits browsing mode) behaves like ondemand when GPU is busy; to deliver performance for gaming and such.
Intellidemand does not jump to highest frequency when screen is off.
Lazy - Thanks to Ezekeel
The Idea here is to eliminate any instabilities caused by fast frequency switching by ondemand.
Lazy governor polls more often than ondemand, but changes frequency only after completing min_time_state
on a step overriding sampling interval.
Lazy also has a screenoff_maxfreq parameter which when enabled will cause the governor to always
select the maximum frequency while the screen is off.
-Ondemandx:
Basically an ondemand with suspend/wake profiles. This governor is supposed to be a battery friendly ondemand. When screen is off, max frequency is capped at 500 mhz. Even though ondemand is the default governor in many kernel and is considered safe/stable, the support for ondemand/ondemandX depends on CPU capability to do fast frequency switching which are very low latency frequency transitions. I have read somewhere that the performance of ondemand/ondemandx were significantly varying for different i/o schedulers. This is not true for most of the other governors. I personally feel ondemand/ondemandx goes best with SIO I/O scheduler.
-Lionheart:
Is a conservative-based governor. The tunables (such as the thresholds and sampling rate) were changed so the governor behaves more like the performance one, at the cost of battery as the scaling is very aggressive.
To 'experience' Lionheart using conservative, try these tweaks:
sampling_rate:10000 or 20000 or 50000, whichever you feel is safer. (transition latency of the CPU is something below 10ms/10,000uS hence using 10,000 might not be safe).
up_threshold:60
down_threshold:30
freq_step:5
Lionheart goes well with deadline i/o scheduler. When it comes to smoothness (not considering battery drain), a tuned conservative delivers more as compared to a tuned ondemand.
BadAss Governor:
Badass removes all of this "fast peaking" to the max frequency. Badass will also take the gpu load into consideration. If the gpu is moderately busy it will bypass the above check and clock the cpu with 1024Mhz. If the gpu is crushed under load, badass will lift the restrictions to the cpu.
Superbad -
A "superbad" super smooth rendition of a highly optimized "smartass" governor!
Darkside -
A "slightly more agressive smart" optimized governor!
Intellidemand2 - Thanks to faux123 and CosmicDan for mods
Uses d_bus ramping, quick and smooth and performance based, do not complain about battery drain on this
governor but it will make everything feel more like project butter
What else-----
-SLQB - (SLAB allocator with Queue)
This memory allocator is designed for small number of CPUs system (such as desktop or smart phone devices). This allocator is design to be simple and it is optimized for using order-0 pages as much as possible (order-0 pages are the simplest therefore quickest type of memory in a Linux system to allocate).
- Alot of changes to code to try improve smoothness ect
- Wifi signal lock on should now be quicker / stronger then before
--When LEDS change green, pink then blue press volume down to enter CWM Recovery
I would like to say a big thanks to -
slz.kiev - for amazing PACman ROM & Testing
FXP - Sources
Cyanogenmod - Souces
DooMLoRD - Everything he's done for XPeria
wechy77 - For helping me test
tempest918 - For the New Logo
xeozus
NobodyAtAll
Faux123
Erasmus
Leedroid
Phil3759
CTCaer
Anyone missing please PM me
Github Sources -b jellybean
https://github.com/garwedgess/semc-kernel-msm7x30
CWM source -- https://github.com/garwedgess/android_bootable_recovery -b lupus-cwm

LuPuS MENU
You can run lupus menu from terminal or scriptmanager or similar, you must run as root or script will exit with a message
in terminal
Code:
su
lupus
* information is in lupus menu
1/ CIFS Menu *
Enable
Disable
2/ zRam Menu *
Enable
Disable
Set zRam size ( default is 60)
3/ Frandom Menu *
Enable
Disable
4/ USB OTG *
Enable
Disable
5/ Clean and Remove tweaks
Remove init.d's
6/ Tweak Menu
Note all tweaks are preset from here and option to set as init.d's
Clean all temp files
SQLITE optimizations
LMK Optimizations
Network optimizations
Defend against ARP spoofing
Remove android logger
SDcard speed tweak
Flag blocks as non-rotational
7/ Performance Menu
Note all options are se by user input from here and option to set as init.d's
Set CPU frequencies
Set Governor
Set IO-Scheduler
Voltage Control
VM tweaks (explained below)
VM Tweaks
dirty ratio and dirty background ratio 1 & 2
This controls how often the kernel writes data to "disk" (in our case the internal microSD system card, not the removable microSD card). When your apps write data to disk, Linux actually doesn't write the data out to the disk right away, it actually writes the stuff to system memory and the kernel handles when and how the data is actually going to be flushed to the disk. These values represent a percentage, the higher the percentage, the longer it waits to flush, the lower the percentage, the more often flushes will occur. Now remember, we are dealing with solid state storage, not the traditional disk platter and spindle. So we are actually able to delay flushes a little longer with solid state versus a traditional hard drive disk.
dirty_expire_centisecs
How old "dirty" data should be before the kernel considers it old enough to be written to disk. It is expressed in 100ths of a second.
dirty_writeback_centisecs
This is the interval of when the writeback daemons periodically wake up and write "old" data out to disk. It is expressed in 100ths of a second.
min free kbytes
This is used to force the Linux VM to keep a minimum number of kilobytes free. The VM uses this number to compute a pages_min value for each lowmem zone in the system. Each lowmem zone gets a number of reserved free pages based proportionally on its size. Default is 2048kb.
overcommit_memory
This controls overcommit of system memory, possibly allowing processes to allocate (but not use) more memory than is actually available.
0 - Heuristic overcommit handling. Obvious overcommits of address space are refused. Used for a typical system. It ensures a seriously wild allocation fails while allowing overcommit to reduce swap usage. root is allowed to allocate slighly more memory in this mode. This is the default.
1 - Always overcommit. Appropriate for some scientific applications.
2 - Don't overcommit. The total address space commit for the system is not permitted to exceed swap plus a configurable percentage (default is 50) of physical RAM. Depending on the percentage you use, in most situations this means a process will not be killed while attempting to use already-allocated memory but will receive errors on memory allocation as appropriate.
Swappiness
A property for the Linux kernel that changes the balance between swapping out runtime memory, as opposed to dropping pages from the system page cache. Swappiness can be set to values between 0 and 100 inclusive. A low value means the kernel will try to avoid swapping as much as possible where a higher value instead will make the kernel aggressively try to use swap space.
VFS Cache Pressure
File system cache (dentry/inode) is really more important than the block cache above in dirty ratio and dirty background ratio, so we really want the kernel to use up much more of the RAM for file system cache, this will increas the performance of the system without sacrificing performance at the application level. The default value is 100, as a percentage, and what you want to do is lower the value to tell the kernel to favor the file system cache and not drop them aggressively.
If you like my work please consider buying me a beer or something else
by clicking the DONATE ME button, of course it isn't needed but greatly appreciated and keeps me motivated.

Changelog ...............
Code:
[hide]
[B][v1] [/B]
- Initial release
- 25 Governors
- 6 Io-Schedulers
- SLQB memory allocator
- Built with linaro 4.6 toolchains
- Swap
- Zram enabled
- Custom voltage control supported
- Supports USB OTG
- Supports ext2, 3 & 4
[B][U]v2[/U][/B]
- Couple of extra tweaks - improvements to battery
- Fixed Wifi issues
- Reverted my disabling of disabling sched_feautures if you get that :P
- Added USB OTG modules needed for USB OTG ( find attached zip at the end of the post)
- Added stable freq-table for higher OCing upto 2ghz
[B][U]v3[/U][/B]
- Completely scrapped previous sources and started fresh
- CWM fixed thanks @ Scritch007
- Built with Linaro 4.7
- Optimized for Linaro
- Thumbee
- Reverted to 1.6 max OC
- Lzo patched
- Use Google Snappy Compression / Decompression
- Added TINY RCU
- Fixed Battery drain ( Tester lost 0.2% overnigh with wifi on ) :victory:
- Uses uncompressed Image {why .img size is bigger)
- Custom improvements for overall smoother performance
[B][U]v4[/U][/B]
- built with latest linaro 4.7.3 (02-01-2013) - Thanks @ ChainFirex
- Added memcopy
- Added compaction
- Lowered vfs_cache_pressure
- LMK (lowmemorykiller) optimizations
- Improved CIFS support
- Enabled USB tether
- Disabled gentle_fair_sleepers
- Updated video drivers
- Clean up on wifi config
- Back-ported binder changes
- TWRP recovery - thanks @ championswimmer & TWRP team
[B][U]v5[/U][/B]
- Built with Linaro 4.7.3 (02-01-2013)
- Free'd RAM (disabled 720p) now 381mb - Thanks at Paul678
- Makefile optimisations (snapdragon & neon) - Thanks at Paul678
- Tweaked permormance on interactive governor - Thanks at Paul678
- Tweaked SIO io sched - Thanks at Paul678
- Free'd some RAM from loggers
- Reduce swappiness
- Fix PageHead
- Fix binder. use of uninitialized variable.
- Fix kernel/net Memory Leaks
- Eliminate kstrdup memory leak
- ipv4: force_igmp_version ignored when a IGMPv3 query received
- Fix Entropy Depleting (no more depleting) - Thanks @ Kees Cook
- enable ipsec tunnel support in kernel (Latest FXP Change)
- ARM7 optimsations + more in config
- TWRP v2.4 - Thanks @ Championswimmer, TWRP Team
- Thanks [user=4402161]@Wechy77[/user] for LuPuS TWRP theme
[B]v6[/B]
- Supports both 4.1 & 4.2 JB
- New IIO Scheduler ZEN thanks [user=2632235]@bbedward[/user]
- New Governor smartassH3 thanks [user=3057569]@Hero[/user]
- Tweaked Deadline IO scheduler
- Tweaked smartassv2
- Frandom
- SFB Net scheduler
- OC up to 1804.8MHz
- Logger backported from CAF
- Free RAM from logger
- LMK updated and optimized + various LMK tweaks
- Various ARM & RAM changes
- TinyRCU optimizations
- Optimized crc32 lib
- various VM changes
- Improved cleancache
- Undervolt LCD display, touch sensor proximity sensor & Wi-Fi thanks @ M66B
- Entropy tweaks
- Try fix for CRT animation [user=4266283]@paul678[/user]
- TWRP & CWM
- LuPuS Menu
- Auto Loading wifi
- All modules and init.d's included No need to flash anything after kernel
Plus alot more changes see [URL="https://github.com/garwedgess/semc-kernel-msm7x30/commits/jellybean"] for full list of credits and patches used[/URL]
[B]v6[/B]
- Latest changes to ALS and Button Backlight -- Thanks @ FXP
- Lowered OC to 1612.8Mhz
- Remove ALS and Button Backlight option from LuPuS Menu (no longer needed)
- Random reboots should be fixed ( for those who where having such issues )
[B]v7[/B]
- Fixed 3D from hanging under high intensity
- Fix pmem for HDPI Mike NG] (no more reboots??)
- CWM Recovery = VOLUME DOWN
- TWRP Recovery = VOLUME UP
- Clean up on LuPuS Menu
- Better wifi check
- KEY RESET ( Menu and POWER)
- Tuned Smartassv3 and SmartassH3 [user=2799345]@M66B[/user]
[B]v8[/B]
- Fixed reboot to recovery on 4.2 (not sure if i broke it on 4.1)
---- Custom CWM
- Clean-up of menu
- Added own wipe options menu -- with extra options
- Aroma File Manager from CWM --- Must have aroma ([COLOR=Red]aromafm.zip) placed on root of sdcard[/COLOR])
- Multi zip installer
- Reboot options - Power off re-added under this menu
- Pointless but people keep asking me for it so re-added wipe battery stats also.
- LuPuS themed...
- Fixed "dancing android"
[/hide]
[B]v9[/B]
- Added option to enable Quick Key Reset (enable / disable via LuPuS Menu)
- Tuned Governors
* superbad
* lionheart
* virtuous
* darkside
* conservative
* smartassH3
- Really use google snappy zRam (improves zRam)
- Added zCache
- Removed persistent RAM
- Removed some more kernel debugging
- uninterruptible sleep
- Update SIO & CFQ
- Added Ultra-KSM
- Removed optimized AES & SHA1 routines
- Updated TWRP to 2.4.4
*Fixed Mount USB Storage in TWRP
- Updated CWM to latest Official CWM source
*Removed reboot options
*Re-added power off and reboot system now to main menu
- Improved wifi-loading scripts
- Clean up of lupus menu
- Fixed root issue on some devices
- Reworked kernel logs (can be found in /data/local/tmp)
- Boot.d - If phone is taking a long time to start move suspicious init.d scripts to /system/etc/boot.d
They will be run in background and won't affect boot time.
LuPuS-Jellybean-DOWNLOADS
If you like my work please consider buying me a beer or something else
by clicking the DONATE ME button, of course it isn't needed but greatly appreciated and keeps me motivated.
480p
LuPuS_urushi_jBv9-ram.img
md5 = 3ff24d7e343beb483aa81d7bcfa1b5f5
[/LIST]
720p
LuPuS_urushi_jBv9.1-full.img
md5 = 1effb6e2ba80afbb55d1bd9d30a426fd
[/LIST]
Mirrors -- all LuPuS Kernels can be found here
www.goo.im/devs/wedgess
Wifi is built in to kernels ramdisk NO MODULES NEEDED
If your MD5 doesn't match re-download

Everithing works fine so far. See benchmark scores.
Sent from my Xperia Ray using xda premium

Wow...nice one! Really responsive! Just wanted to point out that in addition to all the features listed in the OP, that you can undervolt
with this kernel....didn't see it as a feature in the OP...
Thanks!

justmpm said:
Wow...nice one! Really responsive! Just wanted to point out that in addition to all the features listed in the OP, that you can undervolt
with this kernel....didn't see it as a feature in the OP...
Thanks!
Click to expand...
Click to collapse
Lol ye i forgot to add it in to op thanks for reminding me.
Edit- Put of couple of more things into 3rd post, anymore I can remeber will be added
Sent from my GT-I9300 On Official JB

wedgess said:
Lol ye i forgot to add it in to op thanks for reminding me.
Edit- Put of couple of more things into 3rd post, anymore I can remeber will be added
Sent from my GT-I9300 On Official JB
Click to expand...
Click to collapse
very smooth, but has a problem the wifi seems works not stablely, sometimes cause reboot and sometimes cannot been disconnected.

feelow said:
very smooth, but has a problem the wifi seems works not stablely, sometimes cause reboot and sometimes cannot been disconnected.
Click to expand...
Click to collapse
Did you reboot? I have no problem with wifi. Only at first boot I had this problems.
Sent from my Xperia Ray using xda premium

testing...
(thx for your effort sofar :good
1st impression: lower scores on Antatu than with standard PAC-kernel.
i'd like to have a better battery life, so now testing "virtuous/sio, 806/134".
or are there better suggestions?
(like to keep a snappy Ray )

"Custom voltage control supported" not working. The PAC romcontrol says: not supported by your kernel

Wechy77 said:
"Custom voltage control supported" not working. The PAC romcontrol says: not supported by your kernel
Click to expand...
Click to collapse
I don't think that part of RC has been activated....it also doesn't work with the kernel from champilnswimmsr's aokp build. I am using incredicontrol from the play store...but a lot of other apps will let you change the volts.

justmpm said:
I don't think that part of RC has been activated....it also doesn't work with the kernel from champilnswimmsr's aokp build. I am using incredicontrol from the play store...but a lot of other apps will let you change the volts.
Click to expand...
Click to collapse
is there a list of recommended (or safe) voltage settings for the Ray?

Yes i know in rom control it still says not supported not sure why but u can always use SetXperia app from playstore to change it
And poster who asked about safe settings. Try down step -25mv at a time and see what is stable for you. If u get reboots then its obviously not stable.
Or else safest way if your wortied then dont undervolt at all. What maybe stable for someone might not be stable for you
Sent from my GT-I9300 On Official JB

I tryed thi kernel for my CM10 rom. And it seems buggy. Antutu points is lower than on stock kernel, and the perfomance is bad too, including games and UI.

_TREM_ said:
I tryed thi kernel for my CM10 rom. And it seems buggy. Antutu points is lower than on stock kernel, and the perfomance is bad too, including games and UI.
Click to expand...
Click to collapse
lol ok first off this is not stock kernel so you can't compare it to STOCK,Ssecondly i'm not sure what governors, io scheds and frequencies you are using. People who have tested have reported it being smooth and performance being greater not worse. Also I obviously use my own kernels on my own device and my experience is the complete opposite of yours. You sure it not 'your' CM10 rom. Buggy!! how? please do elaborate.
Anyone else confirm what the above pster has said ??

Using it now for some hours with Virtous and SIO and looks very promising. Speed of ROM is for me the same and I dont play games. But Battery seems to be great! I left the screen off a lot and have like 95% deep sleep, so pretty well battery ;D I use FXP142.
EDIT: just tested the game "granny smith'. Runs good! But I didnt test with another kernel.

[GER]Roxxor said:
Using it now for some hours with Virtous and SIO and looks very promising. Speed of ROM is for me the same and I dont play games. But Battery seems to be great! I left the screen off a lot and have like 95% deep sleep, so pretty well battery ;D I use FXP142.
EDIT: just tested the game "granny smith'. Runs good! But I didnt test with another kernel.
Click to expand...
Click to collapse
Ye virtuous is supposed to be more battery friendly then smartassv2
Intellidemand2 would be best performanced based but not the best on battery.
Sent from my GT-I9300 On Official JB

Thanks for the great kernel, really liking the Superbad governor.

I left my ray on during the night, to see what the battery would do...
(i mean screen off, but wifi+3g on)
from 100 to 74% in 9 hours.
8:40 deep sleep (94%)
806/134 virtuous/sio
I cannot compare btw, usually i charge at nighttime, but usage seems quite high?
was hoping for about 90% battery left or something, but like i said, not tested with other kernels.

I think I caught a "wifi" bug. Yesterday the wifi cut out and wouldn't turn back on...after rebooting everything was fine for a few hours and then wifi stopped working. I am not sure if it is really wifi or something else, because if I go into settings I see that wifi is on, I can turn it off but it won't turn back on...if I leave settings and pull down the status bar it show wifi as "on"...when I go back into settings it shows wifi as "on"...and no networks are shown that can be connected. You can do this over and over and every time you reenter settings it says wifi is on. I think it also causes a wakelock from wifestatemanager.
I went into recovery and formatted system and reinstalled PACman v15...a few hours later the problem returned. I flashed in a different kernel and it seemed OK....now I have your kernel on ChampionSwimmer's AOKP ROM and I am waiting to see if the bug returns.
I am not sure if there is something specific I do that activates the bug, so I don't have a logcat of it happening. I attached a logcat of me trying to turn on and off wifi in settings. I also attached the battery stats report from Better Battery Stats in case the wakelock is informative....

[Kernel][5.1] M-Kernel - a76/77 [WiFi/3G] [f2fs/ext4] [5/14/15]

Page 1: Information
Page 2: Changelog and Downloads
Page 3: Additional info and FAQ
Instructions:
Make sure you are on the latest bootloader version before flashing this or any other custom kernel. Search for a flashable zip or use fastboot and the google factory images.
Download Kernel to internal SD card. Flash in recovery. Reboot. Congratulate yourself for wisely installing the best nexus 7 kernel.
A complete list of changes is available at my Github.
Source: https://github.com/Metallice/android_kernel_grouper
Recommended Settings:
The only app supported for changing any kernel parameters and settings is TricksterMod - https://play.google.com/store/apps/details?id=com.bigeyes0x0.trickstermod
CPU governor - TouchDemand with default parameters (default)
I/O Scheduler -
- ROW for pure read speed. Fast reads which are often the most important on mobile. Similar concerns like deadline.
- BFQ for more consistent performance. Slower than Deadline and ROW, but prevents stutters while downloading in background
Max Frequency - 1.2Ghz (Stock max for 2+ cores) (for lollipop it might be a good idea to use 1.3Ghz)
- Note: Tegra sets the max frequency to 1.5Ghz at boot, make sure to change it manually or have an app set it at boot to avoid battery loss. If you have a program such as
TricksterMod set it at boot make sure to include at least a 60 second "delay" in applying boot settings.
- Note 2: DO NOT USE THE APP "SYSTEM TUNER" TO SET FREQUENCIES. CONFLICTS WITH AUDIO PERFLOCK IN KERNEL. Do NOT use system tuner to set frequencies as it conflicts with audio performance lock in this kernel. Will prevent you from lowering your maximum frequency. Use Trickstermod.
GPU Max Freq - 446Mhz (maintains good battery life while smoothing out some games. Anything greater than 446Mhz is so heavily bottlenecked by RAM that it's essentially worthless. 600Mhz might give you 1 or 2 extra FPS for significantly worse heat, battery life, and stability)
- Possible frequencies - To be completed later
Fsync - On
Dynamic Fsync - On (be aware of data loss concerns, even if they actually are minimal.)
SmartDimmer/PRISM - On (off for a63 and lower)
zRAM - off/none (default) (For lollipop it may help with multitasking at the price of speed, although you really shouldn't be trying to heavily multitasking with a 2012 N7 anyway) (Not very useful on android 4.x with >=1GB RAM, for lollipop it's not really helpful >=3Gb)
Data remounting scripts - already included in ramdisk. Additional scripts not needed.
I DO NOT RECOMMEND, nor will I support, any kind of optimization/superdupercharge/placebo script. All settings are already optimized in kernel and ramdisk. Using these scripts or tweaks will only lead to problems and performance degradation.
__________________________________________
If you'd like to buy me some caffeine so I can continue to fit studying and kernel-ing in my busy schedule, feel free to donate below. Thanks so much for all of your support! Clicking the thanks button is always appreciated too

Alpha Changelog (stable feature list above):
a77 - remove CM12.1 specific stuff from ramdisk
a76 - Fix for 5.1
a75 - 5.1 Lollipop update and patches
Click to show complete changelog
a74 -
Fix for TricksterMod. Sync with cm12 ramdisk. Fake update dmcrypt to allow TRIM on encrypted devices (untested). Set ROW as default scheduler.a73 -
Lollipop! Updated toolchain. Removed touch2wake due to the wakeup issues it created for some. Other stuff.a69 -
Quick fix to allow overclocking on stock roms.
a68 -
Update to latest 4.4.3 kernel source
Sync with latest CM 4.4.3 ramdisk
Update to 4.8 toolchain
F2FS support
Zip installation supports all permutations of ext4/f2fs layouts
Based on work by frantisek.nesveda, but modified to support all layouts and be more flexible
Make sure to go to his thread -HERE- and click the thanks button!
Upgrade to BFQ v7r4
Adjust touchboost values
Enable Kernel Samepage Merging - I've gone back and forth on this. For now, enabled.
Probably some other changes I'm forgetting.
a67 - Update + sync ramdisk from cm11 to enable native USB OTG. Add thermal charging shut off. Some kconfig tweaks.
a66 - Only hold wakelock is touch/slide to wake is enabled. Tweak default BFQ values a bit.
a65 - Update BFQ from 5.1 to 6r2. Set BFQ as default for testing. Tweak Deadline and CFQ (Franco's CFQ values). If CFQ is still causing reboots for some, I will revert it to stock in next build. Cgroups timer slack controller. Enable RCU priority boosting for testing.
a64 - merge 4.4 kernel changes. Update ramdisk for 4.4
a63.1 - CM hotfix
a63 - Add Tegra 4 SmartDimmer (ported from TripNRaVeR's port for the One X). It either works much better or is completely broken. Either way, it's an improvement from the old SmartDimmer. Add necessary ramdisk change for PAC rom. Add dm9620 usb ethernet support. Switch back to linaro 4.7 toolchain from google 4.6 (used in mr2 for stability reasons).
a62 - Add double tap to wake thanks to flar2 and sgt. meow. Add configurable timer to keep double tap to wake active after screen shut off. Remove Fsync toggle. Pointless and confusing with Dynamic Fsync available now. Update Dynamic Fsync from faux123. Set backlight levels back to defaults and disable otf_scaling. Some random stuffs.
New sysfs:
/sys/android_touch/wake_timeout
Value is in seconds. Defaults to 60. Set to 0 to keep double tap to wake permanently active at the price of battery.
a61 - Enable compass driver. Add Dynamic Fsync by Faux123. Disable Fsync off at boot. Enable Dynamic Fsync at boot. Remove wifi pm fast/max toggle as it is now pointless and won't work since 4.3 kernel update. Add an older, but simpler, version of usb host mode by mehrvarz. Fixed and enabled many 4.3 config options relating to things like selinux.
a60 - More ramdisk fixes
a59 - Update cm10.2 ramdisk to fix storage issues. Fix 00su init.d.
a58 - Incorporate cm10.2 ramdisk.
a57 - Update to 4.3 kernel base. 4.3 stock only. Ramdisk base courtesy of Francisco Franco. Fsync off at boot since the internal storage is just so appallingly slow.
a56 - Add back some missing config options removed in a55 to support various features. No CIFS support. Couldn't get it to boot for some reason.
a55 - Add v2 of Tegra AHB patch set. Remove and revert USBHOST patches. Revert to almost stock kernel config for testing (will probably revert back later). Revert to stock PA ramdisk for testing. Tweak default TouchDemand parameters for bettter performance. Hard-code deadline and cfq tuneables thanks to the work by those in Franco's thread - details in commitlog on github. Set deadline as default I/O scheduler. Add core hotplugging lock during touch boost/input to interactive governor based on implementation in stock interactive governor (not fully tested). Other minor, inconsequential changes.
a54 - Remove AHB bus drivers and patches.
a53 - USBHOST support and patches. WiFi adhoc IBSS support.
a52 - revert voltage table changes
a51 - fix flickering at brightness level 13 when smartdimmer was enabled by setting SD min to 10. Re-enable a 3g modem reset assignment fix. It was disabled in a49/a50; let's see if re-enabling it causes 3g drops to return (Otherwise TCP proportional rate reduction was the cause). Re-enable wifi p2p patch that was disabled in a49 under the impression it wasn't included in the stock kernel when it actually is (whoops). Increase the some DVFS voltages so that that they are at least as high pre-a50 (according to DVFS debug showing actual running voltage) and not more than 25mV greater than pre-a50. Hard-code default pm_qos_max_cpus as 4 instead of ULONG_MAX. Fixes aesthetic bug where the default tegra hotplug max_cores was 2147483647 (For the curious - it is 2^31 − 1, the maximum value for a 32-bit signed integer in computing).
Oh, and change thread title to accord with new XDA requirements.
a50 - re-enable dynamic edp. Rework some edp limits. Rework DVFS voltage tables to better match frequencies, YMMV. Removed 1.7GHz max frequency option as it was pretty split whether your device could run it or not. If people were more responsible and wouldn't complain about issues when running 1.7 or higher I would leave it in, but unfortunately that's just not the case. So it saves me headaches in the future. Sorry. It's a minor increase from 1.6GHz and most can do 1.6 just fine.
a49 - add some rwsem patches. Revert TCP proportional patch. Revert a wifi p2p patch. Fully stock /net and drivers/net in source now. Add custom min/max backlight interface. I'll add more info when I'm not so busy. Removed zRam support.
Change your max backlight (min - 255) - /sys/module/board_grouper_panel/parameters/max_backlight
Change your min backlight (1 - max) - /sys/module/board_grouper_panel/parameters/min_backlight
Enable/Disable on-the-fly backlight level redistribution through available brightness slots based on new min/max using math below (0/1) - /sys/module/board_grouper_panel/parameters/otf_scaling
- brightness = min_backlight + DIV_ROUND_CLOSEST(((max_backlight - min_backlight) * max((brightness - 10),0)),245);
a48 - actually upload a kernel that is mr1 + row patches + flash fix
a47 - mr1 + row patches + flash fix accidentally uploaded old kernel version...
a46 - disable have_efficient_unaligned_access. Add USB Host mode charging patches.
a45 - Fix adobe flash corruption. Add ARM unaligned access and enable have efficient unaligned access. Make sure slider min brightness and auto-brightness min have the same backlight value.
a44 - Start over at mr1. Add ROW patches. Add LZ4 compression.
a43 - revert all network and wireless patches since mr1.
a42 - revert some config options. Fix fixed_mode on boot for multiboot. Sched_mc_power_savings set to 0 instead of 2 to see how it affects wakeup.
a41 - ARM cpu topology and relevant patches. Enable multi-core scheduling. Enable maximum multi-core scheduling power savings for testing. Switch back to LZ4 ramdisk compression as Multiboot supports it now. Increase touchdemand sampling down factor since sampling rate was decreased previously.
a40 - Revert SLQB. Add latest usb host mode charging from mehrvarz's repo. Force detect/report usb as ac, no apparent benefit. Enabled a config SVIPC or something... I forget. Enabled rndis support from CM.
a39 - SLQB allocator. Switch back to Gzip ramdisk compression for multirom.
a38 - Fix adobe flash playback. Super fast Lz4 compressed for ramdisk and kernel. Arm unaligned efficient memory access. Some misc. wifi and network patches. Many other changes. No guarantees.
__________________________________________________
Downloads:
Alphas 5.1 -
a77 - https://www.androidfilehost.com/?fid=23991606952601904
a76 (CM12.1) - https://www.androidfilehost.com/?fid=23991606952601166
Click to show downloads for older versions of Android
Alphas 5.1 -
a75 - https://www.androidfilehost.com/?fid=95916177934553111
Alphas 5.0 -
a74 - https://www.androidfilehost.com/?fid=95916177934528566
a73 - https://www.androidfilehost.com/?fid=95784891001616369
Alphas 4.4 -
a69 - http://d-h.st/kI7
a68 - http://d-h.st/gPV
a67 - http://goo.im/devs/Metallice/Nexus7/4.4.x/M-Kernel_a67.zip
a66 - http://goo.im/devs/Metallice/Nexus7/4.4.x/M-Kernel_a66.zip
a65 - http://goo.im/devs/Metallice/Nexus7/4.4.x/M-Kernel_a65.zip
a64 - http://goo.im/devs/Metallice/Nexus7/4.4.x/M-Kernel_a64.zip
Milestone 4.3.x Releases -
mr2 (4.3.x)
http://goo.im/devs/Metallice/Nexus7/Milestones/M-Kernel_mr2.zip
Alphas 4.3 (post mr2) -
a63.1 - http://goo.im/devs/Metallice/Nexus7/4.3.x/M-Kernel_a63.1.zip
a63 - http://goo.im/devs/Metallice/Nexus7/4.3.x/M-Kernel_a63.zip
a62 - http://goo.im/devs/Metallice/Nexus7/4.3.x/M-Kernel_a62.zip
Alphas 4.3 (pre mr2) -
a61 - http://goo.im/devs/Metallice/Nexus7/4.3.x/M-Kernel_a61.zip
a60 - http://goo.im/devs/Metallice/Nexus7/4.3.x/M-Kernel_a60.zip
a59 - http://goo.im/devs/Metallice/Nexus7/4.3.x/M-Kernel_a59.zip
a58 - http://goo.im/devs/Metallice/Nexus7/4.3.x/M-Kernel_a58.zip
a57 - http://goo.im/devs/Metallice/Nexus7/4.3.x/M-Kernel_a57.zip
Milestone 4.2.x Releases -
mr1 (4.2.x)
http://goo.im/devs/Metallice/Nexus7/Milestones/M-Kernel_mr1.zip
Alphas 4.2.x -
a56 - http://goo.im/devs/Metallice/Nexus7/4.2.x/M-Kernel_a56.zip
a55 - http://goo.im/devs/Metallice/Nexus7/4.2.x/M-Kernel_a55.zip
a54 - http://goo.im/devs/Metallice/Nexus7/4.2.x/M-Kernel_a54.zip
a53 - http://goo.im/devs/Metallice/Nexus7/4.2.x/M-Kernel_a53.zip
a52 - http://goo.im/devs/Metallice/Nexus7/4.2.x/M-Kernel_a52.zip
__________________________________________________
Legacy downloads available at http://goo.im/devs/Metallice/Nexus7

THIS POST/GLOSSARY NO LONGER UPDATED DUE TO TIME CONSTRAINTS
Glossary of terms:
(that one may not be as familiar with as things like CPU and GPU)
Hotplugging - the process of turning CPU cores on and off.
G core(s) - One of four ARM A9 CPU cores found in the Tegra 3 SoC
LP (core) - The ARM A9 "Low-Power" CPU core found in the Tegra 3 SoC in addition to the 4 G cores. The LP core, contrary to what many seem to believe, does not run in tandem with the 4 G cores.
Runnable Threads (hot plugging) - Limits turning on more cpu cores based on the average number of running threads
Touchdemand - A modified ondemand-based governor that I designed and configured to better suit the Tegra 3 and android based on my observations
Variant -
Scheduler -
Other things
FAQ:
What's the difference between the mr(#) version/download and the a(#) version/download? Which should i download? What do these acronyms mean/stand for?
The mr# (ex. mr1) stands for milestone release number #. The milestone builds are the stable, bug-free, and thoroughly, extensively, and expansively tested builds of m-kernel.
The a# (ex. a38) stands for alpha build number #. The alpha builds listed under downloads are all of the alpha builds after the latest milestone build listed in reverse chronological and "morphological" (? FIX) order. It is the continuation of the "alpha branch" of m-kernel, and is basically the latest milestone with a ton of patches, fixes, and changes that are completely UNTESTED by anyone but me. The number and substantiality of changes since the latest milestone obviously vary and also depends on the number of alpha builds since the latest milestone release. An alpha build isn't guaranteed to be stable, working, and bug-free. They are testing builds leading up to the next milestone
Do you recommend setting the maximum number of cores to 2?
I don't necessarily recommend everyone do this, for it really comes down to personal preference. However, limiting the maximum cores to two is a very simple change to make that will slightly improve battery, with little to no impact on performance. Android 4.x is highly optimized for dual-core processing. There is no part of the Android 4.x OS that needs more than 2 cores for a smooth experience, and likewise there are few to no android applications that need 2 cores.
For the most part, the 3rd and 4th g cores are only activated during time sensitive actions such as opening an app for the first time (i.e. not previously opened and cached in RAM) and during screen rotation. These are short lived operations meaning those 3rd and 4th g cores are quickly turned off afterwards. In essence a small hit to battery life for even smaller benefits.
Why won't my minimum frequency go below 340MHz?!?
As long as you don't use system tuner, the minimum frequency does go below 340MHz. The minimum frequency is temporarily raised to 340MHz during an audio event to prevent audio playback problems when using ondemand and similar governors. The minimum frequency returns to the previous value afterwards. Some apps may show the minimum frequency as 340MHz because clicking the app to open it created a sound causing the minimum to temporarily rise. The app does not change when the minimum frequency goes back to its previous value.
Why can't over clock the GPU as high as I can on other kernels!?!
You can. You have to raise the voltage for the top GPU slot. Other kernels do this automatically and to fixed values. The amount necessary depends on the GPU frequency you are trying to run and your device. No devices are alike and the voltage necessary at whatever frequency will vary considerably from device to devices. Be aware that having to overvolt to run a certain frequency may mean suggest that you shouldn't run that frequency anyway. Raising the GPU frequency and voltage has risks to consider
What is this tegra 3 "variant" or whatever? How do I find it? What does it meeeeaaaannnn??!!?
You can find this info in /sys/kernel/debug/t3_variant
In the stock kernel/source, each device sku is recognized and assigned four ID values. For the CPU there is a primary "cpu speedo id" and a secondary "cpu process id". For the SOC, or core (think LP core, RAM, GPU, etc), there is a primary "soc speedo id" and a secondary "soc process id."
Each "pair" of ids is used to choose the respective voltage tables for the components they represent. I'm going to ignore the soc/core ids as they aren't relevant to my point and are the same for all our devices.
The CPU voltage tables are represented by ( cpu_speedo_id # , cpu_process_id #). The voltage tables that share the same first number, the cpu_speedo_id, all end with the same MHz value. To make things simple, Tegra uses the maximum frequency in the voltage table to determine the maximum frequency. All of our Nexus 7 Tegra 3s share the same cpu_speed_id, corresponding to a maximum frequency of 1.3GHz.
The second number, the cpu_process_id, differs between all of our N7 T3's. Faux123 and everyone refers to value as our "variant." This value, cpu_process_id determines the voltages for each frequency in the table. For each increase in cpu_process_id, the RANGE of voltages for the voltage table is compressed by 25mV (i.e. the voltage for the top frequency is decreased by 25mV while the bottom stays at 800mV and the middle frequency voltages are adjusted accordingly).
Therefore, in a direct sense, the cpu_process_id, or "variant", HAS NOTHING TO DO WITH CPU FREQUENCY. I'll repeat this. YOUR CPU_PROCESS_ID OR VARIANT HAS NO DIRECT CONNECTION TO THE MAXIMUM FREQUENCY CAPABILITIES OF YOUR CHIP. Variant/cpu_process_id refers to the voltage tolerance of your cpu. While there may be correlation or secondary connection to the maximum frequency capabilities of your chip, there is not direct connection. Additionally, cpu_process_id HAS NOTHING TO DO WITH YOUR SOC/CORE AT ALL, WHICH INCLUDES YOUR GPU/LP/RAM. A high cpu_process_id tells you nothing about your core and how high you can clock your GPU.
TL;DR - Variant, or more accurately cpu_process_id, refers to voltage tolerance, and has no direct connection to the max frequency abilities of your chip, and definitely has absolutely no relationship to your core/GPU.
To do:
Core voltages quirks.
Max freq delay necessity.
Why doesn't the kernel come with recommended settings?

One more

Re: [Kernel[3G+Wifi] M-Kernel - mr1
Sweet will flash this and give you some results later
Sent from my VS920 4G using Tapatalk 2

Re: [Kernel[3G+Wifi] M-Kernel - mr1
azoller1 said:
Sweet will flash this and give you some results later
Sent from my VS920 4G using Tapatalk 2
Click to expand...
Click to collapse
+1 I got a good feeling about this one
Sent from my SGH-T999 using xda app-developers app

tdizzle404 said:
+1 I got a good feeling about this one
Sent from my SGH-T999 using xda app-developers app
Click to expand...
Click to collapse
I really hope you're making a joke... I've had a thread in android development for a while now... 37 versions...

Re: [Kernel[3G+Wifi][4.2.2] M-Kernel - mr1
So really there is no need for gpu over clock unless for a benchmark?
Sent from my VS920 4G using Tapatalk 2

azoller1 said:
So really there is no need for gpu over clock unless for a benchmark?
Sent from my VS920 4G using Tapatalk 2
Click to expand...
Click to collapse
Says who? Me? Where?
No of course that's not true. GPU overclock can have benefits. Minimal due to RAM bottlenecking, but it will still marginally imrprove FPS in some cases.

I love your work metallica, we really appreciate it
I remember you made 5(+) different versions just because for 2 people having wifi issues...
You really spend a lot of time at this and this is a great kernel.
Thanks!

Re: [Kernel[3G+Wifi][4.2.2] M-Kernel - mr1
Metallice said:
I really hope you're making a joke... I've had a thread in android development for a while now... 37 versions...
Click to expand...
Click to collapse
No joke here ive had decent results with your kernel I'm just commenting on the update
Sent from my SGH-T999 using xda app-developers app

Re: [Kernel[3G+Wifi][4.2.2] M-Kernel - mr1
Oc GPU to 520 and when I left trickster It blacked out and rebooted
Sent from my Nexus 7 using Tapatalk 2

Nothing to say at the moment but gotta post in it so I get subscribed. Keep up the good work!

I had just posted in the original M-kernel thread and couldnt edit my last post (probably cuz its being moved) . I was unable to set cpu max core to 4 w/o system freezing up. I just upgraded to mr1 and it shows 4 cores active and no freeze ups so far. I will leave everything to stock for now.
Cool you finally moved to "original" forum, makes it alot easier for me to navigate since I am usually in this forum anyways..
thxs
d

azoller1 said:
Oc GPU to 520 and when I left trickster It blacked out and rebooted
Sent from my Nexus 7 using Tapatalk 2
Click to expand...
Click to collapse
Hi, you just need to increase the GPU voltage a little bit before you overclock it to 520mhz, hope that helps

Re: [Kernel[3G+Wifi][4.2.2] M-Kernel - mr1
azoller1 said:
Oc GPU to 520 and when I left trickster It blacked out and rebooted
Sent from my Nexus 7 using Tapatalk 2
Click to expand...
Click to collapse
Maybe you should try reading the FAQ :/
Sent from my Nexus 7 using Tapatalk HD

Re: [Kernel[3G+Wifi][4.2.2] M-Kernel - mr1
Congrats my friend. What a journey!
How,s it feel to be in the big leagues
Edit: mr1 flashed. Keeping it default for now. Seems very smooth. Another excellent kernel. Thank you for everything.
Cheers, FReaKRaNT

Re: [Kernel[3G+Wifi][4.2.2] M-Kernel - mr1
thanks for the hard work the kernel works great and the FAQ was very helpful.
Sent from my Nexus 7 using Tapatalk 2

Απ: [Kernel[3G+Wifi][4.2.2] M-Kernel - mr1
Guys does flash working for u without any problems?
Edit:I'm on Francos kernel now. I just flash this kernel without wipe cache and dalvkin?
Sent from my Nexus 7 using Tapatalk HD

Cool you're in Original Dev now. Congrats Metallice.
Downloading mr1 now. :good:

Better Mobile App

welcome