This is the mail archive of the ecos-discuss@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: Re: OpenRISC eCos package


Thanks for the comments. They kind of vindicate what I initially thought,
i.e. there is more than one way to do it and, perhaps more importantly,
there doesn't seem to be any particular way of doing it.

The conclusion I have come to so far is that the 'variant way' would produce
far too many options and would thus become unwieldy, although this would
appear to be the 'purist' way of doing it. The way Jifl suggests seems to
make the most sense for now. Bart's option (c) is the utopian way.

What I have noticed is that the HALs do seem to be succinctly different for
the different processors therefore I was wondering if any in particular is
considered to be a 'model' template from which to work.

For now, for OpenRISC, I will copy the 'orp' platform and modify it for our
purposes.

Robert Cragie, Design Engineer
_______________________________________________________________
Jennic Ltd, Furnival Street, Sheffield, S1 4QT,  UK
http://www.jennic.com  Tel: +44 (0) 114 281 2655
_______________________________________________________________

> -----Original Message-----
> From: Jonathan Larmour [mailto:jifl at eCosCentric dot com]
> Sent: 17 April 2003 15:35
> To: Scott Furman
> Cc: Robert Cragie; OpenRISC; ECOS
> Subject: Re: [ECOS] Re: OpenRISC eCos package
>
>
> Scott Furman wrote:
> > This all goes to the issue you raise above as to whether or not variant
> > subdirs are appropriate for OpenRISC, but the short answer is that,
> > since there was only one variant at the time I ported eCos, I didn't
> > make the effort to create a separate variant for the feature.  Also,
>
> [ Ignoring Bart's option (c) for the moment since unfortunately
> it doesn't
> yet exist... ]
>
> You don't need variant HALs for each configurable hardware subsystem,
> cache, FPU, etc.... you just need to make the stuff in the architecture
> HAL configurable. You could use CDL to do this naturally, and a specific
> platform could specify "requires" statements for features it
> knows it has,
> say FPU support or not.
>
> But also, not all the configuration has to be done by CDL. It's also
> reasonable to define the features just with standard C
> preprocessor macros.
>
> I suggest taking a look at the eCos SuperH HAL which has a
> similar problem
> due to the way many features can be mixed and matched, and the
> quite large
> but overlapping differences between SH2, SH3 and SH4. But only _some_ of
> that configuration is done via CDL. Although SH isn't configurable in the
> same way, it's solving a virtually identical problem.
>
> Jifl
> --
> eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
> --[ "You can complain because roses have thorns, or you ]--
> --[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine
>
>


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss


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