Related
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....
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
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
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.
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])