From owner-freebsd-arm@FreeBSD.ORG Sun Mar 16 06:40:23 2008 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43719106566C for ; Sun, 16 Mar 2008 06:40:23 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 1586E8FC19 for ; Sun, 16 Mar 2008 06:40:23 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m2G6cJ2r032801; Sun, 16 Mar 2008 00:38:20 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 16 Mar 2008 00:38:54 -0600 (MDT) Message-Id: <20080316.003854.1973602812.imp@bsdimp.com> To: gavin.atkinson@ury.york.ac.uk From: "M. Warner Losh" In-Reply-To: <20080309215651.W3822@ury.york.ac.uk> References: <20080309190951.A3822@ury.york.ac.uk> <20080309.154340.-476177382.imp@bsdimp.com> <20080309215651.W3822@ury.york.ac.uk> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org Subject: Re: ARM platform page on website 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: Sun, 16 Mar 2008 06:40:23 -0000 In message: <20080309215651.W3822@ury.york.ac.uk> Gavin Atkinson writes: : On Sun, 9 Mar 2008, M. Warner Losh wrote: : > In message: <20080309190951.A3822@ury.york.ac.uk> : > Gavin Atkinson writes: : > : After trying to bring it up on an NSLU2, I already have plans to update : > : the other ARM documentation... : > : > How far did you get on this? I have a start of a NSLU2 port too, but : > didn't get too far before life got in the way. : : I last looked at it probably nearly a year ago, before other things took : over. I had it booting up, but failing to recognise the IXP network : interface. I spent quite a bit of time working on this and was able to : get to the point where the MAC address and PHY were correctly recognised, : but it still wouldn't pass packetd. : : The kernel would also panic when it tried to initialise USB. My NSLU2 was : cheap on ebay because the USB ports apparently didn't work on it so I : never spent any time investigating this, especially given the OS that : usually ships on it was constantly complaining about USB port issues too. : : I think I had a driver written for the RTC too, which I can probably dig : out if you want it. I spent a bit of time on it tonight, based on your description. There's one hack to the if_npe.c driver that's needed. Once you have that, then it is relatively simple to get at least a NFS root based copy of AVILA booting. I've not tried usb yet, nor worked on the rtc, iic, gpio, etc. I'll be cleaning this up in the next few days, but just wanted to say thank you for making it sound so easy. Warner From owner-freebsd-arm@FreeBSD.ORG Sun Mar 16 21:44:03 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 E69C3106566C for ; Sun, 16 Mar 2008 21:44:03 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 835558FC1A for ; Sun, 16 Mar 2008 21:44:03 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m2GLfd49048309; Sun, 16 Mar 2008 15:41:40 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 16 Mar 2008 15:42:15 -0600 (MDT) Message-Id: <20080316.154215.1387160441.imp@bsdimp.com> To: bkoenig@alpha-tierchen.de From: "M. Warner Losh" In-Reply-To: <50161.192.168.1.2.1205540152.squirrel@webmail.alpha-tierchen.de> References: <50161.192.168.1.2.1205540152.squirrel@webmail.alpha-tierchen.de> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: arm@freebsd.org 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: Sun, 16 Mar 2008 21:44:04 -0000 In message: <50161.192.168.1.2.1205540152.squirrel@webmail.alpha-tierch= en.de> Bj=F6rn_K=F6nig writes: : I would like to have a preprocessor definition called AT91C_MAIN_CLOC= K : that allows you to specify the main clock frequency of a board in the= : kernel configuration file. It avoids an intricate distinction of case= s in : at91_pmc.c:395ff and you can use the unpatched source code with board= s : that have a different quartz frequency than 10 or 16 MHz. : = : I attached a patch that deals with this issue. Users of TSC boards ne= ed to : add 'options AT91C_MAIN_CLOCK=3D16000000' to their kernel configurati= on : file. I'd go one step further. I'd require everybody to define this value since there's no 'standard' frequency and the value that's there is just the value of the boards we used for the port. It would be even better if it wasn't a #define, but a variable. There's registers that can be read to get the approximate frequency (the chip only supports one of list of something like 16 different frequencies). We should consider it and have an override for those engineers that use a non-standard frequency. Warner From owner-freebsd-arm@FreeBSD.ORG Sun Mar 16 22:35:55 2008 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26052106567B for ; Sun, 16 Mar 2008 22:35:55 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from mail-gw0.york.ac.uk (mail-gw0.york.ac.uk [144.32.128.245]) by mx1.freebsd.org (Postfix) with ESMTP id A41CE8FC19 for ; Sun, 16 Mar 2008 22:35:54 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from mail-gw7.york.ac.uk (mail-gw7.york.ac.uk [144.32.129.30]) by mail-gw0.york.ac.uk (8.13.6/8.13.6) with ESMTP id m2GMZkoN004717; Sun, 16 Mar 2008 22:35:46 GMT Received: from ury.york.ac.uk ([144.32.108.81]) by mail-gw7.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1Jb1SE-0006Ay-9h; Sun, 16 Mar 2008 22:35:46 +0000 Received: from ury.york.ac.uk (localhost.york.ac.uk [127.0.0.1]) by ury.york.ac.uk (8.14.1/8.14.1) with ESMTP id m2GMZkPV052158; Sun, 16 Mar 2008 22:35:46 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from localhost (gavin@localhost) by ury.york.ac.uk (8.14.1/8.14.1/Submit) with ESMTP id m2GMZj7O052155; Sun, 16 Mar 2008 22:35:45 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) X-Authentication-Warning: ury.york.ac.uk: gavin owned process doing -bs Date: Sun, 16 Mar 2008 22:35:45 +0000 (GMT) From: Gavin Atkinson X-X-Sender: gavin@ury.york.ac.uk To: "M. Warner Losh" In-Reply-To: <20080316.003854.1973602812.imp@bsdimp.com> Message-ID: <20080316220847.V19332@ury.york.ac.uk> References: <20080309190951.A3822@ury.york.ac.uk> <20080309.154340.-476177382.imp@bsdimp.com> <20080309215651.W3822@ury.york.ac.uk> <20080316.003854.1973602812.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin.atkinson@ury.york.ac.uk Cc: freebsd-arm@FreeBSD.org Subject: Re: ARM platform page on website 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: Sun, 16 Mar 2008 22:35:55 -0000 On Sun, 16 Mar 2008, M. Warner Losh wrote: > I spent a bit of time on it tonight, based on your description. > There's one hack to the if_npe.c driver that's needed. Once you have > that, then it is relatively simple to get at least a NFS root based > copy of AVILA booting. I've not tried usb yet, nor worked on the rtc, > iic, gpio, etc. Excellent. Does the hack you needed involve copying the MAC address from one place to another? I'm pretty sure I had to do that, and also had to hack the method used to find the correct microcide image. I think the latter change is no longer necessary since if_npe.c 1.6. > I'll be cleaning this up in the next few days, but just wanted to say > thank you for making it sound so easy. No worries, I probably should have said how easy it was to get it at least partially booting. I seem to remember the AVILA kernel config is pretty much usable on the NSLU2 without modification. I'll try to get that RTC code to you some point this week or next, it's on a system that I don't have access to right now. Gavin. From owner-freebsd-arm@FreeBSD.ORG Sun Mar 16 22:52:36 2008 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4956106564A for ; Sun, 16 Mar 2008 22:52:36 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 59D4C8FC12 for ; Sun, 16 Mar 2008 22:52:36 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m2GMmfTI049012; Sun, 16 Mar 2008 16:48:41 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 16 Mar 2008 16:49:18 -0600 (MDT) Message-Id: <20080316.164918.-135507428.imp@bsdimp.com> To: gavin.atkinson@ury.york.ac.uk From: "M. Warner Losh" In-Reply-To: <20080316220847.V19332@ury.york.ac.uk> References: <20080309215651.W3822@ury.york.ac.uk> <20080316.003854.1973602812.imp@bsdimp.com> <20080316220847.V19332@ury.york.ac.uk> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org Subject: Re: ARM platform page on website 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: Sun, 16 Mar 2008 22:52:36 -0000 In message: <20080316220847.V19332@ury.york.ac.uk> Gavin Atkinson writes: : On Sun, 16 Mar 2008, M. Warner Losh wrote: : > I spent a bit of time on it tonight, based on your description. : > There's one hack to the if_npe.c driver that's needed. Once you have : > that, then it is relatively simple to get at least a NFS root based : > copy of AVILA booting. I've not tried usb yet, nor worked on the rtc, : > iic, gpio, etc. : : Excellent. Does the hack you needed involve copying the MAC address from : one place to another? I'm pretty sure I had to do that, and also had to : hack the method used to find the correct microcide image. I think the : latter change is no longer necessary since if_npe.c 1.6. I think you must be right, since it just works for me. I had to use PHY address 1. I need to add support for that. : > I'll be cleaning this up in the next few days, but just wanted to say : > thank you for making it sound so easy. : : No worries, I probably should have said how easy it was to get it at least : partially booting. I seem to remember the AVILA kernel config is pretty : much usable on the NSLU2 without modification. Yes. They are nearly all in common. In fact, I've been trying to modify the config files to make them more common. : I'll try to get that RTC code to you some point this week or next, it's on : a system that I don't have access to right now. That would be cool! I'll look into the usb issues too. Warner From owner-freebsd-arm@FreeBSD.ORG Mon Mar 17 02:10:15 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 E2B281065671 for ; Mon, 17 Mar 2008 02:10:15 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 91C388FC34 for ; Mon, 17 Mar 2008 02:10:15 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id m2H1fpK0062470; Mon, 17 Mar 2008 02:41:51 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.13.4/8.13.4) with ESMTP id m2H1fjTK014585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Mar 2008 02:41:45 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.13.4/8.13.3) with ESMTP id m2H1fimT072110; Mon, 17 Mar 2008 02:41:44 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id m2H1fiSo072109; Mon, 17 Mar 2008 02:41:44 +0100 (CET) (envelope-from ticso) Date: Mon, 17 Mar 2008 02:41:43 +0100 From: Bernd Walter To: "M. Warner Losh" Message-ID: <20080317014143.GQ67602@cicely12.cicely.de> References: <50161.192.168.1.2.1205540152.squirrel@webmail.alpha-tierchen.de> <20080316.154215.1387160441.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20080316.154215.1387160441.imp@bsdimp.com> X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on cicely12.cicely.de Cc: arm@freebsd.org, bkoenig@alpha-tierchen.de Subject: Re: defining the main clock frequency of AT91 boards X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de 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 02:10:16 -0000 On Sun, Mar 16, 2008 at 03:42:15PM -0600, M. Warner Losh wrote: > In message: <50161.192.168.1.2.1205540152.squirrel@webmail.alpha-tierchen.de> > Björn_König writes: > : I would like to have a preprocessor definition called AT91C_MAIN_CLOCK > : that allows you to specify the main clock frequency of a board in the > : kernel configuration file. It avoids an intricate distinction of cases in > : at91_pmc.c:395ff and you can use the unpatched source code with boards > : that have a different quartz frequency than 10 or 16 MHz. > : > : I attached a patch that deals with this issue. Users of TSC boards need to > : add 'options AT91C_MAIN_CLOCK=16000000' to their kernel configuration > : file. And users of BWCT boards ;-) > I'd go one step further. I'd require everybody to define this value > since there's no 'standard' frequency and the value that's there is > just the value of the boards we used for the port. Me too - that way noone can forget defining it and run with the wrong frequency. > It would be even better if it wasn't a #define, but a variable. > There's registers that can be read to get the approximate frequency > (the chip only supports one of list of something like 16 different > frequencies). We should consider it and have an override for those > engineers that use a non-standard frequency. You only need a xtal out of this selection in case you want the ROM code to setup the clocks for console and/or USB right. But it is not required to have them right unless you want to load software using the ROM code with one of those two interfaces. You can still load your software by different kind of external memories and then setup the clocks with your own code. For me it is important to init the external memory, but this of corse can be done using other mechanisms as well. But since we are already about RM9200 clocks. Is it possible today to setup different clocks? I remember that MCK was hardcoded some time ago, but now I saw that it can be setup in the kernel conf. E.g. the MCK can be 80MHz and the only reason it is 60MHz right now is because PCK is 180MHz and MCK has to be divided from that. I always wondered myself if it is faster to run the CPU at 160MHz and have 80MHz MCK. Absolutely everything beside CPU increses in speed with MCK, including external SDRAM, which in almost every case is 133MHz specified anyway. Not to speak about overclocking PCK. So far MCK is defined for up to 80MHz and PCK is defined to be up to 209MHz. The only reason to not run that high is that the PLLA is limited. But in fact the PLL runs fine with at least up to 288MHz. I know that because on my first tests I had the PLL setup for 10MHz xtal, but in fact used a 16MHz - and the CPU did start just fine. Maybe Atmel had to limit the PLL to support the full temperature range or something like that. I have some 32x16 SDRAM chips her to build boards with 128MB RAM and it really would be nice to have them run faster. -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de From owner-freebsd-arm@FreeBSD.ORG Mon Mar 17 17:48:08 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 72E071065671 for ; Mon, 17 Mar 2008 17:48:08 +0000 (UTC) (envelope-from bkoenig@alpha-tierchen.de) Received: from mx02.qsc.de (mx02.qsc.de [213.148.130.14]) by mx1.freebsd.org (Postfix) with ESMTP id 0C57F8FC15 for ; Mon, 17 Mar 2008 17:48:07 +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 mx02.qsc.de (Postfix) with ESMTP id 9327316C000E; Mon, 17 Mar 2008 18:48:06 +0100 (CET) Received: from 192.168.1.2 (SquirrelMail authenticated user bkoenig) by webmail.alpha-tierchen.de with HTTP; Mon, 17 Mar 2008 18:48:05 +0100 (CET) Message-ID: <51329.192.168.1.2.1205776085.squirrel@webmail.alpha-tierchen.de> In-Reply-To: <20080317014143.GQ67602@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> Date: Mon, 17 Mar 2008 18:48:05 +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 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 17:48:08 -0000 > On Sun, Mar 16, 2008 at 03:42:15PM -0600, M. Warner Losh wrote: >> In message: >> <50161.192.168.1.2.1205540152.squirrel@webmail.alpha-tierchen.de> >> Björn_König writes: >> : I attached a patch that deals with this issue. Users of TSC >> : boards need to add 'options AT91C_MAIN_CLOCK=16000000' to their >> : kernel configuration file. > > And users of BWCT boards ;-) The patch added the option to the BWCT kernel configuration. I just mentioned TSC because there is no default configuration in sys/arm/conf/. >> I'd go one step further. I'd require everybody to define this value >> since there's no 'standard' frequency and the value that's there is >> just the value of the boards we used for the port. > > Me too - that way noone can forget defining it and run with the wrong > frequency. I agree. It sounds reasonable to make such an option mandatory. I tried to be conservative. 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. ;-) > But since we are already about RM9200 clocks. > Is it possible today to setup different clocks? > I remember that MCK was hardcoded some time ago, but now I saw that > it can be setup in the kernel conf. It's just overriding the #define in at91rm9200.h. > E.g. the MCK can be 80MHz and the only reason it is 60MHz right now is > because PCK is 180MHz and MCK has to be divided from that. > I always wondered myself if it is faster to run the CPU at 160MHz and > have 80MHz MCK. I think it depends on what you are doing with the board, but in general I would say that the CPU is the bottle neck. I used my board with an 80 MHz master clock and didn't notice better performance (Yes, I reconfigured the memory timings accordingly). Björn From owner-freebsd-arm@FreeBSD.ORG Mon Mar 17 18:03:33 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 992B0106564A for ; Mon, 17 Mar 2008 18:03:33 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 493A78FC13 for ; Mon, 17 Mar 2008 18:03:33 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id m2HI3ULS035388; Mon, 17 Mar 2008 19:03:30 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.13.4/8.13.4) with ESMTP id m2HI3HU1022767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Mar 2008 19:03:17 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.13.4/8.13.3) with ESMTP id m2HI3HsO074618; Mon, 17 Mar 2008 19:03:17 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id m2HI3HFS074617; Mon, 17 Mar 2008 19:03:17 +0100 (CET) (envelope-from ticso) Date: Mon, 17 Mar 2008 19:03:16 +0100 From: Bernd Walter To: =?iso-8859-1?Q?Bj=F6rn_K=F6nig?= Message-ID: <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> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <51329.192.168.1.2.1205776085.squirrel@webmail.alpha-tierchen.de> X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on cicely12.cicely.de Cc: arm@freebsd.org, ticso@cicely.de Subject: Re: defining the main clock frequency of AT91 boards X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de 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 18:03:33 -0000 On Mon, Mar 17, 2008 at 06:48:05PM +0100, Björn König wrote: > > On Sun, Mar 16, 2008 at 03:42:15PM -0600, M. Warner Losh wrote: > >> In message: > >> <50161.192.168.1.2.1205540152.squirrel@webmail.alpha-tierchen.de> > >> Björn_König writes: > The patch added the option to the BWCT kernel configuration. I just > mentioned TSC because there is no default configuration in sys/arm/conf/. > > >> I'd go one step further. I'd require everybody to define this value > >> since there's no 'standard' frequency and the value that's there is > >> just the value of the boards we used for the port. > > > > Me too - that way noone can forget defining it and run with the wrong > > frequency. > > I agree. It sounds reasonable to make such an option mandatory. I tried to > be conservative. I'm more worried about users (inkluding myself ;-) taking a old config without adding the new option, than about beeing conservative. But since we all agree about it :) > 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. > > But since we are already about RM9200 clocks. > > Is it possible today to setup different clocks? > > I remember that MCK was hardcoded some time ago, but now I saw that > > it can be setup in the kernel conf. > > It's just overriding the #define in at91rm9200.h. I just remember it was hardcoded in somewhere some time ago. > > E.g. the MCK can be 80MHz and the only reason it is 60MHz right now is > > because PCK is 180MHz and MCK has to be divided from that. > > I always wondered myself if it is faster to run the CPU at 160MHz and > > have 80MHz MCK. > > I think it depends on what you are doing with the board, but in general I > would say that the CPU is the bottle neck. I used my board with an 80 MHz > master clock and didn't notice better performance (Yes, I reconfigured the > memory timings accordingly). 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? 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. -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de 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 From owner-freebsd-arm@FreeBSD.ORG Mon Mar 17 20:18:50 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 CE326106564A for ; Mon, 17 Mar 2008 20:18:50 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 7E8B28FC1D for ; Mon, 17 Mar 2008 20:18:50 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id m2HKIl0L043630; Mon, 17 Mar 2008 21:18:48 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.13.4/8.13.4) with ESMTP id m2HKIZU6023966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Mar 2008 21:18:35 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.13.4/8.13.3) with ESMTP id m2HKIY82074922; Mon, 17 Mar 2008 21:18:34 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id m2HKIYDh074921; Mon, 17 Mar 2008 21:18:34 +0100 (CET) (envelope-from ticso) Date: Mon, 17 Mar 2008 21:18:34 +0100 From: Bernd Walter To: =?iso-8859-1?Q?Bj=F6rn_K=F6nig?= Message-ID: <20080317201833.GC72551@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> <56448.192.168.1.2.1205780988.squirrel@webmail.alpha-tierchen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <56448.192.168.1.2.1205780988.squirrel@webmail.alpha-tierchen.de> X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on cicely12.cicely.de Cc: arm@freebsd.org, ticso@cicely.de Subject: Re: defining the main clock frequency of AT91 boards X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de 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 20:18:50 -0000 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 From owner-freebsd-arm@FreeBSD.ORG Mon Mar 17 20:41:37 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 B4486106566B for ; Mon, 17 Mar 2008 20:41:37 +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 74FDD8FC25 for ; Mon, 17 Mar 2008 20:41:37 +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 764D2E3553; Mon, 17 Mar 2008 21:41:34 +0100 (CET) Received: from 192.168.1.2 (SquirrelMail authenticated user bkoenig) by webmail.alpha-tierchen.de with HTTP; Mon, 17 Mar 2008 21:41:33 +0100 (CET) Message-ID: <60965.192.168.1.2.1205786493.squirrel@webmail.alpha-tierchen.de> In-Reply-To: <20080317201833.GC72551@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> <56448.192.168.1.2.1205780988.squirrel@webmail.alpha-tierchen.de> <20080317201833.GC72551@cicely12.cicely.de> Date: Mon, 17 Mar 2008 21:41:33 +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 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 20:41:37 -0000 Bernd Walter wrote: > 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. Oh, you've got me there. I forgot that. - My patches do in-kernel reconfiguration of the PLLA. Björn From owner-freebsd-arm@FreeBSD.ORG Mon Mar 17 21:42:27 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 79D98106566C; Mon, 17 Mar 2008 21:42:27 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id DCAC88FC1B; Mon, 17 Mar 2008 21:42:26 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m2HLgQMH058507; Mon, 17 Mar 2008 17:42:26 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m2HLgQIx085248; Mon, 17 Mar 2008 17:42:26 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 9650C73039; Mon, 17 Mar 2008 16:42:25 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080317214225.9650C73039@freebsd-current.sentex.ca> Date: Mon, 17 Mar 2008 16:42:25 -0500 (EST) X-Virus-Scanned: ClamAV 0.92.1/6204/Tue Mar 11 16:43:31 2008 clamav-milter version 0.92.1 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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 21:42:27 -0000 TB --- 2008-03-17 20:50:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2008-03-17 20:50:00 - starting HEAD tinderbox run for arm/arm TB --- 2008-03-17 20:50:00 - cleaning the object tree TB --- 2008-03-17 20:50:27 - cvsupping the source tree TB --- 2008-03-17 20:50:27 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile TB --- 2008-03-17 20:50:34 - building world (CFLAGS=-O -pipe) TB --- 2008-03-17 20:50:34 - cd /src TB --- 2008-03-17 20:50:34 - /usr/bin/make -B buildworld >>> World build started on Mon Mar 17 20:50:36 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /src/usr.bin/fstat/zfs/zfs.c:111: warning: implicit declaration of function 'getvnodemount' /src/usr.bin/fstat/zfs/zfs.c:111: warning: nested extern declaration of 'getvnodemount' /src/usr.bin/fstat/zfs/zfs.c:111: warning: assignment makes pointer from integer without a cast /src/usr.bin/fstat/zfs/zfs.c:118: error: dereferencing pointer to incomplete type /src/usr.bin/fstat/zfs/zfs.c:119: error: dereferencing pointer to incomplete type /src/usr.bin/fstat/zfs/zfs.c:125: error: dereferencing pointer to incomplete type /src/usr.bin/fstat/zfs/zfs.c:126: error: dereferencing pointer to incomplete type /src/usr.bin/fstat/zfs/zfs.c:127: error: dereferencing pointer to incomplete type *** Error code 1 Stop in /src/usr.bin/fstat. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-03-17 21:42:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-03-17 21:42:25 - ERROR: failed to build world TB --- 2008-03-17 21:42:25 - tinderbox aborted TB --- 2418.07 user 300.42 system 3144.77 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Fri Mar 21 21:37:12 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 57A03106566B for ; Fri, 21 Mar 2008 21:37:12 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 111DF8FC19 for ; Fri, 21 Mar 2008 21:37:11 +0000 (UTC) (envelope-from sam@errno.com) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m2LKxRui019110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 21 Mar 2008 13:59:27 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <47E421AE.8020507@errno.com> Date: Fri, 21 Mar 2008 13:59:26 -0700 From: Sam Leffler User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: arm@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-sonic.net-Metrics: ebb.errno.com; whitelist Cc: Subject: gateworks/avila board support 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: Fri, 21 Mar 2008 21:37:12 -0000 I'm working to fill in the missing bits for gateworks/avila boards. I just fixed usb and am working on the 4-port switch, ixp425 crypto support, and anything else I hit. I'm aware of one issue where stuffing all 4 mini-pci slots in a 2348-4 board results in unreliable interrupts. If you are aware of any other problems please let me know or better yet file a PR and assign it to me. Can't promise I can fix 'em this time 'round but will try. Sam From owner-freebsd-arm@FreeBSD.ORG Fri Mar 21 22:45:29 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 C059A1065670 for ; Fri, 21 Mar 2008 22:45:28 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 6165D8FC19 for ; Fri, 21 Mar 2008 22:45:27 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id m2LMhw8E049875; Fri, 21 Mar 2008 23:43:58 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.13.4/8.13.4) with ESMTP id m2LMhpBQ074797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Mar 2008 23:43:52 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.13.4/8.13.3) with ESMTP id m2LMhpBd089554; Fri, 21 Mar 2008 23:43:51 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id m2LMhoad089553; Fri, 21 Mar 2008 23:43:50 +0100 (CET) (envelope-from ticso) Date: Fri, 21 Mar 2008 23:43:50 +0100 From: Bernd Walter To: Sam Leffler Message-ID: <20080321224350.GJ75168@cicely12.cicely.de> References: <47E421AE.8020507@errno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47E421AE.8020507@errno.com> X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on cicely12.cicely.de Cc: arm@freebsd.org Subject: Re: gateworks/avila board support X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2008 22:45:30 -0000 On Fri, Mar 21, 2008 at 01:59:26PM -0700, Sam Leffler wrote: > I'm working to fill in the missing bits for gateworks/avila boards. I > just fixed usb and am working on the 4-port switch, ixp425 crypto > support, and anything else I hit. I'm aware of one issue where stuffing > all 4 mini-pci slots in a 2348-4 board results in unreliable interrupts. > > If you are aware of any other problems please let me know or better yet > file a PR and assign it to me. Can't promise I can fix 'em this time > 'round but will try. How do you want to handle the switch? For the RTL8305SC I have done the rlswitch driver, which currently initializes the switch with fixed compiled values, but I'm not very happy with this. I think it would be better to have a /dev/mii to allow configuring the switch from userland. -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de From owner-freebsd-arm@FreeBSD.ORG Fri Mar 21 23:54:47 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 90942106566B for ; Fri, 21 Mar 2008 23:54:47 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 5B23C8FC2D for ; Fri, 21 Mar 2008 23:54:47 +0000 (UTC) (envelope-from sam@errno.com) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m2LNsZe8020115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Mar 2008 16:54:37 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <47E44ABB.4020004@errno.com> Date: Fri, 21 Mar 2008 16:54:35 -0700 From: Sam Leffler User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: ticso@cicely.de References: <47E421AE.8020507@errno.com> <20080321224350.GJ75168@cicely12.cicely.de> In-Reply-To: <20080321224350.GJ75168@cicely12.cicely.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-sonic.net-Metrics: ebb.errno.com; whitelist Cc: arm@freebsd.org Subject: Re: gateworks/avila board support 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: Fri, 21 Mar 2008 23:54:47 -0000 Bernd Walter wrote: > On Fri, Mar 21, 2008 at 01:59:26PM -0700, Sam Leffler wrote: > >> I'm working to fill in the missing bits for gateworks/avila boards. I >> just fixed usb and am working on the 4-port switch, ixp425 crypto >> support, and anything else I hit. I'm aware of one issue where stuffing >> all 4 mini-pci slots in a 2348-4 board results in unreliable interrupts. >> >> If you are aware of any other problems please let me know or better yet >> file a PR and assign it to me. Can't promise I can fix 'em this time >> 'round but will try. >> > > How do you want to handle the switch? > For the RTL8305SC I have done the rlswitch driver, which currently > initializes the switch with fixed compiled values, but I'm not > very happy with this. > I think it would be better to have a /dev/mii to allow configuring > the switch from userland. > For the Marvell 88E6060 switch the mii code I did has "router" and "bridge" configs that are selected with a hint. Sam