From owner-freebsd-arm@FreeBSD.ORG Mon Mar 17 19:09:52 2008 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF3211065679 for ; Mon, 17 Mar 2008 19:09:52 +0000 (UTC) (envelope-from bkoenig@alpha-tierchen.de) Received: from mx01.qsc.de (mx01.qsc.de [213.148.129.14]) by mx1.freebsd.org (Postfix) with ESMTP id 44E468FC2F for ; Mon, 17 Mar 2008 19:09:52 +0000 (UTC) (envelope-from bkoenig@alpha-tierchen.de) Received: from webmail.alpha-tierchen.de (port-212-202-42-206.dynamic.qsc.de [212.202.42.206]) by mx01.qsc.de (Postfix) with ESMTP id C63CEC7C6D; Mon, 17 Mar 2008 20:09:49 +0100 (CET) Received: from 192.168.1.2 (SquirrelMail authenticated user bkoenig) by webmail.alpha-tierchen.de with HTTP; Mon, 17 Mar 2008 20:09:48 +0100 (CET) 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> Date: Mon, 17 Mar 2008 20:09:48 +0100 (CET) From: =?iso-8859-1?Q?Bj=F6rn_K=F6nig?= To: ticso@cicely.de User-Agent: SquirrelMail/1.4.13 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: arm@freebsd.org, =?iso-8859-1?Q?Bj=F6rn_K=F6nig?= Subject: Re: defining the main clock frequency of AT91 boards X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2008 19:09:52 -0000 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