Develop Bugs

[DEV] Las Venturas - 2.6.35 kernel port for Hero // Version: 1.2 - 13 May

Introduction
After a year of developing, with many stalls due to studying, we finally reached a stable state with the 2.6.35 kernel port. It is a quite honour to introduce you all to the Las Venturas kernel for the GSM Hero. It is a kernel based on the Cyanogenmod sources with updates coming from the AuroraCode forums. (those lads from Aurora are just geniuses) The main idea behind the Las Venturas was well, a fun project. Let's be honest I love deving new things and this is a really a nice project. We always strife to get the best out of our phones and the kernel has a big influence on it.
The 2.6.35 kernel adds speed improvements but in general it provides more functionality than the 2.6.29 kernel (based on the official HTC sources). It also has newer drivers for the Framebuffer (speed), adds ext4, better USB stack for our ARM devices.
Instructions
Go to your favourite recovery. Always wipe dalvik-cache!. Flash the kernel like any other update.zip, reboot and take a coffee while it is booting. Well done! High five yourself, as you just installed 2.6.35 for your Hero!
Downloads
Las Venturas version 1.2
http://www.mediafire.com/download.php?7r5rcr70mh3ynb3
md5sum: c37c43566cf882f21d0f1dde9afeb37d
Las Venturas version 1.1
Links:
http://www.mediafire.com/download.php?p3csh7sajbolp13
md5sum: 25d0fad0ac42ebf20be47f97c0511406
Las Venturas version 0.5.0
links:
http://94.23.152.245/xda/rmr/Las_Venturas-0.5.0.zip (thanks to wupper!)
http://www.multiupload.com/U6KYEOCWEE
md5: fa1d0b5767caa68152fe8166a7f74f4b
The big compare list
Current advantages:
full ext4 support
Newer overlay code, apps tend to be displayed faster than the original .29 kernel
Newer usb-code, more suitable for newer ROMs like Gingerbread and ICS than the .29 kernels
More stable GPS (no more reboots!)
General faster IO than 2.6.29
Less latency for playing sound/music
For the rest, it contains newer drivers for a lot of stuff. As it is a 2.6.35 kernel of course
Current disadvantages:
USB is experimental. Usb-tethering might not work, for non-sense ROMs you can try Erasmus fix
SD-card IO is slightly slower than flykernel (around 0.5%)
Change-log
Changes of last Version 1.2:
Faster general IO output
Fixed some bugs concerning SD speeds
Fixes to the interactive governor
Newer vibration-code, less latency (small impact, but everything is welcome)
Ashmem flushing fix
Code cleanup
Full log:
https://github.com/riemervdzee/hero-kernel-2.6.35/wiki/Changelog
Source code
Config used is found under kernel/arch/arm/config/hero_defconfig
https://github.com/riemervdzee/hero-kernel-2.6.35 (0.5.0 and above)
https://github.com/riemervdzee/cm-kernel (Older repository. For pre 0.5.0 versions)
Thanks list:
--> Elemag -- Initial start of this project, great advisor and debugger
--> s0be -- working on the .35 fork of this project for the Hero CMDA. Good to see another dev'er at work, always inspirational
--> Erasmux -- For his flykernel and his work on getting the .35 to work
--> Ninpo -- Initial start of this project
--> Feeyo -- For general fixes. Great mentor to linux/kernel programming
--> And of course all CyanogenMod lads working on the CM-kernel
Note that I hijacked Elemag's thread (he first opened this topic). So things might sound a bit wrong if you read the first pages

Las Venturax
This post will contain the releases I do until Riemer has time to catch up with me: (Unless I see me and Riemer would like to go in different directions with this kernel I don't want to open another thread for "my" versions)
Las_Venturax-0.6.2.zip (mediafire) (multiupload)
Scheduler tweaks (restored latency to 6ms and enabled hrtick - this time for real!)
SmartassV2: a few bug fixes.
Some upstream updates (thanks arco)
This is a generic "smart updater package" which can also be used to do OC from boot, as explained in my FlyKernel post under
Boot OC and optional tweaks (first post).
USB tethering on this kernel is different from the .29 kernels most ROMs are compatible with. Fixes for CM6/7 are found on post #1029.
More information about SmartassV2 (for users) can be found on my FlyKernel post.
ROM Developers
Developers aiming to integrate this kernel into their ROMs, might find it more convenient to use the following regular update package as a reference:
Las_Venturax-0.6.2-Floyo.zip
In this package the kernel's ramdisk is the one compatible with Floyo 1.4.
If you prefer to recompile the kernel yourself, you are very welcome to do so, but please share your updated sources. Obviously you are changing something (maybe very very small) otherwise why are you recompiling it? Please share with us what changes do you find to work better for you. You are also required to this by the GPL license of the kernel.
Previous versions:
Las_Venturax-0.6.0.zip (multiupload)
Tweaked scheduler parameters (lowered latency to minimum - ROM developers please do NOT overwrite the scheduler params in your init.rc)
Added smartassV2 governor as the new default governor - more details below (since 0.5f, tweaked built in sleep in 0.6.0)
Added interactiveX governor (since 0.5c)
Some compiler optimization (stable since 0.5e)
Fix for jogball notification (since 0.5a)
Use frequency table from fly kernel (since 0.5a)
Based on Las Venturas 0.5.0
Las_Venturax-0.5f.zip (multiupload)
Added smartassV2 governor (set as default)
Las_Venturax-0.5e.zip
Added "Wireless RNDIS" - could this fix usb tethering?
Tweaked compiler optimizations and moved to new toolchain
Las_Venturax-0.5d.zip
This version is a "quick fix" version trying to solve the stability issues (spontaneous reboots) reported with the 0.5c version. Only thing is I have no idea what is causing these problems so this is really a bit of a shot in the dark. Please report any stability issues, and if possible also state which ROM, what you where doing at the time and for spontaneous reboots attach a last_kmsg (i.e. "adb pull /proc/last_kmsg"). Thanks in advance to all the testers.
Reverted part of the compiler optimizations from 0.5c.
Back to NOOP scheduler
Default governor back to smartass. interactiveX is still available and I am still very interested in feedback regarding it.
Additional kernel config tweaks.
Las_Venturax-0.5c.zip
Added interactiveX governor by Imoseyon - for now this is the default governor (most likely a temporary situation).
Use BFQ I/O scheduler
Voodoo compilation optimizations
Fix for cpufreq time_in_state (i.e. SetCPU frequency counters) - broken only in 0.5a version (commit).
Note regarding the "new" interactiveX governor:
From a very quick look at its code, this governor looks promising to me, and I hope that it might provide better battery life over the current alternatives.
I am very interested to hear about the battery and performance with this governor vs. smartass and/or ondemand.
Some philosophical discussion on the subject:
It seems there are quite a lot of smartass/interactive variants out there (in kernels for other devices). I also have some ideas of my own, that will hopefully manifest into a new governor someday soon (smartassV2?).
In the meantime, interactiveX seems relatively close to smartass (also discriminates between screen on/off states), and to the best of my current understanding, in theory, given the parameters I have selected for it, I hope it might improve battery life.
Las_Venturax-0.5a.zip
Fix for jogball notification (commit)
Use frequency table from fly kernel
Based on Las Venturas 0.5.0
All changes are on my github.
Cudos to riemervdzee for all his hard work on this excellent kernel, as well as to all others who have helped to develop and test this kernel.

Yeah any and all kernel devs, get on this. I was supposed to be working on this with Elemag but Froyd has been eating my time. Hopefully one more release should get it "stable" so I can get back onto this.
Elemag has done fantastic work.

Hmm seems like there is already a .34 kernel for the G1. Damn them

Elemag said:
Hello,
A lot of things are already working, including:
MTD
usb
adb
charger/battery
display
keypad+trackball
...and probably most thing not mentioned as not working
Click to expand...
Click to collapse
Do you have a config file with adb working, I am stuck with no ADB using the hero_defconfig.
Also which ROM do you use for testing with this kernel? EDIT: to be more precise, I am mostly interested in the ramdisk you are using to get ADB to work.
Any other ideas how I can get adb to work?

erasmux said:
Do you have a config file with adb working, I am stuck with no ADB using the hero_defconfig.
Also which ROM do you use for testing with this kernel? EDIT: to be more precise, I am mostly interested in the ramdisk you are using to get ADB to work.
Any other ideas how I can get adb to work?
Click to expand...
Click to collapse
quote. i'm very interested

erasmux said:
Do you have a config file with adb working, I am stuck with no ADB using the hero_defconfig.
Also which ROM do you use for testing with this kernel? EDIT: to be more precise, I am mostly interested in the ramdisk you are using to get ADB to work.
Any other ideas how I can get adb to work?
Click to expand...
Click to collapse
Played a bit with the config and I finally got it working. Would still appreciate the config file you are using.

I am using the ramdisk from CM6 default boot.img. The config is hero_defconfig. Testing it under my own CM6 build which should be more or less the same as the CM6-nightlies.

The touchscreen driver synaptics_i2c_rmi.c does it contain the AOSP fixes found in the 2.6.29 kernels ?

rbrucemtl said:
The touchscreen driver synaptics_i2c_rmi.c does it contain the AOSP fixes found in the 2.6.29 kernels ?
Click to expand...
Click to collapse
I think it doesn't - Can't find anything related to eventhub filters.

looks good. thanks for posting sources. I'll help out also

Way awesome. Great job. I'm not too well versed in all this but I'd love to lend a hand as well.

Decad3nce said:
Way awesome. Great job. I'm not too well versed in all this but I'd love to lend a hand as well.
Click to expand...
Click to collapse
Agreed, not my field of expertise but willing to help in any way I can and I'm willing to learn
Sent from my HTC Hero running froyo: take that, Sprint!

Please guys, post here your improvements, your tweaks ecc ecc

mr.bang said:
Please guys, post here your improvements, your tweaks ecc ecc
Click to expand...
Click to collapse
Yeh a "tweak" which would make the rest of the hardware actually work would be nice.... We are still far from getting this kernel to a usable state. Let first concentrate on this.
I personally, have done a massive porting of code from the .29 kernel which has obviously resulted in the kernel not booting now - yippee Now working on trying to get it to boot which could takes anything between days and never.... Is there any way to debug the kernel boot if adb is not working?!
Anyone else working seriously on this?

i'm trying to work on this but i have few building problems..

You can boot, then reboot into a working kernel and pull /proc/last_kmsg if you can't get to adb. It would be nice if you post the output to pastebin and link it here .
As for the massive porting from .29 -- I think that the microp driver needs to be ported first, cause it is probably the bottleneck right now.
I found that the touchscreen driver initializes as /devices/virtual/input/input0 but on the .29 kernel it is input1 and input0 is the headset. I don't know if this can cause it not to work though.
If you have building problems, write to me, preferably in github. I don't have time to work much on this, because I am trying to make my diploma, but will surely take a look if someone has an idea.
Anyway, getting the touchscreen to work will be a breaking point

I actually started working on the SD card not being recognized (seemed easier than fixing the touchscreen or so I thought). Somehow got pulled in to porting a whole lot of code from the .29 kernel's arch/arm/mach-msm directory....
I'll try the last_kmsg thing sounds very usefull

Guys I think porting more and more stuff forward from .29 is a bad idea. Instead the stuff we -need- should be adapted for 2.6.34. Otherwise we're going to end up with some messy 2.6.29/34 hybrid. Everything we need is there in the kernel apart from specific drivers, otherwise 2.6.34 wouldn't work with the G1, however it does.

Hacre said:
Guys I think porting more and more stuff forward from .29 is a bad idea. Instead the stuff we -need- should be adapted for 2.6.34. Otherwise we're going to end up with some messy 2.6.29/34 hybrid. Everything we need is there in the kernel apart from specific drivers, otherwise 2.6.34 wouldn't work with the G1, however it does.
Click to expand...
Click to collapse
I was obviously talking only about drivers....

[KERNEL] [GPL] [4.3] FuguMod kernel (3.0.101) (open, stable, reliable and secure)

FuguMod kernel is now available for the Galaxy Nexus.
It has been reported to work both on GSM and CDMA versions. But I can only test it on GSM version myself.
You can download them at:
http://fugumod.org/galaxy_nexus/
Source and changelog can be found here:
https://github.com/renaudallard/gnexus_kernel
IRC channel:
irc.freenode.net #fugumod
To install, just download the appropriate version for your ROM (4.0.x) and flash it with fastboot (RAW version: fastboot flash boot kernel-$VERSION.img) or flash it with CWM (CWM/zip version).
Please note that not all versions exist in CWM format.
4.0.2 version is based on official google initramfs + init.d support (is now in deprecated state, no future updates will be brought)
4.0.3 version is based on the initramfs of AOSP + init.d support. it is compatible with 4.0.4
4.0.4 version is based on the initramfs of AOSP + init.d support. it is compatible with 4.0.3
4.1.x version is based on the initramfs of AOSP + init.d support.
4.2.x version is based on the initramfs of stock kernel
4.3 version is based on the initramfs of stock kernel (use that one for CM, not reco)
4.3-reco version is based on the initramfs of stock kernel, even with install-recovery.sh enabled (so supersu can work, but if you don't have supersu, don't use it)
for experimental versions, do not flash if you are not ready for big troubles, they may not even boot, burn your phone and eat your cat.
Features:
- stackprotector
- various security enhancements
- RCU boost
- Automatic process grouping
- TUN (compiled in kernel)
- latest 3.0 linux kernel
- newer wifi driver
- gamma/color hack
- CM9 compatibility
- PaX (from r333)
- grsec (from r624)
- TouchWake from Ezekeel (from r778)
Versions
Kernels are based on the below version scheme
kernel_FuguMod_20120111_r20-4.0.3.img
20120111 is the date it has been packaged
r20 is the release number
4.0.3 is the ROM it is compatible with
Color offsets
In CM9, just use the built in function.
For other ROMs, the settings offsets are in
/sys/class/misc/samoled_color/
For example green_v1_offset
Just edit the three green red and blue color settings. Default value is 60.
It can be done on the console with a command like this: echo 55> /sys/class/misc/samoled_color/green_v1_offset
Stable vs Testing
There are sometimes kernels in testing folder. These may be very stable or may not boot at all. Be sure to have an USB cable and fastboot under the hand if you try one of these. That said, in general, if they stay into testing folder for more than 15 min, they should at least boot and work more or less. I tend to remove non booting kernels from testing folder in less than 10 min (depending a little bit on the speed testers take them), and so if you see them one hour later, you should assume they are safe enough to flash.
So, in general Stable is the safest bet, but Testing may be the best. I, myself, generally run testing one.
Deprecated folder
In general, unless you really know what you are doing, you should avoid flashing those, they are mainly there for historical reasons.
Radio drops and blueish/faded screens
Please ensure you are running the correct firmware for bootloader and baseband, like in the matrix in bottom of that page: http://source.android.com/source/building-devices.html
For those where problems persist after flashing recommended versions, try "echo 0 > /sys/kernel/debug/smartreflex/sr_core/autocomp"
OTG unmounting internal SD
Please see http://forum.xda-developers.com/showpost.php?p=24040652&postcount=174
Mirrors
bootloaders: http://fugumod.org/bootloaders-gn/
basebands: http://fugumod.org/modem/galaxy_nexus/
Check for vulnerabilities
http://www.xray.io
Compatibility with hackish style apps
All apps which require direct memory write, access to symbols or memory offsets or modules will NOT work. And, no, don't ask they won't be supported in the future.
Security
If you want good security when your phone is stolen, in addition to encryption, don't forget to turn debugging off. Also, use enpasschanger to change your encryption password, any short PIN encryption can be cracked in a few minutes easily (for example, using my script at http://pastebin.com/Mdu06RZN)
Redistribution
As per GPL, you are authorized to redistribute this kernel with any of your custom ROMs provided you give out the source code like I do. You can link to my github in your distribution site.
However, if you modify the kernel yourself, whatever the modification is (compiling it yourself with a different compiler is a modification), you are not authorized to name it FuguMod, although you can credit me and tell the base comes from FuguMod but you cannot call the kernel itself FuguMod.
Touchwake
to enable it "echo 1 > /sys/devices/virtual/misc/touchwake/enabled"
to make it always on: "echo 1 > /sys/devices/virtual/misc/touchwake/always"
Beware, touchwake is known to sometimes produce screen locks
PGM
See "Compatibility with hackish style apps". Use touchwake instead.
Lost root
Use supersu instead of superuser from chainsDD (superuser from koush seems to work fine too). Change the setting in SuperSU to ignore CM root setting if you are running CM.
Updater app
https://play.google.com/store/apps/details?id=my.zin.rashidi.android.fugumod
root on 4.3
Currently only reco version has support for root access with supersu. Keep in mind that su access is now (as of 4.3) provided by a daemon, which may drain your battery or worse. Please think about your uses for root to see what is better fit for you.

W00t fugumod on the nexus!!
Will try it, thanks for dropping this here.

I'm totally happy

Finally! A kernel we can rely on Thanks alot mate, looking forward to further developments on this. I remember FuguMod fondly on the SGSII

Nitroz said:
Finally! A kernel we can rely on Thanks alot mate, looking forward to further developments on this. I remember FuguMod fondly on the SGSII
Click to expand...
Click to collapse
You probably mean SGS1.

I'm not entirely sure how accurate setcpu is at reading frequencies, but it seems to be stuck at 700mhz after a reboot. Moving the sliders a bit allows the cpu to use the entire range of 350-1200mhz as intended. I'm on AOKP milestone 2 if it matters and using r26.

Haven't yet tried this, but maybe min frequency when booting is set to 700mhz?
when you open setcpu, is the min slider at 350mhz?
What governor are you using? Not sure it matters though, but it might so.

maybe try using cpuspy to read the usage. Also, there may be something in your init.rd limiting the frequencies
Sent from a Nexus

Yes, min and max are set at 350/1200 on the sliders, but the green text says it's at 700/1200. Governor is the default interactive. Right now, I'm only using setcpu as a tool to view my frequencies as everything is "under observation" as I've only had this phone for a week. I did a reboot last night before going to bed. When I woke up 6 hours later, batt was down to 92%. Which is a quite fast considering I only had 5 hours of sleep. That's when I noticed that frequency was pegged at 700mhz the whole time. I tried opening other apps that should ramp up the speed, but as far as I can tell, it was still at 700.
Now, as I said, I'm only using setcpu to check my frequencies so "set at boot" isn't applied. When I apply "set at boot," min/max is at 350/1200 after a reboot and CPU scales up and down properly. So does this mean the default setting of the kernel is 700/1200? The thing is, even with max at 1200. I can't seem to make it scale up to 1200.
EDIT:
nikademus said:
maybe try using cpuspy to read the usage. Also, there may be something in your init.rd limiting the frequencies
Sent from a Nexus
Click to expand...
Click to collapse
I don't seem to have an init.rd file anywhere. I did a search using root explorer.
Edit 2:
CPUSpy says I'm only using 700 and DeepSleep even after running Asphalt 6. This is after a reboot without setting anything at boot with setcpu.

j.go said:
Yes, min and max are set at 350/1200 on the sliders, but the green text says it's at 700/1200. Governor is the default interactive. Right now, I'm only using setcpu as a tool to view my frequencies as everything is "under observation" as I've only had this phone for a week. I did a reboot last night before going to bed. When I woke up 6 hours later, batt was down to 92%. Which is a quite fast considering I only had 5 hours of sleep. That's when I noticed that frequency was pegged at 700mhz the whole time. I tried opening other apps that should ramp up the speed, but as far as I can tell, it was still at 700.
Now, as I said, I'm only using setcpu to check my frequencies so "set at boot" isn't applied. When I apply "set at boot," min/max is at 350/1200 after a reboot and CPU scales up and down properly. So does this mean the default setting of the kernel is 700/1200? The thing is, even with max at 1200. I can't seem to make it scale up to 1200.
EDIT:
I don't seem to have an init.rd file anywhere. I did a search using root explorer.
Edit 2:
CPUSpy says I'm only using 700 and DeepSleep even after running Asphalt 6. This is after a reboot without setting anything at boot with setcpu.
Click to expand...
Click to collapse
OK, 4.0.3 init.rc I have been given is the one from Francisco Franco and it limits the minimum frequency to 700mhz. This will be solved in next build, in a few minutes. Although you should be able to go over 700Mhz

nikademus said:
OK, 4.0.3 init.rc I have been given is the one from Francisco Franco and it limits the minimum frequency to 700mhz. This will be solved in next build, in a few minutes. Although you should be able to go over 700Mhz
Click to expand...
Click to collapse
Ah, well that's good to hear. Maybe the conditions needed to raise the frequency are not being met. Not that I know anything about kernels...

j.go said:
Ah, well that's good to hear. Maybe the conditions needed to raise the frequency are not being met. Not that I know anything about kernels...
Click to expand...
Click to collapse
Try the latest version, I removed all Francisco tweaks.

nikademus said:
Try the latest version, I removed all Francisco tweaks.
Click to expand...
Click to collapse
All right, I'll give it a spin tonight and post how it goes. Thanks!

I think I will be upgrading my phone to 4.0.3. This would mean I would not support 4.0.2 as I would not be able to test it properly. Are there users here who need the 4.0.2 version?

great
R37 für 4.0.3 runs flawless.
I use CM9 kang by fitsnugly.

R40 also flawless on fitsnugglys CM9 kang

r41 is out, probably last release for today

I flashed the latest KANG from today and the 122211 gapps with R41.
Works like a charm so far

aosp kang built today, flashed R43 just now. booted fine first try, wifi/bluetooth are fine, data call as well, rebooted, set scheduler/gov to deadline/ondemand, min/max freq to 1.2ghz, score on antutu maxing out around 5200, 5300. with my modified stock, i hit 6200+ in those conditions.
switch back to cfq/interactive, sd write speed goes up a bit to 10.4mb/s (deadline was just under 9.4mb/s), cpu integer 1304, float 1099, pushes score up a bit but still not reaching 5400 (this is with all tests selected, 2d/3d, database..). tweaked lowmemorykiller, antutu score jumps to 5600+.
but benchmarks mean almost nothing, i know. overall it's pretty smooth, fast on bootup, ocasional "lag" here and there (but that may be Mr. Android's fault).
will report more as the kernel settles in.
thanks nikademus.
edit: just re-installed gta. it seems i have no in-game sounds at all? it's fine until it gets to the main menu though. anybody else seeing this? happening on stock kernel too, wth..
edit2: jumping on r44.

flashed R44 on the latest fitsnugly kang. all is well. as expected, as only unused modules have been removed

[DEV] [KERNEL] UNOFFICIAL - Jelly Bean optimized Kernel for A100

Current release: Version 2.0 (stable) [09/06/2012]
SOURCE CODE: Available at GitHub
*WARNING PLEASE USE AT YOUR OWN RISK*​
DISCLAIMER​
FIRST OF ALL THIS IS NOT AN OFFICIAL KERNEL, IT IS NOT SUPPORTED BY OFFICIAL CM10 ROMS OR ANY PREVIEW ROMS.
ONCE YOU INSTALL THIS KERNEL YOU WILL NOT BE SUPPORTED IN THE CM10 / CM9 OFFICIAL/UNOFFICIAL DEVELOPMENT THREADS
OF ANY FORUM i.e XDA, SLATEDROID, etc.. THIS MEANS THAT YOU MUST NOT REPORT ANY ANDROID / CM BUGS TO THE ORIGINAL
COMMUNTIY THREADS FOR THE ROM YOU USE! YOU MAY HOWEVER REPORT ANY CM/ANDROID/KERNEL RELATED ISSUES TO THIS THREAD ONLY!
Click to expand...
Click to collapse
Features
CPU Overclocking up to 1500mHz (default is set at stock 1000mhz)
Stable GPU Overclock @ 450mhz (scales from 300 - 450)
Userspace CPU undervolting support
Brick prevention/precaution - disabled MMC_CAP_ERASE function from kernel
I/O Schedulers: BFQ, CFQ, SIO, DEADLINE, NOOP, V(R) (Default VR as of v1.3 - prior to 1.2 default = deadline)
Autogroup Scheduler patched to work with Android via User ID task grouping
CPU Governors: Lionheart, SavagedZen, Lazy, Scary, Intellidemand, LagFree, Wheatley, Lulzactive, SmartAssv2, Interactive, Ondemand, Powersave, Userspace, Performance (depending on ROM - interactive governor is usually set as default gov from userspace during init)
ARM libs from Linux 3.x (v2.0+)
Android Drivers from Linux 3.x (v2.0+)
Linux Security from Linux 3.x (v2.0+)
Cleancache + Zcache Support (v2.0+)
Working Zram - to enable see instructions below (v2.0+)
Fixed Video driver glitches (v1.4+)
Cleaned up tons dmesg errors and warnings (v2.0+)
Memory management fixes and patches from 3.x (v2.0+)
Alsa SoC Tiny HAL patch for better compatibility with Jelly Bean and ICS (reduces/eliminates popping sounds)
Plus various other improvements to kernel configuration and code.
Downloads: (if anyone experiences issues downloading from the androidfilehost mirrors please contact [email protected] to notify of outage as requested by afh admin, thanks!)
Current Stable:
Code:
[URL="http://goo.im/devs/godmachine81/a100_kernel/gm-a100-v2.0-signed.zip"]version 2.0[/URL]
Previous Releases:
Code:
[URL="http://beta.androidfilehost.com/?fid=9390062577138008066"]version 1.5[/URL]
[URL="https://github.com/downloads/godmachine81/Acer-A100-JellyBean-Custom-Kernel/godmachine-a100-kernel-v1.3a-signed.zip"]version 1.3a[/URL]
[URL="https://github.com/downloads/godmachine81/Acer-A100-JellyBean-Custom-Kernel/godmachine-a100-kernel-v1.2b-signed.zip"]version 1.2b[/URL]
[URL="https://github.com/downloads/godmachine81/Acer-A100-JellyBean-Custom-Kernel/godmachine-a100-kernel-autogroup-v1.1-signed.zip"]version 1.1[/URL]
[URL="https://github.com/downloads/godmachine81/Acer-A100-JellyBean-Custom-Kernel/godmachine-a100-kernel-autogroup-v1.0.1b-signed.zip"]version 1.0.1b[/URL]
[URL="https://github.com/downloads/godmachine81/Acer-A100-JellyBean-Custom-Kernel/godmachine-a100-kernel-autogroup-v1.0.1-signed.zip"]version 1.0.1[/URL]
[URL="https://github.com/downloads/godmachine81/Acer-A100-JellyBean-Custom-Kernel/godmachine-a100-kernel-autogroup-v1.0-signed.zip"]version 1.0-pre[/URL]
Tools:
Code:
[URL="https://github.com/downloads/godmachine81/Acer-A100-JellyBean-Custom-Kernel/toggle-ag.sh"]toggle-ag[/URL] Tool to Enable/Disable Autogroup and check the status.
'toggle-ag' now included with kernel zip as of 1.3a and is located at /system/xbin/toggle-ag - You may run from a terminal or create Script Manager widgets for each of the script arguments:
Code:
toggle-ag status
toggle-ag on
toggle-ag off
toggle-ag help
Please remember that this script has to be ran as root if you plan to enable/disable autogroup, however you may run as regular user to check the status or get the help dialog.
Important info on toggle-ag script usage (from the script comments):
#**Please note that toggling back and forth the scheduler will
#produce undesired effects, as it takes the system a few minutes
#to switch the process scheduler each time effectively. Imagine
#all processes that run in the backround are rearranged each time
#you switch the process scheduler. In other words you shouldn't
#toggle back and forth to make comparisons as they WILL NOT be
#effective immediately!!
Click to expand...
Click to collapse
Goo Manager Support (NEW!)
You can now download my custom kernels, recovery, tweaks, etc from Goo Manager, available on the Play Store. Goo Manager is similar to ROM Manager, except it works very well with my release of TWRP 2.2.2.0.
First time use instructions:
Set Download path to: /sdcard/goomanager/ in "Settings" (This is important as the location on Android and TWRP need to both be exact same!)
Go back to the main screen in Goo Manager and click Browse Compatible Roms
Choose 'godmachine81'
For kernels choose a100_kernel (you are welcome to look around in my other directories)
Choose the release you wish to download
Choose 'begin download'
You will see a notification for 'Download Finished' - Tap on it
It will prompt you to Select Zip(s) to flash, you may choose more than 1!
After you have selected all the zips you want to flash, go to the option 'Order and flash selected' or if you want to add a zip from a custom location, choose the 'Add zip from another location option'
Once in the Order and flash menu, it is important that you set the order to flash in the proper order, when you are sure it is right, then click Flash (First time you use Goo Manager, it will prompt you that an OpenRecovery is needed, choose that you already have one)
After You click flash, the system will reboot to TWRP, flash your .zip files, and reboot back to android without any user interaction.
ZRAM
What is it?
Zram was developed so that systems with a limited amount of physical ram may allocate a percentage of that to a system swap device using compression. By compressing the data that is in the swap space you can fit more data into the same amount of ram. For example App#1 is consuming 500mb of a total 725mb ram, this leaves you with 225mb free. If you have Zram enabled then App#1 may begin to swap to the zram device, when doing this you will have an advantage, because any amount of data from App#1 that gets swapped out to Zram will be compressed meaning it is actually using less physical ram. So instead of only 225mb free of 725mb you may now end up with something more like 400mb free because data from App#1 is compressed in Zram, in this example thanks to compression you cut the 500mb memory usage of App#1 to 325mb. Zram should have a minimal impact on performance while giving you the benefit of fitting more data into the amount of physical ram your device has.
HOWTO
This kernel includes functional ZRAM support, however to take advantage of it you must enable it from userspace (Android). Cyanogen Mod has an option in Settings > Performance > Memory to enable Zram, however it doesn't properly work - I'm not sure exactly how it is coded in the cm sources, but when you enable zram it doesn't create the zram swap device like it should. To work around this I wrote the following flashable .zip files that contain a script to automatically create the zram swap device at boot, please download and flash the size you wish to allocate to zram:
Zram - 100MB (14% ram)
Zram - 150MB (20% ram)
Zram - 200MB (28% ram)
Zram - 250MB (34% ram)
Zram - 300MB (41% ram)
Zram - 350MB (~50% ram)
To Disable/Remove Zram
In the event that you want to disable Zram then just remove the file(s) at:
/system/etc/init.d/50zram-*
After the 50zram- file has been removed, just reboot your device and you will no longer have Zram enabled. To re-enable just reflash one of the above files.
Flash Back stock kernel?
For those who wanted it: stock-kernel-signed.zip click here to download the stock ICS Kernel - This is the Stock CM kernel from The Android_Device_Acer_A100 Prebuilts on github.
To cut down on general discussion in this thread please note that I have been in the Freenode IRC Dev channel a lot lately. server: irc.freenode.net channel: #iconia-dev - My IRC handle is godmachine81 Join me there for general discussion if you don't mind. Thanks!
Video of Kernel in action on CM10 (appologize for audio and poor quality)
*All references to the Xtreme releases has been removed due lack of time needed to maintain it aside from the stable releases - will update the thread when I Xtreme development gets back underway
ChangeLog:
2.0
Backport several bits mainline code from Linux 3.5 - including Security, ARM Libs, MM, and Android specifics
Zcache + Cleancache added
Ability to concatenate kernel cmdline configuration to Bootloader's cmdline without breaking compatibility with any bootloaders ( needed for zcache/cleancache to work)
Zram patches and updates
Clean up dmesg logs
Deadline IO Sched tweak (1:1 ratio writes/fifo) - VR remains default IOsched
CONFIG: turn off some verbose logging/debugging to reduce overhead, enabled Load Lens Correction Data to smooth out camera operation
TweakIO init script included by default to optimize disk read/write performance
Several other small patches and tweaks to underlying sources
1.6
Minor patches to sources and configuration
1.5
GPU voltage and frequency updates
Interactive governor updated from N7 grouper
Adjust frequency scaling per core for new interactive gov.
1.4
This release was a testing Xtreme release which has recently been removed due to lack of development
1.3a
Script: toggle-ag now included in zip, installs to /system/xbin/toggle-ag
Default IO Scheduler V(R)
Default CPU Governor Lulzactive
1.2b
Bug Fix release for 1.2 - BFQ randomly causing "black screen" issue immediately after boot animation, preventing full boot - reboot resolved issue in most cases, but comes back at random on boot - Setting default I/O scheduler to NOOP until BFQ issue is resolved.
1.2
Autogroup per UID instead of TTY task (huge improvement to autogroup on android)
Set BFQ as default I/O Scheduler
Allocator: Switch to SLUB from SLAB
Remove verbose debugging symbols
Set proper firmware/calibration paths for WiFi in configuration
1.1
Add userspace support for undervolting
GPU OC (400mHZ) on CPU OC > 1000mHZ
Fix "Recent Apps" bug - The glitchy behavior when loading an app cached in the "Recent Apps" menu. Pointed out by DarkNight
Tune SmartassV2 for better behavior and ideal freq set at 760mHZ
Add the following CPU Governors: Lionheart, SavagedZen, Lazy, Scary, Intellidemand, LagFree, Wheatley
Deprecated the non-autogroup release also known as (default)
various other improvements to CPU, voltage, video.
1.0.1b
Add SmartAssv2 CPU Governor
Fix LOCALVERSION
1.0.1
Patched MMC_CAP_ERASE as precautionary to avoid hard brick
1.0-pre
V(R) I/O scheduler Added
SIO I/O scheduler Added
Zram sources backported from 3.0 resolved compile issue
Alpha (First public download)
Overclock added: Min Freq: 216 Max Freq: 1504
CPU Governors: Lulzactive, Ondemand, Interactive, Conservative, Userspace, Performance, Powersave
IO Schedulers: Noop, Deadline, CFQ, BFQ
Autogroup or Default Kernel available
Patch for Tiny HAL - resolves popping in audio on JB/ICS
Click to expand...
Click to collapse
If you would like to help out with the continuance of kernel development for your Acer Iconia Tab A100 please consider a small donation to help out with bills, baby formula, wipes, diapers, etc. All donations are very appreciated by my family and I! Thanks
​

This kernel is pretty slick, tested a previous version of it, nothing but good things to say of it, hit thanks on your way to flash this.
Tapatalked from my Galaxy S II.

pio_masaki said:
This kernel is pretty slick, tested a previous version of it, nothing but good things to say of it, hit thanks on your way to flash this.
Tapatalked from my Galaxy S II.
Click to expand...
Click to collapse
Same to all your projects pio_masaki! I always hit the "thanks" for you too buddy! BTW, the kernel you have been testing is the equivalent in the downloads section to the "default", you may want to take a stab at the "autogroup" kernel. I have been testing it with great responsiveness. Also added in SIO and tweaked some timings/voltages in the new downloads. Glad to hear you have had good results thus far

linuxsociety said:
Same to all your projects pio_masaki! I always hit the "thanks" for you too buddy! BTW, the kernel you have been testing is the equivalent in the downloads section to the "default", you may want to take a stab at the "autogroup" kernel. I have been testing it with great responsiveness. Also added in SIO and tweaked some timings/voltages in the new downloads. Glad to hear you have had good results thus far
Click to expand...
Click to collapse
Yup I have every intention of banging that new kernel, waiting a minute while I build yet another CM10 for further testing of the autobrightness levels, added a couple more slots into the array, should have it nailed this time.

pio_masaki said:
Yup I have every intention of banging that new kernel, waiting a minute while I build yet another CM10 for further testing of the autobrightness levels, added a couple more slots into the array, should have it nailed this time.
Click to expand...
Click to collapse
Was really curious to see how BFS performed with Jelly Bean /ICS either one, but i've not had any luck with getting BFS to run stable so I removed it from my kernel tree for the time being. If i can get a full port to the grouper tree with all our device sources, I'm pretty confident I can get a newer revision of BFS to working. From most of my experience with other devices and other x86 systems though, the BFS doesn't out perform Autogroup anyway, but its mostly just curiosity that makes me want to go through all the trouble of getting it working with tegra2. On another note, I'm not sure why but regardless of the kernel or configuration I use Jelly Bean seems to have a weaker performance in any benchmark than the same kernel/configuration used in ICS. I'm yet to figure out where the bottleneck is in JB. (testing with linpack, quadrant, antutu benchmark all produce lower scores than with ICS) The thing that is most important to me is the actual user experience and feel that you get and not some benchmark score.. I can say that JB is very smooth and the scores don't mean nothing if you don't look at them!!

Awesome kernel! Seems stable enough, audio also works
sent from my A1/500 Iconia slab of awsomeness

Every time I download the zip file and try to flash it I get a Failed message. I am using TWRP to flash with.

tidewaterns said:
Every time I download the zip file and try to flash it I get a Failed message. I am using TWRP to flash with.
Click to expand...
Click to collapse
download it again

tidewaterns said:
Every time I download the zip file and try to flash it I get a Failed message. I am using TWRP to flash with.
Click to expand...
Click to collapse
In TWRP do you have MD5 verification enabled? If you do then it should work after you turn that off, the zip file is signed with SignAPK.jar so it should work without any issues. I have personally flashed both to my device using TWRP. If you are using adb through TWRP to push the .zip then you shouldn't be pushing it to /sdcard/ in recovery the proper location for internal storage is /data/media/ so if you have pushed it to /sdcard/ in adb then it will exist in a directory where permissions aren't accurate for the loader. Push with adb to /data/media if in recovery, or push to /sdcard/ if pushing with adb while your tablet is booted to Android OS.
If for some reason the .zip files are corrupted on github for other users please let me know and I will recompile, recompress, resign, and reupload.. Thanks

Fransis88 said:
download it again
Click to expand...
Click to collapse
Francis88: I assume the zip files flashed ok for you? Anyone else having problems?

Mine works fine. Flashed with twrp. Of course, I cleared dalvik before I flashed. The rebooted. Works fine.
sent from my A1/500 Iconia slab of awsomeness

I really don't like flashing from internal, and twrp, at least 2.1.1, says sdcard for whatever one is mounted. Keep that in mind when flashing in twrp. I think 2.2 says sdc instead. Also in jellybean it goes to storage/sdcard0 for internal sdcard1 for external sdcards. You can probably still use the old paths but those are the correct paths for jellybean.
Tapatalked from my Galaxy S II.

I copy everything to my SD card. You can flash from it.
Actually, I've only ever flashed from internal once, it was jb gapps
sent from my A1/500 Iconia slab of awsomeness

das_webos_transformer said:
I copy everything to my SD card. You can flash from it.
Actually, I've only ever flashed from internal once, it was jb gapps
sent from my A1/500 Iconia slab of awsomeness
Click to expand...
Click to collapse
Well I'm not saying you can't its more of a personal call to never store stuff I don't want to lose on internal, especially since it gets wiped when I wipe for testing.
Tapatalked from my Galaxy S II.

I think there may be some confusion when I say "internal" and "/sdcard" Assuming that one doesn't have an external sdcard, then /sdcard would be internal storage while in android OS (meaning ICS, Gingerbread, Honeycomb, Jellybean, etc), and that same path would be /data/media while in TWRP/CWM (Recovery mode). I've never had my external sdcard (removable one) to mount at /sdcard or /mnt/sdcard on my a100 so I assumed it was safe to recommend flashing from there as I have never had any issues with it, but like I mentioned in the previous post, /sdcard is only your internal user storage while booted into Android OS and not while in Recovery, while in Recovery the symlink doesn't exist so the right location is /data/media..
If anyone isn't familiar with the hierarchical file system and the mount points for their device, then I strongly encourage them NOT to use experimental ROMS, Kernels, etc. including this one. The kernel is a very critical part of the software on the device, and without a working kernel, you WILL NOT have a working device. So if something happens that you don't have the original kernel backed up and a way to flash it, or a full backup that you can access from recovery, then testing experimental kernels is like playing with fire..
A soft brick is highly possible if you obtain: A) the wrong kernel for your device B) a corrupted download kernel -OR - C) An experimental kernel that may be misconfigured or contain "bad" source code. << All of these can be repaired easily from recovery if you have a known good version to restore from, but if you have trouble flashing one kernel that is known to flash successfully for others, then what happens when you get the Fail message when trying to restore your working kernel/system??
Hope nobody takes this the wrong way, just trying to look out for people before things go bad. Good luck..

pio_masaki said:
Well I'm not saying you can't its more of a personal call to never store stuff I don't want to lose on internal, especially since it gets wiped when I wipe for testing.
Tapatalked from my Galaxy S II.
Click to expand...
Click to collapse
I have never had to wipe the internal user storage AKA /data/media & /sdcard while testing any build, Of course it would be very easy to mess things up and accidentally wipe it from recovery, but I've never ran into any issues needing my internal SD wiped (so far).
Pio_masaki you could be talking about something else by internal storage though? Like /system or / or somewhere other than /data/media, /mnt/sdcard[0-] ?

linuxsociety said:
I have never had to wipe the internal user storage AKA /data/media & /sdcard while testing any build, Of course it would be very easy to mess things up and accidentally wipe it from recovery, but I've never ran into any issues needing my internal SD wiped (so far).
Pio_masaki you could be talking about something else by internal storage though? Like /system or / or somewhere other than /data/media, /mnt/sdcard[0-] ?
Click to expand...
Click to collapse
No I mean internal SD. I fully wipe /data including /data/media. Occasionally I dd zero them all too.
Tapatalked from my Galaxy S II.

linuxsociety said:
In TWRP do you have MD5 verification enabled? If you do then it should work after you turn that off, the zip file is signed with SignAPK.jar so it should work without any issues. I have personally flashed both to my device using TWRP. If you are using adb through TWRP to push the .zip then you shouldn't be pushing it to /sdcard/ in recovery the proper location for internal storage is /data/media/ so if you have pushed it to /sdcard/ in adb then it will exist in a directory where permissions aren't accurate for the loader. Push with adb to /data/media if in recovery, or push to /sdcard/ if pushing with adb while your tablet is booted to Android OS.
If for some reason the .zip files are corrupted on github for other users please let me know and I will recompile, recompress, resign, and reupload.. Thanks
Click to expand...
Click to collapse
I do not have MD5 verification enabled. Every time I try to flash it gets to the Verifying partition sizes then I get a failed in red on the screen.

tidewaterns said:
I do not have MD5 verification enabled. Every time I try to flash it gets to the Verifying partition sizes then I get a failed in red on the screen.
Click to expand...
Click to collapse
I would redownload, that's usually a cause if everything else is good. Any error message, like status 7?
Tapatalked from my Galaxy S II.

I finally got it installed and I overclocked it to 1504 mhz . Thanks for your help!
Sent from my A100 using xda premium

[KERNEL] Lightly Modified Zenwatch Kernel

This is a (lightly) modified, based on stock, kernel for the 1st gen Asus Zenwatch; repacked from the stock boot.img (by replacing zImage).
See the changelog below for changes from stock and between versions.
NOTE: This kernel is only for the MEC23S (Android Wear 1.4) build, and is still experimental. I have not tested this on the newest build (and it's likely not compatible), but I'll probably do a final build for the latest version as a sendoff.
To download the kernel, go to the Downloads tab at the top of the OP, and download the file (version)-ondemand.img.
I can provide a mirror if the DevDB download doesn't work for some people.
I'm not entirely sure what else I can test/add to this kernel (without needing root, since it's not flawless on this watch), so if anyone has some suggestions, I can try adding those things to the kernel, so for now, new builds will come as there are new features to add.
If you want to try out this kernel, I recommend that you try just booting it through fastboot first:
Code:
fastboot boot (version)-ondemand.img
If something goes wrong, I am also including the stock kernel (boot_original.img in the downloads tab).
If you decide that you want to flash the kernel, you need to unlock your bootloader first (it will wipe all your data, so backup first), then run this command:
Code:
fastboot flash boot (version)-ondemand.img
To check if the custom kernel actually loaded, run an ADB shell, and type:
Code:
uname -a
The kernel version number should have "(version)-ondemand" right after it.
Notes:
For now, I am mainly planning to test out features that I can add or modify on the kernel without compromising stability or battery life, and I will also be testing each build on my own Zenwatch.
If there is enough interest, I can try and add custom CPU governors or set a different included one as default, but since there's no way to change the governor without root, I'll need to upload separate kernel images for each new default governor.
Vibration intensity is pretty easy to increase, so if 3100 mV still feels a bit weak, I can try bumping it up a bit more, like to 3150 or 3200 mV (I don't want to risk raising it too much and damage hardware).
Building the kernel doesn't take too long, so if there are any bugs or features to be added, I can compile and upload a new kernel pretty quickly.
XDA:DevDB Information
Custom ZW Kernel, Kernel for the Asus ZenWatch
Contributors
itechnoguy
Source Code: https://github.com/iTechnoguy/zwkernel
Kernel Special Features:
Version Information
Status: Testing
Current Beta Version: v2
Beta Release Date: 2016-04-10
Created 2016-03-30
Last Updated 2016-04-10

Changelog:
v2 - 04-10-2016
Changes:
I/O Scheduler no-op added (and made default; stock kernel default was CFQ)
Compiled with Linaro GCC 4.9
Note: So far, ondemand is one of the only CPU governors other than performance that don't cause the Zenwatch to bootloop (including 3rd party governors), so for now, ondemand will remain the default (a couple of other governors, like interactive remain compiled in, but bootloop when made default)
v1 - 03-29-2016
Changes from stock kernel:
Uses the ondemand governor by default (instead of performance)
Slightly increased vibration strength (measured in mV; increased from 3000 to 3100 mV)

To-Do/Look into:
Implementing CPU (and IO schedulers?) governors without having to create a separate kernel image for each governor, meaning needing systemless root to avoid needing to reflash the system partition before an OTA
Possibly add init.d support so that scripts can change the governor on boot (without needing an app, which would probably be hard to use on the ZW's small screen)
Kernel-level support for disabling the default low-bit ambient mode (since build.prop edits don't work)

If you have the opportunity when you are looking around in there see if there is anything in the kernel that forces low bit ambient. I have tried changing the build.prop to turn it off as you would on other devices and it has not been successful.

hecksagon said:
If you have the opportunity when you are looking around in there see if there is anything in the kernel that forces low bit ambient. I have tried changing the build.prop to turn it off as you would on other devices and it has not been successful.
Click to expand...
Click to collapse
I'll look into it, but from what it looks like so far, it seems that low bit ambient mode isn't a kernel-level feature. I'll keep digging around though, and see if there is something within the kernel that controls it.

Maybe ability to disable 2 cores to increase battery life?
Sent from my SM-G925F using Tapatalk

macia10 said:
Maybe ability to disable 2 cores to increase battery life?
Click to expand...
Click to collapse
I can implement that; it's more of a ramdisk edit (as seen in tiny4579's discontinued kernel for this same watch).
I guess there's also the parameter CONFIG_NR_CPUS to set the max number of CPU cores (like setting maxcpus in the ramdisk), but on a kernel level. I'll take a look and test it out.

I've been testing a couple of builds with reduced cores, and I've been running into issues. Any dual core setup I've tried so far (either by limiting the CPUs within the kernel or just the ramdisk) seems to be unstable, causing the watch to reboot within a couple of minutes of finishing boot. I guess the ramdisk editing worked on a previous kernel/build of Android Wear, but it's causing some sort of instability on Marshmallow now.
I also tested with tri-core builds, but none of those even made it past the boot logo.

I have flashed the kernel and will run it for a few days to see if there is any battery improvment. As far as CPU goes maybe using a hotplugging governor is the way to go? Not sure if there are any modern ones out there but I recall back in the day before hotplugging was done with a stand alone module.

hecksagon said:
I have flashed the kernel and will run it for a few days to see if there is any battery improvment. As far as CPU goes maybe using a hotplugging governor is the way to go? Not sure if there are any modern ones out there but I recall back in the day before hotplugging was done with a stand alone module.
Click to expand...
Click to collapse
I've been watching the CPU usage using AIDA64, and it seems like most of the cores are inactive most of the time, so I think the kernel might already be using Qualcomm's built in hotplug driver.
I might have to add in a separate hotplugging governor, which shouldn't be too much of a problem, since the default CPU governors were just performance, ondemand, userspace, and conservative (interactive is also available, which I may make default next if a hotplug governor doesn't work well).
In terms of battery life, I noticed that ondemand does help increase idle/screen-off battery time, but screen-on time seems to be about the same as when using performance.

get about an extra day with ambient off and tap to wake. I'm at the end of day 2 with ~30% left.
I recall back when we had root that previous versions of the official software ran only single core on performance governor. I think the CPU was limited to like 800 or 1000 MHz too.

Yeah, the default max clock speed is set to roughly 787 MHz, and the minimum (in this kernel version) was at 300 MHz.
I think I may make the next build with interactive instead of ondemand, to see if interactive offers any better battery life, since hotplug governors basically refuse to compile with a newer kernel. I'm also considering making the new default minimum clock speed to 250 MHz (or lower, if it doesn't get unstable).

New build is up (v2), available on the DevDB Downloads tab (full name: v2-ondemand.img). See the second post for changes.

I just realized that my watch updated to Android Wear build MWD48B by itself, which also brings a new kernel (Asus posted the new sources a few days ago). I don't know if there's still interest in a modified kernel, but I can try building a new kernel with the updated sources (which may take a bit since I don't have access to my normal build system).

itechnoguy said:
I just realized that my watch updated to Android Wear build MWD48B by itself, which also brings a new kernel (Asus posted the new sources a few days ago). I don't know if there's still interest in a modified kernel, but I can try building a new kernel with the updated sources (which may take a bit since I don't have access to my normal build system).
Click to expand...
Click to collapse
col you have latest build already.
Partners watch has not recieved the update... But she has twrp and the OPs Kernel flashed so may be thats the reason..
Could someone confirm if going back to stock recovery on kernel will allow the update and proved instructions and downloads to restore them

lohtse said:
col you have latest build already.
Partners watch has not recieved the update... But she has twrp and the OPs Kernel flashed so may be thats the reason..
Could someone confirm if going back to stock recovery on kernel will allow the update and proved instructions and downloads to restore them
Click to expand...
Click to collapse
You'll have to restore the stock recovery to install the OTA update (I made a backup of the stock recovery from the last update here: https://drive.google.com/open?id=0B6eYQrCg9u-bUTA2d3dRdEZBbXM).
In terms of having the custom kernel flashed, I don't think that affects the update, because my Zenwatch stealth updated without me noticing (even though I had the kernel flashed), since I had the stock recovery installed, not TWRP.

I would love continued effort on a kernel but it doesn't look like this device has much life left here at XDA. If you don't personally believe you will benefit from your effort, don't make it for others.

hecksagon said:
I would love continued effort on a kernel but it doesn't look like this device has much life left here at XDA. If you don't personally believe you will benefit from your effort, don't make it for others.
Click to expand...
Click to collapse
I am considering doing one final kernel for this watch (no ETA, because I've been really busy lately), since it's very likely that Wear 1.5 will be the final update, so the kernel won't need updating past that (if it's stable, of course). It might not see much use, but it'll still be here for people that continue to use this watch past its official support life.

[KERNEL] TonoKrnl for Nexus 7 (2013)

EDIT: I want to remind everyone DO NOT FILE AN UBUNTU BUG REPORT WITH THIS KERNEL INSTALLED, ALWAYS REVERT BACK TO THE STOCK KERNEL IF YOU HAVE AN ISSUE BEFORE FILING
This is my first actual Kernel project, so please be gentle.
This kernel is ONLY for the Nexus 7 (2013) flo. I do not know if it boots on the deb, theoretically it should as I don't have any flo specific options and there are config options for Deb in the Kernel configuration. It should work for those on stable, rc or rc-proposed and may possibly work on devel (not sure) as long as devel has not released a new kernel package (3.4.0-5-flo+)
I have cherry-picked some battery optimizations from bricked-flo, elementalx-flo (4.4 branch) and some additional commits elsewhere in an attempt to not only improve battery-life but also to bring some Android features (DoubleTap2Wake) to Ubuntu Touch.
Currently it has the following:
- ROW I/O scheduler
- Beginnings of OCing (pulled from ElementalX, I think I'm missing some commits to make this relevant though)
- ElementalX's kernel thermal control
- binfmt_misc support
- CD/DVD Filesystem Support for external optical drives (ISO9660/UDF)
- Some Slimbus enhancements
- Battery life optimizations (changing default MHz, etc.)
- Default CPU governor changed from Performance to Interactive (yes, they had it set to Performance, not sure why.)
- Direct Rendering Interface/Direct Rendering Manager (XFree86 + msm_kgsl_drm)
- and more!
You can check my github for the items cherrypicked into it and there is even a current release which has seen my battery drop 4% in the last 30 minutes with the screen fully on (no autolock), WiFi on and Bluetooth.
The name of the kernel is still up for change, TonoKrnl is not going to be it's final name unless everyone likes it.
Repository is at: http://github.com/ShadowEO/TonoKrnl
Releases can be found: https://github.com/ShadowEO/TonoKrnl/releases
Status of Github Repo: It builds. It boots and it runs. I am trying my hardest not to push changes that break building.

Reserved for future use. Currently the status of the kernel's updates can be found on the issue tracker: https://github.com/ShadowEO/TonoKrnl/issues/5
Be patient, if you don't see new releases right away, it's because I'm still in the process of generating them, check back later.
-- Release 1.0.3-UBports (11/19/2017): A lot was done to bring this kernel back into usable state, see below:
Added OTG Charging
Added initscripts for turning on features (Requires the rootfs to be mounted read/write for manual installation, see my latest post #16 I think...)
Created patches to be applied against a clean UBports kernel tree for certain features (right now, only DT2W and USB Charging)
(USB Host Charging was pulled from flar2's ElementalX source code, it is not turned on by default and can be turned on with
Code:
echo 1 > /sys/module/msm_otg/parameters/usbhost_charge_mode
Feature is tested and does work.
Developers:
1.0.3 brought the kernel tree back into a buildable state and also cleaned up some problems with the previous releases. I am in the process of generating a kernel patchset which will be able to be applied to a clean kernel to bring those features to the stock UBports kernel source. After I complete generating the kernel patchset, I will be rebasing the entire kernel project onto a clean tree (As I am absolutely certain that I have problems like unfinished cherry-picks [missing commits] etc.). Be patient regarding these patches, as I am re-adding the features I pulled in originally by hand rather than cherry-picking them as I appear to have fuxxed up somewhere cherry-picking previously.
If you have any random reboots, try:
Code:
echo 1 >/sys/module/msm_watchdog/parameters/runtime_disable
If you still receive random reboots afterwards or if you received them previously but the above command fixes them, please open an issue on my project tracker with a copy of /proc/last_kmsg attached.
Kernel TODO:
Generate kernel patchset and then rebase onto clean kernel tree
Finish Kernel Feature Documentation and publish (these docs will give information on tweaking the changes to the kernel, such as readahead buffer, turning on/off DT2W, turning on/off usbhost charging, etc.)
Move TonoKrnl initscripts into ramdisk, should make them more robust and reliable.
Create ZIP installer for TWRP recoveries (this is needed for automatic installation of kernel modules, since /lib/modules is a read-only, bound mountpoint for the Android LXC container. To fix this, we just have to move /lib/modules out of the Android container.

Allow me two questions:
Which kernel repository is this branched off? Apologies if that is dumb question, my git and kernel knowledge is cursory at best, but I can't seem to figure this out looking through your github repo.
ShadowEO said:
- Direct Rendering Interface/Direct Rendering Manager (XFree86 + msm_kgsl_drm)
Click to expand...
Click to collapse
What's the intention behind this? Does this have anything to do with enabling the freedreno driver for the GPU and would that pave a way to a setup without Mir, but with wayland or X?

doniks said:
Allow me two questions:
Which kernel repository is this branched off? Apologies if that is dumb question, my git and kernel knowledge is cursory at best, but I can't seem to figure this out looking through your github repo.
What's the intention behind this? Does this have anything to do with enabling the freedreno driver for the GPU and would that pave a way to a setup without Mir, but with wayland or X?
Click to expand...
Click to collapse
This started off with the debian source package for linux-image-flo in the Ubuntu archives which is the kernel for our device. The reason you are having trouble with figuring it out is because I started with the base (Ubuntu's 3.4.0-5-flo+), pulled it into an empty git repo and then started cherry-picking features. It was originally going to be for my own personal consumption as I didn't know how well a custom kernel would be received by the touch community (so far, in all the communities I've posted it, you were the only one to ask any questions ), but since I already had a git repo up, figured that I may as well share it. So here I am, an amateur working on the Linux kernel, and learning a lot.
My full intent was to improve the experience (even marginally) on Ubuntu Touch for the Nexus 7 2013, I wanted to bring the mobile kernel features previously found on the desktop that myself or others may find useful (hence binfmt support for qemu-user), there really is no reason for me to turn on DRI/DRM except to allow playing with Wayland and X, yes, that part is correct, and I have tested the freedreno driver with it (Freedreno does get the KGSL DRI device and does start X)
In addition I found some interesting choices in the kernel in terms of battery life, it would seem that the CPU governor used by the default Ubuntu Kernel is Performance, which would explain why the battery dies so fast, I tried to pull in some battery optimizations from a couple other kernels around the Android scene for the device. So far I'm pleased with the results, and recently found that both the original cherry-picking done for DT2W worked along with the code to add fast charging.
I've had to put the project on hold due to work issues, but once I'm able to work on it again, I'm reverting the last 100 changes pulled in that broke my tree and going from there since my original targets in terms of features actually worked. (I'm pretty sure it was some recent changes to the CPU hotplug driver that killed it, I can no longer compile the kernel without mpdecision on, so that's my likely suspect.)

Thanks for your explanations!
ShadowEO said:
This started off with the debian source package for linux-image-flo in the Ubuntu archives which is the kernel for our device.
Click to expand...
Click to collapse
So something like apt source linux-image-flo? And then to build you use the instructions in the package also?
there really is no reason for me to turn on DRI/DRM except to allow playing with Wayland and X, yes, that part is correct, and I have tested the freedreno driver with it (Freedreno does get the KGSL DRI device and does start X)
Click to expand...
Click to collapse
Exciting!
In addition I found some interesting choices in the kernel in terms of battery life, it would seem that the CPU governor used by the default Ubuntu Kernel is Performance, which would explain why the battery dies so fast
Click to expand...
Click to collapse
I'm really only speculating, but my conjecture to previous mentions of odd govenor choices in android kernels was that the actual android power management magic is happening behind the backs of the governors. But, I'm really just babbling. I don't know much of anything about this. You seem to be getting impressive improvements!
I'm reverting the last 100 changes pulled in that broke my tree and going from there since my original targets in terms of features actually worked.
Click to expand...
Click to collapse
So, that means: "If you want to try it now, don't use v1.0.2, but use v1.0.2-alpha for now." Is that about correct?

doniks said:
Thanks for your explanations!
So something like apt source linux-image-flo? And then to build you use the instructions in the package also?
there really is no reason for me to turn on DRI/DRM except to allow playing with Wayland and X, yes, that part is correct, and I have tested the freedreno driver with it (Freedreno does get the KGSL DRI device and does start X) Exciting!
In addition I found some interesting choices in the kernel in terms of battery life, it would seem that the CPU governor used by the default Ubuntu Kernel is Performance, which would explain why the battery dies so fast
I'm really only speculating, but my conjecture to previous mentions of odd govenor choices in android kernels was that the actual android power management magic is happening behind the backs of the governors. But, I'm really just babbling. I don't know much of anything about this. You seem to be getting impressive improvements!
I'm reverting the last 100 changes pulled in that broke my tree and going from there since my original targets in terms of features actually worked. So, that means: "If you want to try it now, don't use v1.0.2, but use v1.0.2-alpha for now." Is that about correct?
Click to expand...
Click to collapse
I removed the problem download, the only ones available are the source tree downloads and the last known good build I had, I have also tested to ensure that the last build up there works as well as it's the one I'm running on my device until I have time to go through the tree again.
As for building, essentially yes, but you have to build the image separately. Due to how Ubuntu currently has the filesystem set up and with Android's boot images, its not feasible to really package it in a traditional sense. Essentially what I did was create a chroot, apt-get source linux-image-flo and then to get a working defconfig I used the config.* files found in Debian.flo and Debian.master, from there was the tree that I used as my base.
Then run make with the following to customize:
Code:
ARCH=arm make menuconfig
ARCH=arm make -j <number of processors>
To build the image, you'll need to grab the boot image from your device and tear it apart using a abootimg them rebuild it with the Ubuntu ramdisk. If you are using MultiROM, you can just drop it in the folder for your ROM.
Edit: As for the weird choice of governors, I noticed during my investigations (via the cpufreq-info package) that while Android is managing the CPUs that are online (I found it's running it's own version of mpdecision behind the scenes inside the LXC container), it's not doing anything to the CPU governor. That's all managed in the kernel right now through CPUFreq it appears and in the stock kernel it's set to performance, as for the reason for it, I'm not sure myself.. The other governors ARE there though, just unused right now.

ShadowEO said:
This kernel is ONLY for the Nexus 7 (2013) flo. I do not know if it boots on the deb, theoretically it should as I don't have any flo specific options and there are config options for Deb in the Kernel configuration.
Click to expand...
Click to collapse
Jup, it does boot on my deb! I've downloaded the .img, put the tablet in bootloader mode and did
fastboot boot TonoKrnl-1.0.2-flo.img
It booted without problems, and so far it's running for about half an hour or so without any problems. Wifi, sound, video, usb mouse, all work fine.

doniks said:
Jup, it does boot on my deb! I've downloaded the .img, put the tablet in bootloader mode and did
fastboot boot TonoKrnl-1.0.2-flo.img
It booted without problems, and so far it's running for about half an hour or so without any problems. Wifi, sound, video, usb mouse, all work fine.
Click to expand...
Click to collapse
Wow, that's great to hear, I wasn't sure but I was definitely curious since I had seen options for both Deb and Flo in the makeconfig page.
If you can script it in (or edit sysfs.conf) to have it write a 1 to /sys/android_touch/doubletap2wake while it's booting, you can have working DT2W and there's quite some others to mess around with under /sys :3 CPU governors are somewhere there too, just don't have it offhand.
Since you are testing it out, have you noticed any changes in the device's normal battery life? The stock kernel seems to drain 1% every 1 1/2 minutes on my Flo, not doubting that the power optimizations ARE working (I know I'm getting much better life), I'm just wanting to ensure that it's not a placebo effect that I'm experiencing.

ShadowEO said:
If you can script it in (or edit sysfs.conf) to have it write a 1 to /sys/android_touch/doubletap2wake while it's booting, you can have working DT2W
Click to expand...
Click to collapse
After
Code:
echo 1 | sudo tee /sys/android_touch/doubletap2wake
I can indeed (sometimes) wake it with double tapping. I have since quite a while (with the standard kernel) the situation that its really hard to wake up. I have to press the powerbutton many many times. Feels like it is sleeping really deeply.
Since you are testing it out, have you noticed any changes in the device's normal battery life? The stock kernel seems to drain 1% every 1 1/2 minutes on my Flo, not doubting that the power optimizations ARE working (I know I'm getting much better life), I'm just wanting to ensure that it's not a placebo effect that I'm experiencing.
Click to expand...
Click to collapse
Well, I haven't noticed anything. I might just not be in the best position to judge. I rarely have it unplugged for more than a couple of hours at a time and I don't generally monitor the battery status closely. That being said though, I have very definitely never experienced anything remotely close to 1% per 1.5 min!
If you have a particular test/measurement you'd like to see - let me know.

doniks said:
After
Code:
echo 1 | sudo tee /sys/android_touch/doubletap2wake
I can indeed (sometimes) wake it with double tapping. I have since quite a while (with the standard kernel) the situation that its really hard to wake up. I have to press the powerbutton many many times. Feels like it is sleeping really deeply.
Well, I haven't noticed anything. I might just not be in the best position to judge. I rarely have it unplugged for more than a couple of hours at a time and I don't generally monitor the battery status closely. That being said though, I have very definitely never experienced anything remotely close to 1% per 1.5 min!
If you have a particular test/measurement you'd like to see - let me know.
Click to expand...
Click to collapse
I may be exaggerating slightly, but normally my tablet goes from 100% to 95% in about 5 minutes while I'm using it after taking it off the charger (in Ubuntu only, may be an rc-proposed thing too). I haven't seen that behavior since changing kernels. I'm gonna see if I can go ahead and start reverting commits today or possibly reset back to the last known good commit.
As for the screen problems, I think there is a bug in the current doubletap2wake driver, if you look at dmesg after using DT2W for a while, you'll see it being spammed with error messages from the touchscreen driver.
That could possibly be related. Additionally, I think the minimum processor speed defaulted to 384MHz (I didn't touch any processor clock speeds in here) which the Performance governor would never had let the processor hit. So it's likely that the minimum processor speed will need bumped up at least one step there, I get some stuttery behavior on the command line when the screen is off which I hadn't received on the stock kernel.
Edit (07/01/16): I'm not sure what else I can really bring to the table here, mpdecision running in the android LXC container defeats any meaningful changes to the clock speed. I also noticed mention that you shouldn't have two hotplugging daemons running at the same time, effectively that is what the new developments would've brought in. I think my best option to continue this would be to wait until the Xenial transition and see if they make any changes for me to update on.
I'm also quite a novice, so besides cherry picking commits, I'm not sure what else I can do.

ShadowEO, is bluetooth working on your device? With your kernel or with the one from Canonical?
I can't seem to get anything at all to show up on my deb.

I am so embarrassed that I didn't check this thread in so long. Ya, Bluetooth still works on my device with either kernel. Sometimes it doesn't seem to like to power on, so if you are having trouble, try this.
Open Terminal,
do sudo bluetoothctl and see if Nexus 7 (2013) shows up in there. If it does, type power on and hit enter. You should see the bluetooth indicator show up in the status bar. If it doesn't, exit bluetoothctl and do these from a root prompt:
start bluetooth-touch
start bluetooth-touch-flo
Sometimes the commands may take a little bit of time (no idea why honestly), but after those, you should see bluetooth start. At that point, if you still don't, fully power the device down and try again.
For whatever reason, the bluetooth scripts fail every so often, haven't been able to look into it much due to personal things IRL taking up all my time the last few months.

It's been a long while since I touched this project, but I have finally cleaned up the kernel source tree and ensured that it builds properly!
Two features that must remain disabled however are GOVERNOR_ELEMENTALX and MSM_SLEEPER as they are currently broken and do not function as of right now. The defconfig for flo also has sane defaults for the UBports Ubuntu Touch distribution (installable via the UBports installer application) and has DT2W enabled (but not turned on, that requires some extra work) by default.
You should also no longer need to disable the MSM watchdog using the instructions in the OP, running the kernel now and haven't experienced near as many random reboots I used to with the previous version! (I wonder if that was a UTouch problem, because I DO get random reboots sometimes using certain apps, but they're very rare... Then again, I'm not sure if UBports made any initramfs changes for the Flo when they added it to their system-image server, which they may have, since it's in the ubports-touch/15.04 distribution instead of their ubuntu-touch mirror for older, no-longer supported devices)
To turn on DT2W, you must follow the instructions on the github page for the 1.0.2 release.
NOTE: I highly recommend building the kernel from source rather than downloading a release! I have yet to add the current stable release to the github releases page! I also have a zip file with some helper scripts and configuration that can be installed into the UBports rootfs to turn DT2W and Kernel Samepage Merging on at startup. In case that's useful, I'm adding the zip to this post. To install, simply remount your root as read/write, extract the ZIP to / and then "chmod +x /sbin/tonokrnl-init" and reboot. Upon reaching the lightdm greeter, you should be able to shut the screen off, then double tap it to wake.
The files contained in the zip are:
/sbin/tonokrnl-init - Helper Script to start DT2W and KSM
/etc/sudoers/tonokrnl - Allows the user-session upstart config to run the helper script, which requires root.
/home/phablet/.config/upstart/tonokrnl.conf - Upstart configuration to run /sbin/tonokrnl-init using sudo (requires the sudoers file)
Off-topic slightly: The reason this project got set aside, was due to my IRL work, and because I had stopped using Ubuntu Touch and was testing out other ways of getting Linux onto the N7 'flo'. I messed with the Sailfish distribution found in the Nexus 7 2013 forum, then went to postmarketOS and messed with that (it's cool, but rather bare, not enough desktop packages to make it useful [no osk, etc]), then attempted to boot a debian distribution with the Linaro mainline kernel from John Stultz (couldn't even get X11 to start, the system did boot though! Perhaps mesa/libdrm needed recompiling with freedreno support...) and then finally came back to Ubuntu Touch via UBports!
Back on Topic, if you decide to use this kernel (either by building it yourself, or using the new UBports-1.0.3 release that will go up soon!) and install the attached helper scripts (or even find your own solution to on-boot DT2W, KSM, and the Interactive governor) please let me know your experiences! I noticed after turning KSM on that the web browser didn't crash as much, but I'm not sure if it's a placebo effect or not.
(I wonder if @flar2 has a 3.4.0 patchset I can apply rather than attempting to cherry-pick ElementalX into the kernel... That would be amazing to have ElementalX's additions to the kernel under Ubuntu Touch. [Please don't be angry I used a mention flar, I just wanted to ask if you had a patchset for the flo's kernel [version 3.4.0])