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....

[Q] Google goggles ipv6

Hi all,
I have Fat Free Froyo installed with the latest 14th Jan 2011 kernel voguimg-240x320-2.6.32-froyo-14-01-11_14.nbh edited to froyo & panel type 2 from t029000.massey.ac.nz but Google Goggles needs ipv6 support.
Is this a kernel problem or a problem with the build itself? I am experienced in linux, so can modprobe or insmod the ipv6.ko but I don't know where to get it from
Any help would be appreciated!

(message for kernel's developers) take this man! he can dev ipv6!

Jumping the gun there a bit
I triage bugs and work on stuff for Ubuntu. Have also ported a few linux bits to ppc64 (PlayStation 3).
I'm pinching the ipv6.ko from slayhers latest kernel build, hopefully that will work insmod-ding or modprobing it into the kernel thru the terminal on the Kaiser itself.
So, fingers crossed, this may be solved in 5 minutes!!

Didn't work, it must be compiled for a different platform...
Anyone have or know where to get a kernel for the Kaiser with ipv6 support, or failing that the correctly built ipv6.ko for the Kaiser so that it can be insmodded?

Getting it compiled in the kernel is the easy bit, although it does use up a lot of space which is limited in the kaiser's kernel so a little tweaking is needed. Getting it to work with the Kaiser's modem and the builds we currently use is a different matter unfortunately. It will take a bit of modding for it to work but it's more then achievable with a bit of free time. Wish i could buy that stuff!!If i get a chance i will get you the ipv6 module for the kaiser's kernel or a kernel with support for it so you can have a play.

I definitely look forward to it! If I knew how and what to modify I'd do it myself, but I thought arch-specific kernels had to be compiled on the arch itself? If that's the case, I can see how free time would be needed, it'd take hours or days to compile the linux kernel at 400MHz
I have compiled kernels before so if/when I learn how to do it myself, I could start to use my own git repo for more recent daily builds or something.
I'm also thinking about starting working on some *buntu stuff (I know Ubuntu is there for the Kaiser, but soem tweaks would help if I get a chance.)

Hmm, a little Googling goes a long way http://www.androidonhtc.com/wiki/Get_Involved << was hard to find that,so hopefully I can add ipv6 somewhere in the 'make menuconfig' options for the kernel.
Are the standard kernel options used by "make vogue_defconfig" ok to use, i.e. will it build a normal useable kernel so that everything works?

xteejx said:
Hmm, a little Googling goes a long way http://www.androidonhtc.com/wiki/Get_Involved << was hard to find that,so hopefully I can add ipv6 somewhere in the 'make menuconfig' options for the kernel.
Are the standard kernel options used by "make vogue_defconfig" ok to use, i.e. will it build a normal useable kernel so that everything works?
Click to expand...
Click to collapse
Yes, that is th correct make file to use. I have built the kernel with IPV6 support, haven't tested it but have attached the module to the post for you to try

Brilliant! I'll try it sometime within the next couple of days, although I might myself be working on a blazing fast kernel specifically for the HTC Kaiser, and it is SERIOUSLY!!!! fast, even at 400MHz I can notice a massive increase in speed with the exact same build, but I haven't economised too much.
I can see the the options for ipv6 in the ncurses menuconfig, so I guess it's just a case of enabling it and building the zImage right?
I seem to be having the old problem with the wifi though, and I know it's kernel related, but there are only patches for it, i.e. the wlan.ko, but can't see how to implement it myself so it's an all-in-one solution
When I get the hang of the Kaiser hardware properly, I might just push through a newer kernel from the armlinux site so watch this space

xteejx said:
I might myself be working on a blazing fast kernel specifically for the HTC Kaiser, and it is SERIOUSLY!!!! fast, even at 400MHz I can notice a massive increase in speed with the exact same build
Click to expand...
Click to collapse
How have you managed that??? What have you done?

I have no idea how it happened, perhaps the other devs add a load of useless options, but all I did was follow the instructions at that link above and compiled a zImage from the 2.6.32 arm branch, using the 2010 arm tools. Used NBHeditor to edit it for Kaiser, panel 2, froyo, flashed it and bang (not literally thank god).
I can't answer any better than that. I used the default options (for now at least) that the vogue build script uses for the kernel, but bluetooth, camera and gps work. No internet connection as yet either through the network or wifi, dumno what I've missed there, and no ipv6 (but can add that easily enough). Wifi doesn't work either, but I'm working on it, although that MAY be the reason why it's so fast...maybe it's missing a few options...still unsure at this point.
I notice that although this is an open community, and people attach NBHs, there are no changelogs or anything showing what the people have done with the kernel to implement some options, so it's kinda holding me back at the minute.

xteejx said:
I notice that although this is an open community, and people attach NBHs, there are no changelogs or anything showing what the people have done with the kernel to implement some options, so it's kinda holding me back at the minute.
Click to expand...
Click to collapse
That isn't true, all tested changes are pushed to git, you can see what has been changed and how from here: http://androidhtc.git.sourceforge.n....git;a=shortlog;h=refs/heads/htc-vogue-2.6.32

*facepalm!*
Didn't see that, will bookmark it and keep an eye on it, perhaps work with it. Thanks for the link

the androidhtc.com site is not related directly to the develop project because no developer is connected to it. Also the git repository it not hosted in linux to go but on sourceforge (so download the correct git). That site is very outdated.
wifi works if you use the correct branch (on sourceforge) and modules.

Am I right in thinking that http://androidhtc.git.sourceforge.n...7c0bf5edc4f5c6d64ce4df29254e8332ce26b;hb=HEAD is the prebuilt kernels and nbhs from the source at http://androidhtc.git.sourceforge.n...og;h=62f075ddd13f378fd252be94c77e4f93d12584fb ??
I think I'm looking at the right tree now.
Flashing the latest NBH: VOGUIMG-320-FROYO-01-16-11.NBH still gives me the wifi error. Do I need to manually add the wlan.ko to it or ??
I could've sworn that an NBH I flashed before had all that in the NBH and it worked fine.

Ok, got it back to how I had it:
Flashed latest.NBH from http://androidhtc.git.sourceforge.n...7c0bf5edc4f5c6d64ce4df29254e8332ce26b;hb=HEAD and dropped androidupdate.tgz to the /andboot folder of the SD card, installed update thru the boot menu and done.
So in reality there's nothing stopping me grabbing the same kernel source, building it and adding ipv6 support in the ncurses kernel config menu and making an NBH from it and flashing that over, and then doing the androidupdate.tgz, although I think with HTCFlasherGUI you can flash a zImage directly right??

Is there something wrong with the git at http://androidhtc.git.sourceforge.net/git/gitweb.cgi?p=androidhtc/kernel.git;a=summary I can't get access, it's showing old stuff. It looks closed since git clone rejects me

xteejx said:
Is there something wrong with the git at http://androidhtc.git.sourceforge.net/git/gitweb.cgi?p=androidhtc/kernel.git;a=summary I can't get access, it's showing old stuff. It looks closed since git clone rejects me
Click to expand...
Click to collapse
No, nothing wrong with it. Just do:
git clone git://androidhtc.git.sourceforge.net/androidhtc/kernel.git
You then need to set it to the correct branch using 'git checkout -b <branch you want> '
It's the 2.6.32 branch you are interested in, you can find out exactly what it's called using 'git branch -a' which will list the available branches.

Cool. Knew something went wrong somewhere, had to be me lol!
I added that ipv6.ko to the NAND via a androidupdate.tgz (only way I could do it), and it didn't work, something about incorrect module format (or something like that).
Are there any prebuilt kernels or NBHs for the Kaiser that include ipv6? Either as a module that I can insmod it in the terminal or built-in?
I hate being upstaged by people that can use Goggles without any problems.
I know slayher's kernels have ipv6, but I flashed the new stock one from http://forum.cyanogenmod.com/topic/4434-froyo-kernels-by-slayher/ and it didn't work. I mean the kernel did, but Goggles didn't - couldn't insmod it either - same invalid module format as the ipv6.ko scooter did for me

Also the git clone didn't work:
Initialized empty Git repository in /home/name/android-git/kernel/.git/
fatal: The remote end hung up unexpectedly

Krazy-Killa's Kernel Release - RLS 5.9.2.2 Released!

CPUFreq Successfully Installed and Running​
Please visit my website for additional information
After receiving alot of positive results from my Kernel and several releases later. We have arrived at RLS 5.9, a prototype build incorporating CPUFreq for CPU Scaling and Idle control, and a modified version of Power Management. We are at a release stage of this Alpha build, and approaching Beta, where it is as follows:
Each build that is released that has an update to CPUFreq will have an update to the first subversion in the build version (eg. RLS5.9.1.0)
Each build that is released that has an update to Power Management will have an update to the second subversion in the build version (eg. RLS 5.9.0.1)
And of course each upgrade to a specific subsystem of the Kernel will up the version number of that specific subversion.
Current Release: RLS 5.9.2.2​
RLS 5.9.2.2 will mark the beginning of the Beta stage out of Alpha stage. This release is showing far more promising results than my initial CPUFreq release.
I just want to personally thank all who have been supporting me and reporting any and all bugs that have been coming in, as I have been squashing them left and right in preparation to improve our Kernel for our phones to make them more feasible for everyday use.
Currently Being Tested:
Power Management - Reverted some old changes to the power management code, switched too Apps Sleep. Made some minor changes to the original pm.c source code and results are promising. Running VanijlEclair RLS11, and in rare cases the phone still crashes while sleeping, which I believe is related to the phone hiccuping when going to sleep, which in theory could completely blow up the timer that Apps Sleep uses for sleeping. I will investigate this part further, but so far, RLS 5.9.2.2 is much more stable than my previous release.
CPUFreq - No changes to the source code, still attempting to modify permissions so Android can modify the files that are required.
HAReT Users - Thanks in large part to V3rt!g(o) HAReT users can now boot the Kernel. I have made a slight modification to the default.txt file provided in the RLS 5.9 HAReT archive that uses Apps Sleep instead of Power Collapse. From what was reported, the Kernel takes about 2 minutes to initialize from WinMo, but after about 1min30sec to 2min, Android should begin loading.
Radio ROM - Currently Testing Radio 1.71.09.01, and so far it seems very stable and provides better battery usage.
Current Release (RLS5.9.2.2):
Kernel - HTC Polaris support re-introduced.
CPUFreq - Has been installed, and working inside the Kernel only. Android does not recognize CPUFreq correctly.
Processor - MSM-7201 processor increased from 384MHz to 528MHz
Stability - Has been improved further. Phone correctly sleeps and wakes properly. Still occasional crash occurs, but is random. Could go a full day without a crash, or could crash every 4hrs. Issue might be related to how much the CPU is being utilized at the time of wake up.
Power Management - Power Management restored to near WinMo states, still not as good as RLS5.7, but within range. Phone will last a full day of occasional use, and about 80% of the day on moderate use.
Initrd - New BootLogo has been made, and inserted into initrd. Unfortunately boot menu is not accessible. Made install scripts to compensate.
YAFFS2 - Exclusively does ECC checking on it's own without any help from the NAND driver. This should help with data corruption, but is not a permanent solution.
YAFFS2 - Disabled Forced erase chunk checking, slight increase in response time and decrease in read-time.
MTD - Disabled Verify NAND Page Writes
MTD - Disabled GPIO NAND Driver
EXT - EXT2 is currently disabled inside the Kernel. EXT4 has been fully enabled, aside from journaling, and is fully supported in the kernel and install scripts.
System - Switched from DG (High Resolution) Timer, to GP (Low Resolution) Timer.
System - Fully disabled High Resolution Timer -- Provided a decrease in kernel size without loss of performance.
sysfs - Enabled configfs. This will unavoidably increase RAM usage, but allow easier access to sysfs.
MSM - Performance Counter Driver enabled.
FrameBuffer Driver - Decreased fake-vsync delay from 10 to 5. Less times snow effect appears.
Known Issues:
Internal CPUFreq coding is unable to scale the processor, but the hacked msm_cpufreq_* functions are able to control the processor speeds. This will explain why CPUTuner and other Android software is reporting the CPU running at max speed. Will continue to investigate and work out problems with the coding.
JIT Compiler causes issues with framework.acore. Avoid using if possible.
CompCache not the cause of untracked PID errors -- Still investigating cause, though now understanding that it is related to data corruption.
Possibly depending on Radio, GPS takes quite awhile to acquire if not at all. -- Will investigate by flashing an older/newer radio.
Standby code not fully working due to being incompatible with clock code changes. Attempting to re-write power management code to be better compatible with the new clocks code.
CPUFreq Specifics:
Governors - Currently CPUFreq supports the following governors and can be changed while in Android using the Terminal: ondemand, conservative, powersave, performance. Userspace is currently disabled inside the Kernel.
Frequencies - Baseline frequencies the CPU will scale to but not limited too are: 81920 (82MHz), 122880 (123MHz), 245760 (246MHz), 384000 (384MHz). These are just placeholders to control where the CPU needs to scale too base on usage, it will go between lets say 82MHz and 123MHz or use one of the two.
Userspace - Until I can verify CPUFreq is fully operational without any issues, I will not enable Userspace Governor at this time.
Kernel Modules
File Attached to this Post, see below.​
This Kernel has been tested with the AT&T Tilt variant of the Kaiser. Using it on any other Kaiser would in theory produce the same results, but due to minor changes in the hardware of each variant of the Kaiser, I'm still going to stress caution when using this Kernel with any other variant of the Kaiser
Things to note about EXT4: This file system will increase read/write cycles to your SD Card. Use with caution as it will decrease the life of your SD Card. Though since Journaling is disabled, read/write cycles will have decreased, but they are still higher than what they would be if EXT2 was used. If you do not feel comfortable having EXT4 on your SD Card, do not use this Kernel as there is no way to use EXT2. You have been warned.
Things to take note with this Kernel: Do not enable JIT compiler under Settings, as this has produced constant FCs with the acore framework. It is recommended that you enable CompCache and set it to the default 18%, as this provides a significant performance boost, and decreases Home screen closures while running other apps.
USE THIS KERNEL AT YOUR OWN RISK. I TAKE NO RESPONSIBILITY FOR ANY DAMAGES DONE TO YOUR PHONE WHILE USING THIS KERNEL.​

Woohoo ! First Post!
Thank you Krazy-Killa! Will definitely try this now will post after testing!

I am liking what I am seeing. Thanks for putting the effort into creating this. I'm just curious about one thing, you said that Scoot's CM7 RLS1 build has the modules for this kernel included. Is there a separate download of the modules for anyone that might not be using this build?

Hello Krazy-Killa,
Appreciate your effort !
I just installed it on my TYTN II and so far going well -edited .ngh to change the key mapping to normal.
3G works fine. yet to see BT,WiFi &GPS and overall otherwise.
I have tried Scoot's CM7 RLS1 build 2 days ago.is there any major changes you did - i feel some audio notification alerts changed w. r. t. Scoots.
how can i use those audio files if reqd-i mean can copy&dump to a specific folder and repack.
but its not really matter..
At the moment 'push' works fine and eager to see any 'server connection' problem will occur later with the email client.
i have radio 1.70.19.09
Thanks once again for the post.
Cheers !

cerebralgenius said:
I am liking what I am seeing. Thanks for putting the effort into creating this. I'm just curious about one thing, you said that Scoot's CM7 RLS1 build has the modules for this kernel included. Is there a separate download of the modules for anyone that might not be using this build?
Click to expand...
Click to collapse
I will release the modules as a seperate androidupdate file this evening.
@chandra_100,
All my testing shows BT, WiFi, and GPS working. This Scoots CM7 build I released is just repackaged with my built modules for easy install.
Sent from my AT&T Tilt using XDA App

“Removed support for HTC Polaris”
That’s too bad，poor Polaris，555555555555555~

The untracked PID errors are related to froyo only (maybe Gingerbread too). And its related to init.rc provided with each build. Not kernel's fault

dark_prince said:
The untracked PID errors are related to froyo only (maybe Gingerbread too). And its related to init.rc provided with each build. Not kernel's fault
Click to expand...
Click to collapse
Interesting... Well, I had a looping untracked PID this morning, had to reinstall, but that's mainly the only problem I'm now having... If I could I would build a new init, but the bootenv isn't updated.

Krazy-Killa said:
Interesting... Well, I had a looping untracked PID this morning, had to reinstall, but that's mainly the only problem I'm now having... If I could I would build a new init, but the bootenv isn't updated.
Click to expand...
Click to collapse
The bootenv is fully up to date The untracked PID's aren't caused by the init.rc, they are caused by corrupt filesystems or files which mean that the paths that sysinit.rc is trying to mount aren't there or it can't change permissions on a file because it is corrupt.

for me kernel can't find data.img

Ive go some kind of problem. Im using fresh froyo and when I installed your modules update than I got hang in boot. Excatly at "adb_open" line. Without update everything is ok except wifi.
Sorry for my poor english

Neo2SHYAlien said:
for me kernel can't find data.img
Click to expand...
Click to collapse
I'll look into it. Though I may know the reason why, so I'll do some more testing, and will release once I have it fixed.
scooter1556 said:
The bootenv is fully up to date The untracked PID's aren't caused by the init.rc, they are caused by corrupt filesystems or files which mean that the paths that sysinit.rc is trying to mount aren't there or it can't change permissions on a file because it is corrupt.
Click to expand...
Click to collapse
I'll update my local bootenv, thanks.

Good release. Slightly slower than Clemsyn's kernel (tested in quadrant), but good stability. One thing drives me crazy - I have to wait 5-10 seconds after pressing power button to wake device

MaRekRM said:
Good release. Slightly slower than Clemsyn's kernel (tested in quadrant), but good stability. One thing drives me crazy - I have to wait 5-10 seconds after pressing power button to wake device
Click to expand...
Click to collapse
That was mentioned in the known issues, don't worry my next release will fix that (currently testing). Plus it'll add full EXT4 support like with clemsyn's kernel but you can format your SD card with the device now as I have updated initrd.
Sent from my AT&T Tilt using XDA App

Flashing
I'll try... flashing right now.
what about ipv6 support?
*EDIT* nevermind, i just saw that ipv6 is implemented.

Cannot restore databackup.img trough install menu...
I think this kernel canot handle the img fs. Mount is failing.
Sent from my CyanogenMod Kaiser/Kaiser using XDA App

It's because of EXT2 support being turned off... I'm currently testing a new kernel that'll be using EXT4. Running into the same problem you are having with img mounting.
I'm working on isolating the issue why img mounting isn't working.. It's possibly an issue with the init scripts. I'll dig more into it and hopefully get it isolated.

Backup FS
Krazy-Killa said:
It's because of EXT2 support being turned off... I'm currently testing a new kernel that'll be using EXT4. Running into the same problem you are having with img mounting.
I'm working on isolating the issue why img mounting isn't working.. It's possibly an issue with the init scripts. I'll dig more into it and hopefully get it isolated.
Click to expand...
Click to collapse
Probably the script that is generating databackup.img still using ext2.

tiagoclc said:
Probably the script that is generating databackup.img still using ext2.
Click to expand...
Click to collapse
Yep, it was exactly that. Just made the necessary changes, and compiled a new kernel. I'll go ahead and throw it out, but for now I'll point out that I haven't tested it so, please let me know the results.
Init itself is already setup to mount all loopback and SDcard partitions as EXT4 where applicable.
Just use atools to configure the kernel to use /system and/or /data on NAND or SDCard.

Why did you remove polaris support? I think that are plenty of polaris users that want to test your kernel
Thanks

[ROM][WIP][kexec] Ubuntu with Freedreno!

I've been working on getting Ubuntu running on my Sprint Galaxy S3 using the same method I used on my Epic 4G - kexec from recovery loading the root filesystem off a partition on an SD card.
What I've done so far:
* Found a kexec loader to boot into a custom kernel, which is required for booting off an SD card, among other things;
* Compiled a custom kernel with KGSL DRM support enabled for Freedreno;
* Built a minimal Ubuntu 13.10 armhf rootfs and compiled the Freedreno DRM/DDX/Mesa Gallium driver with changes to support the Adreno 225 and stub occlusion query (possibility of full dekstop OpenGL 2.1 support!);
* Got X11 working with USB keyboard, touchscreen, and fbdev. Still working on getting the Freedreno DDX to load.
I still get a kernel oops with the camera driver (http://pastebin.com/egZbxsED), but it apparently doesn't affect stability or cause reboots anymore.
Working so far:
* USB Host - only tested with a keyboard, but other input/storage/audio/video devices should also work.
* Framebuffer console - thanks castrwilliam!
* Touchscreen works with X.org fbdev driver and the following added to /usr/share/X11/xorg.conf.d/11-evdev-quirks.conf:
Code:
Section InputClass
Identifier "Touchscreen"
Driver "evdev"
MatchProduct "sec_touchscreen"
EndSection
* Power and volume buttons
Untested:
* Bluetooth - might need firmware
* Sensors - should work just fine
* Home, menu and back buttons should work but probably need mapping
Unlikely to work due to proprietary Android-only blobs:
* Camera
Kernel config changes:
# IMPORTANT: remove the line that says "depends on !MSM_KGSL_DRM" from drivers/gpu/msm/Kconfig:70
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_VT_CONSOLE=y
CONFIG_DRM=y
CONFIG_MSM_KGSL_DRM=y
I may eventually post a pre-built kernel, but if you don't know how to compile a kernel from source, this guide is not for you.
Likewise, if you don't know how to prepare an armhf Ubuntu root filesystem, this guide won't help much.
After building the kernel, copy arch/arm/boot/zImage to your SD card along with the attached zImage.zip (CWM-flashable kexec loader).
It might need modifications (META-INF/com/google/android/updater-script) depending on how you have your card set up.
UPDATE: Unfortunately, this phone hasn't been a good fit for me. I never got very far booting Ubuntu or Freedreno, so I decided to sell it.
For anyone still interested in this project, I believe castrwilliam has the required patches.
When I get my next Snapdragon device (either the new Nexus 7, a Nexus 4, a Galaxy S4, or another phone with Adreno 320 graphics), I will post the Mesa patches for occlusion query support. Sorry I wasn't more helpful with this device.

Added to favourites, I'll see what I can do with it over the weekend
Sent from my SPH-L710 using Tapatalk 4 Beta

Great work. Good luck debugging.
Sent from my SPH-L710 using xda app-developers app

Maybe taking a look at how Motorola worked Ubuntu, in a way, with Webtop that came on the Photon. The Photon has the integrated Ubuntu-based 'Webtop' application from Motorola. The Webtop application is launched when the phone is connnected to the external display through Laptop dock or HD multimedia dock. In Webtop mode, offering similar user interface of typical Ubuntu desktop, the phone can run several applications on external display such as Firefox web browser, SNS clients and 'mobile view' application enabling total access of the Photon and its screen. In September 2011, Motorola released the source code of Webtop application at SourceForge.
I know it's not an app you're trying to use but it may help in finding how to work some of the kinks you have. I hope that helps

Hi, I'm the person maintaining Ubuntu currently for HP Touchpad (http://forum.xda-developers.com/showthread.php?t=2225462) (which also uses an MSM SOC.) It's starting to show its age... I'm trying to get this to where you have it currently on a Verizon S3 / d2vzw (obviously, kexec'ing into a Verizon kernel instead.) Maybe we could collaborate?
Currently I have the KT747 kernel (kexec host support as well as guest) (compiled as a zImage. If you can provide me with access to the patches you have for freedreno and hopefully also an initramfs image (I'm going to mod the HPTP rootfs, so no need there)... I'd love it.

My only modifications to the kernel so far are the ones I mentioned in the OP and three of Rob Clark's Freedreno commits from the mako-kernel branch of kernel-msm on his GitHub - namely, "kgsl: drm: remove checking on 'active'", "video/msm: add true ARGB", and "kgsl: fix null ptr on cache flush".
At one point I had X11 working with freedreno displaying the GNOME background, but the screen blanked after 10 seconds and I couldn't recover from that. Unfortunately, after experimenting with different kernel config options, I lost that semi-working configuration and the GPU started to page fault, sometimes displaying a corrupted screen and sometimes rebooting before displaying anything.
Believe me, I've been working on this for weeks, and it's very frustrating that it doesn't even sort of work. My minimal modifications to Mesa to get it to recognize the Adreno 225 are highly unlikely to be the cause of the problems, and I highly doubt the differences between the 220 and 225 are to blame since it was working at one point. It's a one liner, figured out from from freedreno/mesa issue #2.
Castrwilliam, the initramfs is the least of your worries. I don't use one, since its only function is to display the Plymouth splash, which doesn't work anyway.

gTan64 said:
...
Castrwilliam, the initramfs is the least of your worries. I don't use one, since its only function is to display the Plymouth splash, which doesn't work anyway.
Click to expand...
Click to collapse
Yeah, I realized how you were doing this after looking at the kexec script. I was trying to boot from Android, not recovery, and was under the impression you had put a disk image on external SD, and then made the initramfs loop-mount that and boot from it... but now I see you partitioned it.
It's a shame you don't have your original config, I'll try to get it booting again on my end. I remember doing something like this a while back, where I made like 10 differently configured kernels at once, and tested them each in turn. I imagine the ramconsole would help a good bit so that I could look a how far we're getting. (The touchpad has its own version of that, which you can read directly from the bootloader (bootie.) Then again, it also has LVM volumes for storage instead of actual partitions (except for boot) - which makes it uber easy to boot lots of OSes.)
Currently I'm not doing too well. I remember that kexec did work at one point on d2vzw hardware but I'm assuming that it still does now (new bootloaders, 3.4 kernels, ...) I do kexec -e, the reboot happens, I see the Samsung bootloader screen, then the screen blanks for like 5 seconds and it reboots again - back into android.

castrwilliam said:
I imagine the ramconsole would help a good bit so that I could look a how far we're getting...
the screen blanks for like 5 seconds and it reboots again - back into android.
Click to expand...
Click to collapse
The RAM console should be enabled by default, so check /proc/last_kmsg once Android boots back up.
It could be something simple like the root filesystem not mounting, either due to how you partitioned the card or not having time to settle, hence rootwait. Or it could be something else. I haven't gotten any useful output in /proc/last_kmsg with the framebuffer console enabled, so make sure that's disabled unless you want a headache and a psychiatrist visit.
Unfortunately, I've spent way too much energy trying to debug the GPU page fault, and I probably won't have much time to work on it after next month. I want this bug dead and forgotten, so more eyes would be great!

X11 works (shows something on screen) with the X.org "fbdev" driver. I can't reproduce anything with "freedreno" (or "modesetting", which I accidentally loaded at one point...)
The touch screen doesn't respond, but the power key works and brings up a shutdown dialog.
Screenshot attached. I used the 13.04 Touchpad rootfs with some modifications...

Okay, you can get the fbcon working by either loading it as a module during boot OR changing its "module_init" macro in drivers/video/console/fbcon.c to "late_initcall".
Picture attached. Sorry for blurriness, I don't have an actual digital camera, only what's on my sig. This should make debugging a bit easier.

Nice to see some more freedreno development on android phones
I'm using freedreno with a slightly different approach, starting it directly from android on a chrooted shell, which is a lot more easier to debug.
The kernel needs some fixes from the mako branch and the following configs:
Code:
CONFIG_DEVTMPFS=y
CONFIG_VT=y
CONFIG_DRM=y
CONFIG_MSM_KGSL_2D=y
CONFIG_MSM_KGSL_DRM=y
Rob Clark (the maintainer of freedreno) has been working on his own kernel driver for adreno gpu:
https://github.com/freedreno/kernel-msm/commits/ifc6410-drm
This would be a nice addition/replacement for the current qualcomm gpu driver.

Wootever said:
Nice to see some more freedreno development on android phones
I'm using freedreno with a slightly different approach, starting it directly from android on a chrooted shell, which is a lot more easier to debug.
The kernel needs some fixes from the mako branch and the following configs:
Code:
CONFIG_DEVTMPFS=y
CONFIG_VT=y
CONFIG_DRM=y
CONFIG_MSM_KGSL_2D=y
CONFIG_MSM_KGSL_DRM=y
Rob Clark (the maintainer of freedreno) has been working on his own kernel driver for adreno gpu:
https://github.com/freedreno/kernel-msm/commits/ifc6410-drm
This would be a nice addition/replacement for the current qualcomm gpu driver.
Click to expand...
Click to collapse
How do you stop the SurfaceFlinger (I think that's proper terminology) from hogging the framebuffer?

Semi Working Freedreno/X11
castrwilliam said:
How do you stop the SurfaceFlinger (I think that's proper terminology) from hogging the framebuffer?
Click to expand...
Click to collapse
HEY, look what I did?!
(There are a lot of patches req'd to get this far. Even at this point, there's a weird bug where the cursor loops across the edge of the screen and windows overlap themselves. If you want to know, I'll elaborate in a further post, otherwise, let's get that touchscreen working for release!)
Thanks to Rob Clark (again, the author of freedreno) who helped me get this far on his IRC channel at Freenode.

castrwilliam said:
HEY, look what I did?!
(There are a lot of patches req'd to get this far. Even at this point, there's a weird bug where the cursor loops across the edge of the screen and windows overlap themselves. If you want to know, I'll elaborate in a further post, otherwise, let's get that touchscreen working for release!)
Thanks to Rob Clark (again, the author of freedreno) who helped me get this far on his IRC channel at Freenode.
Click to expand...
Click to collapse
Are we keeping track of all the necessary patches? I'm on https://github.com/CyanogenMod/android_kernel_samsung_d2, branch cm-10.2_kgsl, with the per-process pagetable hack, the "active" kgsl_drm fix, Adreno 225 case in Mesa (freedreno_screen.c), and my stub occlusion query hack. I wasn't on #freedreno when Rob Clark pointed out the libdrm bug I heard about from the Wiki - did you fix that? I'm still getting the assert crashes.
I'll be on #freedreno at some point tomorrow.

gTan64 said:
Are we keeping track of all the necessary patches? I'm on https://github.com/CyanogenMod/android_kernel_samsung_d2, branch cm-10.2_kgsl, with the per-process pagetable hack, the "active" kgsl_drm fix, Adreno 225 case in Mesa (freedreno_screen.c), and my stub occlusion query hack. I wasn't on #freedreno when Rob Clark pointed out the libdrm bug I heard about from the Wiki - did you fix that? I'm still getting the assert crashes.
I'll be on #freedreno at some point tomorrow.
Click to expand...
Click to collapse
I got this to work by using a fairly old libdrm, but a new DDX (xf86-video-freedreno). I haven't fixed the assert bug on the newer ones.
You need to patch the DDX's msm-device.c to set the width to 736 (has to be a multiple of 32), and then disable/comment out/delete where it calls the mode-set function (there's a comment about making xrandr happy in the right place.) I can make a patch soon, but I have a feeling that this is what made the other bug happen with the looping cursor.
edit -- I fixed the looping cursor. A patch is attached...
Youtube video of it working: http://www.youtube.com/watch?v=rh9wmmYuKxY
Tips:
Set the firnware path for the dhd (wi-fi) driver to /system/etc/wifi/bcmdhd_sta.bin (WITHOUT the _b2 buffix, it will be added by the module). Set the nvram file to /system/etc/wifi/nvram_net.txt. Then, add the Android partitions to the /etc/fstab (mmcblk0p14 is system.)
apt-get install xserver-xorg-input-multitouch and then add a config file under /usr/share/X11/xorg.conf.d/ to get the touchscreen working. It will act like a laptop trackpad. You MUST use the multitouch driver. "evdev" will segfault the server on any touch. Note that you can match the TS in an InputClass with its udev name, "sec_touchscreen".
The date that I compiled the working Freedreno libdrm was the date that Ubuntu 13.04 was released. I'm working on narrowing it down to a Git SHA1 revision. I used Rob Clark's repository, not the freedesktop one.
Use the master branch of the DDX, sorry for the earlier confusion.
For battery savings, you might want to cherry pick the DPMS commit from the a3xx branch of the DDX.

castrwilliam said:
How do you stop the SurfaceFlinger (I think that's proper terminology) from hogging the framebuffer?
Click to expand...
Click to collapse
There are two binaries you can execute with adb shell stop/start that kills and restart the android proccesses, allowing access to the framebuffer.

Okay, so 2-D does work with my mods, but I just tried 3-D last night (ran es2gears with the Adreno 225 mod in place on mesa) and the pagefaults returned.
I did notice something about your pagefault reboots, though: they shouldn't necessarily be happening, it's a NULL pointer dereference that can be fixed in the handler by doing this in drivers/gpu/msm/kgsl_iommu.c (function is kgsl_iommu_fault_handler):
Change
Code:
curr_context->pagefault = 1;
curr_context->pagefault_ts = curr_global_ts;
To:
Code:
if (curr_context) {
curr_context->pagefault = 1;
curr_context->pagefault_ts = curr_global_ts;
}

So anyone got any updates for this if not i will start building upon what is there if it is ok
Sent from my SCH-S960L using xda premium

allenjthomsen said:
So anyone got any updates for this if not i will start building upon what is there if it is ok
Sent from my SCH-S960L using xda premium
Click to expand...
Click to collapse
I guess it is OK. Hopefully you can make a dent in this development. Keeping my eye on this thread.

No longer developing for this phone
Unfortunately, this phone hasn't been a good fit for me. I never got very far booting Ubuntu or Freedreno, so I decided to sell it.
For anyone still interested in this project, I believe castrwilliam has the required patches.
When I get my next Snapdragon device (either the new Nexus 7, a Nexus 4, a Galaxy S4, or another phone with Adreno 320 graphics), I will post the Mesa patches for occlusion query support.

[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.