Can someone port this kernek to ATT?
http://forum.xda-developers.com/showthread.php?t=1263838
tassadar898 said:
Can someone port this kernek to ATT?
http://forum.xda-developers.com/showthread.php?t=1263838
Click to expand...
Click to collapse
Its possible, but there are differences in the softkeys, charging hardware, and nfc at the minimum, so it will take a little work to port that over entirely. What would be better is for one of our current kernel modders to add some of the features of the SIYAH kernel over to their own.
I plan on pulling in 100 MHz support.
He doesn't have that much more, other than extremely experimental features that if you read the thread, tend to break.
Gokhan is quite talented, but he's also VERY aggressive - if you're more careful, you don't have to go through long beta periods with lots of broken releases like he does.
He also released source code for older kernels as megapatches, and now releases as straight full-source tarball drops. It makes separating the good from the bad EXTREMELY difficult.
As far as features he has that I don't currently:
1) 100 MHz support - I plan on this one, it's a fairly high priority as part of my current power management research
2) Crazy wacky alternative governors - these are a great way to somehow combine lag and poor battery life all in one
3) Charge current control - not possible on our devices, we have a different (very crippled) charger IC
4) Touchscreen stuff - I have seen no reports of people having touchscreen issues. If it ain't broke don't fix it.
5) BLN - I'm on the fence on this one. I think the I777 community may actually have the maturity to handle this one. (BLN's dirty little secret on the I9100/I777 - it holds a wakelock while the light is on. This means you lose 50% battery overnight instead of <10% if a notificiation comes in right after bed.)
Entropy512 said:
5) BLN - I'm on the fence on this one. I think the I777 community may actually have the maturity to handle this one. (BLN's dirty little secret on the I9100/I777 - it holds a wakelock while the light is on. This means you lose 50% battery overnight instead of <10% if a notificiation comes in right after bed.)
Click to expand...
Click to collapse
Would it be possible to get past the wakelock issue if you could program that the BLN shuts off after, say 30min, or user defined? That would work in my case but not sure if everyone universally would like it that way. Just a thought...
Hey Entropy nice to see you here! In siyah you can control the GPU voltage for undervolting. I currently do it using the Tegrak kernel module and I reduced the minimum step of 160 mhz to 750mv down from 950mv. I've noticed a nice bump in battery life. In his 2.1 beta version he also has this available feature
SiyahKernel v2.1 - not released yet -
Time to break some records... both performance-wise and battery-wise...
Overclocking part is optimized and bus frequency selection is modified.
User customizable frequency levels. you still have 8 steps, but you will be able to customize them. wanna change 100 to 150 as 100MHz is not stable on your device? wanna change 1400 to 1304 and 1600 to 1504? or increase 1600 to 1696?
User customizable bus frequency selection. no more overheating. if you are a battery freak, just set it to minimum and your device will last more than ever.
Based on Update3 sources...
Thanks for developing for us!!
I'll look into GPU voltage control once I finish my current power management adventures.
Custom frequency steps seems like asking for stability problems. There's no way this is getting ported until he releases 2.1 final, since he isn't very good about GPL compliance.
Thanks! I look forward to testing. If you need a guinea pig let me know.
Entropy512 said:
I'll look into GPU voltage control once I finish my current power management adventures.
Custom frequency steps seems like asking for stability problems. There's no way this is getting ported until he releases 2.1 final, since he isn't very good about GPL compliance.
Click to expand...
Click to collapse
GPU voltage doesn't bring that much other than stabilizing 400MHz, undervolting doesn't go that far down from stock voltages, unless you underclock heavily too.
Also get off his horse about GPL . The license states that you've got 90 days to release your code, until now he released it within the day for final versions, and betas are no longer released on XDA to get off that technicality of the 5 day rule.
There's enough kernels out there with the "stable" philosophy, some of which barely differentiate from stick sources, so people can go and use those if they want to. Siyah is more a Swiss army knife, but you'll have to be careful not to cut yourself, and it's more fun for some to tinker with the phone.
Edit: What you should port though, is update3 sources, those bring significant upgrades in battery life, speed and sound quality.
AndreiLux said:
GPU voltage doesn't bring that much other than stabilizing 400MHz, undervolting doesn't go that far down from stock voltages, unless you underclock heavily too.
Click to expand...
Click to collapse
Yeah, I figured as much, which is why it's pretty low on my priorities list
Also get off his horse about GPL . The license states that you've got 90 days to release your code, until now he released it within the day for final versions, and betas are no longer released on XDA to get off that technicality of the 5 day rule.
Click to expand...
Click to collapse
It says that nowhere. HTC claimed they had 90 days and that is a GPL violation. Easy enough to Google that one. It kind of bit them in the ass though - http://thread.gmane.org/gmane.linux.kernel/1048027 and https://freedom-to-tinker.com/blog/sjs/htc-willfully-violates-gpl-t-mobiles-new-g2-android-phone
After much media pressure they backed down and released sources in only 7 days.
GPLv3 gives an explicit 30-day grace period for resolving violations, but the kernel is not v3, it's GPLv2.
I really should stop pointing Gokhan towards fixes since he's a one-way street.
There's enough kernels out there with the "stable" philosophy, some of which barely differentiate from stick sources, so people can go and use those if they want to. Siyah is more a Swiss army knife, but you'll have to be careful not to cut yourself, and it's more fun for some to tinker with the phone.
Click to expand...
Click to collapse
Yup - If someone else wants to port his more aggressive features they can try - it's just not coming from me.
Edit: What you should port though, is update3 sources, those bring significant upgrades in battery life, speed and sound quality.
Click to expand...
Click to collapse
I'll have to look into that - As of a few weeks ago, the AT&T I777 sources were new enough that I9100 kernels (including Siyah) started to be based off of them. The question is - while Update2 to Update3 is a big improvement, is I777 to update3 such an improvement?
I'll have to check those out tonight and diff them.
update3 is a vastly bigger update than what the AT&T sources were to update2. Performance wise, it's a clear-cut, audio too. As for battery life check back in the AOS thread.
Looking forward to see the update being incorporated.
AndreiLux said:
update3 is a vastly bigger update than what the AT&T sources were to update2. Performance wise, it's a clear-cut, audio too. As for battery life check back in the AOS thread.
Click to expand...
Click to collapse
I'm going to start this over the next week - I've split update3 into what should be separate independent patchsets by component (touchkey, audio, wifi, etc.)
Last one is likely going to be the machine-specific ARM stuff - because that means rewriting the clock control patches completely.
Related
So I was just looking around the Qualcomm open source (CodeAurora) repositories and noticed that lots of interesting things are going on over there for the qsd8x50 that aren't yet in our N1 kernels.
One of the most potentially useful things to us, is adaptive undervolting, that always chooses the optimal voltage level based on the current temperature and silicon process variations.
https www codeaurora.org/gitweb/quic/chrome/?p=kernel.git;a=commit;h=621d0e14e6fcf454974634cf822f06fba1bd6816
If someone could get this into an N1 kernel, we wouldn't need any more experimentation with undervolting and could always run at the maximum possible stable voltage.
Other interesting changes include USB host support (although it's unlikely the N1 hardware is physically wired to allow for this):
https www codeaurora.org/gitweb/quic/chrome/?p=kernel.git;a=commit;h=109894cac8d01c6273cfa0466f7823a04e919bea
Unfortunately, the Chromium kernel for MSM/QSD seems to be structured quite differently and being worked on by a different team to the Android kernel. Still, it'd be nice to see someone attempt to port at least the AVS patch to a CM kernel.
p.s. can a moderator please approve my account to directly include links? This manual link-munging is getting annoying
This sounds interesting
I know a lot of the devs here check out Qualcomm's latests postings, so hopefully they are aware of this...
Also of interest is their framebuffer driver. We need it in the N1 kernel to use their X11 driver.
Has anyone had any luck getting a CAF kernel booting on the N1?
Markdental said:
I know a lot of the devs here check out Qualcomm's latests postings, so hopefully they are aware of this...
Click to expand...
Click to collapse
Yeah I know, but this is their Chromium/ChromeOS kernel, not their Android kernel. Might have gone unnoticed (I for one, had not thought to look there -- I'd have thought the only Chrome-specific kernel changes would've been the X11 driver -- why should platform-power-management changes not be shared across both kernels?)
I ported AVS code to the N1 kernel.
You can download the experimental version here:
http://forum.xda-developers.com/showthread.php?t=654416
AVS kernel is very experimental, and I expect it not to be fully stable.
Also, it looks 1.275v is not really enough for 1.1 GHz - at least AVS complains that it cannot find stable voltage.
Ivan Dimkovic said:
Also, it looks 1.275v is not really enough for 1.1 GHz - at least AVS complains that it cannot find stable voltage.
Click to expand...
Click to collapse
Funny that: a processor rated for 1 GHz (in a world where if they could get away with selling it as a 1.1 GHz processor they certainly would have) isn't actually capable of 1.1 GHz without compromising stability and/or lifetime. Who'd have thought
Cheers for porting it to your kernel though, I'll be interested to see if it makes much difference to battery life.
I got no problems with AVS so far - I will release new kernel update tonight with AVS with no overclocking, as AVS and overclocking do not mix well for some people. Also, I provided the patch-code on my github, so other kernel developers can use AVS too, if they wish. There is still an ugly hack inside (one liner, though) which I will fix tonight, too.
Regarding "getting away" with faster CPU (Qualcomm) - I am not really sure if they would do it. There are market pressures, and CPUs are not always binned according to test validation - rather, other factors are at play, such as market demand.
So, it does happen - if someone is lucky, that is - to receive a CPU which could be binned higher, but it was still released at lower frequency because of market demands.
Intel is a very good example of such practice, and I am sure Qualcomm is no different as this is a huge market.
Ivan Dimkovic said:
I got no problems with AVS so far - I will release new kernel update tonight with AVS with no overclocking, as AVS and overclocking do not mix well for some people. Also, I provided the patch-code on my github, so other kernel developers can use AVS too, if they wish. There is still an ugly hack inside (one liner, though) which I will fix tonight, too.
Regarding "getting away" with faster CPU (Qualcomm) - I am not really sure if they would do it. There are market pressures, and CPUs are not always binned according to test validation - rather, other factors are at play, such as market demand.
So, it does happen - if someone is lucky, that is - to receive a CPU which could be binned higher, but it was still released at lower frequency because of market demands.
Intel is a very good example of such practice, and I am sure Qualcomm is no different as this is a huge market.
Click to expand...
Click to collapse
I'll study this for integration in my .32 kernel...I'll have plenty of time once Holy Week vacation starts here.
Ivan Dimkovic said:
I got no problems with AVS so far - I will release new kernel update tonight with AVS with no overclocking, as AVS and overclocking do not mix well for some people. Also, I provided the patch-code on my github, so other kernel developers can use AVS too, if they wish. There is still an ugly hack inside (one liner, though) which I will fix tonight, too.
Regarding "getting away" with faster CPU (Qualcomm) - I am not really sure if they would do it. There are market pressures, and CPUs are not always binned according to test validation - rather, other factors are at play, such as market demand.
So, it does happen - if someone is lucky, that is - to receive a CPU which could be binned higher, but it was still released at lower frequency because of market demands.
Intel is a very good example of such practice, and I am sure Qualcomm is no different as this is a huge market.
Click to expand...
Click to collapse
No doubt about it. Look at the Desire for example. It will be equipped with the 1ghz Snapdragon but will be underclocked to 768mhz to preserve battery life. So while it is certified for higher speeds HTC feels the market would prefer longer battery life over a little bump up in cpu speed
intersectRaven said:
I'll study this for integration in my .32 kernel...I'll have plenty of time once Holy Week vacation starts here.
Click to expand...
Click to collapse
Out of curiosity, what advantages if any do you see with the .32 kernel over .33?
jlevy73 said:
Out of curiosity, what advantages if any do you see with the .32 kernel over .33?
Click to expand...
Click to collapse
Well, I've been using it for longer than .33 since I found it to be more responsive and a lot more stable with my 3d live wallpapers. Its also smaller when compiled so I can enable the compiler optimizations with ease.
intersectRaven said:
Well, I've been using it for longer than .33 since I found it to be more responsive and a lot more stable with my 3d live wallpapers. Its also smaller when compiled so I can enable the compiler optimizations with ease.
Click to expand...
Click to collapse
Also, the upstream (AOSP) MSM kernel tree is still at .32... I would guess they may be stabilizing for a release as they've merged the -stable patchseries too (2.6.32.9 etc).
TEAM n0ob FIRST RELEASE!
Ok after my OverClock How-To, I decided to play with overclocking and see what exactly can be gained from stock Max regulator Voltage (1.3v). I have found that at stock you can get up to around 1.13ghz. It is slightly faster than what pershoots kernel runs (38400khz).
As persiansown says, the standard stock voltage is set to 1275, and the regulator is maxed at 1.3v.
What Kind of gains will you see?
You will notice a difference in games like Asphalt, that use a lot processor. You will notice a decrease in battery life as well. Your linpack scores will vary from about 8.5-9.5 depending on your chip.
I have included pershoots undervolting, 21MB ramhack, and audio hack as well. Several optimizations, following in the footsteps of the Ivan/intersectRaven Kernels. (You could say we KANGED pershoot and just added two frequencies above his)
The frequencies in the kernel from 1113300-1152000 are at stock voltage(1.3v), and I have included the relevant source files. As such they "should" be safe. You never know though! The frequencies below this are Undervolted down to .925v!
This is using SLUB allocator and Deadline IO scheduler.
The recommendation of Team n0ob, is to use set CPU to set your phone to a frequency below 1.11ghz unless you need the extra power for something. Otherwise your battery life will suck and you will stress your processor for no reason.
This is confirmed working on CM-5.0.6-N1.
WARNING!!! THE LONG TERM EFFECTS OF OVERCLOCKING YOUR PROCESSOR CAN INCLUDE:
1. SHORTENED PROCESSOR LIFE
2. OVERHEATING
3. REDUCED BATTERY LIFE
4. BRICKED (IE DEAD DEVICES)
Mod edit: removed link, till source is link to kernel.
I ask that if you notice anything funny that you flash to a more tested kernel and notify this board immediately. This kernel is at stock voltage, but the increased speeds could have adverse effects. Please let us know if you notice any.
Team n0ob takes no responsibility for any damage that may occur to your device.
Credits: pershoot( thanks for the hard work), Kmobs (same), intersectRaven, Ivan (for beginning optimization trend), Rotohammer(experimental random/music/start fix), Cyanogen for awesome roms (whose source this is pulled from), chris soyars, and coolbho3000, Koush for the anykernel updater.
Team n0ob Testers: jlevey, DAMNiaTX Hell! (Thanks)
Following pershoot, I recompiled the Kernel with VFPv3 Optimizations.
resync to 2.6.33.3, old wifi drivers as everyone has problems with the new ones.
Lowered minV to 925. maxV is still 1.3. Voltages are increased to 1.3 only on the 2 frequencies above pershoots 1.113ghz. The other frequencies are undervolted similar to the Kmobs and or the Pershoot values.
Well, by "lowering processor life", how exactly long will my processor last? Does it depend on my phone? My uses? Im all in it for overclocking, and im very aware of said risk.. But processor life I'm not educated in..
Eclair~ said:
Well, by "lowering processor life", how exactly long will my processor last? Does it depend on my phone? My uses? Im all in it for overclocking, and im very aware of said risk.. But processor life I'm not educated in..
Click to expand...
Click to collapse
Not drastic. Not concrete figures but I've heard figures like instead of something like maybe 6 years, you may get 4-5 years. The processors are designed to last so long that even things that harm them typically still leave them outlasting the upgrade cycle of the user. It depends on the silicon in your phone as well.
Also, Gr8Gorrilla, does this include CM's latest commits from a day or two ago that fixes the pink cam tint issue?
No telling really. It shouldn't be much different than stock. However, as soon as I say that someone will install this brick the phone and blame me. So I am using it and I have a two year contract with T-mobile, I figure it should make it that far.
This is basically pershoots kernel plus 38400 khz. (pershoot in no way endorses this kernel). Take that for what it is worth. The top three voltages 1113, 1132, & 1152, are at stock voltage (1.3v).
I resynced my repo last night before compiling this.
Damn nice kernel is all I have to say
Gr8gorilla said:
I resynced my repo last night before compiling this.
Click to expand...
Click to collapse
Ok thanks! Definitely flashing this now!
Stock voltage is actually 1.275v. The processor is, however, rated to handle 1.3v (it was originally going to ship at 1.3v, but qualcomm decided to have it ship at 1.275v instead)
Gr8gorilla said:
No telling really. It shouldn't be much different than stock. However, as soon as I say that someone will install this brick the phone and blame me. So I am using it and I have a two year contract with T-mobile, I figure it should make it that far.
This is basically pershoots kernel plus 38400 khz. (pershoot in no way endorses this kernel). Take that for what it is worth. The top three voltages 1113, 1132, & 1152, are at stock voltage (1.3v).
Click to expand...
Click to collapse
I also am on a 2 year contract with TMobile, hopefully mine last that long also. Might as well flash this, blah..
persiansown said:
Stock voltage is actually 1.275v. The processor is, however, rated to handle 1.3v (it was originally going to ship at 1.3v, but qualcomm decided to have it ship at 1.275v instead)
Click to expand...
Click to collapse
I stand corrected. I should have said stock max regulator voltage. I will update the OP.
thanks Gr8gorilla
I'm definitely gonna try this out. I've been using intersect's and ivan's, just jumping back and forth. Good to see that there's another kernel out there to play with. Thanks Team n0ob!
Gr8gorilla said:
I have included pershoots undervolting, 8mb ramhack, and audio hack as well. The experimental Rotohammer fix for the headphone jack is compiled in as well, along with several optimizations, following in the footsteps of the Ivan/intersectRaven Kernels. (You could say we KANGED pershoot and just added two frequencies above his)
Click to expand...
Click to collapse
Does this have everything else that the default cyanogenmod's kernal has? (i just want to know if I am going to loose anything from cyan to this kernal)
INeedYourHelp said:
Does this have everything else that the default cyanogenmod's kernal has? (i just want to know if I am going to loose anything from cyan to this kernal)
Click to expand...
Click to collapse
Yes that is correct.
Nexus FireBall 1.15GHz.
I will be also flashing this kernel update to 1.15 GHz tonight. I want to try and optimize my nexus one to its fully potential capabilities. : )
Updated, Changed Kernel optimizations. Since this kernel follows pershoot, he recommends if you are on 5.0.6 to flash the VFPv3 optimized version.
VFP works great
Hi guys when i unzip their 4 files i know the ko and zimage but the other 2 files do i need to install them too?? and how? thanx in advance.
The other two files are the source files. They there so you can research what changes I have made in the voltage and frequencies and also you could compile this on your own if you want.
AOSP Kernels for HTC's 8x50, 7x30, and 8x60 Devices
Also available for the Motorola Xoom
Tiamat kernels are designed for use on all ROMs that are built from the AOSP source code. This includes ROMs built from MIUI, CyanogenMod, and others.
Tiamat receives no support for use with ROMs based on HTC's Sense - use at your own risk.
Click to expand...
Click to collapse
Tiamat Kernels
You can find full details about Tiamat Kernels at our website. The site is up and running and serves as a more centralized location to get updates, downloads, and changelogs for all Tiamat Kernels. There is no forum or Registration, it’s just a more convenient way to keep things organized as we work to add support for more devices.
Click to expand...
Click to collapse
Support
Join the Tiamat Kernel developers on IRC at irc.freenode.net, #tiamat. Support and questions are generally handled faster there than the forums. You can easily join via webchat here.
Click to expand...
Click to collapse
Special Thanks to:
toastcfh, slayher and the CyanogenMod team for the base kernels and everything else they do for the Android community
bcnice20 for generally being awesome
TeamWin for also generally being awesome
netarchy, chad0989, cuviper, and invisiblek for some great code
intersectRaven and redstar3894 for the Mjolnir compiler
JasonK75 for updating threads
Click to expand...
Click to collapse
Quick Links
Click to expand...
Click to collapse
8x50 Changelog
8x60 Changelog
7x30 Changelog
Downloads
FAQ
Source Code
reserved for later
This kernel has been around for the Inc and the Evo. Now I'm bringing it to the N1 and the Desire!!
Great stuff, always nice to have more kernel choices
MOD : Can you post only Nexus One kernel on your post please (more readable)
Had been having some wifi issues this past week using cm7 nightly along with various kernels. Wifi was frequently dropping or just very slow. Spent most of Sunday screwing with my home network which seems stable now. I think comcast must have been doing something. however, my phone wifi was still poor. installed this kernel last night and so far phone is performing as it should on wifi. the difference was immediate. not sure whats going on. cant comment on battery life yet, but it's looking very good through this mornings use. Thank you!
allofusjw said:
Had been having some wifi issues this past week using cm7 nightly along with various kernels. Wifi was frequently dropping or just very slow. Spent most of Sunday screwing with my home network which seems stable now. I think comcast must have been doing something. however, my phone wifi was still poor. installed this kernel last night and so far phone is performing as it should on wifi. the difference was immediate. not sure whats going on. cant comment on battery life yet, but it's looking very good through this mornings use. Thank you!
Click to expand...
Click to collapse
I'm glad it's working for you, but that is strange... The only change I make to wifi from CM is undervolting it. And now that I think about it, I may have forgotten to bring that tweak over to the n1 and desire...
Can you summarize how your kernel differs from the others (CM, pershoot, wildmonks, redstar).
mr_raider said:
Can you summarize how your kernel differs from the others (CM, pershoot, wildmonks, redstar).
Click to expand...
Click to collapse
Versus the main CM kernel, this has unrestricted overclocking, HAVS, smartass, undervotling, sysfs interface and several other tweaks/improvements. I don't have a N1 and honestly dont know anything about the other kernels out there for it. The kernel started on the Inc and Evo, mostly around MIUI, and I was asked by a few people to bring it over to the N1 and Desire, so I figured I would post it up for everyone.
Hi all,
Been running this since 0800 this morning (its now 1800) no problems at all.
Can't say its faster or better on the battery for sure but its certainly no worse than CM stock.
Whats the smartass govenor? Just the same as on demand as it seems to replace it?
Oh, just one thing, although it has the option (in SetCPU) to go down to 128mhz, I've not seen it go lower than 245mhz which makes me wonder if its clocking down to 128 with the screen off.
Anyone else?
bryanchapman9999 said:
Hi all,
Been running this since 0800 this morning (its now 1800) no problems at all.
Can't say its faster or better on the battery for sure but its certainly no worse than CM stock.
Whats the smartass govenor? Just the same as on demand as it seems to replace it?
Oh, just one thing, although it has the option (in SetCPU) to go down to 128mhz, I've not seen it go lower than 245mhz which makes me wonder if its clocking down to 128 with the screen off.
Anyone else?
Click to expand...
Click to collapse
The on demand governor was removed to force the default to smartass (the default is usually set to on demand by the ramdisk and is not affected by setting the default in the kenrel), but the two are not similar. Smartass was built off the interactive governor.
As for the 128Mhz floor - that is something finicky about the smartass governor. It should drop to 128 on any other governor though.
Smartass Governor shows real potential...thanks for this!
what about the wonk?
From what I gather the wonk is due to something in CM7 kernel. I also noticed that it is absent from stock 2.3.3 and also absent from AOSP builds.
Has anyone tried CM7 with this kernel?
thanks for the N1 kernel.
I'll try ASAP.
I will try this kernel now, thanks for posting. New kernel cooks are always welcomed.
After about 18 hrs on this kernel, the results are pleasing.
Extremely stable on the Smartass Governor, which is surprising because I've had friends compile me kernels incorporating this governor, and the end result = unusable.
Battery life seems fantastic so far.
Clocked 128-998. No profiles.
Thank you again for this kernel.
Results on N1
I have been running this kernel for 24hrs at 128/1228 and it's been running great with smartass selected on my AT&T N1. I tried going even higher than 1228 but that causes it to crash immediately (I'm surprised it can even handle 1228.) Linpack is a little low at 23 compared to other kernels that can get up to 40. Quadrant also comes up behind at only 1051.
tried going at the highest setting & it crashed my N1 , BACK TO RESDTAR'S kernel .
Been using the kernel for a few hours, Kernel seems stable but definatly doesnt feel snappy.
phewizzo said:
Been using the kernel for a few hours, Kernel seems stable but definatly doesnt feel snappy.
Click to expand...
Click to collapse
same here, got some freeze
btw oc at 1267 without any crash
Development Goals:
- stability
- energy savings due to more efficient algorithms (whether theoretical or not is unimportant)
- strictly no overclocking unless approved by the manufacturer or my source base integrates it (also, even if my source base integrates it, expect no support for it)
- no undervolting as well unless the manufacturer approves it since it's relatively pointless IMHO...
- all improvements should require MINIMAL user interaction (e.g. you don't need to do anything except flash the kernel or at the very least use SetCPU or the like to set fixed options)
- stability
Latest Kernel Here
20130625_10XX:
- updated with fix for more recent 4.1.2 Sense ROMs (should fix camera issue)
*unsure if this becomes incompatible with older 4.1.2 Sense ROMs though
20130602_07XX:
- NTFS support
- compiled using 4.8 linaro compiler
- improved workqueue queueing
- sleeper improvements
- responsiveness patches to the frequency controllers
20130531_09XX:
- fixed earpiece volume during calls
20130528_17XX:
- more optimizations (see GitHub)
20130527_18XX:
- more ARM implementations (see GitHub)
20130527_10XX:
- ARM implementations of kernel algorithms (see GitHub)
20130527_09XX:
- compiler optimization flags
20130526_22XX:
- initial version
- uses Linaro compiler
You can find my kernels at:
intersectRaven's Kernels
GitHub is at:
intersectRaven's GitHub
FAQ or something like that:
1.) Camera doesn't work!
- Try this fix from Golv here. This usually occurs on older ROMs.
*Latest 20130625_10XX version should solve this without flashing older camera libs.
Reserved 2
Reserved 3
Nice to see ir taking interest in the One. Truly a great dev
Sent from my Nexus 4 using Tapatalk 4 Beta
Uhhh nice to see you here
intersectRaven said:
Development Goals:
- stability
- energy savings due to more efficient algorithms (whether theoretical or not is unimportant)
- strictly no overclocking unless approved by the manufacturer or my source base integrates it (also, even if my source base integrates it, expect no support for it)
- no undervolting as well unless the manufacturer approves it since it's relatively pointless IMHO...
Click to expand...
Click to collapse
Could you please expound on your statement that undervolting is relatively pointless?
From my experience, undervolting
1. Improves battery life because of lower wattage (Voltage * Amperage = Wattage). Even with a really bad binned CPU, it can still make a difference.
2. Cooler operation. This means longer component life - especially important as this phone is very difficult to repair. Battery is sandwiched so the cooler we can keep the device, the longer the battery will last. (Battery longevity practices could be a topic of it's own)
3. It's Fun! Haha. But seriously. I love to tinker. How low can you go??? It's fun seeing a 25% decrease in voltage and it still run stable
I really like your approach with the rest of your points though. We should have a stable kernel that doesn't have to be tuned or tweaked at all. This however, only suites the majority. The minority may want more. I'm currently in the process of making a kernel with as few restrictions as possible. Except that I will put a ceiling on the maximum voltage (1.25v for the cpu)) because I discourage overvolting beyond spec.
Anyway, thanks for the work. The One is Awesome!
m0nz said:
Could you please expound on your statement that undervolting is relatively pointless?
From my experience, undervolting
1. Improves battery life because of lower wattage (Voltage * Amperage = Wattage). Even with a really bad binned CPU, it can still make a difference.
2. Cooler operation. This means longer component life - especially important as this phone is very difficult to repair. Battery is sandwiched so the cooler we can keep the device, the longer the battery will last. (Battery longevity practices could be a topic of it's own)
3. It's Fun! Haha. But seriously. I love to tinker. How low can you go??? It's fun seeing a 25% decrease in voltage and it still run stable
I really like your approach with the rest of your points though. We should have a stable kernel that doesn't have to be tuned or tweaked at all. This however, only suites the majority. The minority may want more. I'm currently in the process of making a kernel with as few restrictions as possible. Except that I will put a ceiling on the maximum voltage (1.25v for the cpu)) because I discourage overvolting beyond spec.
Anyway, thanks for the work. The One is Awesome!
Click to expand...
Click to collapse
Should have put a qualifier there huh? Anyways, it's pointless from a no tweaking perspective since undervolting may not work for some chips and could cause more trouble (random restarts and the like) than it's worth. It's fun for a tweaker (like when I did something like that for the N1) but not for someone who's the flash and forget type. :fingers-crossed:
Thanks
P.S you missing the ":" on the http link
Really glad to have you here iR. Missed your kernels from my nexus one days with those hybrid AVS kernels.
Camera is buggy
Sent from my HTC One using xda app-developers app
chourmovs said:
Camera is buggy
Sent from my HTC One using xda app-developers app
Click to expand...
Click to collapse
The camera will problably need som librarys, like most other kernels, I think. There is a zip for this in other threads (couldn't find it right away)
chourmovs said:
Camera is buggy
Sent from my HTC One using xda app-developers app
Click to expand...
Click to collapse
What is the problem exactly? Also, is this a custom Sense ROM or stock Sense? Just mentioning that it is buggy doesn't actually help me solve it since there are no bugs in my phone.
Sorry
I m on last ardh by mike86 and when I launch camera, it stuck on black canvas then I ve to hard exit
Sent from my HTC One using xda app-developers app
Intersect my man. Nice to see u in the HTC one forums!
Sent from my HTC One using xda app-developers app
Camera troubles
If somebody have problems with the camera, use the camera Fix from here:
http://forum.xda-developers.com/showthread.php?p=41712563
The bug is due to the old source code, released by HTC
If you are using a ROM based in 1.29.xxx.16 like the most of the new custom Roms flash just after the kernel.
Are the old camera libraries, that works with the Custom kernels.
chourmovs said:
Sorry
I m on last ardh by mike86 and when I launch camera, it stuck on black canvas then I ve to hard exit
Sent from my HTC One using xda app-developers app
Click to expand...
Click to collapse
Can you try the link posted below by Maikeu and get back to us whether it fixes the issue?
Maikeu Locatelli said:
If somebody have problems with the camera, use the camera Fix from here:
http://forum.xda-developers.com/showthread.php?p=41712563
The bug is due to the old source code, released by HTC
If you are using a ROM based in 1.29.xxx.16 like the most of the new custom Roms flash just after the kernel.
Are the old camera libraries, that works with the Custom kernels.
Click to expand...
Click to collapse
Posted this in the second post here for future reference.
HI, after fashing this kernel , i cannot hear any sound from call dial ,
008325 said:
HI, after fashing this kernel , i cannot hear any sound from call dial ,
Click to expand...
Click to collapse
Thanks for the heads up! Missed that in my testing. :silly:
*Uploading a fix now.
intersectRaven said:
Thanks for the heads up! Missed that in my testing. :silly:
*Uploading a fix now.
Click to expand...
Click to collapse
Thank you very much i really like this kernel , smooth , cold , save battery
Hi guys
Release 0.4 http://forum.xda-developers.com/showpost.php?p=45243784&postcount=48
New in this release is USB Fast Charging support (must be enabled via new kernel interface, see post for details)
Da_G said:
Old version 0.3 http://forum.xda-developers.com/showpost.php?p=45202710&postcount=28
Old version 0.2. http://forum.xda-developers.com/showpost.php?p=45198825&postcount=25
Old version 0.1! http://forum.xda-developers.com/showpost.php?p=45186352&postcount=18
Click to expand...
Click to collapse
Some of you might remember me from a time long ago and a galaxy far away!
I built/maintained dagkernel on release day for the Note 1, bringing root+overclock+recovery on day one of release
Well, recently my home was burglarized and all of my electronics taken. I took a very big ol hit that made me a sad panda Along with this stuff was my fancy-pants Alienware M18X laptop (minus the power brick, so they can't use it!) - which had all my source codes and development enviornments on it.
Rather than cry over spilt milk (really, I cried for a week! ) I decided I would re-build my development enviornment and crank out a new kernel for Galaxy Note, which is the most powerful computing device I currently have! (I am developing on an old school core 2 duo w/1GB RAM that sure feels slower!)
So, build enviornment is set up and the first build is done. Which is simply a re-built ramdisk and kernel from AT&T source. Using the newest available prebuilt toolchain from Google. I won't release this version as pretty much nothing is changed. But I wanted to get my dev enviornment up and running A first release with actual, substantial changes should be available within the day.
Support will include 4.1.2 stock ROMs (for the S-Pen love), CM, and whatever else I might support (suggestions?!)
GPU/CPU overclock will be supported, with the separate interfaces for overclocking each via an app. Hopefully I can actually push the app out this time around, it stayed internal only last time (although all frequencies and voltages were changable via boot script)
I took a look at the existing 4.1.2 kernels floating around and noted that most of them neglected some patches I made to Samsung's original source that did some funky things like re-set CPU1 (the second CPU) to stock speeds after toggling it off (for power saving)
As a result, the performance of these kernels is probably not quite what it should be after the first CPU shuts off (which happens almost immediately after android is done booting fully, when the load demand on the CPU(s) die)
Of course, my source will be public as it has been since day 1 and anyone is welcome to source my patches without asking. Viva la developers!
May your Galaxy Note run faster than this pos Dell desktop I'm using real-soon-now(tm)
Reserved for the use of the futures.
Reserved for the use of the futures.
Cool beans. Looking forward to this
Sent from my SAMSUNG-SGH-I717 using XDA Premium 4 mobile app
Welcome back
Sent from my SAMSUNG-SGH-I717 using XDA Premium 4 mobile app
Da_G!!!!!! Welcome back
2$HAYNE
Yes, welcome back Da_G. I'm sure there are a ton of us that remember your great work. Looking forward to some more.
Sent from my SAMSUNG-SGH-I717 using Tapatalk 4
Sorry to hear about your stuff!
I'm glad you're still able to churn out things like this though! Keep up the good work!
Welcome back! I loved your old stuff back in the day. Bring on the awesomeness!
Sent From My JellyBeanSandwiched Galaxy Note
ROM: Jellybean Sandwich w/ Hotcakez 1.8ghz kernel
Extras: Viper FX audio engine w/ Buzz Launcher
Sorry for the loss! But I'm glad you're back
Sent from my SAMSUNG-SGH-I717 using xda app-developers app
Sorry to hear of your trouble but glad to hear you're back on your Note development...a big plus for us! Welcome back Da_G!
Very sorry for your break in. Seems the world is full of d-heads. Glad nothing more than stuff was affected.
Welcome back. Of course we remember you. You're one of the first, and best at this Note stuff. Looking forward to seeing what you can put together. Let us know what you need from us.
Do your thing, man and welcome back!
you dont know me, but your reputation precedes you and I am aware of your quality of work.
I will send you a big welcome back
Welcome back :good:
I will have a first release out shortly. Just testing the impact of mpdecision on cpu performance.
For reference at OC to 1.83ghz/performance gov I was able to pull 9556 on antutu benchmark with performance gov and mpdecision disabled, ~6320 prior to overclocking. GPU is at 300MHz.
With ondemand gov and mpdecision enabled, looking around 8550. Lets try with performance gov and mpdecision enabled now...!
These scores seem about on par from what I remember from the first go-round I don't yet have the configuration sysfs interfaces set up.
Wow u know ure stuff n that really sucked about ur belongings but glad ure back in the community! I don't own a i717 but love to see all the roms u guys provide brings envy (in a good way) since my t879 has disappeared lol but good luck n the guys look very excited ure back... Lucky them cheers :beer:
Sent from my SGH-T879 using xda premium
Da_G said:
I will have a first release out shortly. Just testing the impact of mpdecision on cpu performance.
For reference at OC to 1.83ghz/performance gov I was able to pull 9556 on antutu benchmark with performance gov and mpdecision disabled, ~6320 prior to overclocking. GPU is at 300MHz.
With ondemand gov and mpdecision enabled, looking around 8550. Lets try with performance gov and mpdecision enabled now...!
These scores seem about on par from what I remember from the first go-round I don't yet have the configuration sysfs interfaces set up.
Click to expand...
Click to collapse
Awesome bro. How is the battery life? You going to put this out tonight?
Here is a first version, in TWRP/CWM compatible zip file. It is set to 1.83Ghz/300Mhz OC ondemand by default, with mpdecision left enabled. You should be able to use a tool like system tuner to change cpu frequencies and governors. I did not yet enable init.d support for a script in /etc/init.d to change frequencies on boot. It is on my to-do
This build is for 4.1.2 Stock/TW-based ROMs and most likely won't work on CM. Again, that's coming soon
As for battery life, I really don't know yet. I haven't had the phone disconnected from the computer during development, and this computer is so much slower than my old one I don't dare waste time doing things like that just yet. You guys try and let me know
I am thinking about 4 distinct releases,
High Power 4.1.2/Stock and CM
Power Save 4.1.2/Stock and CM
That way I can make one for balls-out speed and one for day to day use. I'm a fan of speed since I have an external battery charger and 4 batteries.
Da_G said:
Here is a first version, in TWRP/CWM compatible zip file. It is set to 1.83Ghz/300Mhz OC ondemand by default, with mpdecision left enabled. You should be able to use a tool like system tuner to change cpu frequencies and governors. I did not yet enable init.d support for a script in /etc/init.d to change frequencies on boot. It is on my to-do
This build is for 4.1.2 Stock/TW-based ROMs and most likely won't work on CM. Again, that's coming soon
As for battery life, I really don't know yet. I haven't had the phone disconnected from the computer during development, and this computer is so much slower than my old one I don't dare waste time doing things like that just yet. You guys try and let me know
I am thinking about 4 distinct releases,
High Power 4.1.2/Stock and CM
Power Save 4.1.2/Stock and CM
That way I can make one for balls-out speed and one for day to day use. I'm a fan of speed since I have an external battery charger and 4 batteries.
Click to expand...
Click to collapse
Seems like everything is running a-ok. I'm using it now Going to test it for the next couple days and see how it runs
Feels a little sluggish to me right off the bat. Tweaking the speed/governor with an app brings it right up to snappiness. Not too bad for a first run on an entirely new(to me) anciently slow computer, though. Only gets better from here
Sent from my SAMSUNG-SGH-I717 using xda app-developers app