Re: [ECOS] Notification of changes required for CPU support

[Gary Thomas <gary@mlbassoc.com>]

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