This is the mail archive of the
ecos-devel@sources.redhat.com
mailing list for the eCos project.
RE: Porting question
- From: Gary Parnes <GaryP at logicpd dot com>
- To: 'Andrew Lunn' <andrew at lunn dot ch>
- Cc: "'ecos-devel at sources dot redhat dot com'" <ecos-devel at sources dot redhat dot com>
- Date: Tue, 2 Dec 2003 10:52:24 -0600
- Subject: RE: Porting question
> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@lunn.ch]
> Sent: Tuesday, December 02, 2003 10:33 AM
> To: Gary Parnes
> Cc: 'ecos-devel@sources.redhat.com'
> Subject: Re: Porting question
>
>
> On Tue, Dec 02, 2003 at 09:42:51AM -0600, Gary Parnes wrote:
> >
> > Hello, I am starting a porting effort to get eCos running
> on one of our
> > development platform kits:
> >
> > http://www.logicpd.com/eps/sharp/devkits/sdk/default.php
> >
> > using a Sharp LH-75401 core:
> >
> > http://www.sharpsma.com/sma/products/mcu_soc/LH75401_splash.htm
> >
> >
> > I want to make sure that I'm designing the package(s)
> properly, so I'm
> > looking for a bit of feedback here. It looks like some of
> the HAL efforts
> > ended up combining the CPU and the board support package
> into one ball of
> > wax (.../hal/arm/ebsa285, for instance).
>
> Out of interest, what do you see in there which you think should be
> somewhere else?
It seems to me that the header file hal_ebsa285.h contains a rich amount of
information specific to the SA-110 processor, not the EBSA285 platform.
Couldn't we make the case that much of the header information -- and
possibly some code, such as hal_clock_initialize() & hal_clock_reset() --
should be in the directory ../hal/arm/sa110/var, with the ebsa285
platform-specific stuff (e.g. initialization of the 21285) residing in
../hal/arm/sa110/ebsa285.
>
> Seeing as how the 75401 has a rich
> > set of on-chip features, I get the feeling that, if I
> really want to do this
> > right, I should be breaking things up into a processor
> layer and a board
> > support layer. For example:
> >
> > ../hal/arm/sh75401/common/v2_0/... (which would contain
> headers and generic
> > code for the LH-75401)
> > ../hal/arm/sh75401/zoomdevkit/v2_0/... (which would contain
> headers and code
> > specific to our Zoom DevKit offering)
>
> I would not put them under the hal. Most of the code should be under
> dev. eg:
> uart driver will probably go im dev/serial/sh/lh75401
> watchdog driver will probably go in dev/watchdog/sh/lh75401
> can driver will probably go in dev/can/sh/lh75401
> touch panel driver will probably go in dev/touch/lh75401
I agree: the drivers for most of the core peripherals (timers and UART's
being the most notable exceptions) should be elsewhere. But, the header that
describes the memory-mapped locations of the various registers on the
lh75401 should still be put somewhere in the HAL hierarchy, correct? And
then there's the system timer init & reset code, which resides in the HAL
hierarchy by design...
> You should also look at the other sh2 drivers. Sharp may have reused
> there cores so a driver from another Sharp device may work with this
> one.
Right-o.
--Gary Parnes