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....
I have looked and been unable to find any links to source for CM6.1.2 WiMax Alpha 3. A tar.gz would be ideal but git-hub works as well as I can pull the tar from there. The reason for the request is to create a CM6/WiMax/HDMI release with full HW acceleration for those that need the pointer support that 6.1.2 provides.
I have tried the one SZ kernel that's available but it has the USB bug and HW accel detect issues and would rather start from a clean slate. Any help on source would be great. Thanks.
Lokifish Marz said:
I have looked and been unable to find any links to source for CM6.1.2 WiMax Alpha 3. A tar.gz would be ideal but git-hub works as well as I can pull the tar from there. The reason for the request is to create a CM6/WiMax/HDMI release with full HW acceleration for those that need the pointer support that 6.1.2 provides.
I have tried the one SZ kernel that's available but it has the USB bug and HW accel detect issues and would rather start from a clean slate. Any help on source would be great. Thanks.
Click to expand...
Click to collapse
It's the same kernel that is being used for CM7. You can roll that back if you want.
Also, why would you want a CM6 ROM when CM7 RC3 just came out?
ViViDboarder said:
It's the same kernel that is being used for CM7. You can roll that back if you want.
Also, why would you want a CM6 ROM when CM7 RC3 just came out?
Click to expand...
Click to collapse
So Alpha3 Froyo is actually a GB kernel? Didn't know that.
I'll check the RC3 change log to see if BT KB/mouse issues have been fixed. If not then still stuck at 6.1.2.
(update) Can find no mention of pointer support on CM7 other than requests. Nothing listed in change log.
Lokifish Marz said:
So Alpha3 Froyo is actually a GB kernel? Didn't know that.
I'll check the RC3 change log to see if BT KB/mouse issues have been fixed. If not then still stuck at 6.1.2.
(update) Can find no mention of pointer support on CM7 other than requests. Nothing listed in change log.
Click to expand...
Click to collapse
The android-x86 project doesn't even have this working yet so it will be a while before cm7 gets it.
spiicytuna said:
The android-x86 project doesn't even have this working yet so it will be a while before cm7 gets it.
Click to expand...
Click to collapse
That's what I figured, so hopefully I can find source for froyo alpha3. If I don't get anything from this Q&A post I'll contact shinzul directly.
Lokifish Marz said:
That's what I figured, so hopefully I can find source for froyo alpha3. If I don't get anything from this Q&A post I'll contact shinzul directly.
Click to expand...
Click to collapse
Merge the patches from the CM7 kernel in to your CM6 kernel then if you don't like the CM7 kernel.
That's the source...
Lokifish Marz said:
That's what I figured, so hopefully I can find source for froyo alpha3. If I don't get anything from this Q&A post I'll contact shinzul directly.
Click to expand...
Click to collapse
Why would you want to do this? The kernel from cm7 will boot cm6. The cm7 kernel is not specific to gingerbread.
spiicytuna said:
Why would you want to do this? The kernel from cm7 will boot cm6. The cm7 kernel is not specific to gingerbread.
Click to expand...
Click to collapse
Was having mouse cursor issues when I tried that but not on the stock alpha3.
Also... Rather than wasting time porting HDMI back to an old rom, why not work on a patch for pointer support in CM7?
Lokifish Marz said:
Was having mouse cursor issues when I tried that but not on the stock alpha3.
Click to expand...
Click to collapse
ahh; then merge the patches from the CM7 hdmi opensource kernel into your CM6 kernel and you'll be golden...but then the question starts to be why not work on porting the hid/mouse support from cm6 to cm7 which seems like the more logical choice of time to benefit all as most people aren't going to want to fall back to cm6.
spiicytuna said:
ahh; then merge the patches from the CM7 hdmi opensource kernel into your CM6 kernel and you'll be golden...but then the question starts to be why not work on porting the hid/mouse support from cm6 to cm7 which seems like the more logical choice of time to benefit all as most people aren't going to want to fall back to cm6.
Click to expand...
Click to collapse
I agree that it does make more sense try to port hid/mouse to cm7 but I still haven't found/seen a real fix to the slow usb issue on the new kernel. My linux is also a bit rusty.
As a reminder, since that build is no longer distributed, the source no longer needs to be made available. The GPL only requires source availability on distribution. If you didn't retrieve the source when the distribution was made available, there's no requirement for kernel devs to go and find a valid point of reference after the fact.
When the alphas were released, the kernel source was made available. The links to the source were removed at the same time the primary distribution link was removed.
agrabren said:
As a reminder, since that build is no longer distributed, the source no longer needs to be made available. The GPL only requires source availability on distribution. If you didn't retrieve the source when the distribution was made available, there's no requirement for kernel devs to go and find a valid point of reference after the fact.
When the alphas were released, the kernel source was made available. The links to the source were removed at the same time the primary distribution link was removed.
Click to expand...
Click to collapse
Oh well. Back to square one.
My memory is a little fuzzy, but I'm pretty sure that we were recommending a 2.6.34 kernel with Alpha 3. It took me but a few minutes to come up with:
https://github.com/toastcfh/cm-kernel/tree/android-msm-2.6.34/
Of course, this kernel has it's own "sleep bug" in that it doesn't let the phone go to sleep at all. Not exactly good for battery life, but you're welcome to fork it and make your own changes.
Use the switch branches dropdown if you want to try one of toastcfh's various 2.6.35 branches instead, but I'm pretty sure those have the USB bug.
Dees_Troy said:
My memory is a little fuzzy, but I'm pretty sure that we were recommending a 2.6.34 kernel with Alpha 3. It took me but a few minutes to come up with:
https://github.com/toastcfh/cm-kernel/tree/android-msm-2.6.34/
Of course, this kernel has it's own "sleep bug" in that it doesn't let the phone go to sleep at all. Not exactly good for battery life, but you're welcome to fork it and make your own changes.
Use the switch branches dropdown if you want to try one of toastcfh's various 2.6.35 branches instead, but I'm pretty sure those have the USB bug.
Click to expand...
Click to collapse
Sounds like a game of pick your poison....what do you want more and what can you live with?
spiicytuna said:
Sounds like a game of pick your poison....what do you want more and what can you live with?
Click to expand...
Click to collapse
That's my kinda game!
Here we go
Common gingerbread-samsung git branch for all of us
This branch contains the fixed Gingerbread source (compiling and working) everyone of us may use as reference git repository.
Fixed in this source:
- all cleaned up gitignores
- missing FSR in Makefile
Take also a look at the updated README.txt that will explain you how to compile and get it working with modules
Also: makes sure you disable, in .config:
[*] Automatically append version information to the version string in menuconfig or CONFIG_LOCALVERSION_AUTO in .config
It will help each developer to exchange patches easily because of the common starting point.
bilboa1 said:
What supercurio means, is that he's offering to have a common GIT repository for the official Samsung kernel of the GT-I9000 (and similar phones).
The GIT tree would contain only Samsung drops and possible other upstream fixes/changes (the kernel being loosely based on the Nexus S kernel, there's at least Samsung and Google as different upstream), as well as bug fixes. No new features etc except maybe Voodoo.
The advantage of that is that the ones not using GIT yet could fork it and make their own kernel variation on a STABLE base. They could also issue pull requests for fixes they made, which would profit everyone. That's the open-source spirit and way of doing things efficiently by the way.
Note that the current GIT already contains fixes for compiling and using Samsung's GB sources with Samsung's firmwares (and binary modules).
I certainly support this idea.
Click to expand...
Click to collapse
How you can fork this repository:
- clone it via github directly
or, if you prefer keeping only this gingerbread branch directly, on your dev computer:
Code:
git clone git://github.com/project-voodoo/linux_gt-i9000.git -b gingerbread-samsung
cd linux_gt-i9000
git remote rm origin
git remote add origin git://your-new-remote-repository.git
git remote add common git://github.com/project-voodoo/linux_gt-i9000.git
This way, for people re-using Vodooo sound for example, it will be as easy as:
Code:
git fetch common
git merge gingerbread-voodoo-sound
If you have more idea of collaboration like that, express yourself
FAQ:
Q: Bleh! I hate this Kernel/ directory.
A: Yes, this was the case for the original commits but now it's a standard Linux repository with everything on its root.
But it didn't worked as expected, so I had to make the change, sorry for the inconvenience to the early adopters.
Q: What happens when Samsung update their source code tarballs
A: I'll update the common git repository accordingly (hopefully fast enough for you)
On your side, all you'll need to do will is.
Code:
git fetch common
− or git fetch git://github.com/project-voodoo/linux_gt-i9000.git
git merge gingerbread-samsung
Say good bye to messy tarballs!
PS: if you're looking to initramfs, take a shot at https://github.com/project-voodoo/samsung_initramfs − contribution welcome.
Good idea, I second that, it will be easier
wrong link
Github reads http://project-voodo.org/
What supercurio means, is that he's offering to have a common GIT repository for the official Samsung kernel of the GT-I9000 (and similar phones).
The GIT tree would contain only Samsung drops and possible other upstream fixes/changes (the kernel being loosely based on the Nexus S kernel, there's at least Samsung and Google as different upstream), as well as bug fixes. No new features etc except maybe Voodoo.
The advantage of that is that the ones not using GIT yet could fork it and make their own kernel variation on a STABLE base. They could also issue pull requests for fixes they made, which would profit everyone. That's the open-source spirit and way of doing things efficiently by the way.
Note that the current GIT already contains fixes for compiling and using Samsung's GB sources with Samsung's firmwares (and binary modules).
Forking in git hub is VERY VERY easy btw.
I certainly support this idea.
Awesome! - I also support this idea
United Galaxy S Developers
Nice idea! Perfect spirit of open source
I hope good things come out og this.
Great move Supercurio - once again !
Simply awesome men
Will the github include the multitouch fix(SGS only using two fingers rather than multiple fingers) that affects Google Maps rotation?
pikachu01 said:
Will the github include the multitouch fix(SGS only using two fingers rather than multiple fingers) that affects Google Maps rotation?
Click to expand...
Click to collapse
The gingerbread-samsung branch promoted here will only contain Samsung kernel sources and won't interfere with other developers modifications.
Only exception is if this source is broken and needs something to work, like nikademus's patch: https://github.com/project-voodoo/linux_gt-i9000/commit/6c8f989f58999770d23236bb172c3a4e1c80586b
It seems that JVK and JVB was pulled from Kies because of an update problem. Looks like we're going to have new ROMs to play with in a week or two (maybe less)
Edit: What about the SSL fix (http://forum.xda-developers.com/showthread.php?t=1040005)
Great, good idea. That's how community development should work!
zorxd said:
Great, good idea. That's how community development should work!
Click to expand...
Click to collapse
Agreed! Thanks for getting things started Supercurio! Now I have to start making a Vibrant branch.
Any chance this code will boot with preempt enabled? Does the MTD driver work with the OneNAND partitions like the NS code does? I'd kind of like to get away from FSR/RFS and such....
Still cloning...
ttabbal said:
Any chance this code will boot with preempt enabled? Does the MTD driver work with the OneNAND partitions like the NS code does? I'd kind of like to get away from FSR/RFS and such....
Still cloning...
Click to expand...
Click to collapse
The code has many similarities with Nexus S one (build from it IMO) and is preempt too
Just a note, I had to edit the Makefile to set the crosscompile variable to the right path
Question: is the generated zImage flashable through ODIN? Don't we need to add the initramfs?
supercurio said:
The code has many similarities with Nexus S one (build from it IMO) and is preempt too
Click to expand...
Click to collapse
Excellent! I just did a defconfig to check it out and saw the preempt in there.. Nice to see Samsung fixing things up a little. Now I need to get a GB ROM to install so I can try to boot.
Thanks again. I'll send a pull request when I have a Vibrant branch ready. Going for minimal modifications, fix touch button mapping and such. People can add whatever they want after that. Now I need to learn the new code tree... wheee! Hopefully the basics are the same, getting the changes into an i9k froyo kernel is pretty easy.
zorxd said:
Just a note, I had to edit the Makefile to set the crosscompile variable to the right path
Question: is the generated zImage flashable through ODIN? Don't we need to add the initramfs?
Click to expand...
Click to collapse
You will need an initramfs... anyone have a default one we can start with for 2.3?
zImage will have to be in a TAR file to flash with Odin. Heimdall can flash a bare zImage, as can the SGS Kernel Flasher tool for Android.
Oh... think I saw a setting in "make menuconfig" for the cross-compiler prefix. Might be able to avoid Makefile mods....
Sorry for the newb question, but how do we generate the initramfs? I guess we could take the one from stock JVB. But how do we extract it and how do we combine our compiled kernel with it?
On a side note, I noticed that CFQ is the default scheduler. Isn't it better to use No-op for flash memory?
this is a diff from EG30 Source to EK02 source released today
http://forums.acsyndicate.net/showthread.php/3491-ACS-Kernel-Source-diff?p=15782
Thanks for digging this out!
The one..the only..SGSII E4GT
You are awesome Chris41g! Thank you.
Are there any noticeable differences, or benefits of using one over the other?
Lots of noticeable differences in the code... as far as using the kernel, I dont know.. I dont have the phone yet.
I posted this to try and make kernel devs lifes a little easier in swapping over to the new source
Tip: For sanity, try splitting the diff. (Best to do it in git)
Start with a bare EG30 tree. Commit it
Apply the diff
"git add" related files
Commit them
Rinse and repeat till you've got everything.
https://github.com/Entropy512/linux_kernel_sgh-i777/commits/samsung_update3 as an example
A day may come when the courage of men fails, when we forsake our friends and break all bonds of fellowship.
But it is not this day! Today, we PIE!
Kernel755Let the adventure begin!
KEWL FEATURES:
1,7 GHz OC!
Lots and lots of governors!
3 extra schedulers!
-O3 optimized!
Moar to come!
AWESOME DOWNLOADS:
The newest release (release, not alpha): http://bit.ly/1jccQXY
More downloads, including alphas and old releases in the changelog in the 3rd post!
FUNNY DISCLAIMER!
Code:
You are free to use this software, but it's not my fault if (when) you mess something up.
Please be careful and beware of being late to work, exploding cows and eating radioactive pie.
Kernel sources: https://github.com/someone755/Kotato/tree/jb_mr2_chocolate_rmfx
XDA:DevDB Information
Kernel755 - PIE, Kernel for the Sony Xperia S
Contributors
someone755
Kernel Special Features:
Version Information
Status: Abandoned
Current Stable Version: N/A
Current Beta Version: a1
Beta Release Date: 2013-12-16
Created 2013-12-16
Last Updated 2014-07-30
And now, a FAQ. @franciscofranco's FAQ, updated to fit our device.
F.A.Q. - Read this before complaining!
1. My phone exploded, HALP!
A: I don't answer to problems without a log. The log file is in /proc/last_kmsg. Paste it on pastie.org and link it on your post. Logcats are useless for Kernel purposes, don't bother posting them.
2. OMG BETTARY SUCKZ, IT DEAD IN 45 MINUTAS, HALP!
A: As you can imagine I don't build kernels to decrease battery life. All the battery life problems come from your apps, either Facebook, or Maps, or some Location Service being enabled etc etc. Check your damn wakelocks and fix them, the kernel is not responsible for them.
3. How do I flash this?
A: Since it's an .elf file, it's only flashable through fastboot. The general command is "fastboot flash kernel.elf"
4. OP is arrogant, I'm gonna call the Internet Police?
A: Deal with it.
5. Touch Control doesn't work in rXXX release, you suckas, fix plixe!
A: I don't know who you are. I don't know what you want. If you are looking for a fix, I can tell you I don't have the solution. But what I do have are a very particular set of skills; skills I have acquired over a very long career. Skills that make me a nightmare for people like you. If you leave now, that'll be the end of it. I will not look for you, I will not pursue you. But if you don't, I will look for you, I will find you, and I ignore you.
6. What's up with the kernel's name?
A: Well I have '755' in my name. So there's that...
7. I'm on stock/CM10/CM9/GB and this kernel doesn't work.
A: This kernel is ONLY for CyanogenMod 10.2 and any ROMs that came of it (like AOKP, for example). Don't flash on anything else unless you are SURE the ROM is based off of OpenSEMC's CM10.2.
8. My Locked-bootloader phone won't boot with this/I can't flash it.
A: This is a custom kernel. It requires an unlocked bootloader.
9. What app do you recommend for dealing with CPU settings?
A: Use TricksterMod. For 2D GPU OC and setting the 2nd core's governor, I recommend Kernel Tuner. Both are feature-packed and free, and if you don't mind an extra icon in your drawer, I say get both.
10. What is the difference between releases marked as a# and r#?
A: The r# releases are considered the most stable, but do not pack all the features. Because my work is rather slow, I'll add an alpha, an a# release, every time a minor change is introduced. But even if they look and feel stable, do not consider them as such. Most of them are dirty builds!!! Meant for advanced users only, so distributed in fastboot-flashable format ONLY!
11. I want to support you and your work!
A: Putting a subtle sign in your signature that you're using my kernel (or like it or have used it). Please, no big banners or anything, just the name of the kernel. That would be appreciated the most.
And now, thanks!
@RaymanFX -- helping me with nearly all issues and, of course the kernel sources. Also for an old project from which I learnt how proper GPU OC is done.
@abcdjdj -- writing a neat tutorial on how to compile kernels, and telling me about the -w flag
@letama -- adding a few new words into my dictionary (initramfs=ramdisk, did you know that!? )
@hei1125 -- for the NOVA kernel, and its' sources
@Forzaferrarileo -- for his kernel, Forzaferrarileo
@IAmTheOneTheyCallNeo, @fusionjack and @DJLamontagneIII -- for detailed toolchain and compiler flags explanation
@franciscofranco -- for inspiring me to get this done
@Wendigogo -- for SCSI and USB fixes help
@cronot -- for new logo and bringing in .96 fixes
@aebob -- for awesome logo idea
@thicklizard -- for helping with -O3
Sony and Google -- Android rules
HTC -- Inventing S-ON, forcing me to buy a Sony phone :3
@all -- for being an awesome community! C:
Changelog!
Code:
a1: [URL]http://bit.ly/1jccQXY[/URL]
-initial release
--O3
-CPU OC
-All governors from POTATO (4.2.x) kernel (lots of 'em)
-All schedulers from POTATO (4.2.x) kernel (zen, fifo, fiops)
I'll give it a try in Letama's dual boot as soon as I have time
I trust you know what you're doing, Wise one.
Still, it is dangerous to go alone. Here, take this. *Hands free pie*
Hey someone755,where are the potatoes??
Well I gotta change something from release to release
many people are moving to a cm11 based rom...
will you make a kernel for that as well?
No, not just yet.
I see 4.3 more stable, while KitKat is still in its early stages.
Also, I see KitKat will be updated more frequently, but I'm lazy, so no.
someone755 said:
No, not just yet.
I see 4.3 more stable, while KitKat is still in its early stages.
Also, I see KitKat will be updated more frequently, but I'm lazy, so no.
Click to expand...
Click to collapse
I see Kitkat gotten more stable than 4.3.. Since video recording and other issues from 4.3 are solved in it.. So probably its best either if Rayman releases a BETA version of 4.3 fixing the bugs or u switch to 4.4 kernel.. :silly: Just an opinion..
I tried your potatoes 4.2.2 kernel and it was great
Waiting for your kitkat kernel since I'm running cm11
Sent from my LT26i using xda app-developers app
Hi,
Just to be sure : this is a kernel for CM10.2 or JB-4.3 roms right ?
You ask it's an optimized -O3 built kernel. Did you solve your problem with /cache size and -O3 optimisations ? Will you build a potatoe kernel (for JB-4.2) including these optimisations ?
Cheers
Yes, it's for CM 10.2/Android 4.3 (OpenSEMC, of course),
Potatoes already have -O3
And just saw that KK is in Beta stage. Might give that a shot, Pie isn't all that popular, as it would seem.
Just need to hang in there for another week, my last part for my custom rig is just around the corner (hopefully).
Thank you for your kernel and for smooth video recording.
I very like OmniROM with your kernel.
I have only two small problems:
- TWRP is little slower than with other kernel (backup taken about 20 minutes)
- I'm not able to select "smartass v2" governor (I thik you have typo in your script, because there are two names in one row (see screenshot)
Lol sorry, I must've derped the Makefile. It'll run nightmare, not smartassv2 if you select it...
About TWRP, I don't have a clue, I never even used CM10.2...
I'll look into fixing it tonight, if I find the time.