In playing around with overclocking the Epic, I created this spreadsheet:
https://spreadsheets.google.com/ccc?key=0Ajd2hyK6pVbidDRhQ0VWOEVlN1VaMW9QSl9rcXExOHc&hl=en
I do not know if sharing the spreadsheet will allow you to temporarily edit the values to play with it or if you will need to make your own copy to play...
The formulas were gathered from S5PC110_EVT1_UM10.pdf which describes the SOC in our Epics.
It allows you to enter in the APLL m,p,s and the MPLL m,p,s and the Dividers on the second sheet and it will display the clock speeds that will be provided to the various components. On third sheet it will actually generate the code to be put into clock.c to test out the values.
One of the most interesting things that I noticed is that the combination of MPLL, MFCDiv, G3DDiv and G2DDiv are ONLY used when the CPU speed is changing to make sure that the A2M speed does not jump too much for the graphics components to continue working before the A2M DIV can be updated. A2M DIV is always kept at 200, depending on the speed, the graphics clock can drop to 166 or so when the CPU is changing speed (could lead to a stutter, I would think).
Something else that I noticed in there is the 2D graphics chip is mentioned as being capable of 250Mhz, while the other two graphics components are only 200Mhz.
Each of the Graphics components can independently choose their clock from one of four sources (currently it uses two A2M and MPLL), it can also use EPLL and VPLL, between those four clocks we may be able to find a group of combinations that will allow us to overclock parts of the graphics components individually and hopefully by small enough increments it does not fail (my first few attempts lead to needing to use odin to restore my epic).
One thing to note is APLL can generate 30MHz to 1GHz (so if I read this correctly we are using it above its capabilities to overclock), MPLL can generate 50Mhz-2Ghz, EPLL can generate 10Mhz - 600 Mhz, VPLL can generate 10Mhz - 600Mhz.
Just looking to generate some new discussion and innovation for our Epics... I am in no way an expert, just learning and sharing what I found out...
Geoff
1st!
10 char
What are you making here?
Sent from my Epic 4G using XDA Premium app
hello guys so i was looking at this project for Motorola Droid X:
http://code.google.com/p/milestone-overclock/
since Droid X has similar OMAP3630 chipset i thought we could try it out for this device...
if it has already been tried out by u guys then sorry for dupe post
anyways the sources available (milestone-overclock-module-1.4.8.tar.gz) were not directly compatible with the i9003 kernel sources (GB_CHN_UPDATE1) so i have modified it slightly.... and now the module gets compiled and it gets loaded (by insmod)... the sysfs and proc interface is active... even the app (MilestoneOverclock148.apk) detects the module correctly... but the changes dont work...
i invite all devs to help out with this...
modified sources are posted here:
https://github.com/DooMLoRD/i9003-overclock
noobs kindly dont spam this thread....
P.S.: Droid X has got overclock upto 1.4GHz with help of this so i am sure we can try little more overclock than 1.1GHz
If you look at the Samsung code in arch/arm/mach-omap2 and /plat-omap, and compare it with code seen for example in the nook color sources (OMAP 3630, see here), there are HUGE differences.
Normally the opp frequency table seems to be hard coded and easy to edit. Samsung on the other hand decided to dynamically assemble it in board-latona.c with info from cpufreq34xx.c (if I overlook that correctly). These differences could be the reason the module does not work.
Further, the line Amit and you changed in clock.c could - but I am not quite sure - actually lead to 10% higher clocks on every opp step. Because what you changed
Code:
- mpurate *= 1000000;
+ mpurate *= 1100000;
is a conversion factor from MHz to Hz. The line
Code:
if (mpurate < 1000)
above seems to be a logical check if the desired clock has been given in Hz or MHz, which is expected to be at max 800 for the 3630. For our 3640 the highest frequency is 1000, which would require the check to be
Code:
if (mpurate < 1001)
or similar, but they might have overlooked this change. If the input is below this boundary, it is thought to be in MHz, and is converted to match the internal logic which works with Hz only.
And two more questions: I experimented a lot with the OC code, and even added two new opps (1100/840 and 1200/865) to my tables. I could select them, and everything including cpufreq scaling tables was correct, but the CPU never was actually clocked above 1000MHz. Do you know why? And did you check if it is with your kernel (compare benchmark values, do not trust any other source, they all lie )?
previously i was also having milestone A853 and by the overclock module it can be overclocked to 1.2 ghz
XDA_Bam said:
If you look at the Samsung code in arch/arm/mach-omap2 and /plat-omap, and compare it with code seen for example in the nook color sources (OMAP 3630, see here), there are HUGE differences.
Normally the opp frequency table seems to be hard coded and easy to edit. Samsung on the other hand decided to dynamically assemble it in board-latona.c with info from cpufreq34xx.c (if I overlook that correctly). These differences could be the reason the module does not work.
Further, the line Amit and you changed in clock.c could - but I am not quite sure - actually lead to 10% higher clocks on every opp step. Because what you changed
Code:
- mpurate *= 1000000;
+ mpurate *= 1100000;
is a conversion factor from MHz to Hz. The line
Code:
if (mpurate < 1000)
above seems to be a logical check if the desired clock has been given in Hz or MHz, which is expected to be at max 800 for the 3630. For our 3640 the highest frequency is 1000, which would require the check to be
Code:
if (mpurate < 1001)
or similar, but they might have overlooked this change. If the input is below this boundary, it is thought to be in MHz, and is converted to match the internal logic which works with Hz only.
And two more questions: I experimented a lot with the OC code, and even added two new opps (1100/840 and 1200/865) to my tables. I could select them, and everything including cpufreq scaling tables was correct, but the CPU never was actually clocked above 1000MHz. Do you know why? And did you check if it is with your kernel (compare benchmark values, do not trust any other source, they all lie )?
Click to expand...
Click to collapse
Yes I know the changes in diff omap kernel sources... Spent a few hrs today comparing milestone/droid x and i9003 kernel sources to get this module complied and loading...
I am sure that the change done by amit is correct, because there is a very prominent change in linpack scores ~18 compared to ~16 which is typical of a 10% overclock...
As for ur other two questions I posted this earlier in the other thread
DooMLoRD said:
Not sure... These omap chips seem to have only 4 bins (300/600/800/1000)... We are currently making the 1000 MHz bin run at 1100mhz... I am not sure if we can add extra bins... I tried adding a lower 125MHz bin, it was shown by setcpu but the device never really went below 300mhz... May be we need to investigate it further...
Sent from my R800i using XDA App
Click to expand...
Click to collapse
P.S.: the chip on this phone is OMAP3630
Sent from my R800i using XDA App
DooMLoRD said:
I am sure that the change done by amit is correct, because there is a very prominent change in linpack scores ~18 compared to ~16 which is typical of a 10% overclock...
Click to expand...
Click to collapse
OK, so the overclock is working. Nice Concerning the mpurate, have a look here. The author is working at TI, so I expect him to be familiar with the code. However, that does not mean we can't use the conversion factor for overclock. It's just not "clean".
DooMLoRD said:
P.S.: the chip on this phone is OMAP3630
Click to expand...
Click to collapse
Yep, you're right. Got that wrong
---------- Post added at 10:50 PM ---------- Previous post was at 10:41 PM ----------
And another idea: For the Nook Color, there is a guy who implemented an interface and an app to change the clocks. It is different from droid-overclock, because he implemented a sysfs interface in the kernel sources. Hope this helps.
http://code.google.com/p/milestone-overclock/
sorry its of no use as yr already checked it out
XDA_Bam said:
And another idea: For the Nook Color, there is a guy who implemented an interface and an app to change the clocks. It is different from droid-overclock, because he implemented a sysfs interface in the kernel sources. Hope this helps.
Click to expand...
Click to collapse
That looks very much like the sysfs interface we added for VDD control on QSD8250/MSM7X30... Should work I think...
Sent from my R800i using XDA App
akashsgpgi said:
http://code.google.com/p/milestone-overclock/
sorry its of no use as yr already checked it out
Click to expand...
Click to collapse
U should be BANNED for spamming.... The link u posted is already there in the second line of the main post...
READ!!!!
Sent from my R800i using XDA App
I made progress with the sysfs interface seen on the Nook. Kernel boots, and the correct rates are displayed under /sys/power/mpu_freq_oppX. I was also able to set the hightest opp to 800 MHz, so that the two highest were both at the same frequency. The setting worked (confirmed with Linpack). But 1100 MHz was ignored (stayed at 1000). Looking into this further.
XDA_Bam said:
I made progress with the sysfs interface seen on the Nook. Kernel boots, and the correct rates are displayed under /sys/power/mpu_freq_oppX. I was also able to set the hightest opp to 800 MHz, so that the two highest were both at the same frequency. The setting worked (confirmed with Linpack). But 1100 MHz was ignored (stayed at 1000). Looking into this further.
Click to expand...
Click to collapse
so wht cpu freq table are u using exactly?
wht i think is we should concentrate on this (atleast for now):
just keep the 4 bins as is (300, 600, 800, 1000)
then try n get the access to these via sysfs (or proc)
see if we can modify them via that interface, say change 1000 to 1100 or change 800 to 900
and then do tests if these work...
if possible make a sysfs (or proc) interface for VDD (voltage control) too...
have u pushed the testing changes... i am working on same thing here... might help to speed things up...
I am currently testing on the master branch, so the branch is "wrong", but this is the commit:
Sysfs interface
Because only underclock works as of now, I am tested setting
Code:
if (mpurate < 2000)
but that didn't help. Now I will define 1100 and 1200 MHz steps in board-latona.c and cpufreq34xx.c to see if this helps.
EDIT: Nope, that didn't solve it. CPU does not run at 1100. Not even 900. Stays at 1000 in both cases. 800 can be forced...
some updates on the overclock module:
we need to search in /proc/kallsyms for:
clk_init_cpufreq_table
cpufreq_stats_update
on our kernel (uc-kernel v04) they are at:
Code:
c005a198 T clk_init_cpufreq_table
c03c5aec t cpufreq_stats_update
these may be different on stock kernel we need to use specific address
I just thought this might be helpful since Optimus black has the same hardware.
joelmonty said:
I just thought this might be helpful since Optimus black has the same hardware.
Click to expand...
Click to collapse
its the same module dude...
these are all based on milestone-overclock module
DooMLoRD said:
some updates on the overclock module:
we need to search in /proc/kallsyms for:
clk_init_cpufreq_table
cpufreq_stats_update
on our kernel (uc-kernel v04) they are at:
Code:
c005a198 T clk_init_cpufreq_table
c03c5aec t cpufreq_stats_update
these may be different on stock kernel we need to use specific address
Click to expand...
Click to collapse
Why these two? Cpufreq seems to be quite happy with the frequency tables. All frequencies are correctly listed, and the highest available for hardware and scaling are correct (say 1100, if I set it). But some "mysterious barrier" doesn't let the cpu clock as high as requested by cpufreq.
XDA_Bam said:
Why these two? Cpufreq seems to be quite happy with the frequency tables. All frequencies are correctly listed, and the highest available for hardware and scaling are correct (say 1100, if I set it). But some "mysterious barrier" doesn't let the cpu clock as high as requested by cpufreq.
Click to expand...
Click to collapse
read the sources of the module it explains why we need to look at those values...
DooMLoRD said:
read the sources of the module it explains why we need to look at those values...
Click to expand...
Click to collapse
Looked into it, and got the module to load and change frequencies by manually setting omap2_clk_init_cpufreq_table_addr=0xXXXXXX. I was able to underclock to 800 and back to 1000 MHz. 1200 was set, but not correctly applied - the mpu was still running at 1000 MHz. Further on, it ****ed up the frequency table. Instead of [300,600,800,1000] it was [600, 600, 1000, 1000] after the test. Not good
XDA_Bam said:
Looked into it, and got the module to load and change frequencies by manually setting omap2_clk_init_cpufreq_table_addr=0xXXXXXX. I was able to underclock to 800 and back to 1000 MHz. 1200 was set, but not correctly applied - the mpu was still running at 1000 MHz. Further on, it ****ed up the frequency table. Instead of [300,600,800,1000] it was [600, 600, 1000, 1000] after the test. Not good
Click to expand...
Click to collapse
yups code needs some more patching but i am sure this is the way forward for stable overclock
I've got the basics working with a completely reworked sysfs interface (no module). See GitHub.
The idea is simple: At all times, there shall be no more than 4 OPPs enabled. For each overclock "wish", we disable the currently highest OPP, and enable the overclocked one. If this has no corresponding OPP yet, we create it.
The code works, and has the following problems / features:
Only the highest OPP can be set for now. Consequently, the overclock has to be higher than 800 MHz.
The voltage is not adjusted, yet. All overclock frequencies are run with the 1 GHz stock voltage.
The cpufreq table, policy and stats are not updated, yet
The cpu does not go into deep sleep after the clocks have been adjusted (possibly because the cpufreq table is wrong)
As OPPs are added to the table if necessary, it is theoretically possible to max out the OPP array by defining new frequencies hundreds of times (depending on the maximum array size).
To set the frequency (in MHz), type
Code:
echo "1100" > /sys/power/overclock_max_freq
It would be really cool if you could take a look, DooMLoRD. The only real problem I see right now is the cpufreq table. If this would be correctly updated, the rest would be "easy" I tried some stuff (not in the commit), but nothing worked, yet.
XDA_Bam said:
I've got the basics working with a completely reworked sysfs interface (no module). See GitHub.
The idea is simple: At all times, there shall be no more than 4 OPPs enabled. For each overclock "wish", we disable the currently highest OPP, and enable the overclocked one. If this has no corresponding OPP yet, we create it.
The code works, and has the following problems / features:
Only the highest OPP can be set for now. Consequently, the overclock has to be higher than 800 MHz.
The voltage is not adjusted, yet. All overclock frequencies are run with the 1 GHz stock voltage.
The cpufreq table, policy and stats are not updated, yet
The cpu does not go into deep sleep after the clocks have been adjusted (possibly because the cpufreq table is wrong)
As OPPs are added to the table if necessary, it is theoretically possible to max out the OPP array by defining new frequencies hundreds of times (depending on the maximum array size).
To set the frequency (in MHz), type
Code:
echo "1100" > /sys/power/overclock_max_freq
It would be really cool if you could take a look, DooMLoRD. The only real problem I see right now is the cpufreq table. If this would be correctly updated, the rest would be "easy" I tried some stuff (not in the commit), but nothing worked, yet.
Click to expand...
Click to collapse
this is the same problem as with other overclocks i was playing with...
the cpufreq table doesnt get updated... only the module based way seems to change that table...
anyways we will have to investigate this further...
oh btw i have found patch to overclock GPU...
DooMLoRD said:
oh btw i have found patch to overclock GPU...
Click to expand...
Click to collapse
Nice. Hehe
So, I'm working on a new jailbreak that I hope will be more reliable and faster. I have my DLL injected into csrss.exe and now need to exploit the kernel.
The exploit itself is rather limiting: you can only decrement an aligned dword whose new value will be greater than zero in a signed sense. If you decrement a dword whose value then becomes zero or negative, the kernel will bugcheck (BSOD). Same if you try to decrement an unaligned dword, because the InterlockedDecrement instructions will throw an exception on ARM.
The ultimate goal is to set g_ciEnabled in ntoskrnl.exe to zero. The current jailbreak works by decrementing that dword almost 0x80000 times to lower g_ciEnabled from 8 to 0. However, this is unreliable for several reasons, mostly due to other flags in that same dword.
The other way to accomplish this is to get arbitrary code running in the kernel, then just write to g_ciEnabled directly. This is a lot easier said than done.
Directly attacking function pointers in the kernel or drivers doesn't work. This is because all kernel pointers have their high bit set, and therefore would bugcheck when decremented.
Setting bits in g_CiDeveloperMode in ci.dll would allow loading of kernel drivers signed with a self-signed certificate - this is test signing mode from the desktop Windows. However, this value is zero, and decrementing it to -1 bugchecks due to being negative.
The function pointers in the system service dispatch table are encoded specially, such that they end up not having their high bit set. This makes them interesting targets. However, this table is stored at an unknown runtime address. This address is unknowable to user mode. Also, the ARM kernel has PatchGuard, meaning that changing the SSDT will bugcheck the next time the PatchGuard DPC runs.
Another idea I had is to poke at our trap frame from a second thread, in order to set the saved status register's privilege level to system - to make the kernel return to a kernel thread but in our space. This is problematic because the trap frame is at an unknown address.
A timing attack could be used, where one thread pokes at the kernel stack of another thread while it executes a system call. This has interesting possibilities, but how would we know the address of the kernel stack for a thread?
Getting a handle to \Device\PhysicalMemory would be nice, but difficult. Also, how would we get the physical address of ntoskrnl.exe? The virtual address is easy by comparison.
Just ramblings of my thought process on this. =)
Myriachan said:
So, I'm working on a new jailbreak that I hope will be more reliable and faster. I have my DLL injected into csrss.exe and now need to exploit the kernel.
Click to expand...
Click to collapse
The main speed issue is that something is out of sync for the first 100 seconds or so after booting that causes the kernel call we exploit to crash.
Myriachan said:
The exploit itself is rather limiting: you can only decrement an aligned dword whose new value will be greater than zero in a signed sense. If you decrement a dword whose value then becomes zero or negative, the kernel will bugcheck (BSOD). Same if you try to decrement an unaligned dword, because the InterlockedDecrement instructions will throw an exception on ARM.
The ultimate goal is to set g_ciEnabled in ntoskrnl.exe to zero. The current jailbreak works by decrementing that dword almost 0x80000 times to lower g_ciEnabled from 8 to 0. However, this is unreliable for several reasons, mostly due to other flags in that same dword.
Click to expand...
Click to collapse
I haven't noticed many, if any issues with it doing that (except that we're not editing g_ciEnabled)
Myriachan said:
The other way to accomplish this is to get arbitrary code running in the kernel, then just write to g_ciEnabled directly. This is a lot easier said than done.
Click to expand...
Click to collapse
Especially since g_ciEnabled doesn't exist on ARM.
Myriachan said:
Directly attacking function pointers in the kernel or drivers doesn't work. This is because all kernel pointers have their high bit set, and therefore would bugcheck when decremented.
Click to expand...
Click to collapse
All kernel code is loaded at 0x80000000 or higher.
Myriachan said:
Setting bits in g_CiDeveloperMode in ci.dll would allow loading of kernel drivers signed with a self-signed certificate - this is test signing mode from the desktop Windows. However, this value is zero, and decrementing it to -1 bugchecks due to being negative.
Click to expand...
Click to collapse
I've been trying to do something like that, but I've hit a wall since all the pointers, as you said, have the negative bit set. I wanted to hijack a pointer in the HalDispatchTable.
Myriachan said:
The function pointers in the system service dispatch table are encoded specially, such that they end up not having their high bit set. This makes them interesting targets. However, this table is stored at an unknown runtime address. This address is unknowable to user mode. Also, the ARM kernel has PatchGuard, meaning that changing the SSDT will bugcheck the next time the PatchGuard DPC runs.
Click to expand...
Click to collapse
Again, all kernel code is loaded at 0x80000000 or higher.
Myriachan said:
Another idea I had is to poke at our trap frame from a second thread, in order to set the saved status register's privilege level to system - to make the kernel return to a kernel thread but in our space. This is problematic because the trap frame is at an unknown address.
A timing attack could be used, where one thread pokes at the kernel stack of another thread while it executes a system call. This has interesting possibilities, but how would we know the address of the kernel stack for a thread?
Click to expand...
Click to collapse
Even if you somehow pull that off, how is that going to be better than the current tool?
Myriachan said:
Getting a handle to \Device\PhysicalMemory would be nice, but difficult. Also, how would we get the physical address of ntoskrnl.exe? The virtual address is easy by comparison.
Click to expand...
Click to collapse
A handle to PhysicalMemory can only be opened by ring-0 code.
g_ciEnabled doesn't exist on arm, we're editing an unnamed variable that controls the required signing level (not rather signing is enabled). See clrokr's blog for more information, and read/search through the Hacking Windows RT to run Desktop Apps thread to see that we've tried quite a few of the things you listed.
All the things you suggested are either impossible (with current knowledge, or just flat out impossible), or far more likely to cause issues than the current jailbreak. Also, what stability issues are you having with the current jailbreak? It works 100% of the time for me.
Hello, I'm new on this forum then I'm sorry if i post in a bad section for my questions... But I think I should post here.
I've got several questions:
- Is there really no risk about undervolting CPU, I asked me about this because no one forum tell risk but compagny thaty produces phones don't set the minimal voltage required for each frequencies.
- Is there an app to force CPU usage at 100% to test undervolt options.
Example: I undervolt 2265MHz with -50mV, I launch app, click on 100% uage then it use at 100% my CPU, if it crash undervolt is to high. If it don't crash undervolt is good, maybe continue tu undervolt.
- Is there an automatic app to undervolt ?
Example: It decrease 1mV by 1mV with always the same frequencie of CPU and 100% CPU usage then when phone crash it restore the last value of voltage, then it do it with another frequency etc etc ...
- Which voltage do you use ? And are there voltages the same for all nexus 5 or they will change depending of each processor.
To give me an opinion about what to use
- If I found a minimum voltage, will it be the same for all kernel ?
Example: I'm on Kernel A, my min for 300MHz is 725mV, I switch to kernel B, Will it work with 725mV for 300MHz??
More generally it depend only of the processor or also of the kernel, governor, I/O scheduler ??
I Think it's all maybe other questions will come
I Thank you for all your constructive response. Don't hesitate to ask me to develop certain question and tell me mistakes .
Theres an undervolting thread. Should be linked in the "Sticky roll-up thread" which you can get to via my signature
Okay, thank you
Okay, I will copy/paste my message
Thak you for the information.