Caanoo / WIZ Overclocking The Caanoo


Simon,

please add support for ogg files to sdl_mixer. Why this format has been removed? Now, we have to compile our own sdl_mixer or using mp3. But distributing our homebrew software with mp3 needs a license, which most of us not have.

Regards
Thomas
 
Exophase said:
Looks like some really good work, thanks Lordus.

I wonder how much impact AHB speed really has in practice. Is the SDRAM clocked directly off of AHB afterall? I meant to check that and forgot to.

If I send you a cache miss timing test are you willing to run it at all those clock speeds too? :D
Click to expand...

just out of personal interest, never done such low-level measurements. how would such a timing test look like? codewise?
 
Last edited by a moderator:
crow_riot said:
just out of personal interest, never done such low-level measurements. how would such a timing test look like? codewise?
Click to expand...

Here's one way to do it:

Read through a big array of memory with steps one cache line apart, so that each load causes a cache miss, then look at the number of cycles per iteration by running many many iterations of this and time it. To remove cache load/instruction execution parallelism follow up the load of the first cache line word with a load of the last word, and remove the number of cycles spent on looping (if you can't figure it out you can time it w/o the loads).

This only tests performance of clean cacheline invalidations, where no writebacks have to be made (ARM9 on Wiz at least is write back, not write through). To test the worse case cache line miss + writeback you can follow the load up with a store to the end of the cache line instead of a second load.
 
Last edited by a moderator:
Exophase said:
Here's one way to do it:

Read through a big array of memory with steps one cache line apart, so that each load causes a cache miss, then look at the number of cycles per iteration by running many many iterations of this and time it. To remove cache load/instruction execution parallelism follow up the load of the first cache line word with a load of the last word, and remove the number of cycles spent on looping (if you can't figure it out you can time it w/o the loads).

This only tests performance of clean cacheline invalidations, where no writebacks have to be made (ARM9 on Wiz at least is write back, not write through). To test the worse case cache line miss + writeback you can follow the load up with a store to the end of the cache line instead of a second load.
Click to expand...

thanks for the explanation. i understand half of it, so that's more than i expected ;)
 
Last edited by a moderator:
notaz said:
simon(gph) said:
1. for overclocking

PLL0 = 530.55Mhz (p=20, m=393, s=0) Changed for IIS(Sound Interface) Source Clock.
AHB = PLL0 / 4
PLL1 = 132.75Mhz (p=6, m=59, s=1) Changed for stability of Caanoo.
BCLK = PLL1
Click to expand...
That's good, sounds like old overclocking method will work with this.

simon(gph) said:
IIS = PLL0/n
Click to expand...
Why?? Won't that cause sound speedup when overclocking? This will break all programs that don't use dedicated threads to generate sound.

simon(gph) said:
If you want to try with it, send me e-mail (simon@gp2x.com).
But i don't want publish it before release.
Click to expand...
Can you publish the kernel source? Linux kernel is licensed under GPLv2, which requires making the source available when binaries are released.
Click to expand...

Sorry, It's mean open the source code such like as WIZ.
I'll upload u-boot and kernel source to file archive when each release new firmware.


And, IIS source clock and divider changed for sample rate.
I change the kernel sound driver to find best divider value for IIS when overclocking or not.
So, It'll be no problem when which PLL0 divider value is selected including overclocking.
Refer to following kernel sound dirver source code.

======================================================================
static long audio_set_dsp_speed(long val, audio_stream_t * s)
{
unsigned int mclk_div, bitclk_div;
int m, b, d=1000000, pll = get_pll_clk(CLKSRC_PLL0);

if( (s->rate == val) && (s->cpu_pll == pll) ) return val;

if(val < 6000 || val > 96000)
return -1;

for(m=32; m<=64; m++)
for(b=2; b<=64; b++)
if(abs(pll/m/b/64-val) <= d)
{
d = abs(pll/m/b/64-val);
mclk_div = m;
bitclk_div = b;
}

/* rate = pll1 / mclk_div / bitclk_div / 64 */
MES_AUDIO_SetClockDivisor(0 ,mclk_div);
MES_AUDIO_SetClockDivisor(1 ,bitclk_div);

s->rate = val;
s->cpu_pll = pll;

return val;
}
======================================================================

Thanks
 
Last edited by a moderator:
Thomas99 said:
Simon,

please add support for ogg files to sdl_mixer. Why this format has been removed? Now, we have to compile our own sdl_mixer or using mp3. But distributing our homebrew software with mp3 needs a license, which most of us not have.

Regards
Thomas
Click to expand...

You are right, and I'd give this issue to software engineer few weeks ago.
and Ogg file must be supported at next release. (15, sep)
 
Last edited by a moderator:
simon(gph) said:
notaz said:
Can you publish the kernel source? Linux kernel is licensed under GPLv2, which requires making the source available when binaries are released.
Click to expand...

Sorry, It's mean open the source code such like as WIZ.
I'll upload u-boot and kernel source to file archive when each release new firmware.
Click to expand...
That's good news!

simon(gph) said:
So, It'll be no problem when which PLL0 divider value is selected including overclocking.
Refer to following kernel sound dirver source code.
Click to expand...
With this code you will sometimes get a large drift. For example, if PLL0 is 570MHz and you want to play 44100Hz sound, your code will result in 44531Hz rate, which is ~1% faster than needed. When you change the overclock, the drift also changes, which may cause glitches on some apps. Are you sure it's better than using PLL1?

A comment about your code:
Code: 
static long audio_set_dsp_speed(long val, audio_stream_t * s)
{
<snip>
    /* rate = pll1 / mclk_div / bitclk_div / 64 */
    MES_AUDIO_SetClockDivisor(0 ,mclk_div);
    MES_AUDIO_SetClockDivisor(1 ,bitclk_div);

    s->rate = val;
    s->cpu_pll = pll;

    return val;
}
You should better
Code: 
return pll / mclk_div / bitclk_div / 64;
here. This way the app/game will know sound is playing not at (for example) requested 44100 rate, but something like 44531 or similar. This way the game has a chance to adjust itself to compensate for faster running sound.
 
Last edited by a moderator:
Is bitclk_div 1 not available? Otherwise you could get pretty accurate frequencies with PLL1 at 132,75MHz for standard sample rates:

[mclk_div, bitclk_div, rate, target, error]

47, 4, 11033, 11025, 0.073%
47, 2, 22066, 22050, 0.073%
47, 1, 44132, 44100, 0.073%
 
Lordus said:
Is bitclk_div 1 not available? Otherwise you could get pretty accurate frequencies with PLL1 at 132,75MHz for standard sample rates:

[mclk_div, bitclk_div, rate, target, error]

47, 4, 11033, 11025, 0.073%
47, 2, 22066, 22050, 0.073%
47, 1, 44132, 44100, 0.073%
Click to expand...

mclk_div, bitclk_div 1 is not available. It's silicon bug.
 
Last edited by a moderator:
notaz said:
simon(gph) said:
notaz said:
Can you publish the kernel source? Linux kernel is licensed under GPLv2, which requires making the source available when binaries are released.
Click to expand...

Sorry, It's mean open the source code such like as WIZ.
I'll upload u-boot and kernel source to file archive when each release new firmware.
Click to expand...
That's good news!

simon(gph) said:
So, It'll be no problem when which PLL0 divider value is selected including overclocking.
Refer to following kernel sound dirver source code.
Click to expand...
With this code you will sometimes get a large drift. For example, if PLL0 is 570MHz and you want to play 44100Hz sound, your code will result in 44531Hz rate, which is ~1% faster than needed. When you change the overclock, the drift also changes, which may cause glitches on some apps. Are you sure it's better than using PLL1?

A comment about your code:
Code: 
static long audio_set_dsp_speed(long val, audio_stream_t * s)
{
<snip>
    /* rate = pll1 / mclk_div / bitclk_div / 64 */
    MES_AUDIO_SetClockDivisor(0 ,mclk_div);
    MES_AUDIO_SetClockDivisor(1 ,bitclk_div);

    s->rate = val;
    s->cpu_pll = pll;

    return val;
}
You should better
Code: 
return pll / mclk_div / bitclk_div / 64;
here. This way the app/game will know sound is playing not at (for example) requested 44100 rate, but something like 44531 or similar. This way the game has a chance to adjust itself to compensate for faster running sound.
Click to expand...

That's good idea. I'll test "return pll / mclk_div / bitclk_div / 64" in various apps & games.
And, I recommend to use following overclocking table.
=============================================================
PLL0=530550000(p=20,m=393,s=0), 22050 : mclk=47, bitclk= 8 [ -3]
PLL0=530550000(p=20,m=393,s=0), 44100 : mclk=47, bitclk= 4 [ -6]
PLL0=533250000(p=20,m=395,s=0), 22050 : mclk=63, bitclk= 6 [ -8]
PLL0=533250000(p=20,m=395,s=0), 44100 : mclk=63, bitclk= 3 [ -16]
PLL0=558900000(p=20,m=414,s=0), 22050 : mclk=44, bitclk= 9 [ 2]
PLL0=558900000(p=20,m=414,s=0), 44100 : mclk=33, bitclk= 6 [ 5]
PLL0=564300000(p=20,m=418,s=0), 22050 : mclk=50, bitclk= 8 [ -8]
PLL0=564300000(p=20,m=418,s=0), 44100 : mclk=50, bitclk= 4 [ -15]
PLL0=587250000(p=20,m=435,s=0), 22050 : mclk=52, bitclk= 8 [ 7]
PLL0=587250000(p=20,m=435,s=0), 44100 : mclk=52, bitclk= 4 [ 14]
PLL0=592650000(p=20,m=439,s=0), 22050 : mclk=60, bitclk= 7 [ -3]
PLL0=592650000(p=20,m=439,s=0), 44100 : mclk=42, bitclk= 5 [ -5]
PLL0=621000000(p=20,m=460,s=0), 22050 : mclk=55, bitclk= 8 [ 2]
PLL0=621000000(p=20,m=460,s=0), 44100 : mclk=55, bitclk= 4 [ 5]
PLL0=626400000(p=20,m=464,s=0), 22050 : mclk=37, bitclk=12 [ -7]
PLL0=626400000(p=20,m=464,s=0), 44100 : mclk=37, bitclk= 6 [ -13]
PLL0=649350000(p=20,m=481,s=0), 22050 : mclk=46, bitclk=10 [ 6]
PLL0=649350000(p=20,m=481,s=0), 44100 : mclk=46, bitclk= 5 [ 13]
PLL0=652050000(p=20,m=483,s=0), 22050 : mclk=42, bitclk=11 [ 2]
PLL0=652050000(p=20,m=483,s=0), 44100 : mclk=33, bitclk= 7 [ 5]
PLL0=654750000(p=20,m=485,s=0), 22050 : mclk=58, bitclk= 8 [ -2]
PLL0=654750000(p=20,m=485,s=0), 44100 : mclk=58, bitclk= 4 [ -4]
PLL0=660150000(p=20,m=489,s=0), 22050 : mclk=52, bitclk= 9 [ -10]
PLL0=660150000(p=20,m=489,s=0), 44100 : mclk=39, bitclk= 6 [ -20]
PLL0=677700000(p=20,m=502,s=0), 22050 : mclk=60, bitclk= 8 [ 10]
PLL0=677700000(p=20,m=502,s=0), 44100 : mclk=60, bitclk= 4 [ 21]
PLL0=688500000(p=20,m=510,s=0), 22050 : mclk=61, bitclk= 8 [ -6]
PLL0=688500000(p=20,m=510,s=0), 44100 : mclk=61, bitclk= 4 [ -11]
PLL0=691200000(p=20,m=512,s=0), 22050 : mclk=49, bitclk=10 [ -10]
PLL0=691200000(p=20,m=512,s=0), 44100 : mclk=49, bitclk= 5 [ -19]
PLL0=711450000(p=20,m=527,s=0), 22050 : mclk=63, bitclk= 8 [ 6]
PLL0=711450000(p=20,m=527,s=0), 44100 : mclk=63, bitclk= 4 [ 12]
PLL0=719550000(p=20,m=533,s=0), 22050 : mclk=51, bitclk=10 [ -5]
PLL0=719550000(p=20,m=533,s=0), 44100 : mclk=51, bitclk= 5 [ -10]
PLL0=722250000(p=20,m=535,s=0), 22050 : mclk=64, bitclk= 8 [ -9]
PLL0=722250000(p=20,m=535,s=0), 44100 : mclk=64, bitclk= 4 [ -18]
PLL0=745200000(p=20,m=552,s=0), 22050 : mclk=48, bitclk=11 [ 2]
PLL0=745200000(p=20,m=552,s=0), 44100 : mclk=44, bitclk= 6 [ 5]
PLL0=747900000(p=20,m=554,s=0), 22050 : mclk=53, bitclk=10 [ -2]
PLL0=747900000(p=20,m=554,s=0), 44100 : mclk=53, bitclk= 5 [ -3]
PLL0=750600000(p=20,m=556,s=0), 22050 : mclk=38, bitclk=14 [ -5]
PLL0=750600000(p=20,m=556,s=0), 44100 : mclk=38, bitclk= 7 [ -10]
PLL0=770850000(p=20,m=571,s=0), 22050 : mclk=42, bitclk=13 [ 9]
PLL0=770850000(p=20,m=571,s=0), 44100 : mclk=39, bitclk= 7 [ 19]
PLL0=776250000(p=20,m=575,s=0), 22050 : mclk=55, bitclk=10 [ 2]
PLL0=776250000(p=20,m=575,s=0), 44100 : mclk=55, bitclk= 5 [ 5]
PLL0=778950000(p=20,m=577,s=0), 22050 : mclk=46, bitclk=12 [ -1]
PLL0=778950000(p=20,m=577,s=0), 44100 : mclk=46, bitclk= 6 [ -2]
PLL0=804600000(p=20,m=596,s=0), 22050 : mclk=57, bitclk=10 [ 5]
PLL0=804600000(p=20,m=596,s=0), 44100 : mclk=57, bitclk= 5 [ 11]
PLL0=810000000(p=20,m=600,s=0), 22050 : mclk=41, bitclk=14 [ -1]
PLL0=810000000(p=20,m=600,s=0), 44100 : mclk=41, bitclk= 7 [ -2]
PLL0=812700000(p=20,m=602,s=0), 22050 : mclk=64, bitclk= 9 [ -5]
PLL0=812700000(p=20,m=602,s=0), 44100 : mclk=48, bitclk= 6 [ -9]
PLL0=832950000(p=20,m=617,s=0), 22050 : mclk=59, bitclk=10 [ 9]
PLL0=832950000(p=20,m=617,s=0), 44100 : mclk=59, bitclk= 5 [ 18]
PLL0=835650000(p=20,m=619,s=0), 22050 : mclk=37, bitclk=16 [ 5]
PLL0=835650000(p=20,m=619,s=0), 44100 : mclk=37, bitclk= 8 [ 11]
PLL0=838350000(p=20,m=621,s=0), 22050 : mclk=54, bitclk=11 [ 2]
PLL0=838350000(p=20,m=621,s=0), 44100 : mclk=33, bitclk= 9 [ 5]
PLL0=846450000(p=20,m=627,s=0), 22050 : mclk=60, bitclk=10 [ -8]
PLL0=846450000(p=20,m=627,s=0), 44100 : mclk=60, bitclk= 5 [ -15]
PLL0=864000000(p=20,m=640,s=0), 22050 : mclk=51, bitclk=12 [ 8]
PLL0=864000000(p=20,m=640,s=0), 44100 : mclk=51, bitclk= 6 [ 17]
PLL0=869400000(p=20,m=644,s=0), 22050 : mclk=56, bitclk=11 [ 2]
PLL0=869400000(p=20,m=644,s=0), 44100 : mclk=44, bitclk= 7 [ 5]
PLL0=874800000(p=20,m=648,s=0), 22050 : mclk=62, bitclk=10 [ -4]
PLL0=874800000(p=20,m=648,s=0), 44100 : mclk=62, bitclk= 5 [ -8]
PLL0=880200000(p=20,m=652,s=0), 22050 : mclk=52, bitclk=12 [ -10]
PLL0=880200000(p=20,m=652,s=0), 44100 : mclk=52, bitclk= 6 [ -20]
PLL0=897750000(p=20,m=665,s=0), 22050 : mclk=53, bitclk=12 [ 5]
PLL0=897750000(p=20,m=665,s=0), 44100 : mclk=53, bitclk= 6 [ 11]
 
Last edited by a moderator:
Hi simon, a little offtopic, sorry.

Do you know if there are plans to release a new Wiz's firmware version?
There's any chance to get the lastest 1.2.1 kernel sources?

Again, sorry for the offtopic :p
 
HopeZ said:
Hi simon, a little offtopic, sorry.

Do you know if there are plans to release a new Wiz's firmware version?
There's any chance to get the lastest 1.2.1 kernel sources?

Again, sorry for the offtopic :p
Click to expand...

Hi HopeZ,

Just before, I finished upload 1.2.1 source code to file archive.
Unofficially, I heard that current test version is 1.2.5. It's integrated Wifi function and so on, and will be release soon.

Thanks.
 
Last edited by a moderator:
Thanks, simon! Also thanks for sending me the new Caanoo firmware. Runs really stable and MAME overclocking now seem to work.
 
jutley said:
gime gime gime please i want overclocking in mame
Click to expand...

Maybe if you email Simon and ask really nicely, he'll give you a pre-release firmware update. :)
He did for me actually, when I was asking about implementing autorun.gpu (turns out it's still in the Caanoo firmware)
 
Last edited by a moderator:
simon(gph) said:
Hi HopeZ,

Just before, I finished upload 1.2.1 source code to file archive.
Unofficially, I heard that current test version is 1.2.5. It's integrated Wifi function and so on, and will be release soon.

Thanks.
Click to expand...

WOW

Thanks simon, that sounds fantastic, also thank you for your speed uploading the firm.

^_^ now it's time to get at work
 
Last edited by a moderator:
Mr 2X said:
Well Tony Han said on FB
" In the middle of September the New Firmware for the Wiz will be available :) "
Click to expand...

Simon, are two uploaded sourcecode for UBOOT the same ?
Click to expand...

No, I uploaded 1.2.1 version, and New Firmware version will be 1.2.5.
1.2.5 version firmware including source code is not released yet.
 
Last edited by a moderator:
Hi Simon,
will be in the next firmware release any change to make the battery last longer. Because it goes flat very quickly...
 
You must log in or register to reply here.

Similar threads

R
Setting Clock Speeds
Replies
4
Views
2K
rlyeh
rlyeh
S
Changing Clock Speed
Replies
6
Views
3K
Vimacs
V
N
GP2X Underclocking Disables Touch Screen?
Replies
5
Views
3K
GernotFrisch
GernotFrisch
Alex.
Caanoo / WIZ Caanoo Ini Files
Replies
7
Views
5K
pierre
P
L
Gpsp Overclocking
Replies
1
Views
3K
SolarLune
SolarLune
Back
Top