Date: Mon, 17 Mar 2008 20:09:48 +0100 (CET) From: =?iso-8859-1?Q?Bj=F6rn_K=F6nig?= <bkoenig@alpha-tierchen.de> To: ticso@cicely.de Cc: arm@freebsd.org, =?iso-8859-1?Q?Bj=F6rn_K=F6nig?= <bkoenig@alpha-tierchen.de> Subject: Re: defining the main clock frequency of AT91 boards Message-ID: <56448.192.168.1.2.1205780988.squirrel@webmail.alpha-tierchen.de> In-Reply-To: <20080317180315.GA72551@cicely12.cicely.de> References: <50161.192.168.1.2.1205540152.squirrel@webmail.alpha-tierchen.de> <20080316.154215.1387160441.imp@bsdimp.com> <20080317014143.GQ67602@cicely12.cicely.de> <51329.192.168.1.2.1205776085.squirrel@webmail.alpha-tierchen.de> <20080317180315.GA72551@cicely12.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > 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. Björn
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?56448.192.168.1.2.1205780988.squirrel>