Hi there,
This is a development thread.
Don't ask for ETAs. Don't ask what's working. Don't ask how to use.
It is not yet in an usable state.
INFORMATION
Click to expand...
Click to collapse
This is an attempt to make a homemade 3.x kernel for our beloved Galaxy S II. I'm targetting the GT-I9100 only for now, if you wish to get it running on other variants (I9100G for instance), feel free to port it to your device and do a pull request.
I started it off Origenboard 3.0.4 kernel patched to 3.0.24, so that we get the most up-to-date opensource drivers, removing the need of porting Samsung drivers from 2.6 (gingerbread) kernel.
We'll be able to merge proprietary stuff from Samsung when they release it (audio and modem mainly), but thanks to what we'll already have we'll have a proper 3.x kernel without any Samsung crap (such as their MTP implementation that is borked it seems).
GIT REPOSITORY
Click to expand...
Click to collapse
http://github.com/xplodwild/android_kernel_samsung_galaxys2
WHAT'S WORKING
Click to expand...
Click to collapse
Keys GPIOs
Regulator and battery (it loads well but Android doesn't show it's charging)
Screen/framebuffer
Touchscreen
MFC (untested but should work from Origen)
RTC Clock
Touchkeys
MAJOR ISSUES
Click to expand...
Click to collapse
Phone never wakes from deep sleep (<== We definitely need experts on this one)
ADB works only after unplugging and replugging USB cable (issue almost located)
HOW TO HELP
Click to expand...
Click to collapse
Well, start forking, do stuff and make pull requests so I merge it and everyone enjoys. I'd need some help for the major issues above (especially the deepsleep issue).
If you're not a developer, well, buy me a coffee, there's a donation button on the left of this post
I'll keep you informed when it'll be ready for "public" use.
Phone never wakes from deep sleep
cpufreq is stuck at 200Mhz in ondemand governor
My guess is that these might be connected - or does conservative work?
Our device becomes very unhappy if it enters suspend when the regulators aren't set high enough to support 200 MHz.
As an experiment - if you set the default voltages for 200/500 to match 800 and it fixes things, that's the problem. If it still breaks - it's something else and I have no clue what.
Entropy512 said:
[*]Phone never wakes from deep sleep
[*] cpufreq is stuck at 200Mhz in ondemand governor
My guess is that these might be connected - or does conservative work?
Our device becomes very unhappy if it enters suspend when the regulators aren't set high enough to support 200 MHz.
As an experiment - if you set the default voltages for 200/500 to match 800 and it fixes things, that's the problem. If it still breaks - it's something else and I have no clue what.
Click to expand...
Click to collapse
I was just thinking that Iirc it puts the device into 800 when waking, or something like that...
Entropy512 said:
Our device becomes very unhappy if it enters suspend when the regulators aren't set high enough to support 200 MHz.
As an experiment - if you set the default voltages for 200/500 to match 800 and it fixes things, that's the problem. If it still breaks - it's something else and I have no clue what.
Click to expand...
Click to collapse
I had the same issue when I haven't enabled the governors, so the CPU was stuck at 1200MHz but won't wake up either from a deep sleep.
I'll have a try with the voltage, but my guess is more that there's some steps missing (the default 2.6 kernel seems to have a "low power mode" in which the board gets before waking up, if I understood it correctly).
At the same time, I'm giving a try with the 3.3 branch at Linaro (check android-3.3 branch at my github). It's harder than 3.0 because there's no more s3c framebuffer, it seems to go directly to FIMD, and the LCD panel has to be setup through SPI.
Some update:
- Touchkeys, clock and various things added/fixed
- Patched to 3.0.24
Edit:
- Added sdcard mounting
Cool stuff should come very quickly
Good work...
---deleted some post----
Sorry u can delete this post as it making thread very ugly..
_____________________
Sent From My Phone
just buy u a expensive coffee! Work hard!
Yeah do you smell sources?
Sent from my GT-I9100 using XDA
boba23 said:
Does this mean you are smelling Samsung source code somewhere? ;-)
boba
Click to expand...
Click to collapse
We'll do our best without them.
True enough.
This kernel is the most exciting thing I'm watching lately.
Really excited about the outcome. Samsung Kernel is just not the way to go if you get an alternative like this, which is far more promising.
Here comes your coffee:
33P346290U8160844
Keep it up!
Before your release ... Samsung Released their open source kernel.. guys Congo.. will wait patiently for your kernel... Thank you.. love u Dev
Sent from my GT-I9100 using Tapatalk
sam razzy said:
Before your release ... Samsung Released their open source kernel.. guys Congo.. will wait patiently for your kernel... Thank you.. love u Dev
Sent from my GT-I9100 using Tapatalk
Click to expand...
Click to collapse
he already know it...pretty sure xplod and codeworkx will bring some state of art kernel to us
Samsung kernel is really dirty : A lot of hacks, outdated drivers, ... The Samsung way, just the same they do with Android (adapt mainline code to their stuff, instead of doing it the other way...)
But we're going to bring everything to a clean 3.0 or 3.3 base soon
Isn't 3.3 bleeding edge?
Sent from my GT-I9100 using XDA
awesome, man
despite not owning a sgs2 I like your work! Samsung should definitely review their way of development, way cook your. own soup, when it. Is. already done by someone else
they should just stay compatible and release the damn hardware drivers ;-)
Sent from my Nexus S using XDA Premium HD app
XpLoDWilD said:
Samsung kernel is really dirty : A lot of hacks, outdated drivers, ... The Samsung way, just the same they do with Android (adapt mainline code to their stuff, instead of doing it the other way...)
But we're going to bring everything to a clean 3.0 or 3.3 base soon
Click to expand...
Click to collapse
What is your definition of "clean"? - since a "clean" 3.0 mainline can't run Android at all, and a "clean" 3.3 can barely run it.
I'm still wondering why you renamed mach-exynos back to mach-exynos4 - you complain about outdated drivers, but you revert progress in the CM codebase? https://github.com/torvalds/linux/commit/830145796a5c8f1ca3f87ea619063c1d99a57df5 (The aforementioned commit was part of the transition from 3.1 to 3.2 in mainline.)
Edit: Some of Samsung's drivers are clearly full of ugly hacks and need major work. However, an automatic judgement of "it's different, therefore it must be old" is clearly not appropriate - it has already led you to make the mistake of "fighting the future" and taking the mach-exynos codebase backwards, when all of the evidence says that in the case of mach-exynos, "different" means "much newer", not "older".
Entropy512 said:
What is your definition of "clean"? - since a "clean" 3.0 mainline can't run Android at all, and a "clean" 3.3 can barely run it.
Click to expand...
Click to collapse
Clean, meaning a clean 3.0 with Android additions in it.
If you take Samsung 3.0.15, there's not much files (if you exclude mach and specific drivers) that looks like "clean" 3.0.15, which causes a LOT of troubles if you want to patch it up.
Entropy512 said:
I'm still wondering why you renamed mach-exynos back to mach-exynos4 - you complain about outdated drivers, but you revert progress in the CM codebase?
Click to expand...
Click to collapse
In mainline 3.0, it's mach-exynos4. It's renamed mach-exynos afterwards. Samsung had BOTH, with duplicated files which could lead to thousands of headaches when patching and doing stuff too.
Entropy512 said:
https://github.com/torvalds/linux/commit/830145796a5c8f1ca3f87ea619063c1d99a57df5 (The aforementioned commit was part of the transition from 3.1 to 3.2 in mainline.)
Edit: Some of Samsung's drivers are clearly full of ugly hacks and need major work. However, an automatic judgement of "it's different, therefore it must be old" is clearly not appropriate - it has already led you to make the mistake of "fighting the future" and taking the mach-exynos codebase backwards, when all of the evidence says that in the case of mach-exynos, "different" means "much newer", not "older".
Click to expand...
Click to collapse
Take Samsung max8997 driver, it's clearly 2.6 one. Mainline got a different implementation, not much complete as of 3.0 unfortunately (MUIC missing for instance).
XpLoDWilD said:
Clean, meaning a clean 3.0 with Android additions in it.
If you take Samsung 3.0.15, there's not much files (if you exclude mach and specific drivers) that looks like "clean" 3.0.15, which causes a LOT of troubles if you want to patch it up.
Click to expand...
Click to collapse
Makes sense, although unfortunately, some things are clearly backports of newer code, see below.
In mainline 3.0, it's mach-exynos4. It's renamed mach-exynos afterwards. Samsung had BOTH, with duplicated files which could lead to thousands of headaches when patching and doing stuff too.
Click to expand...
Click to collapse
Not sure what codebase you're looking at, but in the I9100 source drop I've been working with, there was only mach-exynos, not mach-exynos4, and definitely not both.
No matter what you name it, you're not going to be able to track mainline with this unless you sacrifice MASSIVE amounts of functionality (such as ditching support for any idle state deeper than WFI), because at least in this particular instance, mach-exynos in the Samsung drop is simply lightyears ahead of mainline.
You're going to have to either forget about bringing in mainline patches that touch mach-exynos for a long time, or accept a major reduction in functionality - no matter how you do it, mach-exynos needs to differ significantly from mainline to be even remotely useful.
Take Samsung max8997 driver, it's clearly 2.6 one. Mainline got a different implementation, not much complete as of 3.0 unfortunately (MUIC missing for instance).
Click to expand...
Click to collapse
This one is, of course, a tough one - Is the different implementation in mainline actually newer or older? Determining new vs. old in Samsung drops can be difficult - it may just be taking forever to mainline the additional stuff in Samsung's driver, just like the features just mainlined in 3.3 have been in Android kernels for well over a year.
Entropy512 said:
Not sure what codebase you're looking at, but in the I9100 source drop I've been working with, there was only mach-exynos, not mach-exynos4, and definitely not both.
Click to expand...
Click to collapse
My bad, after checking it must be codeworkx that merged it wrong (he put samsung on top of "stock" 3.0.15 to check the differences), I guess files weren't deleted.
Entropy512 said:
No matter what you name it, you're not going to be able to track mainline with this unless you sacrifice MASSIVE amounts of functionality (such as ditching support for any idle state deeper than WFI), because at least in this particular instance, mach-exynos in the Samsung drop is simply lightyears ahead of mainline.
You're going to have to either forget about bringing in mainline patches that touch mach-exynos for a long time, or accept a major reduction in functionality - no matter how you do it, mach-exynos needs to differ significantly from mainline to be even remotely useful.
Click to expand...
Click to collapse
I'm not talking specifically about mach-exynos implementation, but more all the other things that got touched around it.
Entropy512 said:
This one is, of course, a tough one - Is the different implementation in mainline actually newer or older? Determining new vs. old in Samsung drops can be difficult - it may just be taking forever to mainline the additional stuff in Samsung's driver, just like the features just mainlined in 3.3 have been in Android kernels for well over a year.
Click to expand...
Click to collapse
If copyright header is right, Samsung's one is 2009-2010 whereas 3.3 is from 2011. One example is that the Samsung driver uses mutexes and locks, which are not needed anymore and are not present anymore in mainline. This causes deadlocks everywhere when trying to use them in a "clean" kernel.
Related
UPDATE
Due to unforeseen issues with this build and a plethora of people incapable of reading even simple notes, this release is being pulled while we work out some issues with our own internal testers.
Thank you.
Kernels. The final pain in the arse. These are the voyages of the dev team Ninphetamine. Our continuing mission, to break strange new code. To seek out new bugs and strange implementations. To boldly go where no phone has gone...before.
*cue musical score*
It's been some time since I last graced the Android community. Draped in the success of FroydVillain 1.5, empowered from my victories over Froyo's poor (and non existent) AOSP implementation for the HTC Hero, onward I charged into the task of dragging the ancient kernel of the Hero into the 21st century. However, after seeing how HTC are as likely to stick to recommended kernel practices as I am likely to win a Miss Universe contest, (This is highly unlikely and the least significant reason is that I am not female.) I buckled like a jet fighter made from tin foil and surrendered faster than an agoraphobic Frenchman. There has been some advances into more modern kernels for the Hero but as I predicted they're still plagued with issues, all of which can be blamed squarely on HTC.
It took some major rehabilitation to get me back into the Android development scene, a key factor in that rehab being the ownership of a Samsung Galaxy S. A delightful phone, still in my opinion the best single core Android phone that money can buy. Beautiful screen, fast, elegant and excellent on battery. It nursed me through those dark days of waking up in cold sweats with github commits circling through my head, kernel debug symbols blinking in the dark of the night like Vietnam flashbacks, breaking down into incoherent rants on IRC development channels ending eventually with "YOU WEREN'T THERE MAN, YOU JUST DON'T UNDERSTAND, HTC WILL COME AND GET YOU EVENTUALLY, THEN YOU'LL KNOW". Oh how I longed to find a high up HTC developer in a bathroom to blow them away before ending my own bitter misery. Alas, it was not to be.
After a successful tour of duty as a regular non developing user on the Samsung Galaxy S, I treated myself to a brand new and shiny Samsung Galaxy S II. As soon as I used the device and checked out the available source code for it, I knew I was ready, I knew I was fully recovered to be able to break free from the oppression of HTC, I knew that I was capable to step once more unto the breach and step back into Android development. The stage set, the orchestra struck...all that remained was to see if the Samsung Galaxy II could dance.
And dance it can. Accompanied by my trusty partner in crime netarchy (because this time if I go down in a gibbering wreck I'm damn sure taking someone with me) there is at last another phone with the magic, capabilities and horsepower to endure the test of time and upgrades, that like the Hero has carved out a niche of not only being the good of its generation but being the very best of its generation. Such hardware deserves only the best development efforts and here we are.
The best kernel for a phone that any human hand is capable of producing at this very moment in time. This will of course be rendered moot with the next release BUT RIGHT NOW, this is it boys and girls. Download it, flash it, use it with whatever ROM you wish (VillainROM of course for those with an IQ north of my shoe size) and enjoy the liberated freedom, speed and stability that those whoever owned a HTC Hero became accustomed to.
After much arguing with Samsung's inane practices, lack of logic, bizarre design decisions and enough harrassment via their support interface that I confidently expect a restraining order any day now, I bring you...
Ninphetamine version 1.0, the beginning.
Features:
Overclocking up to 1.6GHz. The phone is blisteringly fast at stock 1.2GHz so be happy you can push it to 1.6GHz. We will not provide higher, if you want higher then make your own.
Full voltage control interface. Via SetCPU you can set voltage as low as 800mV or as high as 1500mV for each speed in the database. If you're possessed with the intelligence of a baboon and destroy your phone as a result, do not come crying to us. All you'll get is a quote in this thread with much mocking from myself and your peers.
Patches and bug fixes up to and including 2.6.35.11. We're working on going up to 2.6.35.13 however the important fixes are in already. As well as some that never made it to 2.6.35.y -at all-.
Fully tested performance optimisations. This kernel comes with BFQv2-r1 IO scheduler enabled as default along with some tweaked parameters for this scheduler. These were painstakingly tested over many many many many many MANY different benchmark tests. These are the best. Anyone who claims otherwise or says that noop or deadline or CFQ is better, they're wrong. Why? Because I say so and I'm right.
A customised and trimmed down initramfs, including Clockworkmod. Many thanks to ogdobber for this who kindly gave me the template including ClockWorkMod that I took and further improved upon. All storage mounts are optimised for performance and data throughput, busybox is included as well as a much improved shell that by default provides tab completion even via adb shell. Please note that by default, adb is insecure, this means that adb shell, adb remount etc all work and give root access immediately.
So there you have it. Please download, flash, test and report any issues/bugs in this thread. I'll then either completely ignore the dumb posts or take on board constructive ones and use those reports/suggestions, incorporate them into the next version and then take all the credit.
Thanks to:
This release would not have been possible without the awesome and tireless work of netarchy, of Nexus S and Asus Transformer fame. Thanks also to ogdobber and supercurio for their assistance. Also thanks to mattgirv, Lenny, Rawat, Obihoernchen, geko95gek and Ante0 for being my guinea pigs for the many many test builds that were made before this final release, no doubt without them there would be a lot more bugs in this release than there already are. Also not forgetting of course, the everlasting patience of my wonderful wife, without which I never would have bothered picking Android up again at all.
Bugs/Issues:
Please of course report them in this thread, however before doing so, please:
Wipe dalvik.
Ensure you have no other OC software installed such as Tegrak. The only OC software supported by this kernel is SetCPU (or setting manually via command line of course).
Are you using a custom ROM? See if you still get issues with stock Samsung firmware or VillainROM. I cannot test with every single custom ROM out there, so I test with stock Samsung (naturally) and my ROM of choice.
If you're still having issues such as random hangs/crashes/reboots and if these issues still occur at stock speeds/voltages then please do the following:
Install the Android SDK if you have not already done so.
In a command window, do the following:
Code:
adb logcat > USERNAME-logcat.log
Then in another window:
Code:
adb shell cat /proc/kmsg > USERNAME-kmsg.log
Naturally replacing USERNAME with your name and make these logs available either via attachment or pastebin or whatever. Please do not paste them directly into posts as these logs can become quite large quite quickly.
Known Issues:
adb install <package> currently does not work.
Version 1.1
Changelog:
Some minor edits to the initramfs to fix adb install <application>.apk and a few other path issues. Loses the nice adb shell with tab completion, but fixes some issues. Download links updated.
Version 1.2
Changelog:
More initramfs changes to fix an issue with nandroid backups.
Making nandroid backups work again may have broken the "adb install" package install method, but I figure working nandroid and needing to push the apk to the phone to then install with Application Manager beats broken nandroids. I'll look further into the adb install issue later today.
Version 1.4
Changelog:
Some configuration changes to try and track down the random hangs/reboots people are experiencing.
Support for startup scripts in /system/etc/init.d added should ROM makers wish to use them.
Added debugging code, which prevents deep sleep in version 1.4, but makes crashes easier to diagnose.
FAQ/General Points
I hate Odin. It is a giant buggy piece of ****. Things can inexplicably go wrong for no other reason than Odin is a big heap of proprietary fail. Before reporting issues with the kernel, please either flash it with CWM or Heimdall. I highly recommend Heimdall, it will flash a jpeg to your kernel filesystem if you tell it to and somehow it'll boot anyway. I do all my testing with Heimdall so it's safe to assume that if I'm posting it, Heimdall will flash it. Heimdall also has the advantage of being open source and completely cross platform. Please take the time to download it and get used to using it, it will save you a lot of pain in the future.
This kernel has been tested with 2.3.3 KF2 and 2.3.4 KG1. There is no reason it shouldn't work with any ROM revision.
Somewhat amazing that I need to point this out, but you MUST FLASH THE KERNEL FOR THE VOLTAGE TAB TO APPEAR IN SETCPU.
Don't use tegrak with this kernel. DO. NOT. USE. TEGRAK. WITH. THIS. KERNEL.
The voltage that's adjusted is the CPU core voltage.
Major_Sarcasm said:
Just a FYI for those people that can't make logical connections; if you have Tegrak OC installed when you flash this kernel, you might end up with a boot loop. Go back to default settings in the app, then uninstall it before flashing.
Click to expand...
Click to collapse
More will be added to this post as the need arises.
pulled for now
SUPER !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Thank you !!!
netarchy said:
Use the voltage interface in SetCPU.
Click to expand...
Click to collapse
OOOO who is here!!! famous netarchy
Hacre said:
Reserved
Click to expand...
Click to collapse
Welcome. Will give it a try.
2.3.3, 2.3.4 ... all ok w this universal kernel?
EDIT: Great... I see you edited Post #2, and the answer is yes.
Thanks for the kernel. Does this have the multi-touch fix included?
jlevy73 said:
Thanks for the kernel. Does this have the multi-touch fix included?
Click to expand...
Click to collapse
I've not noticed an issue with multi-touch, of what do you speak?
*subscribes to thread*
netarchy said:
Use the voltage interface in SetCPU.
Click to expand...
Click to collapse
Okay maybe this is a dumb question, how do you undervolt using setcpu? I know I use it to underclock, and AFAIK it's different from undervolting. I've check the interface of setcpu just now trying to find undervolting options
mach0boi said:
Okay maybe this is a dumb question, how do you undervolt using setcpu? I know I use it to underclock, and AFAIK it's different from undervolting. I've check the interface of setcpu just now trying to find undervolting options
Click to expand...
Click to collapse
Make sure you're using the latest version, and use the voltages tab.
mach0boi said:
Nice! So how will you do the undervolting here?
Click to expand...
Click to collapse
Ummm...
Hacre said:
Full voltage control interface. Via SetCPU you can set voltage as low as 800mV
Click to expand...
Click to collapse
If only I'd mentioned it in the OP...
netarchy said:
Make sure you're using the latest version, and use the voltages tab.
Click to expand...
Click to collapse
Ooh okay i didn't knew there was such feature! thank you!
Hacre said:
Ummm...
If only I'd mentioned it in the OP...
Click to expand...
Click to collapse
I'm sorry maybe I'm just using an outdated version and never knew you could actually do that. Forgive my ignorance
sorry i am new to android so i do not know about undervolt or overclock, can anyone please tell me best combination of voltages on 1.6ghz that does not effect battery life?
ravian29 said:
sorry i am new to android so i do not know about undervolt or overclock, can anyone please tell me best combination of voltages on 1.6ghz that does not effect battery life?
Click to expand...
Click to collapse
The stock max voltage of the CPU is 1275-1300mV. Anything under this improves battery life, anything over this harms battery life from the standard "stock" expectations. Just like with a PC, not all processors are created equal. There is no setting for 1.6GHz that will not affect battery life as at best you'll need to increase voltage from the standard max setting. If you're not sure, use our defaults, these have been tested on two different handsets. There isn't even a guarantee that 1.6GHz will even work on your handset.
If you're not sure or are not confident, don't touch it. Any settings you set past 1.2GHz/1300mV are at your own risk, may damage your handset or even rip a hole in the space-time continuum, then you'll not only look an idiot with a broken handset but Stephen Hawking will be really pissed and you really don't want him trying to crush your toes in that tank he calls a wheelchair.
Best case scenario, try our defaults and only increase voltage in 25mV steps. If you find yourself a 1450mV and your phone still isn't stable then 1.6GHz isn't going to work for you. If battery life is your concern, then consider undervolting in 25mV increments at 1.2GHz or even 1GHz or 800KHz.
mach0boi said:
Ooh okay i didn't knew there was such feature! thank you!
Click to expand...
Click to collapse
I am using the latest version 2.24, i don't see a voltage tab there..I only see Main, Profiles, Advanced, Info, About
@hacre cheers mate
umair9001 said:
I am using the latest version 2.24, i don't see a voltage tab there..I only see Main, Profiles, Advanced, Info, About
Click to expand...
Click to collapse
In Settings -> About Phone what does the Kernel version show?
umair9001 said:
I am using the latest version 2.24, i don't see a voltage tab there..I only see Main, Profiles, Advanced, Info, About
Click to expand...
Click to collapse
Yeah also checked it and I'm also using the latest version. Was about to ask this. Another question, is that voltage tab option kernel related? I'm using cfroot kernel and cannot find that damn voltage tab I'm using tegrak to undervolt. If I knew there's a feature like this in SetCPU, I should've not bought tegrak
All ICS kernel updates can go here. This is for Entropy, LipShitz, Task and any other who is actually working on the ICS kernel.
If you post here, it will be deleted on the spot so just fair warning...
First!
These are always my latest *unsupported* builds:
i9100 Touchwiz Based Roms: http://www.cheatersedge.org/android/i777/TWzImage.tar
AOSP Based Roms: http://www.cheatersedge.org/android/i777/AOKPzImage.tar
Red5 said:
If you post here, it will be deleted on the spot so just fair warning...
Click to expand...
Click to collapse
Come at me bro!
j/k..
Seriously guys.. No fooling around!
Fenny maybe I missed it but do you have a thread to discuss this tw kernel. So far so good. I had already converted OmegaRom 5.1 with everything and was just waiting on a kernel. So far so good. I am gonna look through my notes on how/where to fix the home haptic feedback but other than that all 4 buttons seem to working perfectly. I have sent a pm to the des of OmegaRom to see if they wanted it ported (help porting it to our phones) but i have heard back from them so far. Will continue playing with it with your kernel and test it out. I have run the OmegaRom for about three days already and have had any issues so testing with your kernel is now upon me. Thanks for your work on this. Rich
Fixed: All keys and home haptic working now, though home haptic seems lighter than the other keys.
Sent from my SGH-I777 using xda premium
Until things are cleaned up better, there aren't going to be threads. There's enough to be done and enough things are still not working right that new threads aren't justified yet.
https://github.com/Entropy512/initramfs_galaxys2_ics
https://github.com/Entropy512/kernel_galaxys2_ics
used to build the attached zImage. If you don't know what to do with a raw zImage, this isn't ready for you yet. Simple as that - there is a lot of things missing (like, don't set any profiles in SetCPU with reduced clock frequencies, bad things will happen) - I still haven't tested flashing zips in CWM. nandroid backup/restore seems to work but no guarantees.
You still need to disable Samsung Noise Reduction or use a hacked Phone.apk along with a hacked /system/usr/keylayout/sec_touchkey.kl (see Hellraiser on github) for it to work in a reasonable way. There's probably a large pile of **** still broken. Don't pester me with bug reports - there's a pile of stuff I KNOW I still need to address.
When I tried the attached patch yesterday, it made the screen wake problem significantly worse. Progress in the wrong direction is still progress, as it gives you an idea where to look. I'm going to investigate this further tonight.
It was an attempt to add the missing GPIO definitions that are in the Gingerbread source tree into the ICS kernel.
Entropy, not stating a fact and you KNOW a heck a lot more than I so take this with a grain of salt. I have been playing with lots of different files on a ported/converted i9100 ICS Rom (Omega Rom 5.1) and used these for the usr files and have seen the screen wake issue. http://db.tt/DUe4afdh Maybe it has nothing to do with these though. I have changed many other things like csc folder, csc other files, many other things also. Also I am using the kernel posted by Fenny if that matters or is much different than yours a I have tested it out yet. I only replied here because one of the files I removed was the gpio file completely as other files inside seemed to have the same configurations. Maybe I am WAY off base here. If you want to try the Rom i converted already to see if anything helps let me know and I will send a link to you. Thanks for all your hard work.
Sent From My KickAss ATT SGS2 SPORTING my CobraRom
Sorry.... went to bed and woke up to 50 more pages on other thread.What company shares network with att that has ICS??
Tap-Tap Talking
You know... if this thread is no posting allowed, and not stickied, it is just going to get BURIED.
Sent from my GT-I9100 using XDA
Better off doing how its being done... if use another developers ... you just mirror same issues...if build yourself you know whats what.
Tap-Tap Talking
Entropy512 said:
When I tried the attached patch yesterday, it made the screen wake problem significantly worse. Progress in the wrong direction is still progress, as it gives you an idea where to look. I'm going to investigate this further tonight.
It was an attempt to add the missing GPIO definitions that are in the Gingerbread source tree into the ICS kernel.
Click to expand...
Click to collapse
Isn't 4.0 a total new build from Sammy? Honestly.... from what I'm looking at...I don't see ginger GPIO being compatible..but should be if all they used was duct-tape and staples to parse another kernal together.I'm buying a laptop. You guys use sdk? Entropy..what program are you using for kernal popping? Give me area you want help....will do
Tap-Tap Talking
LipShitz said:
Sorry.... went to bed and woke up to 50 more pages on other thread.What company shares network with att that has ICS??
Tap-Tap Talking
Click to expand...
Click to collapse
AT&T does not share its network with anyone - unless you're thinking of the MVNOs that use their network, which are almost exclusively using low-end prepaid devices.
The I777 is AT&T-unique - no other carrier uses it. Everyone else uses I9100 variants. (Except the Korean carriers, which have the M250S/K/L, and NTT DoCoMo, which has an I9100 variant branded as SC-02 I believe.)
Entropy512 said:
AT&T does not share its network with anyone - unless you're thinking of the MVNOs that use their network, which are almost exclusively using low-end prepaid devices.
The I777 is AT&T-unique - no other carrier uses it. Everyone else uses I9100 variants. (Except the Korean carriers, which have the M250S/K/L, and NTT DoCoMo, which has an I9100 variant branded as SC-02 I believe.)
Click to expand...
Click to collapse
Sc-02-i9100....this is what we have source? I want to run another of att dual core. I made a call to my work for that persons contact info. If I get..(I will) it will help in big way. If you read my first 2 pm's from other day...you know what I mean.
Tap-Tap Talking
Fenny said:
You know... if this thread is no posting allowed, and not stickied, it is just going to get BURIED.
Sent from my GT-I9100 using XDA
Click to expand...
Click to collapse
Ill make sure it stays at the top.
LipShitz said:
Sc-02-i9100....this is what we have source? I want to run another of att dual core. I made a call to my work for that persons contact info. If I get..(I will) it will help in big way. If you read my first 2 pm's from other day...you know what I mean.
Tap-Tap Talking
Click to expand...
Click to collapse
I'll catch up on your PMs soon.
I think I've found the screen wake bug: I misread the #ifdefs in the Gingerbread kernel, and realized they unmap the HOME key GPIO.
There was no such unmapping in the ICS kernel - so the GPIO was left mapped to HOME but left floating, which explains both random wakes and spurious HOME presses. It's also why the patch I posted this morning caused guaranteed screen wakes on resume - GPX3(5) is the HOME GPIO and was set to pulldown by that patch - it's an active-low GPIO.
Attached is a test kernel zImage and two patches - if these solve screen wake for those experiencing it, I'll push the patches to github and probably release the first Daily Driver ICS tonight even though I still haven't fixed SetCPU hangs.
This kernel is for Touchwizz firmwares only - if it solves the problem for everyone I'll work with the CM9 maintainers on integrating the attached patches, which apply to the current state of my github repo.
Let me know when you get to test point. Shoot it over if you want.
I have started writing a new program that will enable you to do parcing of 2 total diff Kernals,full factory and custom ROMs., yank out APK's and cook me dinner. What It will prob be 2gig in size..will streamline it. But when done--- WE WILL RULE THE WORLD!.. yea ok.
Tap-Tap Talking
Here is a kernel I compiled to work with MIUIv4 for this weeks update 2.3.23:
http://www.mediafire.com/?5bm1l4t1bmbd8bm
All good... little laggy(prob CPU hang) 200-1200 CPU set? No wake issue yet. I'm on 1.5 hours.
Tap-Tap Talking
I restarted phone and stuck on startup logo(samsung bla bla bla) i need to hook it up to laptop and flash it. Will not go into cwm with power and both volume. Im on my infuse.
Sent from my SAMSUNG-SGH-I997 using Tapatalk
Sorry Double Post
[KERNEL] Starship-Kernel The Next Generation Stock/AOSP & CM-13 04/25/16 (Linaro 4.9)
Welcome to Starship Kernel The Next Generation (TNG) for the Nexus 6 Shamu. Not much else to say other than more than ever the Kernel is by design light wait, power efficient and moves at Warp Speed. There are no special features to play around with but instead designed to just be installed and just work. If looking for things to play around with may as well just move on as this is probably not the kernel for you.
Have shed some light on a few names below but really need to thank all the Nexus 6 Kernel Developers as could not have done much of anything without them. Before this project I had limited Kernel knowledge. Have been developing since I guess my first Rom had been CM6 based but never had much Kernel dealings. Have always worked joining up with a team to get CM or other AOSP like Roms up and running on TouchWiz,. Sense and other devices far from the Stock Android Experience. In working in groups and teams have for the most part always been the Device File & Vendor Blob guy. Everything I have learned about Kernels has honestly come from sifting through other Kernels and researching the hell out of out of commits until being able to stand on my own 2 feet and think so far have done a dam good job putting together a hell of a Kernel for the Nexus 6 that is extremely stable and performs well beyond expectation besides the big ol Jinx I just through out there.
This is now the new and improved Next Generation moving from say warp 6 to warp 9. Would say 10 but some funky stuff goes down at ten and if you dont know lets just say its not a place you wana go.
Definitely need to throw up thanks to Flair2, Imoseyon and Neoboddy89 as have used a decent amount of their commits in particular..
Features Worth Noting
Have placed features into either groups or single commits that make rather large improvements but are welcome to sift through the Kernels Commit History below as there are many individual changes to numerous to mention in a single post or even page . As mentioned most come from just sifting over and reading commits from every Kernel I could find. Most from Shamu but also some carefully selected from other devices with similar hardware
Kernel Version 3.10.101
Fast USB Charging
LZ4 Compression
Sio & Bfq i/o Schedulers - "bfq" used as default scheduler
ExFAT Support
Power Efficient Workqueues
KGSL Optimixations
Audio Codec Optimizations
Video Firmware Optimizations
CPU Idle Optimizations
GPU Power saving Optimizations
Adreno_Idler
Color Temperature Interface Using PCC
Frandom Support
LED Support (Rom must also Support)
MSM Vidc: Optimizations
Net: Wireless Bcmdhd, Various Optimizations
PM Enhancements.
F2FS 3.10
Starship Kernel, Nough Said!!
Source / Commit History aka change log
https://github.com/Chairshot215/starship_kernel_moto_shamu/commits/mm-mr1?page=1
Download Starship-Kernel_Class_SMTNG7_(Linaro-4.9) (04.16.2016)
Marshmallow 6.0.1 Stock/AOSP
https://www.androidfilehost.com/?fid=24499762636007231
CM-13.0
https://www.androidfilehost.com/?fid=24499762636007230
Again I am not responsible for any negative effects using any of the files on this thread or any post that has been linked in this thread so using is all at your own risk.
seems like nexus 6 development just blew up with new ROMs and kernels, thank you pal
Sent from my Nexus 6 using Tapatalk
Yup!
Does this kernel bypass force encryption?
Team Octos -Nexus 6
force encryption is disabled in the r_2 boot.img but so far is still showing that my N6 is Encrypted. With that said have not performed the recommended factory reset when going from a force encrypted boot.img to one that is not.
System UI Crash
Perhaps I've misinterpreted the OP, but I seem to have a major issue. Assuming this kernel is meant for 5.1.1 AOSP builds, upon flashing the kernel and wiping caches I get System UI crashes that do not allow me to actually start Android... am I at fault here?
That is odd I have flashed on AOSP many a time and have not had any issue. This is pure AOSP I compile without any modifications though. Is it a Rom on the forum, can maybe take a look see what might be the issue.
chairshot215 said:
That is odd I have flashed on AOSP many a time and have not had any issue. This is pure AOSP I compile without any modifications though. Is it a Rom on the forum, can maybe take a look see what might be the issue.
Click to expand...
Click to collapse
An issue like this is usually directed at the ramdisk. You may want to look into moving to an any kernel installer instead.
Sent from my Nexus 6 using Tapatalk
I was unencrypted, flashed the kernel and it booted up and told me encryption failed so I had to wipe and start over and decrypt again. If its disabled why did it encrypt again?
Sent from my Nexus 6 using Tapatalk
I like Starship ROM since my Nexus 5. :laugh::laugh::laugh:
ps000000 said:
I like Starship ROM since my Nexus 5. :laugh::laugh::laugh:
Click to expand...
Click to collapse
I hope you are referring to the Kit-Kat version and not the test flight Lollipop Rom I had up for a few days, lol.
Had pretty much put most of a year counting the L-Previews into that thing but was honestly not happy and did not think it measured up to what I had been releasing under Starship since Froyo so took it down and decided it was time for some off time. May pick it up again with M, Lollipop version had a few nice things could probably use. Think I had just about changed every hex color throughout the entire source. Took me for a loop when Google started using the Teal coloring I was using for a few versions.
calaeb08 said:
I was unencrypted, flashed the kernel and it booted up and told me encryption failed so I had to wipe and start over and decrypt again. If its disabled why did it encrypt again?
Sent from my Nexus 6 using Tapatalk
Click to expand...
Click to collapse
Sorry had a hectic week, maybe you can save me some time. Honestly was trying to stay away from forums for a bit once got my N6. Was not till deciding to post something I looked around. Don't know how long I had only unlocked the bootloader so could fastboot the Kernel. Wanted over weekend to fix this and above mentioned any kernel so is more versatile than stock and pure AOSP. If could save me time and tell me what had done wrong would be a helpful thing. Am all about helpful and not so much smartest in the room syndrome so anyway committed the "fstab" had used if you see the issue at a glance. Otherwise think tomorrow is going to be a couch bound day so will read more into it.
https://github.com/Starship-Android...mmit/5f101827c8a0317d489134de756aacc534215d48
chairshot215 said:
I hope you are referring to the Kit-Kat version and not the test flight Lollipop Rom I had up for a few days, lol.
Had pretty much put most of a year counting the L-Previews into that thing but was honestly not happy and did not think it measured up to what I had been releasing under Starship since Froyo so took it down and decided it was time for some off time. May pick it up again with M, Lollipop version had a few nice things could probably use. Think I had just about changed every hex color throughout the entire source. Through me for a loop when Google started using the Teal coloring I was using for a few versions.
Sorry had a hectic week, maybe you can save me some time. Honestly was trying to stay away from forums for a bit once got my N6. Was not till deciding to post something I looked around. Don't know how long I had only unlocked the bootloader so could fastboot the Kernel. Wanted over weekend to fix this and above mentioned any kernel so is more versatile than stock and pure AOSP. If could save me time and tell me what had done wrong would be a helpful thing. Am all about helpful and not so much smartest in the room syndrome so anyway committed the "fstab" had used if you see the issue at a glance. Otherwise think tomorrow is going to be a couch bound day so will read more into it.
https://github.com/Starship-Android...mmit/5f101827c8a0317d489134de756aacc534215d48
Click to expand...
Click to collapse
I myself know nothing about developing roms or kernels, that's why I'm here to ride on the bus with the smart kids lol. I do know that you can just leave it the way it is, but you gotta let people know it's forced encryption so they don't have to start all over. They can flash that zip that disables it before booting up.
What's the point of a sig anyways?
Well Definitely it for Lollipop, Probably. One thing that bothered me moving from the N5 to N6 is my BT Headset sounded like a warped and scratched record. I had lucked out with that pair in that had been reasonable priced and sounded amazing previously. Have added a few choice commits, well almost 2 pages but the things work like a charm. Decided for that and a few other reasons for one last post until 6.0.
I remember you from the galaxy victory forums :3 thanks for trying with CM. We were SOL, but theres still development going on there!
Sent from my Nexus 6 using Tapatalk
NolenUmar said:
I remember you from the galaxy victory forums :3 thanks for trying with CM. We were SOL, but theres still development going on there!
Sent from my Nexus 6 using Tapatalk
Click to expand...
Click to collapse
Yeah I actually am still receiving emails about the Victory. Not that I could ever return to either the screen size or Touchwiz but wish I still had the device. Still feel like that SOB defeated me. Had been I think the 3rd device I worked on developing from the CM source and was so dead set on doing everything crazy proper so it could be an officially supported device. Wish I still had the device as do not like the feeling of spending countless hours on something and then leave unfinished. Think in the end all but GPS, Camera and that dang reboot when switching from Wifi to LTE. Think I used the Apexq as a template for getting everything else going. Otherwise wish the community luck. The phone was nice for the Price just a shame it has been years and everyone is still stuck on Stock with last I checked a bunch of out dated Kernels. Anyhow thats my Victory, rather defeated Rant. Remember at one point had got so frustrated used some command I don't remember off the top of my head and a lib decompiler and made the below list of all the files and their dependencies when trying to put together a vendor blob list.
http://pastebin.com/SFyJ14kv
Whats crazy about just pulling up this list is that I see the creation date was todays date but in 2013. Just had to mention that SOB device. Now I’m all worked up, lol.
Updated the M Kernel to r1.2 as works fine with SuperSU 5.1
This is an Encrypted Kernel. Will probably change with next update but for now it is Encrypted.
Now 2.0 with a few optimizations. Forgot about encryption but again looking for next update,lol.
Eill give it a try when it doesnt force enycrption
Sent from my Nexus 6 using Tapatalk
calaeb08 said:
Eill give it a try when it doesnt force enycrption
Sent from my Nexus 6 using Tapatalk
Click to expand...
Click to collapse
Yeah will need to look at that again. I use the same any-kernel installer for Lollipop-r_3.0-Kernel and M-6.0-r_2.0-Kernel.
With the L Kernel either flashing with an already un-encrypted Rom or flashing and performing a data wipe / factory reset with an encrypted Rom all works fine without encryption being forced.
Could be I just messed up the test with the M-6.0-r_2.0-Kernel and it actually does not enforce encryption as it uses the same fstab.shamu as the L version . Just did not feel like going through a data wipe to double check so am putting it off until the next release. Otherwise if you are not encrypted and remove the fstab.shamu file from the Ramdisk folder in the M-6.0-r_2.0-Kernel zip before flashing the Rom should still stay un-encrypted. I have at least not seen or read anything stating there is a difference between L&M when it comes to encryption.
Otherwise this is the anykernel installer used in both L&M. The only difference is the zImage-dtb I use.
https://github.com/Starship-Android/anykernel
chairshot215 said:
Yeah will need to look at that again. I use the same any-kernel installer for Lollipop-r_3.0-Kernel and M-6.0-r_2.0-Kernel.
With the L Kernel either flashing with an already un-encrypted Rom or flashing and performing a data wipe / factory reset with an encrypted Rom all works fine without encryption being forced.
Could be I just messed up the test with the M-6.0-r_2.0-Kernel and it actually does not enforce encryption as it uses the same fstab.shamu as the L version . Just did not feel like going through a data wipe to double check so am putting it off until the next release. Otherwise if you are not encrypted and remove the fstab.shamu file from the Ramdisk folder in the M-6.0-r_2.0-Kernel zip before flashing the Rom should still stay un-encrypted. I have at least not seen or read anything stating there is a difference between L&M when it comes to encryption.
Otherwise this is the anykernel installer used in both L&M. The only difference is the zImage-dtb I use.
https://github.com/Starship-Android/anykernel
Click to expand...
Click to collapse
You'd probably be better off using hellsgods anykernel scripts. Though, I'm not sure why yours isn't working to disable it. Theres also a fed patcher that should fix it. It kinda defeats the purpose of anykernel if your replacing files in the ramdisk instead of editing them.
Sent from my Nexus 6 using Tapatalk
Hello all, I am looking for a way to enable all cores on the Honor 5x. If you use Kernel Adiutor (and I'm sure you do) you'll notice that 99% of the time (save for a reboot) your little cluster is offline when using any AOSP ROM, now the only way I've found to enable them is to edit the value in the active file located in /sys/module/cluster_plug directory. The issue with this method is that it just enables them, 95% of the workload is still handled by the big cluster, even when it's straining itself the little cluster fails to pick up any of the workload. I have done clean installs of the Blaze kernel and the issue is still not resolved. Any incite into this issue will be greatly appreciated. Thanks.
You'll need to mess with:
/sys/devices/system/cpu/cpu0/core_ctl/min_cpus
/sys/devices/system/cpu/cpu0/core_ctl/max_cpus
/sys/devices/system/cpu/cpu4/core_ctl/min_cpus
/sys/devices/system/cpu/cpu4/core_ctl/max_cpus
It takes integer value ranging from 0-4. 0-4 meaning how many cores you want online per cluster.
The only issue is that I don't have /core_ctl directory that you've specified, I don't recall ever having it on this ROM, though I could be wrong. I'm using the krexus ROM in case I hadn't specified before.
I know, reading the stock ROM forums I got very excited to see the before mentioned information that was posted only to see that said (/core_ctl) directory was missing from any AOSP ROM I had used. This is the one thing that is holding me up from giving up my Windows phone as my business phone (the lag as a result of only being able to use 4 cores is intolerable in my line of work) even giving a link to what all these directory files mean would be very helpful. Thanks.
You could google what those directory means and that would give you that answer.
I have done this (and I consider myself well versed in the ways of the interwebs and I rarely come up with anything useful but I've been working on a solution for my original question and feel I am close to achieving it. I will post once I do.....though if anyone has ANY suggestions at all I'm open to try, all of my discoveries have been made through trial and error.
tboned82 said:
I have done this (and I consider myself well versed in the ways of the interwebs and I rarely come up with anything useful but I've been working on a solution for my original question and feel I am close to achieving it. I will post once I do.....though if anyone has ANY suggestions at all I'm open to try, all of my discoveries have been made through trial and error.
Click to expand...
Click to collapse
You may be needing a custom kernel to achieve this successfully.
Sent from my honor 5X using XDA Labs
adriansticoid said:
You may be needing a custom kernel to achieve this successfully
Click to expand...
Click to collapse
I can't recall if I mentioned it or not but I'm using the blaze kernel at the moment (as far as I know it's the only custom one available for this phone?) Also the CPU control I desire is available inside the stock KIWI ROM, just wish I knew of a way to "port" that hotplug to a AOSP ROM.... thinking SELinux policy is prohibiting me from achieving the CPU control I'm after, but not sure if it's the only thing at play when it comes to this issue.
tboned82 said:
I can't recall if I mentioned it or not but I'm using the blaze kernel at the moment (as far as I know it's the only custom one available for this phone?) Also the CPU control I desire is available inside the stock KIWI ROM, just wish I knew of a way to "port" that hotplug to a AOSP ROM.... thinking SELinux policy is prohibiting me from doing this, but not sure if it's the only thing at play when it comes to this issue.
Click to expand...
Click to collapse
Have you joined the beta channel of Blaze in Telegram?
adriansticoid said:
Have you joined the beta channel of Blaze in Telegram?
Click to expand...
Click to collapse
I have not, but would be very interested, what is Telegram?
tboned82 said:
I have not, but would be very interested, what is Telegram?
Click to expand...
Click to collapse
It's a messaging app. Just like Whatsapp, but with some diferences. You can check it in the Play Store. Telegram group link is in the Blaze kernel thread.
Wow thank you, I dirty flashed it (since version 2 dirty flashed fine) and didn't have pleasing results, going to do a clean flash AOSP, but those hotplug features are exactly what our phones need! Who's ready to hunt down some flagships?
tboned82 said:
Wow thank you, I dirty flashed it (since version 2 dirty flashed fine) and didn't have pleasing results, going to do a clean flash AOSP, but those hotplug features are exactly what our phones need! Who's ready to hunt down some flagships?
Click to expand...
Click to collapse
You didn't have screens of death?
Sent from my honor 5X using XDA Labs
tboned82 said:
didn't have pleasing results
Click to expand...
Click to collapse
Don't bother with blaze kernel. It's heavily flawed. As soon as you turn on hotplugging phone will crash and you have to reboot. Unfortunately development seems to be halted.
alpinista82 said:
Don't bother with blaze kernel. It's heavily flawed. As soon as you turn on hotplugging phone will crash and you have to reboot. Unfortunately development seems to be halted.
Click to expand...
Click to collapse
Yeah the developer have not seen action the past few weeks.
adriansticoid said:
You didn't have screens of death?
Click to expand...
Click to collapse
I apologize for my absence, I really hate being that "guy" but all my free time has been devoted to tracking down a nasty electrical gremlin in my sister in laws car, but no I have never had any adverse effects from dirty flashing anything really
alpinista82 said:
Don't bother with blaze kernel. It's heavily flawed. As soon as you turn on hotplugging phone will crash and you have to reboot. Unfortunately development seems to be halted.
Click to expand...
Click to collapse
I currently have blaze kernel installed and using the method I've mentioned before am able to enable all cores, but with very poor load balancing, and the beta version is far from RTM at the moment so guess I'm stuck with version 2 for the time being.
adriansticoid said:
Yeah the developer have not seen action the past few weeks.
Click to expand...
Click to collapse
I have noticed this as well, which is unfortunate because the dev seems like a very talented coder who is quite capable of the task at hand, sometimes life gets in the way of the things we would like to do so I'm just going to be patient and hope he picks back up on the project.
tboned82 said:
I apologize for my absence, I really hate being that "guy" but all my free time has been devoted to tracking down a nasty electrical gremlin in my sister in laws car, but no I have never had any adverse effects from dirty flashing anything really
I currently have blaze kernel installed and using the method I've mentioned before am able to enable all cores, but with very poor load balancing, and the beta version is far from RTM at the moment so guess I'm stuck with version 2 for the time being.
I have noticed this as well, which is unfortunate because the dev seems like a very talented coder who is quite capable of the task at hand, sometimes life gets in the way of the things we would like to do so I'm just going to be patient and hope he picks back up on the project.
Click to expand...
Click to collapse
It's been that story for many developers man. A great project paused because life hit hard again. I believe he'll come back to it soon.
tboned82 said:
Hello all, I am looking for a way to enable all cores on the Honor 5x. If you use Kernel Adiutor (and I'm sure you do) you'll notice that 99% of the time (save for a reboot) your little cluster is offline when using any AOSP ROM, now the only way I've found to enable them is to edit the value in the active file located in /sys/module/cluster_plug directory. The issue with this method is that it just enables them, 95% of the workload is still handled by the big cluster, even when it's straining itself the little cluster fails to pick up any of the workload. I have done clean installs of the Blaze kernel and the issue is still not resolved. Any incite into this issue will be greatly appreciated. Thanks.
Click to expand...
Click to collapse
flash official cm 12.1 built. lol no deep sleep and all cores online...go for it.
methuselah said:
flash official cm 12.1 built. lol no deep sleep and all cores online...go for it.
Click to expand...
Click to collapse
Drains battery like hell. Lol.
Sent from my Galaxy Tab 3 using XDA Labs
methuselah said:
flash official cm 12.1 built. lol no deep sleep and all cores online...go for it.
Click to expand...
Click to collapse
I had thought of doing this, though I don't see any cm 12.1 links in the Honor 5x thread, just 13, (though I'm at work at the moment and have to be stealthy about my research...errgghh Damn kids and their Snapchat) and I have to admit I've kind of fallen in love with the Krexus ROM and am apprehensive to flash another. Just need that hotplug support (and OTA updates would be nice as well
Hey
This will not be a (much) maintained thread. This is the main thread: G5 forum
Kernel is for Lineage based roms. Works with Android 11
US996 = Officially unlocked
US996Dirty = Unlocked "the other way"
It was tested to give about 30% longer battery life, using youtube playback constantly, than stock lineage/lighthouse kernels.
Stock (original lg) rom was tested also, which lasted 7h in the test. The same as my kernel, but I dare say my kernel will be faster
in addition, but it's obviously difficult to compare stock vs lineage in that manner (stock being very old un-optimized userspace).
Keep in mind the number above is from G5 which has a 2800mAh battery. The tester's battery was also a bit worn.
-----------------------------
Downloads:
V0.8 - Androidfilehost
Beta builds - Androidfilehost
-----------------------------
UPDATE - feb 14 2022
Version 0.7 Beta2 uploaded. You'll find it in the link above.
UPDATE - april 26 2022
For H990 - version 0.7 beta4 - To solve crashing (obsolete with 0.7 stable build)
UPDATE - june 28 2022
Version 0.7 uploaded -- Built with gcc12.1, disabled kpti for better performance and enabled zram (with upstreamed lz4, zsmalloc, zram)
Removed the old builds from this post
UPDATE - feb 19 2023
Version 0.8 uploaded
Source
Thanks to @AShiningRay
I've put his undervolt, and tweak to schedutil in v0.7
I will try building the H990DS variant , Will send here.
Mysteriouslog6 said:
I will try building the H990DS variant , Will send here.
Click to expand...
Click to collapse
Don't bother, I'm building now. I forgot the 990 is also a very common device.
I will also upload the final/stable build for each device at some point.
Edit: Added to post #1
Hi, is the IR working with this kernel? Thanks
timba123 said:
App says so
Click to expand...
Click to collapse
Unfortunately this app only checks if the IR blobs have been implemented and can be accessed by the phone's OS, because it reports the same info on Lineage's stock kernel where the IR doesn't work properly after sending the first signal, so that app is not a reliable way to test it. I could be wrong tho, since i would really like to test this kernel's IR by myself, but it throws me right into fastboot when flashing it on top of either LOS 18.1 or Lighthouse.
IR is not working. I've looked into that and i understand now why nobody has ir working.
The main driver part is in userspace, so we need to implement a solution from a msm8996
LeEco device which has the same ir chip (maxq616), on the ROM side. This is in official Lineage
here: https://review.lineageos.org/c/LineageOS/android_device_leeco_msm8996-common/+/274548
GitHub - LineageOS/android_device_leeco_msm8996-common
Contribute to LineageOS/android_device_leeco_msm8996-common development by creating an account on GitHub.
github.com
People have been saying Gamma kernel works; that may be, but looking at his sources show
no changes in that regard. So then he either wrote his own driver based on NDA restricted
documents or he found something ready-made. In any case; not making it public would be
the right ting to honor the NDA and not get in trouble.
Just putting it out here for potentially interested devs. I have shown this to one of the Lighthouse
devs, and he is currently trying to port those changes.
AShiningRay said:
I could be wrong tho, since i would really like to test this kernel's IR by myself, but it throws me right into fastboot when flashing it on top of either LOS 18.1 or Lighthouse.
Click to expand...
Click to collapse
I see you have a H910 device. Anyone else have the same problem?
askermk2000 said:
I see you have a H910 device. Anyone else have the same problem?
Click to expand...
Click to collapse
As far as i tested some time ago, gamma kernel had the same behaviour after flashing, but i tested that one on LOS 17.1. It might be because my refurbished V20 is a bit weird in regards to the SoC. No matter where i check it, the phone reports a Snapdragon 821 (MSM8996Pro) with clock tables all the way up to 2.34Ghz and etc even on LG's stock rom, which i find really strange because the V20's are supposed to have a Snapdragon 820, so i'm not really sure if that is the reason behind the fastboot problem, since both LG stock and Lineage's kernel works just fine.
And as for gamma, even the IR on that seems a bit finicky at best due to some reports on V20 Reddit also saying it doesn't work, making it even less likely to ascertain exactly "how" or "why" it works there. I am also compiling a custom kernel for the V20 based on LOS 18.1 sources and from what i saw, gamma's source has basically identical IR files, be it LIRC or IRRC, and some logging about the IR has specifically shown me that the kernel is actually issuing the signal correctly, but something breaks between the kernel and the OS, making the ConsumerIRService return error -1 right after that., which eventually led me to this as well:
[REF] How Infrared is (not) working on LePro3 - some infos for IR devs
So, I was also interested why 3rd party infrared apps are not working on the LePro 3, and did some debugging. This thread somehow documents my findings step by step... Edit - Dec 1, 2016: As the postings below got a little bit technical, I'll...
forum.xda-developers.com
It might be something outside of the kernel, but i don't have the skills to mess around with ROMs yet and logging it is the best i can do on them.
AShiningRay said:
As far as i tested some time ago, gamma kernel had the same behaviour after flashing, but i tested that one on LOS 17.1. It might be because my refurbished V20 is a bit weird in regards to the SoC. No matter where i check it, the phone reports a Snapdragon 821 (MSM8996Pro) with clock tables all the way up to 2.34Ghz and etc even on LG's stock rom, which i find really strange because the V20's are supposed to have a Snapdragon 820, so i'm not really sure if that is the reason behind the fastboot problem, since both LG stock and Lineage's kernel works just fine.
Click to expand...
Click to collapse
Ah ok. I know why then.
You see, me and Omar removed some board definitions from our kernel to make it smaller. Those where definitions for sd821 V20s - which we gathered was for some prototype devices which would likely never be in circulation.
But here you are with one such device
Edit: see here: https://github.com/stendro/msm8996_...a80921570789d20375f0b62516be3c6973ccb3375552a
askermk2000 said:
Ah ok. I know why then.
You see, me and Omar removed some board definitions from our kernel to make it smaller. Those where definitions for sd821 V20s - which we gathered was for some prototype devices which would likely never be in circulation.
But here you are with one such device
Edit: see here: https://github.com/stendro/msm8996_...a80921570789d20375f0b62516be3c6973ccb3375552a
Click to expand...
Click to collapse
Welp, at least the phone is doing its job of being a device mainly for development, lol. It also means your kernel probably works fine on H910's running a snapdragon 820, and thanks for clearing that up, makes me feel a bit more comfortable knowing that the chance of my phone being some kind of Frankenstein is a bit smaller.
If you need any testing or logs in the future, i'll be happy to help.
timba123 said:
LG V20 Pro Coming soon to Japan - Trendy Techz
In this post we shared the complete details of upcoming smartphone LG V20 Pro which is coming soon to Japan store. Complete details are here in this post.
trendytechz.com
Click to expand...
Click to collapse
Mine doesn't look very similar to this Pro version, since my variant is actually a H910 and save for the SoC, everything else fits right in line with other standard V20's (the screen for example is clearly 5.7", since it is relatively bigger than my 5.5" Redmi Note 4 despite having smaller bezels, while the V20 Pro reportedly has a 5.2" screen plus a Snap 820, mine also has 64GB of internal storage versus the Pro's 32GB), if i flash a kernel or ROM of any other variant it either gives me a very glitched screen rendering right at boot (US996) or doesn't boot at all.
Edit: After finding some pictures of the Pro model's back, i can now affirm that the design is completely different from mine, even the camera layout that puts the flash and laser in the center and not on the sides, while the one i have is the opposite just like the default mode, so it definitely isn't the Japanese Pro version, but thanks for the heads-up.
AShiningRay said:
And as for gamma, even the IR on that seems a bit finicky at best due to some reports on V20 Reddit also saying it doesn't work, making it even less likely to ascertain exactly "how" or "why" it works there. I am also compiling a custom kernel for the V20 based on LOS 18.1 sources and from what i saw, gamma's source has basically identical IR files, be it LIRC or IRRC, and some logging about the IR has specifically shown me that the kernel is actually issuing the signal correctly, but something breaks between the kernel and the OS, making the ConsumerIRService return error -1 right after that., which eventually led me to this as well:
It might be something outside of the kernel, but i don't have the skills to mess around with ROMs yet and logging it is the best i can do on them.
Click to expand...
Click to collapse
The Lighthouse dev I mentioned has replied. He says that LG has proprietary blobs specifically for IR, and LeEco don't. He'd rather make it work as intended with the blob, instead of using some hacky solution.
So then it makes sense that it work on first try and possibly working normally on gamma - there is some facility already there. Why it doesn't work I can't quite fathom though.
I have looked at source, dtb, configuration... but I may have missed something. I may have to compare to stock config, at least we know it works there.
askermk2000 said:
The Lighthouse dev I mentioned has replied. He says that LG has proprietary blobs specifically for IR, and LeEco don't. He'd rather make it work as intended with the blob, instead of using some hacky solution.
So then it makes sense that it work on first try and possibly working normally on gamma - there is some facility already there. Why it doesn't work I can't quite fathom though.
I have looked at source, dtb, configuration... but I may have missed something. I may have to compare to stock config, at least we know it works there.
Click to expand...
Click to collapse
I guess the only reason the IR supposedly works in Gamma is due to proprietary code not released on Github, because i ran through a massive gitlog of its repository going all the way back to january 2016 and there is no relevant commit about LG's IR as well, only the CAF updates seem to change IR files, and those seem to be present on lineage's source as far as the files are concerned. I could also have missed something, but it is highly unlikely at this point. We could at least find someone that managed to make the Infrared work on Gamma and check if they are running the latest ROMs or if the older ones like LOS 16 are also part of the reason why it works there.
And about the Lighthouse dev's response: That's a bummer, LG could have gone with the SDK approach as LeEco did, now i can just hope he manages to port the proprietary IR blobs successfully, since the only alternative left would be to reverse engineer it.
AShiningRay said:
I guess the only reason the IR supposedly works in Gamma is due to proprietary code not released on Github, because i ran through a massive gitlog of its repository going all the way back to january 2016 and there is no relevant commit about LG's IR as well, only the CAF updates seem to change IR files, and those seem to be present on lineage's source as far as the files are concerned. I could also have missed something, but it is highly unlikely at this point. We could at least find someone that managed to make the Infrared work on Gamma and check if they are running the latest ROMs or if the older ones like LOS 16 are also part of the reason why it works there.
And about the Lighthouse dev's response: That's a bummer, LG could have gone with the SDK approach as LeEco did, now i can just hope he manages to port the proprietary IR blobs successfully, since the only alternative left would be to reverse engineer it.
Click to expand...
Click to collapse
Was my conclusion first as well.
I checkout to gamma-pie source and did a quick make, to create .config for H850. Then I compared to lineage h850 config.
There are two options that stand out that are enabled on gamma but not on lineage, those are:
CONFIG_DEVPORT
CONFIG_AUDITSYSCALL with accompanying (CONFIG_AUDIT_WATCH and CONFIG_AUDIT_TREE)
I did see this before but didn't pay much attention, but now that we know blobs are present, perhaps they make use of some of those facilities.
askermk2000 said:
Was my conclusion first as well.
I checkout to gamma-pie source and did a quick make, to create .config for H850. Then I compared to lineage h850 config.
There are two options that stand out that are enabled on gamma but not on lineage, those are:
CONFIG_DEVPORT
CONFIG_AUDITSYSCALL with accompanying (CONFIG_AUDIT_WATCH and CONFIG_AUDIT_TREE)
I did see this before but didn't pay much attention, but now that we know blobs are present, perhaps they make use of some of those facilities.
Click to expand...
Click to collapse
There's also a possibility that those configs are only needed on older android versions, as that gamma branch is for android 9 and we are currently on 11. But nonetheless i will add those configs into my kernel and see if it compiles, then check if the IR status changes, shouldn't be much of a problem. I'll report back in a few hours.
Edit: Managed to test it sooner than expected (thankfully no repo sync was needed on lineage sources), and there was no change whatsoever, the infrared still fails after the first transmit signal.
The audit configs themselves are mostly used to audit file changes in the kernel so it is more of a system admin feature, while the devport one was more promising, since there was a chance that the IR could be using /dev/port as a way to let the apps interact with it directly, and considering how hacky some proprietary code can be (LG messes up even the KDZ recovery files sometimes, like with my old LG Leon, essentially making it unrecoverable), so you never know.
Turns out the lineage kernel source code has all of those configs defined in the files and they were just disabled.
AShiningRay said:
There's also a possibility that those configs are only needed on older android versions, as that gamma branch is for android 9 and we are currently on 11. But nonetheless i will add those configs into my kernel and see if it compiles, then check if the IR status changes, shouldn't be much of a problem. I'll report back in a few hours.
Edit: Managed to test it sooner than expected (thankfully no repo sync was needed on lineage sources), and there was no change whatsoever, the infrared still fails after the first transmit signal.
The audit configs themselves are mostly used to audit file changes in the kernel so it is more of a system admin feature, while the devport one was more promising, since there was a chance that the IR could be using /dev/port as a way to let the apps interact with it directly, and considering how hacky some proprietary code can be (LG messes up even the KDZ recovery files sometimes, like with my old LG Leon, essentially making it unrecoverable), so you never know.
Turns out the lineage kernel source code has all of those configs defined in the files and they were just disabled.
Click to expand...
Click to collapse
Thanks for testing. I'm compiling gamma kernel now to see if it works, else there's no point in messing with that source.
Another interesting bit is module signature. Gamma has modules enabled and signature disabled. Then I though it might
be possible for blobs to be signed and verified in a similar manner as the *.ko modules in lib/modules.
I asked on irc with some knowledgeable folks, and the answer was: yes its possible. but I'll see at least if gamma works as is, if it does then that could be the cause.
askermk2000 said:
Thanks for testing. I'm compiling gamma kernel now to see if it works, else there's no point in messing with that source.
Another interesting bit is module signature. Gamma has modules enabled and signature disabled. Then I though it might
be possible for blobs to be signed and verified in a similar manner as the *.ko modules in lib/modules.
I asked on irc with some knowledgeable folks, and the answer was: yes its possible. but I'll see at least if gamma works as is, if it does then that could be the cause.
Click to expand...
Click to collapse
Understood. As it stands, all modules compiled by the lineage kernel are test modules for TCP, IO Blocks, optional TCP algorithms and other nonessential things, everything else is baked into the kernel itself. The general lack of warnings of any kind pertaining to them also means that everything that should be compiled is being completed without any problems, unless lineage's default GCC and Clang are implicitly omitting those errors. I'm almost releasing my custom kernel here on the V20 subforum as well, so it will be easier to find people to test it too.
Ok, so it seems it didn't work.
I haven't used the phone previously as a remote, but I got Asmart remote on there, and have a samsung tv in standby.
I tried to shuffle through all samsung models pressing the power button, but tv didn't react.
Then I tried looking at the ir led through a phone camera while pressing button and I could not see anything.
askermk2000 said:
Ok, so it seems it didn't work.
I haven't used the phone previously as a remote, but I got Asmart remote on there, and have a samsung tv in standby.
I tried to shuffle through all samsung models pressing the power button, but tv didn't react.
Then I tried looking at the ir led through a phone camera while pressing button and I could not see anything.
Click to expand...
Click to collapse
That's the worst part actually, i only managed to ascertain that it works on the first transmission because my IR app had a preset that worked on my LGTV right at the start. Mi Remote for example behaves just as your app is behaving, where my TV doesn't respond at all to it, so i guess the phone's IR hangs no matter if it sends the correct signal or not. The only difference there is that my H910 still flashes the IR light even after the first transmit while using Lean Remote, but with a massive delay between each cycle and even freezing the app for a while, but still, only the first command is issued.
askermk2000 said:
The Lighthouse dev I mentioned has replied. He says that LG has proprietary blobs specifically for IR, and LeEco don't. He'd rather make it work as intended with the blob, instead of using some hacky solution.
So then it makes sense that it work on first try and possibly working normally on gamma - there is some facility already there. Why it doesn't work I can't quite fathom though.
I have looked at source, dtb, configuration... but I may have missed something. I may have to compare to stock config, at least we know it works there.
Click to expand...
Click to collapse
Issue is most likely kernel related OR consumerIR related. Reason it works on gamma is that it's using an older version of the linux kernel source compared to say los 18.1. After the kernel was upstreamed, Ir broke.