Unfortunately the developer is unable to post source for these kernels at this time. Because of this, I am closing this thread and removing the download links. If you have any questions about GPL compliance, feel free to read this post.
Updates listed here:
-Added new version of 1.5 kernel in post 3.
-Added 1.7 kernel in post 3.
-Added CPU frequency table list in post 5.
I made these UV kernels because i wanted to play with undervolting and see if i could extend the battery life on the device..... it seems to have worked out well for me so far, i have been using the stock battery since last night, and today am still at at least 85% battery left. I hope you too will experience improved battery life! I am surprised at how much I have been able to lower the voltages and still maintain stability..... i haven't had a single freeze-up or glitch yet! But if you do encounter anything like this, try the UV5 kernel above, which has slightly higher voltages than the UV6. And also I would keep a copy of the kernel with stock voltages handy
I have also been using SetCpu to set my min. frequency down to 192(default is 384 i believe), and i haven't had any lockups or problems with that either. So between that and the UV, my phone seems to be using little power while in sleep mode.
I will probably experiment with even more undervolting soon, and will notify of updates here in the thread. i can also post or provide the exact voltages for these kernels for anyone interested. enjoy!
The Following 12 Users Say Thank You to yogi2010 For This Useful Post: [ Click to Expand ]
- Modified CPU table to accomodate Qualcomm 1.5GHz S3 Snapdragon chip speed.
- HTC cuts it off at 1.2GHz on the stock kernel.
- Re-scaled CPU table and L2 cache.
- Max voltage 1.2 volts even at 1.5GHz (HTC was 1.25 volts @ 1.5GHz)
Voltage tables to be posted later - no voltages exceed what the stock kernel came pre-coded with, and we have undervolted the 1.5GHz frequency to 1.2 volts instead of the 1.25 volts HTC put it in for. Runs fine at 1.2 volts, has been for months for me.
(we used that 1.25volts at 1.7GHz instead...)
Otherwise all voltage tables are back to HTC stock, and new frequencies leading to 1.5GHz HTC did not put in had the voltage used from the lower frequency beneath it.
1.5 GHz is where the 'Two-Headed Snapdragon takes flight'.
(quote is the title of a Snapdragon white-paper)
The idea here is to give the superscaler dual-core processor the scaling options to choose from to take advantage of that ability...
- Stock 1.28.531.9 or 1.28.531.10
- Bulletproof 1.1
- 1.55.531.3 software base
- ICS Roms
Size: 3.57 MB
March 17th, 2012
- Max voltage 1.25 volts at 1.7GHz (HTC had 1.25 volts @ 1.5GHz)
We used the 1.25 volts HTC laid out for the 1.5GHz frequency for our 1.7GHz frequency instead. Runs great! ...and we stay within a voltage level that was already recommended to us through the code by HTC, so we are probably not putting too much voltage through the chip yet.
(we'll even see if we can knock that down a bit too, soon)
If 1.5GHz is where the dragon takes flight, then 1.7Ghz is where it starts razing villages ~ !
1.7GHz is where this device is most comfortable (in my opinion).
NOTE: 1.7GHz is above ANY manufacturer recommendations - you are your own warranty now. (pay out of pocket for breakage - you've been warned)
...The idea here is to give the superscaler dual-core processor the scaling options to choose from to take advantage of that ability:
I said that in the 1.5 kernel, but it's moreso true in this 1.7 one. There are a lot of options for frequencies that the Scorpions can use to scale to exactly the right level of effort needed to get the job done.
I am not sure at what point the table becomes too bloated and we see a hit on performance. I doubt very highly we've hit it yet, especially given the testing i've been doing - this is more a worry for pushing higher then 1.7GHz then here, but something to put out there now.
- Stock 1.28.531.9 or 1.28.531.10
- Bulletproof 1.1
- 1.55.531.3 software base
- ICS Roms
Size: 3.57 MB
March 17th, 2012
here is a screenshot of my battery usage with the UV6 kernel, on the stock 1.28.531.10 ROM, rooted and debloated of course, and using the stock battery. granted, i slept 7 of those hours, and i wasn't on the phone constantly, but i put in at least moderate data and texting use, and a quick call or two. i'm decently happy with it so far.
there hasn't been a ton of support for what HTC has done, software-wise, with our device, but i tend to think it runs pretty well, and that kudos are deserved. the 1.55.531.3 ROM especially seems nice and balanced, with steady battery drain, and few bugs. we would like to develop for the that new update, but for now are basically learning and working with what kernel source we have.
The Following 3 Users Say Thank You to yogi2010 For This Useful Post: [ Click to Expand ]
1188000 is considered the 1.2GHz rating by HTC/T-Mobile. (device manufacturer and carrier.)
Qualcom rates the chip at 1.2GHz recommended, 1.5GHz maximum. Every other device that has this chip runs at 1.5GHz.
...how is this fair to us?
Granted - they are trying to do a good thing - no doubt this is part of a solution to the battery issue after they got data back from the earlier Sensation launch.
In a lot of ways the doubleshot is singled out for being nerfed, Most of the people who would've gotten this device got the Sensation instead (basically the same device) because it launched a bit sooner. Then this gets nerfed on top CPU speed and turns away more potential buyers who go by the numbers in-store to compare.
So, now we fix - with HTC releasing the source code to the kernel a while ago, we can now do this ourselves and wake up the sleeping dragon at the heart of the doubleshot.
Suddenly, it's all okay - - the manufacturers decisions based on how they wanted to market the hardware are no longer something we have to just deal with and grumble about, now we can just go ahead and tailor the device to suit our needs.
I spent a significant amount of time crawling through the kernel source surrounding the specific hardware being used in the doubleshot, and ran around tracking down any scrap of information I could about the components and how they work. I bought the doubleshot based on it's hardware and what it was capable of.
Between all the device documentation found and the countless hours wide-eyed in wonder drifting through the kernel source for the device, I was able to employ everything I learned about overclocking desktops and graphics cards over the years.
I sat down with my calculator and ran all the numbers to make a nice, mathematically balanced table based on the various multipliers that make up the device's internal speeds across the hardware inside.
This project was, and is, a goal of mine since before buying the device, and thanks to yogi2010's help it's becoming a reality.
Please forgive me for not having my source set up for download yet, I will get to that as soon as I can - meantime i've kept very detailed records and will get it all together and available.
Thanks for your patience on this!
Look forward to a nice and re-scaled 1.7GHz kernel soon...
Then I can spend some time on experimenting above 1.7GHz...
Mathematically there should be a bunch of frequencies available, but they are not as harmonious to the various multipliers involved and theoretically some of them should be unstable.
I don't recommend anyone run over 1.7GHz as the risk of permanent damage to the device becomes pretty severe after that.
Increases in the system speed like this, beyond manufacturers ratings, can be very dangerous in a permanently damaging way. I continue on for curiosities sake, and I have a doubleshot that I purchased privately, out of manufacturers warranty and with no insurance plan.
In short, I have a device I can melt and there isn't a person I can cast blame on beyond myself, for surely no one else is at fault when I eventually break it doing this.
Even if no immediate damage results from pushing the device far past it's design limits, the long-term lifespan of the device is dramatically reduced. The types of stresses I intend to put the machine through are not anything near normal or what it was designed for.
That all being said -
I'm curious. I'm driven to know, and so I want to see for myself first-hand what it can do.
The rule to overclocking is to find your boundaries and then work out the maximum stable settings you can use in both directions.
...Finding the low end of the spectrum is no biggie, can't hurt undervolting or underclocking anything on it...
...Finding the top end of the operating range, though, is a destructive art by nature.
I wouldn't want to put something I wanted to rely on and last me a while through this - a desktop, maybe ... a small electronics device, especially one like this?
I will likely get a lot of use out of the second device because it shouldn't kill it in just finding the boundaries, but it will likely be replaced with another doubleshot when it starts to die and retire into salvageable parts for repairs.
In short: I bought a device to use for development and curiosities sake - it's not even attached to a plan. Be aware of the stresses overclocking can have on your device and think carefully before overclocking your device.
Once again, I do NOT recommend running above 1.7GHz - I do see a noticeable level of improvement in FPSE playing Castlevania: Symphony of the Night, and the benefit of reasonable overclock is real. Above 1.7GHz is not reasonable but possible.
If we had more RAM, we could hold a higher stable speed, but the device performs admirably and is something I am proud to own. HTC and Qualcomm did a damn fine job on the hardware this thread is about.
Just about any gripes I have about the device are limitations of software, be it apps, the OS or the kernel itself. Since we have the 220.127.116.11 source we can work on fixing things like this and more.
kernels take time to develop, but having control over how the device physically operates enables you to streamline it's processes and do it's job more efficiently.
I look forward to the HTC release of the kernel source for the 18.104.22.168 kernel from the OTA!
Projects like this would not exist without the open source community and places like XDA.
...so yea, higher clock speeds are coming. But kernels aren't like apps and other stuff.
Supposing I had a freshly compiled kernel and installed it right now, it takes at LEAST 24 solid hours to settle in - and even that is highly dependent upon usage.
So you would be looking at several days of direct testing just by myself just off of one compile operation to start to get good readings - one thing you can't rush are kernels. It might run fine for 6 hours then start bugging out, you really have to just use it to know for sure.
I don't like to just toss stuff out there and hope for the best and with overclocking it's even more important. If there's going to be a problem, especially one that may result in physical damge, i'll find out on my own device(s) first before releasing anything.
This is not the kind of thread you should expect daily software updates in, it's a longer process then that.
I remeber when tbalden was creating his kernels, he had to turn off the (infrared?) Sensor which controls auto back light adjustment, as well as the keyboard light. The workaround for the keyboard was to always have it on whenever the phone was on/keyboard was out. Diabling the sensor resulted in MASSIVE battery savings, in addition to the undervolt work he did. Perhaps we can implement this in one of the undervolt kernels? In my mind, it should be extremely safe, because it does not affect the current/voltage or even the CPU in any way.
The Following User Says Thank You to dung8604 For This Useful Post: [ Click to Expand ]
By now, we’re all quite familiar with Tasker, the personal automation app that seems to be able to … more
XDA Developers was founded by developers, for developers. It is now a valuable resource for people who want to make the most of their mobile devices, from customizing the look and feel to adding new functionality. Are you a developer?