From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18402 invoked by alias); 12 May 2006 12:09:49 -0000 Received: (qmail 18393 invoked by uid 22791); 12 May 2006 12:09:48 -0000 X-Spam-Status: No, hits=-3.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from londo.lunn.ch (HELO londo.lunn.ch) (80.238.139.98) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 12 May 2006 12:09:45 +0000 Received: from lunn by londo.lunn.ch with local (Exim 3.36 #1 (Debian)) id 1FeWSi-0006E4-00; Fri, 12 May 2006 14:09:40 +0200 Date: Fri, 12 May 2006 12:09:00 -0000 To: John Eigelaar Cc: ecos-devel@sources.redhat.com Subject: Re: AT91SAM7X Port Message-ID: <20060512120940.GC23687@lunn.ch> References: <20060512110441.GA23687@lunn.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11+cvs20060403 From: Andrew Lunn X-IsSubscribed: yes Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2006-05/txt/msg00013.txt.bz2 On Fri, May 12, 2006 at 02:05:13PM +0200, John Eigelaar wrote: > On Fri, 12 May 2006 13:04:41 +0200, Andrew Lunn wrote: > > > > > Not yet. There is a strong chance that i will need such a port next > > month. If this happens i will be tasked by my employer to make the > > port. So if you are doing a port i suggest we work together. Which of > > the X peripherals are you interested in? I need an Ethernet driver > > which i can connect to lwip. > > SPI, UART, EMAC with lwip, probably the same as you do ... I don`t need SPI. However the existing AT91 SPI driver compiles cleanly with the SAM7S. So it just needs testing... > > What may be more of a problem is the two GPIO controllers. The > > existing code, var HAL, SPI, USART etc, assumes that the pins they use > > are on GPIO port A. If this is not true with the X it might get > > messy. We need to compare the S and X and see what is connected where > > with respect to the GPIO controllers. > > This is actually a problem with the existing S port as well, as the > alternative peripheral pinouts is not really addressed. This might be a > good oppurtunity to devise a proper solution for this if we are forced to. If i remember correctly, i did add them to var_io.h. However nothing actually uses them. Andrew