When I worked on some ARM embedded projects, we used the zero wait state SRAM of the ARM chip to speed up our applications. The performance benefit is tremendous. There is no published way to access it on Windows Mobile, but there probably is a way. Anyone have a clue? Most likely it will be addresses lower or higher than the video buffer.
Thanks,
L.B.
logical quest..
hi.!
I was interested for your topic..
i know that there are some app
that permise you the overclocking
of texas omap...what is this? another
type of overclocking? i think that is
very dangerous way..the risk for the cpu
fusion is high..!so..i don't think that is
a good idea..and the margin that you have
for example with an 200 Mhz processor is minimum for
a good overclocking..if i were you, i should not force the default limit setting by the HTC company.. Ppc device haven't a fan for heat's dissipation (it isn't a PC!) , so when you use the PDA and consequently you make his overclocked cpu under pressure, its go aut of order and..Bang.! do you agree?
What I'm asking has nothing to do with overclocking. The DRAM in PDA's is slow compared to how fast instructions can execute. Built into most ARM CPUs is a small amount of static RAM (usually 256K or 384K) that is usually used for the video buffer. The excess memory is useful for storing data for your applications to run quicker since it won't have to wait for the RAM.
I personally do not overclock my PDAs.
is this a sort of SecondLevelDataCache as Winzozz XP?
devilpera64: This is SRAM as in STATIC RAM. It's a little area of high speed memory (0 wait state) built onto the processor silicon. It's quite useful for use as a video buffer and for speeding up critical sections of code.
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
I'm trying to study the Snapdragon 845 voltage regulators, but am struggling to find the regulator source code.
Usually, my approach to finding the regulator source code would be to watch all regulators, change the CPU frequency and see which regulator is changing values and then grep the regulator's name in the sources to find the relevant files. On the OnePlus6, this doesn't seem to be happening for some reason.
Is there a simpler or more generic way to find CPU voltage regulators regardless of the SoC? Where can I find the regulator source code for the snapdragon845 on the OnePlus6? My goal is to try and understand the undervolting behavior of this chip.
phenoxis said:
I'm trying to study the Snapdragon 845 voltage regulators, but am struggling to find the regulator source code.
Usually, my approach to finding the regulator source code would be to watch all regulators, change the CPU frequency and see which regulator is changing values and then grep the regulator's name in the sources to find the relevant files. On the OnePlus6, this doesn't seem to be happening for some reason.
Is there a simpler or more generic way to find CPU voltage regulators regardless of the SoC? Where can I find the regulator source code for the snapdragon845 on the OnePlus6? My goal is to try and understand the undervolting behavior of this chip.
Click to expand...
Click to collapse
This should go in the q and a section
joemossjr said:
This should go in the q and a section
Click to expand...
Click to collapse
My bad. I was fighting with the forum to try and add a title (on my browser, the title text input keeps vanishing before I can type anything) and ended up posting. To the best of my knowledge, I'm unable to find a 'delete thread' option. If someone can help me find it, I will go ahead and delete this post, if not @moderators: sorry for the hassle, please delete this post.
I will post in the Q&A forum.
Dont worry about deleting and re-posting. I went ahead and asked mods to move it.
Check these files:
sdm845-qrd.dtsi
sdm845-sde.dtsi
sdm845.dtsi
sdm845-v2.dtsi
Zombie said:
Dont worry about deleting and re-posting. I went ahead and asked mods to move it.
Check these files:
sdm845-qrd.dtsi
sdm845-sde.dtsi
sdm845.dtsi
sdm845-v2.dtsi
Click to expand...
Click to collapse
I'm looking at these files, but I don't understand which regulator I should be looking at . Could you please provide a couple of pointers?
I tried looking for 'cpu' and 'core', but failed to find anything that seemed relevant. I do see the CPU groups and clusters, but no sign of association of a voltage regulator with CPU(s).
I was half expecting the answers to be .c and .h files and the voltages to be in some sort of a table-like frequency <-> voltage entries. I don't quite know how to go about reading .dts(i) files
edit: sdm845.dtsi gives me the cluster configuration and in sdm845-v2.dtsi, I do see what I think are DVFS tables, but no sign of a regulator name.
phenoxis said:
I'm looking at these files, but I don't understand which regulator I should be looking at . Could you please provide a couple of pointers?
I tried looking for 'cpu' and 'core', but failed to find anything that seemed relevant. I do see the CPU groups and clusters, but no sign of association of a voltage regulator with CPU(s).
I was half expecting the answers to be .c and .h files and the voltages to be in some sort of a table-like frequency <-> voltage entries. I don't quite know how to go about reading .dts(i) files
edit: sdm845.dtsi gives me the cluster configuration and in sdm845-v2.dtsi, I do see what I think are DVFS tables, but no sign of a regulator name.
Click to expand...
Click to collapse
New chip new set of issues. I havent had much time to look into it because of real life. The only chip ive managed undervolting on was the 835 which worked. But everything is different with the 845
rpmh
There are new interface and they call that RPMh Regulators. Read the wiki in source files. At this moment of time I'm trying to anderstand how it work, at least there possible manually limit voltage range, but I can't say is it working.