Thinking Ahead - Overclocking to 1.267 GHz [Possibility] - Nexus One Android Development

As some of you may know, the 45nm QSD8650A due out later this year can run at an incredible 1.3Ghz, 30% faster than the current Scorpion core used in the Nexus One. I was, of course, getting kind of jealous of this speed, and wanted to see if it was possible on the Nexus One. Since the model number hasn't changed much (from QSD8x50 to QSD8x50A), I thought that the "A" might only indicate a die shrink and not any significant hardware changes.
Warning: the following information is for kernel developers!
It appears to be a possibility. I dug through the kernel source of the Nexus One and I've discovered that the QSD8250 in the Nexus One might be able to reach ~1.267GHz. I point you to the following file in the kernel source:
http://android.git.kernel.org/?p=ke...f5dab31e6ffece;hb=android-msm-2.6.29-nexusone
Near the beginning of the file, a list of frequencies is given. Starting from 384MHz, the frequencies start basing off a PLL called SCPLL, and increases in multiples of 38.4MHz. If you look at the table, the frequency defined in each row that uses SRC_SCPLL is 38400*sc_l_value (sc_l_value is also defined in the table, in hex).
If you look at 998MHz, it's 38400*0x1A = 998000, which is the max clock of the Nexus One. Now take the closest speed to 1.3GHz if you continue the 38400KHz increments. 1.267GHz should be 38400*0x21, or 38400*33. Where else do we see 33 in the code?
The function if scpll_set_freq() contains the following simple code for bounding sc_l_value. Note that the maximum value is exactly 33, and not 26 (0x1A)! Also, the minimum value is 10, which matches the lowest SCPLL speed, 384000.
Code:
if (lval > [b]33[/b])
lval = [b]33[/b];
if (lval < 10)
lval = 10;
33*38400 (1.267GHz) nicely corresponds with the maximum 1.3GHz of the 45nm Scorpion. Qualcomm rounded 998MHz to 1GHz so there's no reason why they wouldn't round 1.267GHz to 1.3GHz.
CPU voltages are also defined in the table. Some previous versions of acpuclock-scorpion.c had the CPU running at 1.3 volts at 998MHz, but now it's running at 1.275 volts at 998MHz. What we know from that is that the processor can handle up to 1.3 volts (or possibly more). If the processor can't go above 998MHz at 1.275 volts, we know we can (somewhat) safely increase the voltage to 1.3, and unsafely increase it above that.
There is, of course, a comment saying: "output of scpll 128-998 MHZ," which is contrary to the bounds defined in scpll_set_freq(). If this really is the case, overclocking might still be possible, but it would be harder.
What would really help is if someone sent us detailed Qualcomm documentation for the QSD8250/Scorpion core. Don't post it publicly, as Qualcomm is Cease and Desist happy about such things.
My Nexus One is currently not unlocked, as it's waiting for an RMA, so there's no way for me to develop/test any of this. Swetland would also know a lot about this, but who knows what kind of NDA he is under from Qualcomm
It might be as simple as appending a few lines to the table. Keep in mind that the last value (vdd/voltage) might need to be adjusted:
Code:
{ 1036800, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x1B, 0, 1300 },
{ 1075200, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x1C, 0, 1300 },
{ 1113600, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x1D, 0, 1300 },
{ 1152000, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x1E, 0, 1300 },
{ 1190400, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x1F, 0, 1300 },
{ 1228800, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x20, 0, 1300 },
{ 1267200, CCTL(CLK_TCXO, 1), SRC_SCPLL, 0x21, 0, 1300 },
{ 0 },
I also found the exact commit where the Scorpion was changed back to 1.275v from 1.3v:
http://android.git.kernel.org/?p=ke...ff;h=7fcffb1e4554e1e364e994e5ce1ef7e471422ebf
The commit was made after the holiday N1s were passed out so we can probably conclude that it's reasonably safe.
Edit:
Just an update: Qualcomm's code in Codeaurora reveals that there is an eFUSE defining the max clock of the processor, read from a certain address, and as predicted, 1267200 is indeed a valid maximum speed for some versions of the Scorpion (this is, more likely than not, the "1.3GHz" quoted by Qualcomm). It also explains the Liquid's situation. The Scorpion core in the Liquid is probably not underclocked (at least not any more than the Neuxs One is underclocked in relation to the 8x50a), but intended to run at 768MHz max.
https://www.codeaurora.org/gitweb/q...c;hb=7d031492392a410d4814b6e104f53d55b0ae499b
Code:
switch (tcsr_spare2 & 0xF0) {
case 0x30:
max_acpu_khz = 768000;
break;
case 0x20:
case 0x00:
max_acpu_khz = 998400;
break;
case 0x10:
max_acpu_khz = 1267200;
break;
default:
pr_warning("Invalid efuse data (%x) on Max ACPU freq!\n",
tcsr_spare2);
goto skip_efuse_fixup;
}
I feel that the people who have the knowledge required to make these tweaks can experiment with them responsibly. I do not encourage releasing a kernel publicly capable of reaching higher speeds or voltages.

---

Really hope this is possible...you do great work!

---

Wow that would be sweet
Don't think we'd need it soon but man, just the bragging rights

---

Very interested in this and nice find.

---

Almost entirely possible from a hardware standpoint.
And I bet that is exactly it, a change in manufacturing process... the end result being a lower voltage requirement and stability at higher speed (and a longer run time at lower clock speeds).
Don't know how much of a boost we would see performance wise... lower battery life of course and more heat. Not a bad thing to start looking at however as who knows, we could be crying for a bit more speed in the not too distant future.

---

This sort of thing (pushing the CPU beyond the rated/validated max frequency and voltage) definitely falls in the "could permanently damage the hardware" category. Pushing the voltage out of spec tends to lead to fatal L2 cache errors, etc just for starters.

---

swetland said:
This sort of thing (pushing the CPU beyond the rated/validated max frequency and voltage) definitely falls in the "could permanently damage the hardware" category. Pushing the voltage out of spec tends to lead to fatal L2 cache errors, etc just for starters.
Click to expand...
Click to collapse
Totally agree there.

---

KiD0M4N said:
Totally agree there.
Click to expand...
Click to collapse
U can brick your nexus by flashing too. But we do it anyway.
So lets start to overclock

---

DocRambone said:
U can brick your nexus by flashing too. But we do it anyway.
So lets start to overclock
Click to expand...
Click to collapse
The industry has a lot of fear about "open" devices being a big money sink, largely due to concerns about increased RMA costs in highly competitive consumer electronics markets. If the community starts taking actions that lead to these fears becoming reality (third party software permanently damaging devices, etc), it becomes a lot harder to convince manufacturers that "more open" is good for them.
This is the kind of thing that will make it really difficult for me to effectively argue that the current unlocked bootloader warranty policy is overly conservative and should be changed to be more flexible in the face of hardware defects discovered post-unlock, etc.

---

swetland said:
The industry has a lot of fear about "open" devices being a big money sink, largely due to concerns about increased RMA costs in highly competitive consumer electronics markets. If the community starts taking actions that lead to these fears becoming reality (third party software permanently damaging devices, etc), it becomes a lot harder to convince manufacturers that "more open" is good for them.
This is the kind of thing that will make it really difficult for me to effectively argue that the current unlocked bootloader warranty policy is overly conservative and should be changed to be more flexible in the face of hardware defects discovered post-unlock, etc.
Click to expand...
Click to collapse
The small fraction that do this will never have a impact on the manufactures.

---

I'm with swetland here. Overclocking the CPU up to its rated max (Like the G1) is great, but hacking the kernel to push the CPU past its rated limit is just asking for trouble in a device with tolerances as tight as the N1, remember that in a desktop machine if you OC past the rating of the CPU you are always told to ensure you have sufficient cooling and have MB's that can handle the Vcore increase, no such thing is possible here.
Do you really think people are going to go "oh well I knew the risks" when their N1 fails after 6/12/18 months if it's been OC'd or do you think they're going to complain bloody murder on forums, making the image of the N1 even worse?
We're already trying to defeat the bootloader relock security. The combination of these two things has great potential to ruin Google's good work with HTC.
All IMHO of course

---

I have to disagree, HTC do not care about XDA's efforts.
As long is not a market app that overclocks nexus they wont notice.

---

swetland said:
The industry has a lot of fear about "open" devices being a big money sink, largely due to concerns about increased RMA costs in highly competitive consumer electronics markets. If the community starts taking actions that lead to these fears becoming reality (third party software permanently damaging devices, etc), it becomes a lot harder to convince manufacturers that "more open" is good for them.
This is the kind of thing that will make it really difficult for me to effectively argue that the current unlocked bootloader warranty policy is overly conservative and should be changed to be more flexible in the face of hardware defects discovered post-unlock, etc.
Click to expand...
Click to collapse
The warranty policy position is totally understandble, especially if you consider the hoardes of people that have bricked their devices on this forum, mostly due to thier own massive ignorance and inability to read
Personally I don't expect any warranty whatsoever after unlock, but I'm the kind of a nerd that has tons of bricked stuff at home after playing around with it too much
I just hope that HTC will be willing to fix obvious manufacturing errors (like dust under the screen, broken pixels) despite phones being unlocked. Just because they have the right to not fix it, there is no need for them to be asses about it. If someone tries to RMA a device with a cooked QSD in it due to overclocking, they deserve to be turned away.
Now if we can only be allowed to flash the splash screen, w/ the padlock superimposed on top if unlocked

---

I think people who have purchased and own a device have the right to do whatever they want to that device. And if they want to share what they are doing with others, I am interested to read it. As long as the risks involved are made clear, I see no harm in sharing. The vast majority of users will not attempt this anyway unless it is shown over time to be safe.

---

I'm with swetland...
Anybody who thinks there is a small fraction of people who are on these forums who may brick their phones is a fool. Just think about how many idiot post are posted in the wrong section & how many people can't follow simple instruction to flash their phone. I think for every idiot that post that can't follow simple instructions, there are probably at least 10 people who are lurking and not posting at all. I lurked for as long as I could and didn't sign up until I had to so I could download a file or view a screenshot. The market has made the idiots flock to XDA by posting information in the market apps themselves or the comments. Just look at the comments that say "What is root and how do I get it? Hit me up at [email protected]"
The point of this is, This forum is filled with both some of the smartest people I have come across and the dumbest. Either one there are a lot of. If there is a software update that pushes the phone faster, people will flash it. Even if they have been warned it could fry their processor (Like every post about flashing your phone could brick it).
I don't mind pushing the processor to the speed it was designed to run at, but I wouldn't want to push it any faster. How many fried $500 phones do you think it would take before they start to notice. It sure didn't seem to take google too long to notice Cyanogen and he wasn't even bricking phones.

---

Certainly, it's your phone and nobody's stopping you from doing anything with it. I'm less concerned about what people who are fully aware that they're pushing the hardware past its design limits do than what happens when somebody releases supercool-overclocked-tasty-rom.img or whatever and a pile of early adopter types who enjoy trying the new shiny and are pretty good at ignoring any and all warnings end up doing to their hardware.
It's been a long road to get to the point where these devices are shipping with unlockable bootloaders as a feature, not an exploit. We're certainly not done yet, as can be seen based on concerns about the warranty language around unlocking, etc.
I'm simply asking that people consider that actions taken here will impact future devices and possibly show some restraint when appropriate. I'd like to enable future devices to be *more* open, and will continue to work toward that goal, but the actions of this community, and others who create modified system images and make them available to broader userbases *do* have the ability to make my work much, much harder, or much, much easier.

---

swetland said:
Certainly, it's your phone and nobody's stopping you from doing anything with it. I'm less concerned about what people who are fully aware that they're pushing the hardware past its design limits do than what happens when somebody releases supercool-overclocked-tasty-rom.img or whatever and a pile of early adopter types who enjoy trying the new shiny and are pretty good at ignoring any and all warnings end up doing to their hardware.
It's been a long road to get to the point where these devices are shipping with unlockable bootloaders as a feature, not an exploit. We're certainly not done yet, as can be seen based on concerns about the warranty language around unlocking, etc.
I'm simply asking that people consider that actions taken here will impact future devices and possibly show some restraint when appropriate. I'd like to enable future devices to be *more* open, and will continue to work toward that goal, but the actions of this community, and others who create modified system images and make them available to broader userbases *do* have the ability to make my work much, much harder, or much, much easier.
Click to expand...
Click to collapse
Very true. Unfortunately, I'm not sure if there's a whole lot that can be done about that. We can limit what happens here to be sure, but some jerk dev, somewhere, will ignore the warnings and "give the people what they want" to make a quick buck.

---

Im not sure if this is really necesary...
I think with 1ghz and 512mb ram we have enough for so long...
And of course, the only thing i like from the iphone, there is no reason to "put on steroids" a pda, just clean and improve the OS and optimize the apps...

---

The simple solution is to just make your hardware safe from software damage. Shut the thing down if it goes far enough out of spec to potentially damage something... like desktop CPUs will shut down when the temperature goes too high.
swetland said:
The industry has a lot of fear about "open" devices being a big money sink, largely due to concerns about increased RMA costs in highly competitive consumer electronics markets. If the community starts taking actions that lead to these fears becoming reality (third party software permanently damaging devices, etc), it becomes a lot harder to convince manufacturers that "more open" is good for them.
This is the kind of thing that will make it really difficult for me to effectively argue that the current unlocked bootloader warranty policy is overly conservative and should be changed to be more flexible in the face of hardware defects discovered post-unlock, etc.
Click to expand...
Click to collapse

---

granted, this is complete speculation on my part. but I just find it farfatched that HTC cares much about people who brick their devices. It doesn't effect HTC's bottom line in any way. their policy is that if you gain access to functions that have the potential to damage the device's hardware, your warranty is voided. nobody can credibly blame HTC when someone overclocks ther device and it gets fried, so they lose neither money nor PR damage.
of course, anyone who promotes a hack for a device without properly disclosing the risks is irresponsible and wrong. likewise, so is someone who mods their device without engaging in the research to properly decide if it is worth the risk to them persoanlly.
as far as persuaduing HTC to be more open with their devices, I think it might be a little idealistic to assume that any device manufacturuer will ever change warranty policy regarding modding. making it easy to unlock the bootlaoder is nice of them, but its also of no risk to them because they're not liable for what happens to it if you do that. they will never take on added risk by exapanding their warranty coverage for people like us no matter how many people brick their phones or not.