From owner-freebsd-arm@FreeBSD.ORG Tue Mar 20 17:09:20 2007 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4897416A40B for ; Tue, 20 Mar 2007 17:09:20 +0000 (UTC) (envelope-from tcheek@pixelfish.com) Received: from mail01.vmatrixmail.com (mail01.vmatrixmail.com [216.219.244.230]) by mx1.freebsd.org (Postfix) with ESMTP id 058B513C4AE for ; Tue, 20 Mar 2007 17:09:20 +0000 (UTC) (envelope-from tcheek@pixelfish.com) Received: (vmatrix@mail01.vmatrixmail.com) by vmatrixmail.com id S6075694AbXCTQpF for ; Tue, 20 Mar 2007 08:45:05 -0800 To: freebsd-arm@freebsd.org MIME-Version: 1.0 X-Mailer: Rich Media Mail V4. Vmatrix, (C) 2003 From: "Tammie Cheek" Sender: "Tammie Cheek" Message-Id: Date: Tue, 20 Mar 2007 08:45:05 -0800 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Online Video Leads The Trends In Marketing X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tcheek@pixelfish.com List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2007 17:09:20 -0000 Greetings!

Are you happy with your results from Social Linux Expo 2007? Did you have what it takes to make the difference between creating excitement and blending in with the competition, between lots of hot leads and a few hard sells ... between success and failure?

Did you have video?

Why video? Video vividly demonstrates the features and benefits of your products. Video captures the praises of your most enthusiastic customers. Video instills interest, reaction and trust. Video sells.

In just 45 days, PixelFish creates marketing videos that become an integral part of your marketing and sales efforts when it streams from your Web site, launches from multimedia email newsletters, plays from CD video brochures and loops from a DVD at your tradeshow booth.

We are PixelFish. We deliver “The Evolution of Video”. And we guarantee results. Click on the videos to the right to see samples of our work.

Contact us today for a free evaluation of your video marketing needs.


Tammie Cheek
PixelFish, Inc.
800.503.3020 x7110
tcheek@pixelfish.com
http://www.pixelfish.com
John's Incredible Pizza Co. Video
NHK Laboratories Video
Network Hardware Resale Video
------------------------------------------------ Unsubscribe to safely remove yourself from this email list, please send email to info@pixelfish.com. Powered by Pixelfish http://www.pixelfish.com From owner-freebsd-arm@FreeBSD.ORG Wed Mar 21 16:14:48 2007 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DACB816A414 for ; Wed, 21 Mar 2007 16:14:48 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from mx.bulinfo.net (mx.bulinfo.net [193.194.156.1]) by mx1.freebsd.org (Postfix) with ESMTP id 96F7513C45B for ; Wed, 21 Mar 2007 16:14:48 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id 44022368E4 for ; Wed, 21 Mar 2007 18:14:46 +0200 (EET) Received: from mx.bulinfo.net ([127.0.0.1]) by localhost (mx.bulinfo.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18497-03-5 for ; Wed, 21 Mar 2007 18:14:43 +0200 (EET) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id 0C5D036907 for ; Wed, 21 Mar 2007 18:14:26 +0200 (EET) Message-ID: <460159E0.9010301@bulinfo.net> Date: Wed, 21 Mar 2007 18:14:24 +0200 From: Krassimir Slavchev User-Agent: Thunderbird 1.5 (X11/20060201) MIME-Version: 1.0 To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mx.bulinfo.net Subject: SD card speed? 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: Wed, 21 Mar 2007 16:14:49 -0000 Hello, I have made some test: dd if=/dev/zero of=file.dat bs=1m count=10 SD card on arm - 10485760 bytes transferred in 41.431916 secs (253084 bytes/sec) NFS mount from arm - 10485760 bytes transferred in 6.181458 secs (1696325 bytes/sec) SD card on i386 PC - 10485760 bytes transferred in 6.765610 secs (1549862 bytes/sec) The SD card is very slow on arm may be because it uses 1 bit bus. Is there any problems with 4 bit bus support or my card is incorrectly detected? Best Regards From owner-freebsd-arm@FreeBSD.ORG Wed Mar 21 16:31:02 2007 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D4FFA16A46D for ; Wed, 21 Mar 2007 16:31:02 +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 529C413C483 for ; Wed, 21 Mar 2007 16:31:01 +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 l2LGUt9F020426; Wed, 21 Mar 2007 17:30:55 +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 l2LGUlNY027562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Mar 2007 17:30:47 +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 l2LGUk6Z055059; Wed, 21 Mar 2007 17:30:47 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id l2LGUkQe055058; Wed, 21 Mar 2007 17:30:46 +0100 (CET) (envelope-from ticso) Date: Wed, 21 Mar 2007 17:30:46 +0100 From: Bernd Walter To: Krassimir Slavchev Message-ID: <20070321163045.GV48074@cicely12.cicely.de> References: <460159E0.9010301@bulinfo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <460159E0.9010301@bulinfo.net> 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.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on cicely12.cicely.de Cc: freebsd-arm@freebsd.org Subject: Re: SD card speed? 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: Wed, 21 Mar 2007 16:31:02 -0000 On Wed, Mar 21, 2007 at 06:14:24PM +0200, Krassimir Slavchev wrote: > Hello, > > I have made some test: > > dd if=/dev/zero of=file.dat bs=1m count=10 > SD card on arm - 10485760 bytes transferred in 41.431916 secs > (253084 bytes/sec) > NFS mount from arm - 10485760 bytes transferred in 6.181458 secs > (1696325 bytes/sec) > SD card on i386 PC - 10485760 bytes transferred in 6.765610 secs > (1549862 bytes/sec) > > The SD card is very slow on arm may be because it uses 1 bit bus. > > Is there any problems with 4 bit bus support or my card is incorrectly > detected? 4-bit Support is not implemented yet. I have a implementation and tried it once, but got data corruption and hadn't retested, since this is not the main reason for low speed. We don't do multiblock read/write so far, which is the main point. Multiblock read is implemented, but deactivated, since it needs a MCI workaround to be useable. Multiblock write isn't implemented yet. The whole story is on my TODO list, but my unfortunately ARM development time is currently very limited because of other projects. -- 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 Wed Mar 21 17:05:13 2007 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6E23016A402 for ; Wed, 21 Mar 2007 17:05:13 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 21EAE13C46E for ; Wed, 21 Mar 2007 17:05:13 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id l2LH3ZTc091634; Wed, 21 Mar 2007 10:03:35 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 21 Mar 2007 11:03:35 -0600 (MDT) Message-Id: <20070321.110335.41724594.imp@bsdimp.com> To: krassi@bulinfo.net From: Warner Losh In-Reply-To: <460159E0.9010301@bulinfo.net> References: <460159E0.9010301@bulinfo.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Wed, 21 Mar 2007 11:03:35 -0600 (MDT) Cc: freebsd-arm@freebsd.org Subject: Re: SD card speed? 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: Wed, 21 Mar 2007 17:05:13 -0000 From: Krassimir Slavchev Subject: SD card speed? Date: Wed, 21 Mar 2007 18:14:24 +0200 > Hello, > > I have made some test: > > dd if=/dev/zero of=file.dat bs=1m count=10 > SD card on arm - 10485760 bytes transferred in 41.431916 secs > (253084 bytes/sec) > NFS mount from arm - 10485760 bytes transferred in 6.181458 secs > (1696325 bytes/sec) > SD card on i386 PC - 10485760 bytes transferred in 6.765610 secs > (1549862 bytes/sec) > > The SD card is very slow on arm may be because it uses 1 bit bus. > > Is there any problems with 4 bit bus support or my card is incorrectly > detected? 4-bit support would help the speed a little. Multi-block would help more for large, bulk transfers. I didn't enable 4-bit support because I ran out of time when I originally did this work to make sure it worked. There's some minor issues with the code that need to be ironed out that lead to data corruption if you don't do it right (which is why it is effectively disabled). There's a hardware errata for the MCI device. Its bytes are swapped. So we work around this by doing the I/O one block at a time then swapping the bytes before anyone can notice. We do this in a stupid way, which turns off multiblock read/writes. Ooops. there may also be some extra data copies that slow things down. I was getting more like 400k/s from the raw device, which is sufficiently fast for our product. Maybe I'll look again at this, as the boot time was recently flagged as a possible issue. Small increases in the I/O speed of the boot media lead to big improvements in the /etc/rc.d system due to flaws in its design. Warner From owner-freebsd-arm@FreeBSD.ORG Thu Mar 22 00:32:02 2007 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0672516A405 for ; Thu, 22 Mar 2007 00:32:02 +0000 (UTC) (envelope-from dave@dogwood.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.239]) by mx1.freebsd.org (Postfix) with ESMTP id C5B8013C4C1 for ; Thu, 22 Mar 2007 00:32:01 +0000 (UTC) (envelope-from dave@dogwood.com) Received: by nz-out-0506.google.com with SMTP id r28so339559nza for ; Wed, 21 Mar 2007 17:32:01 -0700 (PDT) Received: by 10.35.128.1 with SMTP id f1mr2474310pyn.1174523521322; Wed, 21 Mar 2007 17:32:01 -0700 (PDT) Received: from Gecko.dogwood.com ( [66.91.140.188]) by mx.google.com with ESMTP id f24sm4970090pyh.2007.03.21.17.31.59; Wed, 21 Mar 2007 17:32:00 -0700 (PDT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 21 Mar 2007 14:31:27 -1000 To: freebsd-arm@freebsd.org From: David Cornejo Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4601ce80.5b8c468e.49f9.13fa@mx.google.com> Subject: awk hanging 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: Thu, 22 Mar 2007 00:32:02 -0000 Hi, I am trying to build and install some ports on an Avila board - however with certain packages (i.e. ruby) it gets to the install phase and awk goes into a state where it's constantly running and never comes out (I let it run for four days and then killed it). I have reproduced this in both stable and current. Gdb in current fails to attach to awk, and gdb seems to be completely missing in 6.2. Any suggestions on how to debug this? Would a gdb from ports work? thanks for any help, dave c From owner-freebsd-arm@FreeBSD.ORG Thu Mar 22 00:38:06 2007 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E5DEC16A404 for ; Thu, 22 Mar 2007 00:38:06 +0000 (UTC) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (cognet.ci0.org [80.65.224.102]) by mx1.freebsd.org (Postfix) with ESMTP id 56FE313C468 for ; Thu, 22 Mar 2007 00:38:05 +0000 (UTC) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (localhost.ci0.org [127.0.0.1]) by dong.ci0.org (8.13.8/8.13.8) with ESMTP id l2M0sjvC072910; Thu, 22 Mar 2007 01:54:45 +0100 (CET) (envelope-from mlfbsd@dong.ci0.org) Received: (from mlfbsd@localhost) by dong.ci0.org (8.13.8/8.13.8/Submit) id l2M0sigx072909; Thu, 22 Mar 2007 01:54:44 +0100 (CET) (envelope-from mlfbsd) Date: Thu, 22 Mar 2007 01:54:44 +0100 From: Olivier Houchard To: David Cornejo Message-ID: <20070322005444.GA72878@ci0.org> References: <4601ce80.5b8c468e.49f9.13fa@mx.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4601ce80.5b8c468e.49f9.13fa@mx.google.com> User-Agent: Mutt/1.4.1i Cc: freebsd-arm@freebsd.org Subject: Re: awk hanging 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: Thu, 22 Mar 2007 00:38:07 -0000 On Wed, Mar 21, 2007 at 02:31:27PM -1000, David Cornejo wrote: > Hi, > > I am trying to build and install some ports on an Avila board - > however with certain packages (i.e. ruby) it gets to the install > phase and awk goes into a state where it's constantly running and > never comes out (I let it run for four days and then killed it). I > have reproduced this in both stable and current. Gdb in current > fails to attach to awk, and gdb seems to be completely missing in > 6.2. Any suggestions on how to debug this? Would a gdb from ports work? > > thanks for any help, > dave c Hi David, I'm going to investigate. Can you tell if it just happens randomly, or if it always happens with some ports, but not others ? If it always happens with the same ports, can you name one that is faster to build than ruby ? ;) Thanks a lot for reporting ! Olivier From owner-freebsd-arm@FreeBSD.ORG Thu Mar 22 00:57:55 2007 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7819F16A4C9 for ; Thu, 22 Mar 2007 00:57:55 +0000 (UTC) (envelope-from dave@dogwood.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.235]) by mx1.freebsd.org (Postfix) with ESMTP id 40A9413C4EA for ; Thu, 22 Mar 2007 00:57:54 +0000 (UTC) (envelope-from dave@dogwood.com) Received: by nz-out-0506.google.com with SMTP id r28so344874nza for ; Wed, 21 Mar 2007 17:57:54 -0700 (PDT) Received: by 10.35.111.14 with SMTP id o14mr2455461pym.1174525074007; Wed, 21 Mar 2007 17:57:54 -0700 (PDT) Received: from Gecko.dogwood.com ( [66.91.140.188]) by mx.google.com with ESMTP id x56sm5000950pyg.2007.03.21.17.57.52; Wed, 21 Mar 2007 17:57:53 -0700 (PDT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 21 Mar 2007 14:57:19 -1000 To: Olivier Houchard From: David Cornejo In-Reply-To: <20070322005444.GA72878@ci0.org> References: <4601ce80.5b8c468e.49f9.13fa@mx.google.com> <20070322005444.GA72878@ci0.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4601d491.4aa98b4d.0418.503c@mx.google.com> Cc: freebsd-arm@freebsd.org Subject: Re: awk hanging 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: Thu, 22 Mar 2007 00:57:55 -0000 Unfortunately I didn't note which ones, but I do remember that the ones that failed were big, slow to compile packages. :-( This was under 7.0, I just moved to 6.2 and have just started to recompile my ports, if I catch the other I'll let you know. dave c At 02:54 PM 3/21/2007, Olivier Houchard wrote: >On Wed, Mar 21, 2007 at 02:31:27PM -1000, David Cornejo wrote: > > Hi, > > > > I am trying to build and install some ports on an Avila board - > > however with certain packages (i.e. ruby) it gets to the install > > phase and awk goes into a state where it's constantly running and > > never comes out (I let it run for four days and then killed it). I > > have reproduced this in both stable and current. Gdb in current > > fails to attach to awk, and gdb seems to be completely missing in > > 6.2. Any suggestions on how to debug this? Would a gdb from ports work? > > > > thanks for any help, > > dave c > >Hi David, > >I'm going to investigate. >Can you tell if it just happens randomly, or if it always happens with some >ports, but not others ? >If it always happens with the same ports, can you name one that is faster to >build than ruby ? ;) > >Thanks a lot for reporting ! > >Olivier From owner-freebsd-arm@FreeBSD.ORG Thu Mar 22 08:03:39 2007 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 49E5316A523 for ; Thu, 22 Mar 2007 08:03:39 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.freebsd.org (Postfix) with ESMTP id C733913C4B8 for ; Thu, 22 Mar 2007 08:03:37 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id E6A5833C94; Thu, 22 Mar 2007 10:03:35 +0200 (SAST) Date: Thu, 22 Mar 2007 10:03:35 +0200 From: John Hay To: freebsd-arm@freebsd.org Message-ID: <20070322080335.GA52745@zibbi.meraka.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: progress on the adi pronghorn metro board 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: Thu, 22 Mar 2007 08:03:39 -0000 Hi Guys, With this patch I am at the stage where both an Avila 2348-4 and the ADI Pronghorn Metro boot from the same kernel binary. The "main" stuff is working, ie. console, ethernet and mini-pci slots. The iic bus on the Avila is still working. The one for the Pronghorn is configured, but I must still write a driver for their max6652 temperature/voltage sensor before I will know if it is really working. The biggest difference between the 2 boards are in the 16 GPIO pins. I think there is only 1 pin that have the same function. :-/ So what I did was to create a structure and then have 2 instances of it, one with Avila values in it and one with Pronghorn values. Then early in the boot phase, the board type gets detected and a pointer gets set to the relevant structure. All the drivers then use this pointer to get the correct values. The efect is that most of the drivers needs no checks for the different boards. What I would like to know is, if this approach is acceptable? Should I use different files to put the stuff in? My code is not finished yet, but I thought that I would like to get some feedback. I still have to replace some of the numbers in the structure with defined values. I would also like to try and really probe the iic devices and not just assume that they are there. John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org Index: avila_led.c =================================================================== RCS file: /home/ncvs/src/sys/arm/xscale/ixp425/avila_led.c,v retrieving revision 1.1 diff -u -r1.1 avila_led.c --- avila_led.c 22 Nov 2006 12:57:17 -0000 1.1 +++ avila_led.c 21 Mar 2007 19:04:14 -0000 @@ -66,6 +66,8 @@ static int led_avila_probe(device_t dev) { + if (ixp425_board->ib_board_type != BOARD_AVILA) + return ENXIO; device_set_desc(dev, "Gateworks Avila GPIO connected LED"); return (0); } Index: avila_machdep.c =================================================================== RCS file: /home/ncvs/src/sys/arm/xscale/ixp425/avila_machdep.c,v retrieving revision 1.3 diff -u -r1.3 avila_machdep.c --- avila_machdep.c 2 Feb 2007 05:14:21 -0000 1.3 +++ avila_machdep.c 22 Mar 2007 05:42:19 -0000 @@ -260,6 +260,8 @@ extern vm_offset_t xscale_cache_clean_addr; +static void init_board_type(void); + void * initarm(void *arg, void *arg2) { @@ -482,6 +484,7 @@ * Fetch the SDRAM start/size from the ixp425 SDRAM configration * registers. */ + init_board_type(); cninit(); memsize = ixp425_sdram_size(); physmem = memsize / PAGE_SIZE; @@ -539,3 +542,70 @@ return ((void *)(kernelstack.pv_va + USPACE_SVC_STACK_TOP - sizeof(struct pcb))); } + +static struct ixp425_board board_avila = { + .ib_board_type = BOARD_AVILA, + .ib_pci_int_a = IXP425_INT_GPIO_11, + .ib_pci_int_b = IXP425_INT_GPIO_10, + .ib_pci_int_c = IXP425_INT_GPIO_9, + .ib_pci_int_d = IXP425_INT_GPIO_8, + .ib_pci_clk_en = -1, + .ib_pci_clk = 14 /* GPIO_PCI_CLK */, + .ib_pci_reset = 13 /* GPIO_PCI_RESET */, + .ib_pci_slot_top = 32, + .ib_ata_cs0 = IXP425_EXP_BUS_CS1_HWBASE, + .ib_ata_cs0_size = IXP425_EXP_BUS_CS1_SIZE, + .ib_ata_cs1 = IXP425_EXP_BUS_CS2_HWBASE, + .ib_ata_cs1_size = IXP425_EXP_BUS_CS2_SIZE, + .ib_ata_int_pin = 12, + .ib_ata_int = IXP425_INT_GPIO_12, + .ib_iic_scl = 6 /* GPIO_I2C_SCL */, + .ib_iic_sda = 7 /* GPIO_I2C_SDA */, + .ib_uartcn_vbase = IXP425_UART0_VBASE, + .ib_uartcn_hwbase = IXP425_UART0_HWBASE, + .ib_uartcn_int = IXP425_INT_UART0, + .ib_uartalt_vbase = IXP425_UART1_VBASE, + .ib_uartalt_hwbase = IXP425_UART1_HWBASE, + .ib_uartalt_int = IXP425_INT_UART1, + .ib_watchdog = -1 +}; + +static struct ixp425_board board_pronghorn = { + .ib_board_type = BOARD_PRONGHORN, + .ib_pci_int_a = IXP425_INT_GPIO_4, + .ib_pci_int_b = IXP425_INT_GPIO_6, + .ib_pci_int_c = IXP425_INT_GPIO_11, + .ib_pci_int_d = IXP425_INT_GPIO_1, + .ib_pci_clk_en = 3, + .ib_pci_clk = 14 /* GPIO_PCI_CLK */, + .ib_pci_reset = 12, + .ib_pci_slot_top = 20, + .ib_ata_cs0 = IXP425_EXP_BUS_CS3_HWBASE, + .ib_ata_cs0_size = IXP425_EXP_BUS_CS3_SIZE, + .ib_ata_cs1 = IXP425_EXP_BUS_CS4_HWBASE, + .ib_ata_cs1_size = IXP425_EXP_BUS_CS4_SIZE, + .ib_ata_int_pin = 0, + .ib_ata_int = IXP425_INT_GPIO_0, + .ib_iic_scl = 10, + .ib_iic_sda = 9, + .ib_uartcn_vbase = IXP425_UART1_VBASE, + .ib_uartcn_hwbase = IXP425_UART1_HWBASE, + .ib_uartcn_int = IXP425_INT_UART1, + .ib_uartalt_vbase = IXP425_UART0_VBASE, + .ib_uartalt_hwbase = IXP425_UART0_HWBASE, + .ib_uartalt_int = IXP425_INT_UART0, + .ib_watchdog = 13, +}; + +struct ixp425_board *ixp425_board; + +static void +init_board_type(void) +{ + bootverbose = 1; + if (bus_space_read_4(&ixp425_bs_tag, IXP425_EXP_VBASE, + EXP_TIMING_CS2_OFFSET) != 0) + ixp425_board = &board_avila; + else + ixp425_board = &board_pronghorn; +} Index: ixdp425_pci.c =================================================================== RCS file: /home/ncvs/src/sys/arm/xscale/ixp425/ixdp425_pci.c,v retrieving revision 1.1 diff -u -r1.1 ixdp425_pci.c --- ixdp425_pci.c 19 Nov 2006 23:55:23 -0000 1.1 +++ ixdp425_pci.c 21 Mar 2007 19:13:51 -0000 @@ -56,59 +56,76 @@ { struct ixp425_softc *sc = device_get_softc(device_get_parent(dev)); struct ixppcib_softc *pci_sc = device_get_softc(dev); - uint32_t reg; + uint32_t intn, reg; /* PCI Reset Assert */ reg = GPIO_CONF_READ_4(sc, IXP425_GPIO_GPOUTR); - reg &= ~(1U << GPIO_PCI_RESET); - GPIO_CONF_WRITE_4(sc, IXP425_GPIO_GPOUTR, reg & ~(1U << GPIO_PCI_RESET)); + reg &= ~(1U << ixp425_board->ib_pci_reset); + GPIO_CONF_WRITE_4(sc, IXP425_GPIO_GPOUTR, reg); /* PCI Clock Disable */ reg = GPIO_CONF_READ_4(sc, IXP425_GPIO_GPCLKR); reg &= ~GPCLKR_MUX14; GPIO_CONF_WRITE_4(sc, IXP425_GPIO_GPCLKR, reg & ~GPCLKR_MUX14); + /* The ixp425 do not support 66MHz pci clock. */ + if (ixp425_board->ib_pci_clk_en != -1) { + reg = GPIO_CONF_READ_4(sc, IXP425_GPIO_GPOUTR); + reg &= ~(1U << ixp425_board->ib_pci_clk_en); + GPIO_CONF_WRITE_4(sc, IXP425_GPIO_GPOUTR, reg); + } + /* * set GPIO Direction * Output: PCI_CLK, PCI_RESET * Input: PCI_INTA, PCI_INTB, PCI_INTC, PCI_INTD */ reg = GPIO_CONF_READ_4(sc, IXP425_GPIO_GPOER); - reg &= ~(1U << GPIO_PCI_CLK); - reg &= ~(1U << GPIO_PCI_RESET); - reg |= ((1U << GPIO_PCI_INTA) | (1U << GPIO_PCI_INTB) | - (1U << GPIO_PCI_INTC) | (1U << GPIO_PCI_INTD)); + if (ixp425_board->ib_pci_clk_en != -1) + reg &= ~(1U << ixp425_board->ib_pci_clk_en); + reg &= ~(1U << ixp425_board->ib_pci_clk); + reg &= ~(1U << ixp425_board->ib_pci_reset); + reg |= ((1U << ixp425_board->ib_pci_int_a) | + (1U << ixp425_board->ib_pci_int_b) | + (1U << ixp425_board->ib_pci_int_c) | + (1U << ixp425_board->ib_pci_int_d)); GPIO_CONF_WRITE_4(sc, IXP425_GPIO_GPOER, reg); /* * Set GPIO interrupt type * PCI_INT_A, PCI_INTB, PCI_INT_C, PCI_INT_D: Active Low */ - reg = GPIO_CONF_READ_4(sc, GPIO_TYPE_REG(GPIO_PCI_INTA)); - reg &= ~GPIO_TYPE(GPIO_PCI_INTA, GPIO_TYPE_MASK); - reg |= GPIO_TYPE(GPIO_PCI_INTA, GPIO_TYPE_ACT_LOW); - GPIO_CONF_WRITE_4(sc, GPIO_TYPE_REG(GPIO_PCI_INTA), reg); - - reg = GPIO_CONF_READ_4(sc, GPIO_TYPE_REG(GPIO_PCI_INTB)); - reg &= ~GPIO_TYPE(GPIO_PCI_INTB, GPIO_TYPE_MASK); - reg |= GPIO_TYPE(GPIO_PCI_INTB, GPIO_TYPE_ACT_LOW); - GPIO_CONF_WRITE_4(sc, GPIO_TYPE_REG(GPIO_PCI_INTB), reg); - - reg = GPIO_CONF_READ_4(sc, GPIO_TYPE_REG(GPIO_PCI_INTC)); - reg &= ~GPIO_TYPE(GPIO_PCI_INTC, GPIO_TYPE_MASK); - reg |= GPIO_TYPE(GPIO_PCI_INTC, GPIO_TYPE_ACT_LOW); - GPIO_CONF_WRITE_4(sc, GPIO_TYPE_REG(GPIO_PCI_INTC), reg); - - reg = GPIO_CONF_READ_4(sc, GPIO_TYPE_REG(GPIO_PCI_INTD)); - reg &= ~GPIO_TYPE(GPIO_PCI_INTD, GPIO_TYPE_MASK); - reg |= GPIO_TYPE(GPIO_PCI_INTD, GPIO_TYPE_ACT_LOW); - GPIO_CONF_WRITE_4(sc, GPIO_TYPE_REG(GPIO_PCI_INTD), reg); + intn = ixp425_board->ib_pci_int_a; + reg = GPIO_CONF_READ_4(sc, GPIO_TYPE_REG(intn)); + reg &= ~GPIO_TYPE(intn, GPIO_TYPE_MASK); + reg |= GPIO_TYPE(intn, GPIO_TYPE_ACT_LOW); + GPIO_CONF_WRITE_4(sc, GPIO_TYPE_REG(intn), reg); + + intn = ixp425_board->ib_pci_int_b; + reg = GPIO_CONF_READ_4(sc, GPIO_TYPE_REG(intn)); + reg &= ~GPIO_TYPE(intn, GPIO_TYPE_MASK); + reg |= GPIO_TYPE(intn, GPIO_TYPE_ACT_LOW); + GPIO_CONF_WRITE_4(sc, GPIO_TYPE_REG(intn), reg); + + intn = ixp425_board->ib_pci_int_c; + reg = GPIO_CONF_READ_4(sc, GPIO_TYPE_REG(intn)); + reg &= ~GPIO_TYPE(intn, GPIO_TYPE_MASK); + reg |= GPIO_TYPE(intn, GPIO_TYPE_ACT_LOW); + GPIO_CONF_WRITE_4(sc, GPIO_TYPE_REG(intn), reg); + + intn = ixp425_board->ib_pci_int_d; + reg = GPIO_CONF_READ_4(sc, GPIO_TYPE_REG(intn)); + reg &= ~GPIO_TYPE(intn, GPIO_TYPE_MASK); + reg |= GPIO_TYPE(intn, GPIO_TYPE_ACT_LOW); + GPIO_CONF_WRITE_4(sc, GPIO_TYPE_REG(intn), reg); /* clear ISR */ GPIO_CONF_WRITE_4(sc, IXP425_GPIO_GPISR, - (1U << GPIO_PCI_INTA) | (1U << GPIO_PCI_INTB) | - (1U << GPIO_PCI_INTC) | (1U << GPIO_PCI_INTD)); + (1U << ixp425_board->ib_pci_int_a) | + (1U << ixp425_board->ib_pci_int_b) | + (1U << ixp425_board->ib_pci_int_c) | + (1U << ixp425_board->ib_pci_int_d)); /* wait 1ms to satisfy "minimum reset assertion time" of the PCI spec */ DELAY(1000); @@ -119,7 +136,7 @@ /* PCI Clock Enable */ reg = GPIO_CONF_READ_4(sc, IXP425_GPIO_GPCLKR); reg |= GPCLKR_MUX14; - GPIO_CONF_WRITE_4(sc, IXP425_GPIO_GPCLKR, reg | GPCLKR_MUX14); + GPIO_CONF_WRITE_4(sc, IXP425_GPIO_GPCLKR, reg); /* * wait 100us to satisfy "minimum reset assertion time from clock stable @@ -128,14 +145,25 @@ DELAY(100); /* PCI Reset deassert */ reg = GPIO_CONF_READ_4(sc, IXP425_GPIO_GPOUTR); - reg |= 1U << GPIO_PCI_RESET; - GPIO_CONF_WRITE_4(sc, IXP425_GPIO_GPOUTR, reg | (1U << GPIO_PCI_RESET)); + reg |= 1U << ixp425_board->ib_pci_reset; + GPIO_CONF_WRITE_4(sc, IXP425_GPIO_GPOUTR, reg); pci_sc->sc_irq_rman.rm_type = RMAN_ARRAY; pci_sc->sc_irq_rman.rm_descr = "IXP425 PCI IRQs"; - CTASSERT(PCI_INT_D < PCI_INT_A); - /* XXX this overlaps the irq's setup in ixp425_attach */ + /* + * XXX this overlaps the irq's setup in ixp425_attach + * + * PCI irq's on the Pronghorn are not consecutive, so do + * them one at a time. + */ if (rman_init(&pci_sc->sc_irq_rman) != 0 || - rman_manage_region(&pci_sc->sc_irq_rman, PCI_INT_D, PCI_INT_A) != 0) + rman_manage_region(&pci_sc->sc_irq_rman, + ixp425_board->ib_pci_int_a, ixp425_board->ib_pci_int_a) != 0 || + rman_manage_region(&pci_sc->sc_irq_rman, + ixp425_board->ib_pci_int_b, ixp425_board->ib_pci_int_b) != 0 || + rman_manage_region(&pci_sc->sc_irq_rman, + ixp425_board->ib_pci_int_c, ixp425_board->ib_pci_int_c) != 0 || + rman_manage_region(&pci_sc->sc_irq_rman, + ixp425_board->ib_pci_int_d, ixp425_board->ib_pci_int_d) != 0) panic("ixp425_md_attach: failed to set up IRQ rman"); } @@ -145,15 +173,22 @@ int ixp425_md_route_interrupt(device_t bridge, device_t device, int pin) { - static int ixp425_pci_table[IXP425_MAX_DEV][IXP425_MAX_LINE] = - { - {PCI_INT_A, PCI_INT_B, PCI_INT_C, PCI_INT_D}, - {PCI_INT_B, PCI_INT_C, PCI_INT_D, PCI_INT_A}, - {PCI_INT_C, PCI_INT_D, PCI_INT_A, PCI_INT_B}, - {PCI_INT_D, PCI_INT_A, PCI_INT_B, PCI_INT_C}, - }; - int dev; - + static int ixp425_pci_table[IXP425_MAX_DEV][IXP425_MAX_LINE]; + static int table_filled = 0; + int di, dev, li; + + if (table_filled == 0) { + ixp425_pci_table[0][0] = ixp425_board->ib_pci_int_a; + ixp425_pci_table[0][1] = ixp425_board->ib_pci_int_b; + ixp425_pci_table[0][2] = ixp425_board->ib_pci_int_c; + ixp425_pci_table[0][3] = ixp425_board->ib_pci_int_d; + for (di = 1; di < IXP425_MAX_DEV; di++) + for (li = 0; li < IXP425_MAX_LINE; li++) + ixp425_pci_table[di][li] = + ixp425_pci_table[0][(di + li) % + IXP425_MAX_LINE]; + table_filled = 1; + } dev = pci_get_slot(device); if (bootverbose) device_printf(bridge, "routing pin %d for %s\n", pin, Index: ixp425.c =================================================================== RCS file: /home/ncvs/src/sys/arm/xscale/ixp425/ixp425.c,v retrieving revision 1.5 diff -u -r1.5 ixp425.c --- ixp425.c 14 Mar 2007 19:03:07 -0000 1.5 +++ ixp425.c 19 Mar 2007 09:50:59 -0000 @@ -278,9 +278,9 @@ rmanp = &sc->sc_irq_rman; if (isuart) { if (device_get_unit(dev) == 0) - start = IXP425_INT_UART0; + start = ixp425_board->ib_uartcn_int; else - start = IXP425_INT_UART1; + start = ixp425_board->ib_uartalt_int; end = start; } break; @@ -289,9 +289,9 @@ rmanp = &sc->sc_mem_rman; if (isuart) { if (device_get_unit(dev) == 0) - start = IXP425_UART0_HWBASE; + start = ixp425_board->ib_uartcn_hwbase; else - start = IXP425_UART1_HWBASE; + start = ixp425_board->ib_uartalt_hwbase; end = start + 0x1000; } if (getvbase(start, end - start, &vbase)) @@ -326,9 +326,9 @@ if (flags & INTR_TYPE_TTY) { /* XXX: wrong. */ if (device_get_unit(dev) == 0) - rman_set_start(ires, IXP425_INT_UART0); + rman_set_start(ires, ixp425_board->ib_uartcn_int); else - rman_set_start(ires, IXP425_INT_UART1); + rman_set_start(ires, ixp425_board->ib_uartalt_int); rman_set_end(ires, rman_get_start(ires)); } BUS_SETUP_INTR(device_get_parent(dev), child, ires, flags, filt, intr, Index: ixp425_iic.c =================================================================== RCS file: /home/ncvs/src/sys/arm/xscale/ixp425/ixp425_iic.c,v retrieving revision 1.1 diff -u -r1.1 ixp425_iic.c --- ixp425_iic.c 19 Nov 2006 23:55:23 -0000 1.1 +++ ixp425_iic.c 21 Mar 2007 17:50:07 -0000 @@ -61,6 +61,8 @@ device_t sc_dev; bus_space_tag_t sc_iot; bus_space_handle_t sc_gpio_ioh; + uint32_t sc_scl_bit; + uint32_t sc_sda_bit; device_t iicbb; }; @@ -85,11 +87,13 @@ sc->sc_dev = dev; sc->sc_iot = sa->sc_iot; sc->sc_gpio_ioh = sa->sc_gpio_ioh; + sc->sc_scl_bit = 1U << ixp425_board->ib_iic_scl; + sc->sc_sda_bit = 1U << ixp425_board->ib_iic_sda; GPIO_CONF_SET(sc, IXP425_GPIO_GPOER, - GPIO_I2C_SCL_BIT | GPIO_I2C_SDA_BIT); + sc->sc_scl_bit | sc->sc_sda_bit); GPIO_CONF_CLR(sc, IXP425_GPIO_GPOUTR, - GPIO_I2C_SCL_BIT | GPIO_I2C_SDA_BIT); + sc->sc_scl_bit | sc->sc_sda_bit); /* add generic bit-banging code */ if ((sc->iicbb = device_add_child(dev, "iicbb", -1)) == NULL) @@ -113,10 +117,10 @@ struct ixpiic_softc *sc = ixpiic_sc; uint32_t reg; - GPIO_CONF_SET(sc, IXP425_GPIO_GPOER, GPIO_I2C_SCL_BIT); + GPIO_CONF_SET(sc, IXP425_GPIO_GPOER, sc->sc_scl_bit); reg = GPIO_CONF_READ_4(sc, IXP425_GPIO_GPINR); - return (reg & GPIO_I2C_SCL_BIT); + return (reg & sc->sc_scl_bit); } static int @@ -125,10 +129,10 @@ struct ixpiic_softc *sc = ixpiic_sc; uint32_t reg; - GPIO_CONF_SET(sc, IXP425_GPIO_GPOER, GPIO_I2C_SDA_BIT); + GPIO_CONF_SET(sc, IXP425_GPIO_GPOER, sc->sc_sda_bit); reg = GPIO_CONF_READ_4(sc, IXP425_GPIO_GPINR); - return (reg & GPIO_I2C_SDA_BIT); + return (reg & sc->sc_sda_bit); } static void @@ -136,11 +140,11 @@ { struct ixpiic_softc *sc = ixpiic_sc; - GPIO_CONF_CLR(sc, IXP425_GPIO_GPOUTR, GPIO_I2C_SDA_BIT); + GPIO_CONF_CLR(sc, IXP425_GPIO_GPOUTR, sc->sc_sda_bit); if (val) - GPIO_CONF_SET(sc, IXP425_GPIO_GPOER, GPIO_I2C_SDA_BIT); + GPIO_CONF_SET(sc, IXP425_GPIO_GPOER, sc->sc_sda_bit); else - GPIO_CONF_CLR(sc, IXP425_GPIO_GPOER, GPIO_I2C_SDA_BIT); + GPIO_CONF_CLR(sc, IXP425_GPIO_GPOER, sc->sc_sda_bit); DELAY(I2C_DELAY); } @@ -149,11 +153,11 @@ { struct ixpiic_softc *sc = ixpiic_sc; - GPIO_CONF_CLR(sc, IXP425_GPIO_GPOUTR, GPIO_I2C_SCL_BIT); + GPIO_CONF_CLR(sc, IXP425_GPIO_GPOUTR, sc->sc_scl_bit); if (val) - GPIO_CONF_SET(sc, IXP425_GPIO_GPOER, GPIO_I2C_SCL_BIT); + GPIO_CONF_SET(sc, IXP425_GPIO_GPOER, sc->sc_scl_bit); else - GPIO_CONF_CLR(sc, IXP425_GPIO_GPOER, GPIO_I2C_SCL_BIT); + GPIO_CONF_CLR(sc, IXP425_GPIO_GPOER, sc->sc_scl_bit); DELAY(I2C_DELAY); } Index: ixp425_pci.c =================================================================== RCS file: /home/ncvs/src/sys/arm/xscale/ixp425/ixp425_pci.c,v retrieving revision 1.4 diff -u -r1.4 ixp425_pci.c --- ixp425_pci.c 6 Mar 2007 10:58:22 -0000 1.4 +++ ixp425_pci.c 21 Mar 2007 17:18:45 -0000 @@ -355,8 +355,9 @@ slot &= 0x1f; func &= 0x07; /* configuration type 0 */ - PCI_CSR_WRITE_4(sc, PCI_NP_AD, (1U << (32 - slot)) | - (func << 8) | (reg & ~3)); + PCI_CSR_WRITE_4(sc, PCI_NP_AD, + (1U << (ixp425_board->ib_pci_slot_top - slot)) | + (func << 8) | (reg & ~3)); } } else { /* configuration type 1 */ Index: ixp425var.h =================================================================== RCS file: /home/ncvs/src/sys/arm/xscale/ixp425/ixp425var.h,v retrieving revision 1.2 diff -u -r1.2 ixp425var.h --- ixp425var.h 17 Jan 2007 00:58:25 -0000 1.2 +++ ixp425var.h 21 Mar 2007 17:15:57 -0000 @@ -87,8 +87,38 @@ #define GPIO_CONF_READ_4(sc, reg) \ bus_space_read_4(sc->sc_iot, sc->sc_gpio_ioh, reg) +struct ixp425_board { + int ib_board_type; + int ib_pci_int_a; + int ib_pci_int_b; + int ib_pci_int_c; + int ib_pci_int_d; + int ib_pci_clk_en; + int ib_pci_clk; + int ib_pci_reset; + int ib_pci_slot_top; + int ib_ata_cs0; + int ib_ata_cs0_size; + int ib_ata_cs1; + int ib_ata_cs1_size; + int ib_ata_int_pin; + int ib_ata_int; + int ib_iic_scl; + int ib_iic_sda; + int ib_uartcn_vbase; + int ib_uartcn_hwbase; + int ib_uartcn_int; + int ib_uartalt_vbase; + int ib_uartalt_hwbase; + int ib_uartalt_int; + int ib_watchdog; +}; +#define BOARD_AVILA 0 +#define BOARD_PRONGHORN 1 + extern struct bus_space ixp425_bs_tag; extern struct bus_space ixp425_a4x_bs_tag; +extern struct ixp425_board *ixp425_board; void ixp425_io_bs_init(bus_space_tag_t, void *); void ixp425_mem_bs_init(bus_space_tag_t, void *); Index: uart_bus_ixp425.c =================================================================== RCS file: /home/ncvs/src/sys/arm/xscale/ixp425/uart_bus_ixp425.c,v retrieving revision 1.1 diff -u -r1.1 uart_bus_ixp425.c --- uart_bus_ixp425.c 19 Nov 2006 23:55:23 -0000 1.1 +++ uart_bus_ixp425.c 19 Mar 2007 17:21:42 -0000 @@ -82,8 +82,9 @@ * just set them here and proceed. But this is fragile... */ bus_space_write_4(&ixp425_a4x_bs_tag, - device_get_unit(dev) == 0 ? IXP425_UART0_VBASE : IXP425_UART1_VBASE, - IXP425_UART_IER, IXP425_UART_IER_UUE | IXP425_UART_IER_RTOIE); + device_get_unit(dev) == 0 ? ixp425_board->ib_uartcn_vbase : + ixp425_board->ib_uartalt_vbase, IXP425_UART_IER, + IXP425_UART_IER_UUE | IXP425_UART_IER_RTOIE); return(uart_bus_probe(dev, 0, IXP425_UART_FREQ, 0, 0)); } Index: uart_cpu_ixp425.c =================================================================== RCS file: /home/ncvs/src/sys/arm/xscale/ixp425/uart_cpu_ixp425.c,v retrieving revision 1.1 diff -u -r1.1 uart_cpu_ixp425.c --- uart_cpu_ixp425.c 19 Nov 2006 23:55:23 -0000 1.1 +++ uart_cpu_ixp425.c 19 Mar 2007 17:20:20 -0000 @@ -62,6 +62,6 @@ di->parity = UART_PARITY_NONE; uart_bus_space_io = &ixp425_a4x_bs_tag; uart_bus_space_mem = NULL; - di->bas.bsh = IXP425_UART0_VBASE; + di->bas.bsh = ixp425_board->ib_uartcn_vbase; return (0); } From owner-freebsd-arm@FreeBSD.ORG Thu Mar 22 09:26:12 2007 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B3CDD16A515 for ; Thu, 22 Mar 2007 09:26:12 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.freebsd.org (Postfix) with ESMTP id 303C513C43E for ; Thu, 22 Mar 2007 09:26:12 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 23CF633CAE; Thu, 22 Mar 2007 11:26:10 +0200 (SAST) Date: Thu, 22 Mar 2007 11:26:10 +0200 From: John Hay To: freebsd-arm@freebsd.org Message-ID: <20070322092609.GA58744@zibbi.meraka.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: current to 6-stable merge plans/policy 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: Thu, 22 Mar 2007 09:26:12 -0000 Hi Guys, What are the ideas (policy) about merging the arm/ixp425/avila stuff to 6-stable? I see some arm stuff gets merged, but it does not look like everything? Is it just that people merge what they need? Just trying to get a feel for it. Up to now I have used 6-stable on our soekris and wrap boards, but we are probably going to use the Avila boards a bit more, so I was wondering if I should use -current or 6-stable on them. Up to now my Avila and ADI testing was done with -current, but I'm not sure if that is a good idea for boxes that will end up in rural areas far far away. Hmm. Not that I have seen a panic on the Avila boards, but they have gone through a lot less testing up to now. John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-arm@FreeBSD.ORG Thu Mar 22 09:45:22 2007 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A91ED16A402 for ; Thu, 22 Mar 2007 09:45:22 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from mx.bulinfo.net (mx.bulinfo.net [193.194.156.1]) by mx1.freebsd.org (Postfix) with ESMTP id 06B1D13C4C2 for ; Thu, 22 Mar 2007 09:45:21 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id 2796D3777B; Thu, 22 Mar 2007 11:45:20 +0200 (EET) Received: from mx.bulinfo.net ([127.0.0.1]) by localhost (mx.bulinfo.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75644-02; Thu, 22 Mar 2007 11:45:15 +0200 (EET) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id 0C6703777C; Thu, 22 Mar 2007 11:45:15 +0200 (EET) Message-ID: <46025027.80805@bulinfo.net> Date: Thu, 22 Mar 2007 11:45:11 +0200 From: Krassimir Slavchev User-Agent: Thunderbird 1.5 (X11/20060201) MIME-Version: 1.0 To: freebsd-arm@freebsd.org, freebsd-ports@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mx.bulinfo.net Cc: Subject: Problems installing perl on arm? 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: Thu, 22 Mar 2007 09:45:22 -0000 I am using CURRENT on arm and can't install perl 5.8.8 from ports. The port is compiled on arm. ===> Installing for perl-5.8.8 ===> Generating temporary packing list ===> Checking if lang/perl5.8 already installed make install.perl install.man STRIPFLAGS= DESTDIR="" AutoSplitting perl library LD_LIBRARY_PATH=/usr/ports/lang/perl5.8/work/perl-5.8.8 ./miniperl -Ilib -e 'use AutoSplit; autosplit_lib_modules(@ARGV)' lib/*.pm LD_LIBRARY_PATH=/usr/ports/lang/perl5.8/work/perl-5.8.8 ./miniperl -Ilib -e 'use AutoSplit; autosplit_lib_modules(@ARGV)' lib/*/*.pm make lib/re.pm `lib/re.pm' is up to date. Making DynaLoader (static_pic) LD_LIBRARY_PATH=/usr/ports/lang/perl5.8/work/perl-5.8.8 cc -o perl -Wl,-E -Wl,-R/usr/local/lib/perl5/5.8.8/mach/CORE perlmain.o lib/auto/DynaLoader/DynaLoader.a libperl.so `cat ext.libs` -lm -lcrypt -lutil Making utilities Making x2p stuff Making B (dynamic) Making ByteLoader (dynamic) Making Cwd (dynamic) Making DB_File (dynamic) Making Data::Dumper (dynamic) Making Devel::DProf (dynamic) Making Devel::PPPort (dynamic) Making Devel::Peek (dynamic) Making Digest::MD5 (dynamic) Making Encode (dynamic) Making Fcntl (dynamic) Making File::Glob (dynamic) Making Filter::Util::Call (dynamic) Making I18N::Langinfo (dynamic) Making IO (dynamic) Making IPC::SysV (dynamic) Making List::Util (dynamic) Making MIME::Base64 (dynamic) Making NDBM_File (dynamic) Making Opcode (dynamic) Making POSIX (dynamic) Making PerlIO::encoding (dynamic) Making PerlIO::scalar (dynamic) Making PerlIO::via (dynamic) Making SDBM_File (dynamic) Making Socket (dynamic) Making Storable (dynamic) Making Sys::Hostname (dynamic) Making Sys::Syslog (dynamic) Making Time::HiRes (dynamic) Making Unicode::Normalize (dynamic) Making XS::APItest (dynamic) Making XS::Typemap (dynamic) Making attrs (dynamic) Making re (dynamic) Making threads (dynamic) Making threads::shared (dynamic) Making Errno (nonxs) *** Error code 1 (ignored) Everything is up to date. Type 'make test' to run test suite. if [ -n "" ]; then cd utils; make compile; cd ../x2p; make compile; cd ../pod; make compile; else :; fi LD_LIBRARY_PATH=/usr/ports/lang/perl5.8/work/perl-5.8.8 ./perl installperl --destdir= Can't load 'lib/auto/File/Glob/Glob.so' for module File::Glob: Service unavailable at lib/XSLoader.pm line 70. at lib/File/Glob.pm line 96 Compilation failed in require at installperl line 132. BEGIN failed--compilation aborted at installperl line 132. *** Error code 255 Stop in /tmp/perl5.8/work/perl-5.8.8. *** Error code 1 Stop in /tmp/perl5.8/work/perl-5.8.8. *** Error code 1 Stop in /tmp/perl5.8. centipad# cd .. centipad# ls .ICE-unix .XIM-unix file.dat .X11-unix .font-unix perl5.8 centipad# rm -r perl5.8 centipad# cd /usr/ports/lang/perl5.8/ centipad# ls Makefile distinfo pkg-descr pkg-plist Makefile.man files pkg-message work centipad# make package ===> Installing for perl-5.8.8 ===> Generating temporary packing list ===> Checking if lang/perl5.8 already installed make install.perl install.man STRIPFLAGS= DESTDIR="" AutoSplitting perl library LD_LIBRARY_PATH=/usr/ports/lang/perl5.8/work/perl-5.8.8 ./miniperl -Ilib -e 'use AutoSplit; autosplit_lib_modules(@ARGV)' lib/*.pm LD_LIBRARY_PATH=/usr/ports/lang/perl5.8/work/perl-5.8.8 ./miniperl -Ilib -e 'use AutoSplit; autosplit_lib_modules(@ARGV)' lib/*/*.pm make lib/re.pm `lib/re.pm' is up to date. Making DynaLoader (static_pic) LD_LIBRARY_PATH=/usr/ports/lang/perl5.8/work/perl-5.8.8 cc -o perl -Wl,-E -Wl,-R/usr/local/lib/perl5/5.8.8/mach/CORE perlmain.o lib/auto/DynaLoader/DynaLoader.a libperl.so `cat ext.libs` -lm -lcrypt -lutil Making utilities Making x2p stuff Making B (dynamic) Making ByteLoader (dynamic) Making Cwd (dynamic) Making DB_File (dynamic) Making Data::Dumper (dynamic) Making Devel::DProf (dynamic) Making Devel::PPPort (dynamic) Making Devel::Peek (dynamic) Making Digest::MD5 (dynamic) Making Encode (dynamic) Making Fcntl (dynamic) Making File::Glob (dynamic) Making Filter::Util::Call (dynamic) Making I18N::Langinfo (dynamic) Making IO (dynamic) Making IPC::SysV (dynamic) Making List::Util (dynamic) Making MIME::Base64 (dynamic) Making NDBM_File (dynamic) Making Opcode (dynamic) Making POSIX (dynamic) Making PerlIO::encoding (dynamic) Making PerlIO::scalar (dynamic) Making PerlIO::via (dynamic) Making SDBM_File (dynamic) Making Socket (dynamic) Making Storable (dynamic) Making Sys::Hostname (dynamic) Making Sys::Syslog (dynamic) Making Time::HiRes (dynamic) Making Unicode::Normalize (dynamic) Making XS::APItest (dynamic) Making XS::Typemap (dynamic) Making attrs (dynamic) Making re (dynamic) Making threads (dynamic) Making threads::shared (dynamic) Making Errno (nonxs) *** Error code 1 (ignored) Everything is up to date. Type 'make test' to run test suite. if [ -n "" ]; then cd utils; make compile; cd ../x2p; make compile; cd ../pod; make compile; else :; fi LD_LIBRARY_PATH=/usr/ports/lang/perl5.8/work/perl-5.8.8 ./perl installperl --destdir= Can't load 'lib/auto/File/Glob/Glob.so' for module File::Glob: Service unavailable at lib/XSLoader.pm line 70. at lib/File/Glob.pm line 96 Compilation failed in require at installperl line 132. BEGIN failed--compilation aborted at installperl line 132. *** Error code 255 Stop in /usr/ports/lang/perl5.8/work/perl-5.8.8. *** Error code 1 Stop in /usr/ports/lang/perl5.8/work/perl-5.8.8. *** Error code 1 Stop in /usr/ports/lang/perl5.8. From owner-freebsd-arm@FreeBSD.ORG Thu Mar 22 10:50:49 2007 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A760116A484; Thu, 22 Mar 2007 10:50:49 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from mx.bulinfo.net (mx.bulinfo.net [193.194.156.1]) by mx1.freebsd.org (Postfix) with ESMTP id 4FD6E13C45E; Thu, 22 Mar 2007 10:50:49 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id 3510237885; Thu, 22 Mar 2007 12:50:48 +0200 (EET) Received: from mx.bulinfo.net ([127.0.0.1]) by localhost (mx.bulinfo.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80723-05; Thu, 22 Mar 2007 12:50:43 +0200 (EET) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id 16C1837883; Thu, 22 Mar 2007 12:50:43 +0200 (EET) Message-ID: <46025F82.4020403@bulinfo.net> Date: Thu, 22 Mar 2007 12:50:42 +0200 From: Krassimir Slavchev User-Agent: Thunderbird 1.5 (X11/20060201) MIME-Version: 1.0 To: Anton Berezin , freebsd-arm@freebsd.org, freebsd-ports@freebsd.org References: <46025027.80805@bulinfo.net> <20070322104505.GC16764@heechee.tobez.org> In-Reply-To: <20070322104505.GC16764@heechee.tobez.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mx.bulinfo.net Cc: Subject: Re: Problems installing perl on arm? 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: Thu, 22 Mar 2007 10:50:49 -0000 I jush fixed the problem. It wasn't in perl. I don't know why but I found wrong links in /usr/lib: libc.so -> /usr/obj/......./libc.so.7 ... Thanks for the reply Anton Berezin wrote: > On Thu, Mar 22, 2007 at 11:45:11AM +0200, Krassimir Slavchev wrote: > >> I am using CURRENT on arm and can't install perl 5.8.8 from ports. The >> port is compiled on arm. >> > > Can I get a temporary access to the box in question to debug the problem? > I do not have any freebsd-arm boxes available. > > Cheers, > \Anton. > From owner-freebsd-arm@FreeBSD.ORG Thu Mar 22 12:40:07 2007 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4640816A40E for ; Thu, 22 Mar 2007 12:40:07 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from mx.bulinfo.net (mx.bulinfo.net [193.194.156.1]) by mx1.freebsd.org (Postfix) with ESMTP id EF3F613C4E3 for ; Thu, 22 Mar 2007 12:40:05 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id 3C7A437A3D; Thu, 22 Mar 2007 14:40:04 +0200 (EET) Received: from mx.bulinfo.net ([127.0.0.1]) by localhost (mx.bulinfo.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89611-03; Thu, 22 Mar 2007 14:40:03 +0200 (EET) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id EE9E6379D5; Thu, 22 Mar 2007 14:40:02 +0200 (EET) Message-ID: <46027921.2020401@bulinfo.net> Date: Thu, 22 Mar 2007 14:40:01 +0200 From: Krassimir Slavchev User-Agent: Thunderbird 1.5 (X11/20060201) MIME-Version: 1.0 To: Olivier Houchard References: <4601ce80.5b8c468e.49f9.13fa@mx.google.com> <20070322005444.GA72878@ci0.org> In-Reply-To: <20070322005444.GA72878@ci0.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mx.bulinfo.net Cc: freebsd-arm@freebsd.org Subject: Re: awk hanging 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: Thu, 22 Mar 2007 12:40:07 -0000 Hi, I have the same problem when installing perl-5.8.8. top shows: 13390 root 1 121 0 5768K 1380K RUN 42:26 98.10% awk The process is still running, let me know if I can help? Olivier Houchard wrote: > On Wed, Mar 21, 2007 at 02:31:27PM -1000, David Cornejo wrote: > >> Hi, >> >> I am trying to build and install some ports on an Avila board - >> however with certain packages (i.e. ruby) it gets to the install >> phase and awk goes into a state where it's constantly running and >> never comes out (I let it run for four days and then killed it). I >> have reproduced this in both stable and current. Gdb in current >> fails to attach to awk, and gdb seems to be completely missing in >> 6.2. Any suggestions on how to debug this? Would a gdb from ports work? >> >> thanks for any help, >> dave c >> > > Hi David, > > I'm going to investigate. > Can you tell if it just happens randomly, or if it always happens with some > ports, but not others ? > If it always happens with the same ports, can you name one that is faster to > build than ruby ? ;) > > Thanks a lot for reporting ! > > Olivier > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > -- Krassimir Slavchev Bulinfo Ltd. krassi@bulinfo.net (+359 2) 969-9160 http://www.bulinfo.net (+359 2) 969-9166 From owner-freebsd-arm@FreeBSD.ORG Thu Mar 22 15:04:23 2007 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BEB6816A405 for ; Thu, 22 Mar 2007 15:04:23 +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 977A713C487 for ; Thu, 22 Mar 2007 15:04:23 +0000 (UTC) (envelope-from sam@errno.com) Received: from [10.0.0.248] (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id l2MF4LQG026404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Mar 2007 08:04:23 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <46029AF5.20903@errno.com> Date: Thu, 22 Mar 2007 08:04:21 -0700 From: Sam Leffler User-Agent: Thunderbird 1.5.0.9 (X11/20070208) MIME-Version: 1.0 To: John Hay References: <20070322080335.GA52745@zibbi.meraka.csir.co.za> In-Reply-To: <20070322080335.GA52745@zibbi.meraka.csir.co.za> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: progress on the adi pronghorn metro board 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: Thu, 22 Mar 2007 15:04:23 -0000 John Hay wrote: > Hi Guys, > > With this patch I am at the stage where both an Avila 2348-4 and the > ADI Pronghorn Metro boot from the same kernel binary. The "main" stuff > is working, ie. console, ethernet and mini-pci slots. The iic bus on > the Avila is still working. The one for the Pronghorn is configured, > but I must still write a driver for their max6652 temperature/voltage > sensor before I will know if it is really working. > > The biggest difference between the 2 boards are in the 16 GPIO pins. > I think there is only 1 pin that have the same function. :-/ > > So what I did was to create a structure and then have 2 instances of > it, one with Avila values in it and one with Pronghorn values. Then > early in the boot phase, the board type gets detected and a pointer > gets set to the relevant structure. All the drivers then use this > pointer to get the correct values. The efect is that most of the > drivers needs no checks for the different boards. > > What I would like to know is, if this approach is acceptable? Should > I use different files to put the stuff in? > > My code is not finished yet, but I thought that I would like to get > some feedback. I still have to replace some of the numbers in the > structure with defined values. I would also like to try and really > probe the iic devices and not just assume that they are there. I'm not sure whether it makes sense to support different boards in a single binary (variations on a board design yes). My experience is that embedded applications are often cycle starved and giving up cycles for flexibility like this is ok only for devel/bringup. I suspect compile-time configuration is preferable. However if this flexibility is desirable it might be better to use ivar's hung off the nexus. Sam From owner-freebsd-arm@FreeBSD.ORG Thu Mar 22 15:05:45 2007 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EDC2116A401 for ; Thu, 22 Mar 2007 15:05:45 +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 CC18013C48A for ; Thu, 22 Mar 2007 15:05:45 +0000 (UTC) (envelope-from sam@errno.com) Received: from [10.0.0.248] (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id l2MF5jgt026430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Mar 2007 08:05:45 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <46029B48.9000906@errno.com> Date: Thu, 22 Mar 2007 08:05:44 -0700 From: Sam Leffler User-Agent: Thunderbird 1.5.0.9 (X11/20070208) MIME-Version: 1.0 To: John Hay References: <20070322092609.GA58744@zibbi.meraka.csir.co.za> In-Reply-To: <20070322092609.GA58744@zibbi.meraka.csir.co.za> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: current to 6-stable merge plans/policy 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: Thu, 22 Mar 2007 15:05:46 -0000 John Hay wrote: > Hi Guys, > > What are the ideas (policy) about merging the arm/ixp425/avila stuff > to 6-stable? I see some arm stuff gets merged, but it does not look > like everything? Is it just that people merge what they need? > > Just trying to get a feel for it. Up to now I have used 6-stable on > our soekris and wrap boards, but we are probably going to use the > Avila boards a bit more, so I was wondering if I should use -current > or 6-stable on them. Up to now my Avila and ADI testing was done with > -current, but I'm not sure if that is a good idea for boxes that will > end up in rural areas far far away. Hmm. Not that I have seen a panic > on the Avila boards, but they have gone through a lot less testing up > to now. Not sure what's been missed. I see no reason not to MFC anything arm-related unless it breaks code compatibility (and even there it's unlikely there are 3rd party codes to worry about). Sam From owner-freebsd-arm@FreeBSD.ORG Thu Mar 22 15:11:43 2007 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 85B1516A400 for ; Thu, 22 Mar 2007 15:11:43 +0000 (UTC) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (cognet.ci0.org [80.65.224.102]) by mx1.freebsd.org (Postfix) with ESMTP id C1B4013C46E for ; Thu, 22 Mar 2007 15:11:41 +0000 (UTC) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (localhost.ci0.org [127.0.0.1]) by dong.ci0.org (8.13.8/8.13.8) with ESMTP id l2MFR9Jm079066; Thu, 22 Mar 2007 16:27:09 +0100 (CET) (envelope-from mlfbsd@dong.ci0.org) Received: (from mlfbsd@localhost) by dong.ci0.org (8.13.8/8.13.8/Submit) id l2MFR8Qo079065; Thu, 22 Mar 2007 16:27:09 +0100 (CET) (envelope-from mlfbsd) Date: Thu, 22 Mar 2007 16:27:08 +0100 From: Olivier Houchard To: Sam Leffler Message-ID: <20070322152708.GA79016@ci0.org> References: <20070322080335.GA52745@zibbi.meraka.csir.co.za> <46029AF5.20903@errno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46029AF5.20903@errno.com> User-Agent: Mutt/1.4.1i Cc: freebsd-arm@freebsd.org Subject: Re: progress on the adi pronghorn metro board 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: Thu, 22 Mar 2007 15:11:43 -0000 On Thu, Mar 22, 2007 at 08:04:21AM -0700, Sam Leffler wrote: > John Hay wrote: > > Hi Guys, > > > > With this patch I am at the stage where both an Avila 2348-4 and the > > ADI Pronghorn Metro boot from the same kernel binary. The "main" stuff > > is working, ie. console, ethernet and mini-pci slots. The iic bus on > > the Avila is still working. The one for the Pronghorn is configured, > > but I must still write a driver for their max6652 temperature/voltage > > sensor before I will know if it is really working. > > > > The biggest difference between the 2 boards are in the 16 GPIO pins. > > I think there is only 1 pin that have the same function. :-/ > > > > So what I did was to create a structure and then have 2 instances of > > it, one with Avila values in it and one with Pronghorn values. Then > > early in the boot phase, the board type gets detected and a pointer > > gets set to the relevant structure. All the drivers then use this > > pointer to get the correct values. The efect is that most of the > > drivers needs no checks for the different boards. > > > > What I would like to know is, if this approach is acceptable? Should > > I use different files to put the stuff in? > > > > My code is not finished yet, but I thought that I would like to get > > some feedback. I still have to replace some of the numbers in the > > structure with defined values. I would also like to try and really > > probe the iic devices and not just assume that they are there. > > I'm not sure whether it makes sense to support different boards in a > single binary (variations on a board design yes). My experience is that > embedded applications are often cycle starved and giving up cycles for > flexibility like this is ok only for devel/bringup. I suspect > compile-time configuration is preferable. > > However if this flexibility is desirable it might be better to use > ivar's hung off the nexus. > > Sam I tend to agree. I think one config file per board is not too much to handle, and detecting which board we're currently running can be difficult. Olivier From owner-freebsd-arm@FreeBSD.ORG Thu Mar 22 15:15:56 2007 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 25B7416A400 for ; Thu, 22 Mar 2007 15:15:56 +0000 (UTC) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (cognet.ci0.org [80.65.224.102]) by mx1.freebsd.org (Postfix) with ESMTP id 8464213C4BA for ; Thu, 22 Mar 2007 15:15:55 +0000 (UTC) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (localhost.ci0.org [127.0.0.1]) by dong.ci0.org (8.13.8/8.13.8) with ESMTP id l2MFVOs5079104; Thu, 22 Mar 2007 16:31:24 +0100 (CET) (envelope-from mlfbsd@dong.ci0.org) Received: (from mlfbsd@localhost) by dong.ci0.org (8.13.8/8.13.8/Submit) id l2MFVNeJ079103; Thu, 22 Mar 2007 16:31:23 +0100 (CET) (envelope-from mlfbsd) Date: Thu, 22 Mar 2007 16:31:23 +0100 From: Olivier Houchard To: Sam Leffler Message-ID: <20070322153123.GB79016@ci0.org> References: <20070322092609.GA58744@zibbi.meraka.csir.co.za> <46029B48.9000906@errno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46029B48.9000906@errno.com> User-Agent: Mutt/1.4.1i Cc: freebsd-arm@freebsd.org Subject: Re: current to 6-stable merge plans/policy 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: Thu, 22 Mar 2007 15:15:56 -0000 On Thu, Mar 22, 2007 at 08:05:44AM -0700, Sam Leffler wrote: > John Hay wrote: > > Hi Guys, > > > > What are the ideas (policy) about merging the arm/ixp425/avila stuff > > to 6-stable? I see some arm stuff gets merged, but it does not look > > like everything? Is it just that people merge what they need? > > > > Just trying to get a feel for it. Up to now I have used 6-stable on > > our soekris and wrap boards, but we are probably going to use the > > Avila boards a bit more, so I was wondering if I should use -current > > or 6-stable on them. Up to now my Avila and ADI testing was done with > > -current, but I'm not sure if that is a good idea for boxes that will > > end up in rural areas far far away. Hmm. Not that I have seen a panic > > on the Avila boards, but they have gone through a lot less testing up > > to now. > > Not sure what's been missed. I see no reason not to MFC anything > arm-related unless it breaks code compatibility (and even there it's > unlikely there are 3rd party codes to worry about). > > Sam Hi John, Sorry for lack of answers, I really need to get back in the loop. Avila works fine in RELENG_6. Generally, MFC'ing arm stuff should happen more often. On an unrelated note, your changes (I think, maybe I should've had a closer look) seem to provoke an interrupt storm on ATA when there's no CF card inserted, I seem to remember it may be why we did some ugly stuff. Olivier From owner-freebsd-arm@FreeBSD.ORG Thu Mar 22 16:50:12 2007 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 78F4416A400 for ; Thu, 22 Mar 2007 16:50:12 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id D902D13C48C for ; Thu, 22 Mar 2007 16:50:11 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id l2MGnMeW016253; Thu, 22 Mar 2007 09:49:22 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 22 Mar 2007 10:49:30 -0600 (MDT) Message-Id: <20070322.104930.1649769545.imp@bsdimp.com> To: jhay@meraka.org.za From: "M. Warner Losh" In-Reply-To: <20070322092609.GA58744@zibbi.meraka.csir.co.za> References: <20070322092609.GA58744@zibbi.meraka.csir.co.za> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 22 Mar 2007 10:49:23 -0600 (MDT) Cc: freebsd-arm@freebsd.org Subject: Re: current to 6-stable merge plans/policy 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: Thu, 22 Mar 2007 16:50:12 -0000 In message: <20070322092609.GA58744@zibbi.meraka.csir.co.za> John Hay writes: : What are the ideas (policy) about merging the arm/ixp425/avila stuff : to 6-stable? I see some arm stuff gets merged, but it does not look : like everything? Is it just that people merge what they need? Merge as necessary has been the MO for us in the avila and at91rm9200 stuff. There's lots of people using these things, so a little care is in order. But not a lot... Warner From owner-freebsd-arm@FreeBSD.ORG Thu Mar 22 16:57:52 2007 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C88E316A405 for ; Thu, 22 Mar 2007 16:57:52 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 349AC13C4DD for ; Thu, 22 Mar 2007 16:57:52 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id l2MGrMKd016465; Thu, 22 Mar 2007 09:53:23 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 22 Mar 2007 10:53:30 -0600 (MDT) Message-Id: <20070322.105330.-1350499346.imp@bsdimp.com> To: sam@errno.com From: "M. Warner Losh" In-Reply-To: <46029AF5.20903@errno.com> References: <20070322080335.GA52745@zibbi.meraka.csir.co.za> <46029AF5.20903@errno.com> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 22 Mar 2007 10:53:24 -0600 (MDT) Cc: freebsd-arm@freebsd.org Subject: Re: progress on the adi pronghorn metro board 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: Thu, 22 Mar 2007 16:57:52 -0000 In message: <46029AF5.20903@errno.com> Sam Leffler writes: : John Hay wrote: : > Hi Guys, : > : > With this patch I am at the stage where both an Avila 2348-4 and the : > ADI Pronghorn Metro boot from the same kernel binary. The "main" stuff : > is working, ie. console, ethernet and mini-pci slots. The iic bus on : > the Avila is still working. The one for the Pronghorn is configured, : > but I must still write a driver for their max6652 temperature/voltage : > sensor before I will know if it is really working. : > : > The biggest difference between the 2 boards are in the 16 GPIO pins. : > I think there is only 1 pin that have the same function. :-/ : > : > So what I did was to create a structure and then have 2 instances of : > it, one with Avila values in it and one with Pronghorn values. Then : > early in the boot phase, the board type gets detected and a pointer : > gets set to the relevant structure. All the drivers then use this : > pointer to get the correct values. The efect is that most of the : > drivers needs no checks for the different boards. : > : > What I would like to know is, if this approach is acceptable? Should : > I use different files to put the stuff in? : > : > My code is not finished yet, but I thought that I would like to get : > some feedback. I still have to replace some of the numbers in the : > structure with defined values. I would also like to try and really : > probe the iic devices and not just assume that they are there. : : I'm not sure whether it makes sense to support different boards in a : single binary (variations on a board design yes). My experience is that : embedded applications are often cycle starved and giving up cycles for : flexibility like this is ok only for devel/bringup. I suspect : compile-time configuration is preferable. I've noticed that Linux actually does support one kernel for each 'type' of CPU. Their kernel can support multiple different AT91RM9200 boards at least. The boot loader tells the kernel the board type (assigned out of a central location, it seems), and then there's a table in the kernel that is keyed to this type. As each device in the system is initialized, the necessary data is used to for things like sd card write protect line, mii details, etc. There's no way to disable this. It has been very handy to have one kernel or the different boards I'm using here at work as well. Or it was until I broke it with a couple of TSC specific configuration things for our board... I've also noticed that many people just download a prebuilt linux kernel and/or flash image to try on their boards. At least judging from the traffic on the linux lists, this is a highly useful feature. Warner From owner-freebsd-arm@FreeBSD.ORG Thu Mar 22 17:01:18 2007 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4F19616A403 for ; Thu, 22 Mar 2007 17:01:18 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id E11DA13C46E for ; Thu, 22 Mar 2007 17:01:17 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id l2MGwmGt016736; Thu, 22 Mar 2007 09:58:49 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 22 Mar 2007 10:58:56 -0600 (MDT) Message-Id: <20070322.105856.-1337019401.imp@bsdimp.com> To: mlfbsd@ci0.org From: "M. Warner Losh" In-Reply-To: <20070322152708.GA79016@ci0.org> References: <20070322080335.GA52745@zibbi.meraka.csir.co.za> <46029AF5.20903@errno.com> <20070322152708.GA79016@ci0.org> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 22 Mar 2007 10:58:49 -0600 (MDT) Cc: freebsd-arm@freebsd.org Subject: Re: progress on the adi pronghorn metro board 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: Thu, 22 Mar 2007 17:01:18 -0000 In message: <20070322152708.GA79016@ci0.org> Olivier Houchard writes: : I think one config file per board is not too much to handle, and detecting : which board we're currently running can be difficult. On Linux, the boot loader does all of the detection (usually by being hard-wired for a board) and passes the result to the kernel... The one wrinkle that we have is that we often include extra devices via hints for things on, eg, the IIC bus. Multi-variant hint select isn't supported. I agree that auto detection would be hard. Maybe we should at least print a warning if we are compile for board type 43 and the loader says we're 25. It would be especially hard for different cores. All AT91RM9200 would be doable, if not a bit tedious in spots. All AT91* ARM 9 parts would be much harder, in part due to the multi-variant hint selection that would be necessary and in part due to some of the kinkier differences between the ARM910 core and the ARM926EJS core, not to mention the while issue of 'do I need this workaround for this bad hunk of silicon or not'. Warner From owner-freebsd-arm@FreeBSD.ORG Thu Mar 22 17:17:44 2007 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5554716A400 for ; Thu, 22 Mar 2007 17:17:44 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.freebsd.org (Postfix) with ESMTP id E213C13C44C for ; Thu, 22 Mar 2007 17:17:43 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 41FB833CAE; Thu, 22 Mar 2007 19:17:42 +0200 (SAST) Date: Thu, 22 Mar 2007 19:17:42 +0200 From: John Hay To: Olivier Houchard Message-ID: <20070322171742.GA76915@zibbi.meraka.csir.co.za> References: <20070322080335.GA52745@zibbi.meraka.csir.co.za> <46029AF5.20903@errno.com> <20070322152708.GA79016@ci0.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070322152708.GA79016@ci0.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-arm@freebsd.org Subject: Re: progress on the adi pronghorn metro board 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: Thu, 22 Mar 2007 17:17:44 -0000 On Thu, Mar 22, 2007 at 04:27:08PM +0100, Olivier Houchard wrote: > On Thu, Mar 22, 2007 at 08:04:21AM -0700, Sam Leffler wrote: > > John Hay wrote: > > > Hi Guys, > > > > > > With this patch I am at the stage where both an Avila 2348-4 and the > > > ADI Pronghorn Metro boot from the same kernel binary. The "main" stuff > > > is working, ie. console, ethernet and mini-pci slots. The iic bus on > > > the Avila is still working. The one for the Pronghorn is configured, > > > but I must still write a driver for their max6652 temperature/voltage > > > sensor before I will know if it is really working. > > > > > > The biggest difference between the 2 boards are in the 16 GPIO pins. > > > I think there is only 1 pin that have the same function. :-/ > > > > > > So what I did was to create a structure and then have 2 instances of > > > it, one with Avila values in it and one with Pronghorn values. Then > > > early in the boot phase, the board type gets detected and a pointer > > > gets set to the relevant structure. All the drivers then use this > > > pointer to get the correct values. The efect is that most of the > > > drivers needs no checks for the different boards. > > > > > > What I would like to know is, if this approach is acceptable? Should > > > I use different files to put the stuff in? > > > > > > My code is not finished yet, but I thought that I would like to get > > > some feedback. I still have to replace some of the numbers in the > > > structure with defined values. I would also like to try and really > > > probe the iic devices and not just assume that they are there. > > > > I'm not sure whether it makes sense to support different boards in a > > single binary (variations on a board design yes). My experience is that > > embedded applications are often cycle starved and giving up cycles for > > flexibility like this is ok only for devel/bringup. I suspect > > compile-time configuration is preferable. > > > > However if this flexibility is desirable it might be better to use > > ivar's hung off the nexus. > > > > Sam > > I tend to agree. > I think one config file per board is not too much to handle, and detecting > which board we're currently running can be difficult. > > Olivier I think my code changes are mostly in the attach routines or routines that are used by them, so I don't think it will have an influence on run-time speed. The biggest win for me would be that one could build a single distro that would be able to run any of the two boards. They are so similar, same cpu, 2 ethernets, 4 mini-pcis. But I guess in reality few groups/companies will source more than one board for a product. John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-arm@FreeBSD.ORG Thu Mar 22 17:43:07 2007 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4740116A401 for ; Thu, 22 Mar 2007 17:43:07 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.freebsd.org (Postfix) with ESMTP id D929A13C457 for ; Thu, 22 Mar 2007 17:43:06 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 7C68733C82; Thu, 22 Mar 2007 19:43:05 +0200 (SAST) Date: Thu, 22 Mar 2007 19:43:05 +0200 From: John Hay To: Olivier Houchard Message-ID: <20070322174305.GB76915@zibbi.meraka.csir.co.za> References: <20070322092609.GA58744@zibbi.meraka.csir.co.za> <46029B48.9000906@errno.com> <20070322153123.GB79016@ci0.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070322153123.GB79016@ci0.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-arm@freebsd.org Subject: Re: current to 6-stable merge plans/policy 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: Thu, 22 Mar 2007 17:43:07 -0000 On Thu, Mar 22, 2007 at 04:31:23PM +0100, Olivier Houchard wrote: > On Thu, Mar 22, 2007 at 08:05:44AM -0700, Sam Leffler wrote: > > John Hay wrote: > > > Hi Guys, > > > > > > What are the ideas (policy) about merging the arm/ixp425/avila stuff > > > to 6-stable? I see some arm stuff gets merged, but it does not look > > > like everything? Is it just that people merge what they need? > > > > > > Just trying to get a feel for it. Up to now I have used 6-stable on > > > our soekris and wrap boards, but we are probably going to use the > > > Avila boards a bit more, so I was wondering if I should use -current > > > or 6-stable on them. Up to now my Avila and ADI testing was done with > > > -current, but I'm not sure if that is a good idea for boxes that will > > > end up in rural areas far far away. Hmm. Not that I have seen a panic > > > on the Avila boards, but they have gone through a lot less testing up > > > to now. > > > > Not sure what's been missed. I see no reason not to MFC anything > > arm-related unless it breaks code compatibility (and even there it's > > unlikely there are 3rd party codes to worry about). > > > > Sam > > Hi John, > > Sorry for lack of answers, I really need to get back in the loop. > Avila works fine in RELENG_6. Maybe I should try it then. :-) > Generally, MFC'ing arm stuff should happen more > often. > On an unrelated note, your changes (I think, maybe I should've had a closer > look) seem to provoke an interrupt storm on ATA when there's no CF card > inserted, I seem to remember it may be why we did some ugly stuff. It might be because of a "bug" that I fixed. Roughly at line 190+: - /* interrupt is active low */ - GPIO_CONF_WRITE_4(sa, GPIO_TYPE_REG(AVILA_IDE_GPIN), - GPIO_CONF_READ_4(sa, GPIO_TYPE_REG(AVILA_IDE_GPIN) | - GPIO_TYPE(AVILA_IDE_GPIN, GPIO_TYPE_ACT_LOW))); + /* interrupt is active high */ + GPIO_CONF_WRITE_4(sa, GPIO_TYPE_REG(ide_gpin), + (GPIO_CONF_READ_4(sa, GPIO_TYPE_REG(ide_gpin)) & + ~GPIO_TYPE(ide_gpin, GPIO_TYPE_MASK)) | + GPIO_TYPE(ide_gpin, GPIO_TYPE_ACT_HIGH)); The old code had a bracket problem, so it actually read from a bogus address: GPIO_CONF_READ_4(sa, GPIO_TYPE_REG(AVILA_IDE_GPIN) | GPIO_TYPE(AVILA_IDE_GPIN, GPIO_TYPE_ACT_LOW)) which happened to be all ones, and wrote that to the interrupt config register, which caused all the interrupts in that register to be edge triggered on both edges. So when I fixed it, I also changed it to be active high, because all the docs I could find have the cf interrupt as active high. Maybe the line floats high if nothing is connected to it? The Pronghorn docs says that they have GPIO2 and GPIO3 connected to CD1 and CD2 of the CF header, so you can read GPIO2 and GPIO3 and if both are low, you can assume a CF installed, otherwise there is no CF. So on the Pronghorn board one could do that test in the probe routine and fail there already. Maybe one can only configure the interrupt if there is an CF installed? Or maybe use another interrupt edge? John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-arm@FreeBSD.ORG Thu Mar 22 22:29:19 2007 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 03C4916A40D for ; Thu, 22 Mar 2007 22:29:19 +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 70FE213C4EA for ; Thu, 22 Mar 2007 22:29:18 +0000 (UTC) (envelope-from sam@errno.com) Received: from [10.0.0.248] (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id l2MMT6BW030154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Mar 2007 15:29:07 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <46030332.30007@errno.com> Date: Thu, 22 Mar 2007 15:29:06 -0700 From: Sam Leffler User-Agent: Thunderbird 1.5.0.9 (X11/20070208) MIME-Version: 1.0 To: John Hay References: <20070322080335.GA52745@zibbi.meraka.csir.co.za> <46029AF5.20903@errno.com> <20070322152708.GA79016@ci0.org> <20070322171742.GA76915@zibbi.meraka.csir.co.za> In-Reply-To: <20070322171742.GA76915@zibbi.meraka.csir.co.za> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: progress on the adi pronghorn metro board 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: Thu, 22 Mar 2007 22:29:19 -0000 John Hay wrote: > On Thu, Mar 22, 2007 at 04:27:08PM +0100, Olivier Houchard wrote: >> On Thu, Mar 22, 2007 at 08:04:21AM -0700, Sam Leffler wrote: >>> John Hay wrote: >>>> Hi Guys, >>>> >>>> With this patch I am at the stage where both an Avila 2348-4 and the >>>> ADI Pronghorn Metro boot from the same kernel binary. The "main" stuff >>>> is working, ie. console, ethernet and mini-pci slots. The iic bus on >>>> the Avila is still working. The one for the Pronghorn is configured, >>>> but I must still write a driver for their max6652 temperature/voltage >>>> sensor before I will know if it is really working. >>>> >>>> The biggest difference between the 2 boards are in the 16 GPIO pins. >>>> I think there is only 1 pin that have the same function. :-/ >>>> >>>> So what I did was to create a structure and then have 2 instances of >>>> it, one with Avila values in it and one with Pronghorn values. Then >>>> early in the boot phase, the board type gets detected and a pointer >>>> gets set to the relevant structure. All the drivers then use this >>>> pointer to get the correct values. The efect is that most of the >>>> drivers needs no checks for the different boards. >>>> >>>> What I would like to know is, if this approach is acceptable? Should >>>> I use different files to put the stuff in? >>>> >>>> My code is not finished yet, but I thought that I would like to get >>>> some feedback. I still have to replace some of the numbers in the >>>> structure with defined values. I would also like to try and really >>>> probe the iic devices and not just assume that they are there. >>> I'm not sure whether it makes sense to support different boards in a >>> single binary (variations on a board design yes). My experience is that >>> embedded applications are often cycle starved and giving up cycles for >>> flexibility like this is ok only for devel/bringup. I suspect >>> compile-time configuration is preferable. >>> >>> However if this flexibility is desirable it might be better to use >>> ivar's hung off the nexus. >>> >>> Sam >> I tend to agree. >> I think one config file per board is not too much to handle, and detecting >> which board we're currently running can be difficult. >> >> Olivier > > I think my code changes are mostly in the attach routines or routines that > are used by them, so I don't think it will have an influence on run-time > speed. The biggest win for me would be that one could build a single > distro that would be able to run any of the two boards. They are so > similar, same cpu, 2 ethernets, 4 mini-pcis. But I guess in reality few > groups/companies will source more than one board for a product. I thought I saw you change some #define's to variable refs in code the fiddled with the gpio pins for things like pci interrupt handling. If no changes affect the fast paths then I'm fine with adding a board descriptor and using it instead of hardwired values--but I still think you might be able to do this more cleanly by hanging the data off the nexus instead of adding a global variable. Sam From owner-freebsd-arm@FreeBSD.ORG Fri Mar 23 06:18:09 2007 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 726B316A402 for ; Fri, 23 Mar 2007 06:18:09 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.freebsd.org (Postfix) with ESMTP id AA77B13C44C for ; Fri, 23 Mar 2007 06:18:08 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 981A533C82; Fri, 23 Mar 2007 08:18:06 +0200 (SAST) Date: Fri, 23 Mar 2007 08:18:06 +0200 From: John Hay To: Sam Leffler Message-ID: <20070323061806.GA15599@zibbi.meraka.csir.co.za> References: <20070322080335.GA52745@zibbi.meraka.csir.co.za> <46029AF5.20903@errno.com> <20070322152708.GA79016@ci0.org> <20070322171742.GA76915@zibbi.meraka.csir.co.za> <46030332.30007@errno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46030332.30007@errno.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-arm@freebsd.org Subject: Re: progress on the adi pronghorn metro board 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, 23 Mar 2007 06:18:09 -0000 On Thu, Mar 22, 2007 at 03:29:06PM -0700, Sam Leffler wrote: > John Hay wrote: > > On Thu, Mar 22, 2007 at 04:27:08PM +0100, Olivier Houchard wrote: > >> On Thu, Mar 22, 2007 at 08:04:21AM -0700, Sam Leffler wrote: > >>> John Hay wrote: > >>>> Hi Guys, > >>>> > >>>> With this patch I am at the stage where both an Avila 2348-4 and the > >>>> ADI Pronghorn Metro boot from the same kernel binary. The "main" stuff > >>>> is working, ie. console, ethernet and mini-pci slots. The iic bus on > >>>> the Avila is still working. The one for the Pronghorn is configured, > >>>> but I must still write a driver for their max6652 temperature/voltage > >>>> sensor before I will know if it is really working. > >>>> > >>>> The biggest difference between the 2 boards are in the 16 GPIO pins. > >>>> I think there is only 1 pin that have the same function. :-/ > >>>> > >>>> So what I did was to create a structure and then have 2 instances of > >>>> it, one with Avila values in it and one with Pronghorn values. Then > >>>> early in the boot phase, the board type gets detected and a pointer > >>>> gets set to the relevant structure. All the drivers then use this > >>>> pointer to get the correct values. The efect is that most of the > >>>> drivers needs no checks for the different boards. > >>>> > >>>> What I would like to know is, if this approach is acceptable? Should > >>>> I use different files to put the stuff in? > >>>> > >>>> My code is not finished yet, but I thought that I would like to get > >>>> some feedback. I still have to replace some of the numbers in the > >>>> structure with defined values. I would also like to try and really > >>>> probe the iic devices and not just assume that they are there. > >>> I'm not sure whether it makes sense to support different boards in a > >>> single binary (variations on a board design yes). My experience is that > >>> embedded applications are often cycle starved and giving up cycles for > >>> flexibility like this is ok only for devel/bringup. I suspect > >>> compile-time configuration is preferable. > >>> > >>> However if this flexibility is desirable it might be better to use > >>> ivar's hung off the nexus. > >>> > >>> Sam > >> I tend to agree. > >> I think one config file per board is not too much to handle, and detecting > >> which board we're currently running can be difficult. > >> > >> Olivier > > > > I think my code changes are mostly in the attach routines or routines that > > are used by them, so I don't think it will have an influence on run-time > > speed. The biggest win for me would be that one could build a single > > distro that would be able to run any of the two boards. They are so > > similar, same cpu, 2 ethernets, 4 mini-pcis. But I guess in reality few > > groups/companies will source more than one board for a product. > > I thought I saw you change some #define's to variable refs in code the > fiddled with the gpio pins for things like pci interrupt handling. If I think the only pci code that patch touch are these functions: ixdp425_pci.c:ixp425_md_attach() ixdp425_pci.c:ixp425_md_route_interrupt() ixp425.c:ixp425_alloc_resource() ixp425.c:ixp425_setup_intr() ixp425_pci.c:ixppcib_conf_setup() As far as I know none of them are in the fast path? Where I do have changes in the fast path is in the iic code. I changed all the GPIO_I2C_SDA_BIT and GPIO_I2C_SCL_BIT to sc->sc_sda_bit and sc->sc_scl_bit. I doubt if that will make a difference in the real world though. > no changes affect the fast paths then I'm fine with adding a board > descriptor and using it instead of hardwired values--but I still think > you might be able to do this more cleanly by hanging the data off the > nexus instead of adding a global variable. I'll have a look at ivars from the nexus. I will have to check if the nexus is already alive by the time the console is initialized. The boards use different uarts for their console. Interesting that Warner's description of how linux does it, sounds a lot like my try. Except that I do not pass the board type in from the loader. John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-arm@FreeBSD.ORG Fri Mar 23 10:57:06 2007 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A2C2D16A403 for ; Fri, 23 Mar 2007 10:57:06 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.freebsd.org (Postfix) with ESMTP id 7C21913C487 for ; Fri, 23 Mar 2007 10:57:05 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 54B3E33C8B; Fri, 23 Mar 2007 12:57:02 +0200 (SAST) Date: Fri, 23 Mar 2007 12:57:02 +0200 From: John Hay To: Olivier Houchard Message-ID: <20070323105702.GA30372@zibbi.meraka.csir.co.za> References: <20070322092609.GA58744@zibbi.meraka.csir.co.za> <46029B48.9000906@errno.com> <20070322153123.GB79016@ci0.org> <20070322174305.GB76915@zibbi.meraka.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070322174305.GB76915@zibbi.meraka.csir.co.za> User-Agent: Mutt/1.4.2.1i Cc: freebsd-arm@freebsd.org Subject: Re: current to 6-stable merge plans/policy 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, 23 Mar 2007 10:57:06 -0000 On Thu, Mar 22, 2007 at 07:43:05PM +0200, John Hay wrote: > On Thu, Mar 22, 2007 at 04:31:23PM +0100, Olivier Houchard wrote: > > On Thu, Mar 22, 2007 at 08:05:44AM -0700, Sam Leffler wrote: > > > John Hay wrote: > > > > Hi Guys, > > > > > > > > What are the ideas (policy) about merging the arm/ixp425/avila stuff > > > > to 6-stable? I see some arm stuff gets merged, but it does not look > > > > like everything? Is it just that people merge what they need? > > > > > > > > Just trying to get a feel for it. Up to now I have used 6-stable on > > > > our soekris and wrap boards, but we are probably going to use the > > > > Avila boards a bit more, so I was wondering if I should use -current > > > > or 6-stable on them. Up to now my Avila and ADI testing was done with > > > > -current, but I'm not sure if that is a good idea for boxes that will > > > > end up in rural areas far far away. Hmm. Not that I have seen a panic > > > > on the Avila boards, but they have gone through a lot less testing up > > > > to now. > > > > > > Not sure what's been missed. I see no reason not to MFC anything > > > arm-related unless it breaks code compatibility (and even there it's > > > unlikely there are 3rd party codes to worry about). > > > > > > Sam > > > > Hi John, > > > > Sorry for lack of answers, I really need to get back in the loop. > > Avila works fine in RELENG_6. > > Maybe I should try it then. :-) Well I cross-compiled 6-stable, installed it on an nfs server and booted an Avila from it. That worked. So then I wanted to compile some ports on it. For a start I wanted olsrd. That needed a lot of things amongst other libiconv. That died with a compiler error like this: ################## /bin/sh /usr/local/bin/libtool --mode=compile cc -I. -I. -I../include -I./../include -O2 -fno-strict-aliasing -pipe -mbig-endian -march=armv5te -D__XSCALE__ -DLIBDIR=\"/usr/local/lib\" -DENABLE_RELOCATABLE=1 -DIN_LIBRARY -DINSTALLDIR=\"/usr/local/lib\" -DNO_XMALLOC -Dset_relocation_prefix=libiconv_set_relocation_prefix -Drelocate=libiconv_relocate -DHAVE_CONFIG_H -c ./iconv.c mkdir .libs cc -I. -I. -I../include -I./../include -O2 -fno-strict-aliasing -pipe -mbig-endian -march=armv5te -D__XSCALE__ -DLIBDIR=\"/usr/local/lib\" -DENABLE_RELOCATABLE=1 -DIN_LIBRARY -DINSTALLDIR=\"/usr/local/lib\" -DNO_XMALLOC -Dset_relocation_prefix=libiconv_set_relocation_prefix -Drelocate=libiconv_relocate -DHAVE_CONFIG_H -c ./iconv.c -fPIC -DPIC -o .libs/iconv.o In file included from ./cns11643.h:38, from ./converters.h:203, from ./iconv.c:67: ./cns11643_inv.h:13889: warning: useless keyword or type name in empty declaration ./cns11643_inv.h:13889: warning: empty declaration In file included from ./converters.h:204, from ./iconv.c:67: ./big5.h:4104: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop in /usr/ports/converters/libiconv/work/libiconv-1.9.2/lib. *** Error code 1 Stop in /usr/ports/converters/libiconv/work/libiconv-1.9.2. *** Error code 1 Stop in /usr/ports/converters/libiconv. ################## Any ideas? I did compile it on -current Avila a few days ago. Is there a reason that fdisk is not build for the arm on 6-stable? John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-arm@FreeBSD.ORG Fri Mar 23 23:13:34 2007 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A3F8C16A401 for ; Fri, 23 Mar 2007 23:13:34 +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 6071213C43E for ; Fri, 23 Mar 2007 23:13:34 +0000 (UTC) (envelope-from sam@errno.com) Received: from [10.0.0.248] (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id l2NNDTfo040668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Mar 2007 16:13:30 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <46045F19.2050308@errno.com> Date: Fri, 23 Mar 2007 16:13:29 -0700 From: Sam Leffler User-Agent: Thunderbird 1.5.0.9 (X11/20070208) MIME-Version: 1.0 To: John Hay References: <20070322080335.GA52745@zibbi.meraka.csir.co.za> <46029AF5.20903@errno.com> <20070322152708.GA79016@ci0.org> <20070322171742.GA76915@zibbi.meraka.csir.co.za> <46030332.30007@errno.com> <20070323061806.GA15599@zibbi.meraka.csir.co.za> In-Reply-To: <20070323061806.GA15599@zibbi.meraka.csir.co.za> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: progress on the adi pronghorn metro board 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, 23 Mar 2007 23:13:34 -0000 John Hay wrote: > On Thu, Mar 22, 2007 at 03:29:06PM -0700, Sam Leffler wrote: >> John Hay wrote: >>> On Thu, Mar 22, 2007 at 04:27:08PM +0100, Olivier Houchard wrote: >>>> On Thu, Mar 22, 2007 at 08:04:21AM -0700, Sam Leffler wrote: >>>>> John Hay wrote: >>>>>> Hi Guys, >>>>>> >>>>>> With this patch I am at the stage where both an Avila 2348-4 and the >>>>>> ADI Pronghorn Metro boot from the same kernel binary. The "main" stuff >>>>>> is working, ie. console, ethernet and mini-pci slots. The iic bus on >>>>>> the Avila is still working. The one for the Pronghorn is configured, >>>>>> but I must still write a driver for their max6652 temperature/voltage >>>>>> sensor before I will know if it is really working. >>>>>> >>>>>> The biggest difference between the 2 boards are in the 16 GPIO pins. >>>>>> I think there is only 1 pin that have the same function. :-/ >>>>>> >>>>>> So what I did was to create a structure and then have 2 instances of >>>>>> it, one with Avila values in it and one with Pronghorn values. Then >>>>>> early in the boot phase, the board type gets detected and a pointer >>>>>> gets set to the relevant structure. All the drivers then use this >>>>>> pointer to get the correct values. The efect is that most of the >>>>>> drivers needs no checks for the different boards. >>>>>> >>>>>> What I would like to know is, if this approach is acceptable? Should >>>>>> I use different files to put the stuff in? >>>>>> >>>>>> My code is not finished yet, but I thought that I would like to get >>>>>> some feedback. I still have to replace some of the numbers in the >>>>>> structure with defined values. I would also like to try and really >>>>>> probe the iic devices and not just assume that they are there. >>>>> I'm not sure whether it makes sense to support different boards in a >>>>> single binary (variations on a board design yes). My experience is that >>>>> embedded applications are often cycle starved and giving up cycles for >>>>> flexibility like this is ok only for devel/bringup. I suspect >>>>> compile-time configuration is preferable. >>>>> >>>>> However if this flexibility is desirable it might be better to use >>>>> ivar's hung off the nexus. >>>>> >>>>> Sam >>>> I tend to agree. >>>> I think one config file per board is not too much to handle, and detecting >>>> which board we're currently running can be difficult. >>>> >>>> Olivier >>> I think my code changes are mostly in the attach routines or routines that >>> are used by them, so I don't think it will have an influence on run-time >>> speed. The biggest win for me would be that one could build a single >>> distro that would be able to run any of the two boards. They are so >>> similar, same cpu, 2 ethernets, 4 mini-pcis. But I guess in reality few >>> groups/companies will source more than one board for a product. >> I thought I saw you change some #define's to variable refs in code the >> fiddled with the gpio pins for things like pci interrupt handling. If > > I think the only pci code that patch touch are these functions: > > ixdp425_pci.c:ixp425_md_attach() > ixdp425_pci.c:ixp425_md_route_interrupt() > ixp425.c:ixp425_alloc_resource() > ixp425.c:ixp425_setup_intr() > ixp425_pci.c:ixppcib_conf_setup() > > As far as I know none of them are in the fast path? Sounds good; consider me happy. > > Where I do have changes in the fast path is in the iic code. I changed > all the GPIO_I2C_SDA_BIT and GPIO_I2C_SCL_BIT to sc->sc_sda_bit and > sc->sc_scl_bit. I doubt if that will make a difference in the real > world though. I agree that spending some cycles in the i2c path is ok. > >> no changes affect the fast paths then I'm fine with adding a board >> descriptor and using it instead of hardwired values--but I still think >> you might be able to do this more cleanly by hanging the data off the >> nexus instead of adding a global variable. > > I'll have a look at ivars from the nexus. I will have to check if the > nexus is already alive by the time the console is initialized. The > boards use different uarts for their console. > > Interesting that Warner's description of how linux does it, sounds a > lot like my try. Except that I do not pass the board type in from the > loader. The board description for linux is more extensive. If we continue down this path of parameterizing board params ours will grow too. Sam From owner-freebsd-arm@FreeBSD.ORG Fri Mar 23 23:15:57 2007 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 174E816A400 for ; Fri, 23 Mar 2007 23:15:57 +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 CCA6D13C45D for ; Fri, 23 Mar 2007 23:15:56 +0000 (UTC) (envelope-from sam@errno.com) Received: from [10.0.0.248] (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id l2NNFrt9040698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Mar 2007 16:15:53 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <46045FA9.9020905@errno.com> Date: Fri, 23 Mar 2007 16:15:53 -0700 From: Sam Leffler User-Agent: Thunderbird 1.5.0.9 (X11/20070208) MIME-Version: 1.0 To: John Hay References: <20070322092609.GA58744@zibbi.meraka.csir.co.za> <46029B48.9000906@errno.com> <20070322153123.GB79016@ci0.org> <20070322174305.GB76915@zibbi.meraka.csir.co.za> <20070323105702.GA30372@zibbi.meraka.csir.co.za> In-Reply-To: <20070323105702.GA30372@zibbi.meraka.csir.co.za> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: current to 6-stable merge plans/policy 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, 23 Mar 2007 23:15:57 -0000 John Hay wrote: > On Thu, Mar 22, 2007 at 07:43:05PM +0200, John Hay wrote: >> On Thu, Mar 22, 2007 at 04:31:23PM +0100, Olivier Houchard wrote: >>> On Thu, Mar 22, 2007 at 08:05:44AM -0700, Sam Leffler wrote: >>>> John Hay wrote: >>>>> Hi Guys, >>>>> >>>>> What are the ideas (policy) about merging the arm/ixp425/avila stuff >>>>> to 6-stable? I see some arm stuff gets merged, but it does not look >>>>> like everything? Is it just that people merge what they need? >>>>> >>>>> Just trying to get a feel for it. Up to now I have used 6-stable on >>>>> our soekris and wrap boards, but we are probably going to use the >>>>> Avila boards a bit more, so I was wondering if I should use -current >>>>> or 6-stable on them. Up to now my Avila and ADI testing was done with >>>>> -current, but I'm not sure if that is a good idea for boxes that will >>>>> end up in rural areas far far away. Hmm. Not that I have seen a panic >>>>> on the Avila boards, but they have gone through a lot less testing up >>>>> to now. >>>> Not sure what's been missed. I see no reason not to MFC anything >>>> arm-related unless it breaks code compatibility (and even there it's >>>> unlikely there are 3rd party codes to worry about). >>>> >>>> Sam >>> Hi John, >>> >>> Sorry for lack of answers, I really need to get back in the loop. >>> Avila works fine in RELENG_6. >> Maybe I should try it then. :-) > > Well I cross-compiled 6-stable, installed it on an nfs server and booted > an Avila from it. That worked. So then I wanted to compile some ports on > it. For a start I wanted olsrd. That needed a lot of things amongst > other libiconv. That died with a compiler error like this: > > ################## > /bin/sh /usr/local/bin/libtool --mode=compile cc -I. -I. -I../include -I./../include -O2 -fno-strict-aliasing -pipe -mbig-endian -march=armv5te -D__XSCALE__ -DLIBDIR=\"/usr/local/lib\" -DENABLE_RELOCATABLE=1 -DIN_LIBRARY -DINSTALLDIR=\"/usr/local/lib\" -DNO_XMALLOC -Dset_relocation_prefix=libiconv_set_relocation_prefix -Drelocate=libiconv_relocate -DHAVE_CONFIG_H -c ./iconv.c > mkdir .libs > cc -I. -I. -I../include -I./../include -O2 -fno-strict-aliasing -pipe -mbig-endian -march=armv5te -D__XSCALE__ -DLIBDIR=\"/usr/local/lib\" -DENABLE_RELOCATABLE=1 -DIN_LIBRARY -DINSTALLDIR=\"/usr/local/lib\" -DNO_XMALLOC -Dset_relocation_prefix=libiconv_set_relocation_prefix -Drelocate=libiconv_relocate -DHAVE_CONFIG_H -c ./iconv.c -fPIC -DPIC -o .libs/iconv.o > In file included from ./cns11643.h:38, > from ./converters.h:203, > from ./iconv.c:67: > ./cns11643_inv.h:13889: warning: useless keyword or type name in empty declaration > ./cns11643_inv.h:13889: warning: empty declaration > In file included from ./converters.h:204, > from ./iconv.c:67: > ./big5.h:4104: internal compiler error: Segmentation fault: 11 > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > *** Error code 1 > > Stop in /usr/ports/converters/libiconv/work/libiconv-1.9.2/lib. > *** Error code 1 > > Stop in /usr/ports/converters/libiconv/work/libiconv-1.9.2. > *** Error code 1 > > Stop in /usr/ports/converters/libiconv. > ################## > > Any ideas? I did compile it on -current Avila a few days ago. I believe there was an arm/xscale-specific vm bug fixed not too long ago in HEAD. Might not have been MFC'd. > > Is there a reason that fdisk is not build for the arm on 6-stable? It wasn't needed originally so was just removed instead of dealing with portability problems. Sam