From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11786 invoked by alias); 14 Jun 2006 21:09:54 -0000 Received: (qmail 11778 invoked by uid 22791); 14 Jun 2006 21:09:53 -0000 X-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_20,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; Wed, 14 Jun 2006 21:09:50 +0000 Received: from lunn by londo.lunn.ch with local (Exim 3.36 #1 (Debian)) id 1FqccQ-0004mR-00; Wed, 14 Jun 2006 23:09:42 +0200 Date: Wed, 14 Jun 2006 21:09:00 -0000 To: "C. Adam Lamb" Cc: ecos-devel@sourceware.org Subject: Re: Intention to Port eCos to STR9 Message-ID: <20060614210942.GA15848@lunn.ch> References: <00c001c68fef$94598bd0$63000a0a@corp.ilxlightwave.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00c001c68fef$94598bd0$63000a0a@corp.ilxlightwave.com> 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-06/txt/msg00018.txt.bz2 On Wed, Jun 14, 2006 at 02:17:37PM -0600, C. Adam Lamb wrote: > Hi Gang, > > I?m currently looking into porting eCos to the STR912 processor.? The > processor is on the bleeding edge (it just came out), so I?m still waiting > for my eval board. > > My first goal in this message is to both let everyone know that I should be > starting to work on this soon and see if anyone else might be working on > this as well? > > Second goal is to have someone with some eCos experience make sure my > porting approach isn?t too far off.? O.K. First tip. Try not to have tunnel vision on the STR912. Try taking a look at all the STR7 and STR9 devices. Work out what is common and what is different. Try to make your port as generic as possible. So if for example the UART is the same for all devices, just write a STR UART driver, not a STR912 UART driver. Same goes for SPI, FLASH controller, etc. If a peripheral for the STR9xx is different from the STR7xx write an STR9xx driver. And lastly, if the STR912 has something unque, write an STR912 unique driver. Same goes for the HAL. Try to split it up into a varient HAL for STR9xx and a specific HAL STR912. Maybe it is even possible to have a three layer HAL, with STR at the top. The different between the STR7 and STR9 will be the MMU setup. So maybe it is possible to put the MMU code into the STR9xx HAL package and have most of the code in the STR HAL package. The advantage of doing it like this is it makes it easier for others to do ports to other members of the STR family building on what you have done. I made a mistake here with the AT91SAM family. I did a port to the AT91SAM7S and later found out that the AT91SAM7X is 99% the same. I then ended up with a naming mess since the AT91SAM7S package now also supports the AT91SAM7X devices. And i guess sometime in the future the AT91SAM9 is going to be supported by the AT91SAM7S package. Ugly. > I will be using the all of the GNU tools for building and debugging.? That is normal. Using anything else for compiling is virtually impossible. You do have more flexibility with debugging, but i still recommend gdb. You can add a GUI on top if you like, eg Insight, DDD, etc. > I intend to purchase either Signum System?s JTAG Jet with Trace or the PEEDI > JTAG Emulator if I can?t get my company to pony up for the slightly more > expensive device from Signum.? Both of those devices claim to be compatible > with the GNU debuggers.? Anyone with experience with either of those > devices?? I've had good experiance with PEEDI with the AT91SAM7S development board. You need an up to date version of gdb. The version on the eCos website as part of the ARM toolchain is too old for breakpoints to work properly. Andrew