Overclocking

[dom]

Cool! I wasn't sure if the RAM speed had to be an integer multiple of anything like the various GPU timings.

No. ARM, SDRAM and GPU each have their own PLLs can can be unrelated frequencies.
The GPU core, h264, v3d and isp share a PLL, so need to have related frequencies.

Looking at the code, the PLL will be set to:
pll_freq = core_freq * 2^n, for smallest n satisfying pll_freq > 600MHz.

GPU core, h264, v3d and isp should all be integer divisors of PLL freq.
So if core_freq=480, then pll_freq=960. That would allow a v3d_freq of 320 with an integer divider.

Cool! I wasn't sure if the RAM speed had to be an integer multiple of anything like the various GPU timings.

No. ARM, SDRAM and GPU each have their own PLLs can can be unrelated frequencies.
The GPU core, h264, v3d and isp share a PLL, so need to have related frequencies.

Looking at the code, the PLL will be set to:
pll_freq = core_freq * 2^n, for smallest n satisfying pll_freq > 600MHz.

GPU core, h264, v3d and isp should all be integer divisors of PLL freq.
So if core_freq=480, then pll_freq=960. That would allow a v3d_freq of 320 with an integer divider.

This explanation has made the most sense to me of them all. It is the pll_freq that has to be an integer divisor, not a divisor of core_freq.
Thanks dom

Thanks dom, that clears up some stuff! I wanted to up my core_freq but using xbmc on that box as well meant I had to keep it in sync with the rest of the gpu ones - and it couldn't be over 300.
this means I can still try something like 300 for the other gpu frequencies, and core_freq at 450. Meaning a pll_freq at 900. Right?

[dom]

Thanks dom, that clears up some stuff! I wanted to up my core_freq but using xbmc on that box as well meant I had to keep it in sync with the rest of the gpu ones - and it couldn't be over 300.
this means I can still try something like 300 for the other gpu frequencies, and core_freq at 450. Meaning a pll_freq at 900. Right?

Yes, that should be fine.

Yes, that should be fine.

Thanks, but it wasn't. My chip just can't do 450 core_freq, and any lower it seems I'm better off with gpu_freq at 300. Even with overvolting to 6.

Hopefully my second RPi order will be able to handle that - one of them are going on permanent solar power and won't need any overclock

PS. I can clock to 450 and 500 as I wish as long as I don't start XBMC - which pretty much means, the problems don't start untill you really utilize the GPU. I think a LOT of people here are going to run into problems with their overclock settings when they start using the GPU.

[dom]

Thanks, but it wasn't. My chip just can't do 450 core_freq, and any lower it seems I'm better off with gpu_freq at 300. Even with overvolting to 6.

You probably need more than a 700mA power supply for that sort of overclock.
(and even then it depends how amenable your specific Pi is to overclocking whether that will work).

USB port on my router is fine for stock frequencies, but not sufficient for overclocking.

You probably need more than a 700mA power supply for that sort of overclock.
(and even then it depends how amenable your specific Pi is to overclocking whether that will work).

USB port on my router is fine for stock frequencies, but not sufficient for overclocking.

Yea no luck I'm afraid, it's the chip. I was using a 750mA Blackberry adapter (which is good quality), and just now tried a 1A Samsung S3 adapter (also good quality) and it's exactly the same - so no lack in power input, just the chip won't handle more (while GPU is being abused).
I have a 2.1A adapter laying around here somewhere I could try, but it just isn't the power that's the problem.

*EDIT*
As I mentioned, I can do alot more as long as I stay away from the GPU - both 1000 on arm, 500 on core works fine for console and X. XBMC will lock it hard after a couple secs though, as I suspect omxplayer would as well.

This is my current config. Seems to be working fine. I cannot get arm_freq to be stable at 850.
I am trying to get quake or openarena working to test the gpu settings. Trying Quake3 from memetic.org which is supposed to work with raspianhf with sound. Openarena from Synaptic is giving video mode errors.

Code: Select all

arm_freq=800

# pll_freq=Core_freq*2^n if core=480, then pll=960 gpu=320 or 480
# pll must be 600 or more
core_freq=480
gpu_freq=320
# probably do not need to specify all if gpu_freq specified.
h264_freq=320
v3d_freq=320
isp_freq=320

sdram_freq=500
hdmi_force_hotplug=1
# enable hdmi sound =2
hdmi_drive=2
hdmi_group=2
config_hdmi_boost=4
disable_overscan=1
framebuffer_width=1366
framebuffer_height=768

# settings for Motorola Lapdock

This is my current config. Seems to be working fine. I cannot get arm_freq to be stable at 850.
I am trying to get quake or openarena working to test the gpu settings. Trying Quake3 from memetic.org which is supposed to work with raspianhf with sound. Openarena from Synaptic is giving video mode errors.

Code: Select all

arm_freq=800

# pll_freq=Core_freq*2^n if core=480, then pll=960 gpu=320 or 480
# pll must be 600 or more
[b]core_freq=480
gpu_freq=320[/b]
# probably do not need to specify all if gpu_freq specified.
h264_freq=320
v3d_freq=320
isp_freq=320

sdram_freq=500
hdmi_force_hotplug=1
# enable hdmi sound =2
hdmi_drive=2
hdmi_group=2
config_hdmi_boost=4
disable_overscan=1
framebuffer_width=1366
framebuffer_height=768

# settings for Motorola Lapdock

Question to dom: Would core_freq be set to 320 or 480 with this setup?

I'd suggest you pump core_freq to 375, and leave the rest at 250, for GPU power, and gpu_freq at stock and arm_freq at 850 for CPU power.

Matthew:out

[dom]

Question to dom: Would core_freq be set to 320 or 480 with this setup?

Both are valid in terms of integer ratios of clocks and PLL.

I'd expect 480 will only work with overvolting, but otherwise pick the highest one that is stable for you.

The 480 core appeared to working. Then I got quake 3 up; crashed. 450 the same thing. I will try 375 next. When the other two RasPii get here it will be time to push this one into overvolting. Quake3 with sound is the ticket! still trying to get Openarena working. Might have been the core setting. Nope still getting "GLimp_Init() - could not loadOpenGL subsystem error".

What's making it so that all the clocks can't be at their own max at the same time? E.g, arm_freq could hit 1150 and sdram_freq could be 550 separately , but only 1100 and 500 at the same time, respectively.

Is it a weak VReg?

What's making it so that all the clocks can't be at their own max at the same time? E.g, arm_freq could hit 1150 and sdram_freq could be 550 separately , but only 1100 and 500 at the same time, respectively.

Is it a weak VReg?

could be that as the Voltage regulator may not be designed to handle that much power or the adapter coming from the wall can't provide that much.

arm_freq and sdram_freq can be set seperately. The video freqs are what are tied together under gpu_freq. The divisor stuff is for core_freq that ties into the gpu.

arm_freq has its own clock (pll)
sdram_freq has its own clock (pll)

gpu_freq, if specified, sets v3d_freq, h264_freq, isp_freq
core_freq: gpu_freq as integer divisor or v3d_freq, h264_freq, isp_freq must be set seperately as INTEGER DIVISORS of core_freq. All explained in detail above.

As to why some RasPi overclock better than others, look back for @dom's explanation. Some of it is the wafers at production and some is PSU and or other power problems. So mostly just luck as to which RasPi you end up with. Mine refuses to be stable at anything over ARM 800MHz, GPU 320MHz, and SDRAM 500MHz, with no overvolt. Brothers RasPI ARM 900MHz, GPU 325, MHz SDRAM 500MHz no overvolt. Others have been able to go even higher without overvolting.

Thanks, cleared up something I was thinking about. I should've been more clear though. I was asking why some people could hit, for example:

arm_freq=1150
sdram_freq=500

and:

arm_freq=1100
sdram_freq=550

but not:

arm_freq=1150
sdram_freq=550

and whether this was power supply issue, a board voltage regulator issue, or an internal voltage regulator issue. It'd be nice for some of these people to post their power supply info.

Just wanted to share my experience with the Pi.

No overvolting.
Attached a heatsink.
1A iPhone charger.

Code: Select all

arm_freq=950
sdram_freq=500
gpu_freq=250


Running XBMC stable while at 100% load.
The gpu freq does not seem to like any higher than 300. Still have to play more around with that, or overvolt.

[dom]

and whether this was power supply issue, a board voltage regulator issue, or an internal voltage regulator issue. It'd be nice for some of these people to post their power supply info.

Yes, can be an input (5V) power supply current issue, or the input polyfuse restricting voltage/current, or the internal 1.2V voltage regulator current limit.

Okay, so the 3v3 and 1v8 regulators should provide adequate power for any overclocking? I see their datasheets say 1.0A each, assuming they get enough input voltage and amperage.

Looking at the schematic, tp1 is after the polyfuse. Should I edit the wiki in the tp1 tp2 voltage check section to say checking amperage could blow the polyfuse, possibly weakening it?

And is it safe to check the voltage of the regulators while the pi is running?

Yes, can be an input (5V) power supply current issue, or the input polyfuse restricting voltage/current, or the internal 1.2V voltage regulator current limit.

I checked voltage after the 5v (5.02) 3.3v (3.28) good and the 1.8v (1.8) good. Is there any external point to check the 1.2v? There was nothing I could find on the schematics. Nothing you could do about it anyway.

If it was the incoming poly fuse you could swap it out for a 1.1A which spec at a lower resistance range.

Looking at the schematic, tp1 is after the polyfuse. Should I edit the wiki in the tp1 tp2 voltage check section to say checking amperage could blow the polyfuse, possibly weakening it?

TP1 and TP2 can only be used for measuring voltage. If you tried to use them to measure current, your multimeter would act as a short-circuit on the Pi's power input, and it'll be a race whether the fuse in your multimeter or the polyfuse on the RPi will blow first

And is it safe to check the voltage of the regulators while the pi is running?

As long as you attach your probes to the right place, yup that's fine. If you don't know where "the right place" is, I'd suggest not trying.

This topic is relevant to my interests.

Just curious, as this doesn't seem to have been explicitely covered. Dom, and others, have mentioned the way core_freq ties into gpu_freq via an integer dividor of the pll, which is based on the core_freq. So my question is, when you set the core_freq higher, do you not have to adjust the gpu_freq as well? Or if left default, does it simply go by the same integer dividor and therefore is automatically raised with core_freq?

Many people have posted how they raised arm, ram, and core freqs but no mention of gpu freq, so that's why I wonder. If it just sticks to 250 without manual modification, then it seems that it would be less stable with a raised core_freq.

TP1 and TP2 can only be used for measuring voltage. If you tried to use them to measure current, your multimeter would act as a short-circuit on the Pi's power input, and it'll be a race whether the fuse in your multimeter or the polyfuse on the RPi will blow first

This is completely irrelevant to this thread, but I have an old mechanical multimeter that I used to short-circuit for testing power supplies like all the time. A couple of seconds of 12A never seriously harmed it . It bent the tip of the probes, though. Though, I agree TP1 and TP2 are only for testing voltage under various amounts CPU/GPU load (usually drops a few tenths of volts)

We are not showing concern about damage to the meter. Do you think it a good idea to short TP1 and TP2 together, effectively shorting the 5V supply rails on the circuit board though?

We are not showing concern about damage to the meter. Do you think it a good idea to short TP1 and TP2 together, effectively shorting the 5V supply rails on the circuit board though?

Shorting out TP1 and TP2 will make the 6v 1A polyfuse trip. In essence it won't do any damage to the board at all, as the polyfuse (labelled F3; it's the green thing on the bottom of the board) will prevent a prolonged short-circuit

I consider a fuse of any type to be the last resort when things go wrong. I don't consider doing something that would deliberately cause a safety device to trip, to be good practice, unless it is to test that the safety device works.