STK1000 default running clock

Go To Last Post
14 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi there,

I was just about to ask if changing the stk1000 cristal was the way to reach the 150Mhz cited in the datasheet and atmel site, but I figured on other posts that there is some multiplier applied.

So, can anyone point me out what is the default CPU frequency on the STK1000? I have run mplayer on it and found it to be a bit slower than I expected. Also, Qtopia interview demo takes a lot of time to load.

Cheers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MCK is on PLL0 (which in turn is driven by OSC0) running at 140MHz by default.

If you're using a relatively new kernel you can get access to cpufreq data through sysfs. Off the top of my head the path is somthing like /sys/devices/system/cpu/cpu0/cpufreq or something. You can find the current cpufreq governer and the current frequency as well as changing either of these. Though not above 140MHz atm, for that you'll need to play around deeper in the (u-boot or linux? I think linux..) code.

-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What kind of media file are you playing, format on both sound and video?

Remember to execute mplayer with "-ac mad" if you have compressed audio.

Are you loading your applications of sd-card, flash or network? I find flash and network to be a lot faster than sd-card. SD-card is nice for storing the media files.

Hans-Christian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Actually I was playing the Transformers official trailler on it :P
mplayer said it was MPEG4 and the audio is mp3 but I had it disabled with -nosound. It has some small stops while playing, could be as you said due to the sd-card. I downloaded the file with wget then played it off the sd-card.

What concerns me a bit more is the awfull lot of time it takes to start the video and when running the Qtopia demo it takes really a lot to finish drawing the interface for the first time. I had assumed that the kit was severely underclocked looking at the small value cristal in it.

On the qtopia thing, I'm not sure if the q_atomic_* are to blame since the arm one is just like the default with software locks. I am guessing that it could be that there are too many fonts to load but even so, shouldn't take that long. In anycase, I was looking at the datasheets but couldn't find an xchg replacement, it doesn't really contain the "atomic" keyword anywhere as it seams, any advice?

I will check out the sysfs and see at what clock speed I'm running at, thanks for the tips :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The problem about the AVR32-"port" for Qtopia, is that it is a quick and pretty dirty hack just to see if it works :) And like many quick and dirty hacks, they seem to hang around until somebody does it properly :)

Hans-Christian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That's what I was looking for, doing it properly. As I have quite some experience with Qt internals (I ported quite a lot of it back when there was no GPL). But as far as I can tell, the only bits that can be improved are the atomic operations and writting an accelerated screen driver. The later could be easy if DirectFB is optimized as the Trolls are working on a screen driver that uses it at the labs.trolltech.com and the atomic operations as I said before, don't seam that critical and I don't really know which asm instructions are atomic and which are not as the doc doesn't say :(

Sadly I might end up with Nano-X, as Qtopia core OEM commercial license prices are next to extorsion. :(

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I know how has had some ideas about how to attack the atomic operations, perhaps he will read this thread and give some feedback :)

Hans-Christian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Correa wrote:
I was just about to ask if changing the stk1000 cristal was the way to reach the 150Mhz cited in the datasheet and atmel site, but I figured on other posts that there is some multiplier applied.

The default frequency for the STK1000 with no particular firmware running on it (no Linux) is 20 MHz. It will run at that speed unless your firmware changes it.

The maximum recommended frequency is 200 MHz. You get to different frequencies by programming the PLL with suitable factors. I've had my STK1000 running at about 20 different frequencies between 20 and 200 MHz.

I've heard comments that you can even exceed 200 MHz but there may be some risk of damage to the CPU due to overheating.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

squidgit, how recent should it be to have this interface? I have 2.6.18.8, but I only have up to /sys/devices/system/cpu/cpu0/ with no usefull info in there.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You need 2.6.22 or hight IIRC.

Hans-Christian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yup, though the applicable patches (at least the version of the patches I've got) actually apply cleanly to 2.6.18 if you're nailed to that release.

-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was unable to mount the root filesystem on the sdcard with anything higher than .18 There was a bug with it was conflicting patches, can't remember right now. So, is that in the past or are you guys mounting the rootfs on nfs?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've written up some information about atomic operations on AVR32 at http://avr32linux.org/twiki/bin/...

Note that the current implementation in Qtopia is probably not any worse than ARM. It's just that AVR32 can do much better :)

To answer your question, I believe the only instruction on AVR32 that is really atomic by itself is xchg, but it has very limited usability, basically just binary spinlocks. To implement proper atomics like atomic add, atomic set/clear bits, etc. you need to use the stcond instruction.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Correa wrote:
I was unable to mount the root filesystem on the sdcard with anything higher than .18 There was a bug with it was conflicting patches, can't remember right now. So, is that in the past or are you guys mounting the rootfs on nfs?
You shouldn't need to apply any patches to make it work.. Booting from SD off new kernels is fine AFAIK, there were issues with .20 but all else should be fine. If you've got access to git, use that to clone the avr32 git tree and you'll get something good.

-S.