From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18348 invoked by alias); 29 Aug 2007 19:00:36 -0000 Received: (qmail 18324 invoked by uid 22791); 29 Aug 2007 19:00:33 -0000 X-Spam-Check-By: sourceware.org Received: from 204-133-123-27.dia.static.slbbi.com (HELO mail.chez-thomas.org) (204.133.123.27) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 29 Aug 2007 19:00:29 +0000 Received: by mail.chez-thomas.org (Postfix, from userid 999) id 5124C19501FA; Wed, 29 Aug 2007 13:00:27 -0600 (MDT) Received: from [192.168.1.101] (hermes_local [192.168.1.101]) by mail.chez-thomas.org (Postfix) with ESMTP id C90C519500C0; Wed, 29 Aug 2007 13:00:19 -0600 (MDT) Message-ID: <46D5C242.3010405@mlbassoc.com> Date: Wed, 29 Aug 2007 19:00:00 -0000 From: Gary Thomas User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: Scott Moore CC: ecos-discuss@ecos.sourceware.org, Steve Gaskill References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] Notification of changes required for CPU support X-SW-Source: 2007-08/txt/msg00163.txt.bz2 Scott Moore wrote: > > Although we are not ready yet to commit changes, I thought it > would be good if we would give an overview of changes required > to support a new processor/processor board combination under > ecos, and get feedback on what the form of the changes should > be before putting that back to the ecos project. > > The lpc2xxx series from NXP (formerly Phillips) has proceeded > through the lpc21xx and lpc22xx series to the current lpc23xx > series. The board we are working with is the MCB2300 available > from Keil. The current support under ecos is the MCB2100 board. > > Unfortunately, unlike what the lpc2xxx directory tree under > ecos implies, the lpc23xx series processors aren't in fact > compatible with the lpc21xx and lpc22xx series. The method > of handling interrupts changed. The lpc2xxx series is downward > compatable with the ARM convention of a single IRQ vector at > location $28 in that the vector automatically selected by the > processor is placed in a register, which the instruction at > $28 can move to the PC, thus accomplishing a vectored > interrupt. This is downward compatible with ARM general > conventions, because if the code ignores the automatic vectoring > and simply proceeds to the the IRQ handler code from $28, > the code will function, but simply not benefit from the > automatic vectoring. > > The lpc2xxx code in ecos ignores the automatic vectoring, but > uses the lpc2xxx autovectoring hardware to automatically > determine which logical vector (from 0-15) is being serviced. > This is then passed to the IRQ service code when it reaches > the point it needs to find the vector number, so that it can > look it up in the hal_interrupt_data and hal_interrupt_handlers > tables. > > Since the lpc2xxx/var code depends on the hardware vectoring > in this way, and also because the number of interrupts servicable > by the CPU increase from 16 to 32, and because of other minor > ways the interrupt handling changes, the lpc2xx/var code must > change for the lpc23xx processors. > > Here is a list of the files that required changes: > > ../hal/arm/lpc2xxx/var/current/src/lpc2xxx_misc.c > ../hal/arm/lpc2xxx/var/current/include/var_io.h > > This gets us going, but clearly creates a conflict in ecos, > since the lpc2xxx tree no longer supports all processors in the > series. > > I'm open to suggestions about what to do about that before trying > to put it back to ecos. The possibilities are: > > 1. Break the lpc2xxx tree into lpc21xx_lpc22xx and lpc23xx trees. > > 2. Have the lpc2xxx code automatically configure per the processor. > > Other? > > Right now, I am just hacking up the lpc2xxx series to get our stuff > running without regard for lpc21xx and lpc22xx backwards compatibility. > > Hey, blame Phillips for creating an incompatibility in their own > series. How similar are the processor(s), apart from the interrupt handling difference you've pointed out? My preference would be to keep the tree as it is and add a CDL option which describes the processor. The code you've pointed to can then have conditional support based on this CDL. Precedent for this would be the PowerPC (e.g. not all 8xx processors are the same, but they are close enough to have a common HAL) and SH (again a myriad of variants) Have a look at how those HALs handle this. Once you have something that works, propose it on ecos-patches and we can discuss making these changes to the common CVS. -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss