defining the main clock frequency of AT91 boards

[Bernd Walter]

On Mon, Mar 17, 2008 at 08:09:48PM +0100, Björn König wrote:
> Bernd Walter wrote:
> > On Mon, Mar 17, 2008 at 06:48:05PM +0100, Björn König wrote:
> >> I think users will notice very quickly if they run their board with the
> >> wrong frequency, because they won't get output on the serial console -
> >> maybe already too late. ;-)
> >
> > Console speed is about MCK.
> > Inside the kernel the xtal Clock is only used to setup PLLB for USB,
> > so it is just USB, which is not working.
> 
> The PLLA clock is generated from the main clock. PLLA is the source for
> PCK and MCK. Therefore a different quartz have influence over the console
> speed.

AFAIK PLLA is not setup in the kernel - it is done by the board firmware.
So defining xtal frequency in the kernel has no influence on that.

> > I was thinking about network performance.
> > Core can only be faster with higher PCK if running from cache, otherwise
> > it is slowed down by MCK based things.
> > I was hoping to get more speed for routing, but maybe the network code
> > is working too much inside caches.
> >
> > What kind of application did you try with the higher MCK?
> 
> Everything but network I/O. :-P - I'll check this later again.
> 
> > What kind of RAM settings are you talking about?
> > Almost all SDRAM on such boards is 133MHz (worst case I would expect
> > 100MHz), so no need to slow memory settings down for just 80MHz.
> > And I don't see any reason to even add further waitstates, since 133MHz
> > SDRAM should be good for at least 100MHz without additional waitsates.
> > The only parameter you can tune is refresh, since the refresh frequency
> > doesn't need to increase as well, but I doubt that this would make more
> > than an academic difference in speed.
> 
> I'm talking about all parameters that you can tune in the SDRAMC
> configuration register, i.e. RAS, RCD, RP and so on. A higher MCK means an
> decreasing clock cycle length, so I should increase the delay parameters.
> I make an example: the active to precharge delay (RAS) requires to be at
> least 44 ns for my memory module. The cycle length of a 60 MHz MCK tick is
> 16.66 ns. That means the delay has to be at least 3 clock cycles. With a
> 80 MHz MCK I have to increase it to 4 clock cycles to use the memory
> modules within the specifications. With a theoretical MCK of 133 MHz it
> has to be at least 6 cycles.

Damn - I nearly forgot about the precharge time - thanks for reminding
me to this.
My RAM is 44ns as well.

-- 
B.Walter                http://www.bwct.de      http://www.fizon.de
bernd at bwct.de           info at bwct.de            support at fizon.de