Date: Mon, 17 Mar 2008 21:18:34 +0100 From: Bernd Walter <ticso@cicely12.cicely.de> To: =?iso-8859-1?Q?Bj=F6rn_K=F6nig?= <bkoenig@alpha-tierchen.de> Cc: arm@freebsd.org, ticso@cicely.de Subject: Re: defining the main clock frequency of AT91 boards Message-ID: <20080317201833.GC72551@cicely12.cicely.de> In-Reply-To: <56448.192.168.1.2.1205780988.squirrel@webmail.alpha-tierchen.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> <56448.192.168.1.2.1205780988.squirrel@webmail.alpha-tierchen.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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@bwct.de info@bwct.de support@fizon.de
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080317201833.GC72551>