This is the mail archive of the ecos-devel@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]