[ECOS] OpenRISC eCos package

[ECOS] OpenRISC eCos package

[Robert Cragie]

Hi Scott,

I am starting to use the OpenRISC eCos package submitted by you for our
custom target. As we are not using cache or MMU, this has raised some issues
(note I'm not that familiar with the CDL and have some limited experience of
porting, so please bear with me).

1) What's the best way to approach configuration for a 'soft' processor like
this whose architecture can be configured? My thoughts are that you could
either:

a) Include support for everything in the arch and have them selectable via
cdl_packages/cdl_options
b) Properly define variants and platforms and use cdl_interface to indicate
the options variants/platforms export.

(a) seems acceptable for now, but (b) seems to be the 'proper' solution
based on the tenet of configurability promoted by eCos. However, given the
configurability of the OpenRISC CPU, I guess (b) could potentially give you
a large number of combinations - I'm not sure if this would be a problem.

2) Looking at the ARM HAL, cache support is in the platform subdirectory,
whereas for OpenRISC it is in the 'arch' subdirectory. Shouldn't it be in
the platform subdirectory?

3) vectors.S includes cache manipulation code - shouldn't this be elsewhere
(ideally hal_cache.h)?

I'm happy to help sort out the right way to configure eCos for different
options.

Out of interest, what template did you use for the port?

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


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

[ECOS] Re: OpenRISC eCos package

[Scott Furman]

[Re-sending as plain text message, since ecos-discuss rejects MIME 
multipart/alternative]

Robert Cragie wrote:

>1) What's the best way to approach configuration for a 'soft' processor like
>this whose architecture can be configured? My thoughts are that you could
>either:
>  
>
For those on the ecos-discuss mailing list that may not be familiar with 
the issue, Robert is referring to the fact that the OpenRISC processor 
is a "synthesizable soft-core" CPU.  It is distributed in the form of 
code that can be customized and then compiled into hardware of different 
types.  Cache size, number and width of registers, whether or not MMUs 
are present or certain instructions are implemented,  are all choices 
made available to the CPU designer.  In fact, there are dozens of 
options permitted by the OpenRISC architecture document, not to mention 
support for adding custom instructions and memory units.  That creates, 
effectively, the potential for a near-infinite number of CPU variants.

There are architecture-defined registers in the CPU that indicates how 
CPU options/parameters have been customized, so theoretically one could 
create a HAL architecture port that adapts at run time to the OpenRISC 
processor HW, disabling support for CPU features that are 
unimplemented.  That approach, however, would result in both some 
inefficiency and code bloat, so it's more likely that support would be 
compiled into eCos just for those CPU features/options that are 
implemented in the target CPU.

>a) Include support for everything in the arch and have them selectable via
>cdl_packages/cdl_options
>b) Properly define variants and platforms and use cdl_interface to indicate
>the options variants/platforms export.
>
>(a) seems acceptable for now, but (b) seems to be the 'proper' solution
>based on the tenet of configurability promoted by eCos. However, given the
>configurability of the OpenRISC CPU, I guess (b) could potentially give you
>a large number of combinations - I'm not sure if this would be a problem.
>  
>
I think the eCos variant system isn't as useful with a synthesizable CPU 
architecture as with conventional architectures, where the menu of CPU 
variants is comparitively small.  Rather than picking the single HAL 
variant corresponding to the features of CPU model xyz, a developer 
configuring eCos for OpenRISC must add a variant package for each 
implemented hardware option (cache, floating point support, MMU, 64-bit 
regs, etc.) and set the value of CDL parameters for each of those 
variant packages, e.g. cache size, number of registers.  In this case, 
the CPU "variants" are really just HAL architecture options that can be 
mixed-and-matched almost arbitrarily.   So, I think the issue boils down 
to whether or not the code for an option lives in a separate HAL variant 
subdir or in the HAL's arch subdir.

As to whether model (a) or (b) is correct, I think we should lean 
towards whatever is customary in the eCos codebase.  However, I also 
think whether or not (a) or (b) is correct is partly a matter of 
mindset: Should one think of the CPU architecture as a whole entity with 
pieces that can be optionally disabled or as a small core logic ball 
with pieces that can optionally be glommed on ?

For any particular CPU option, I would be more likely to segregate the 
corresponding HAL code into its own variant subdir if:

    * It represents a single choice among several different HW variants
      rather than merely disabling/enabling a HW option, e.g. one type
      of on-chip memory controller chosen from a menu of several
      possible memory controllers or,
    * The code  can be cleanly separated out, e.g. without littering the
      architecture HAL code with numerous macro invocations or,
    * It represents a HW extension not defined by the OpenRISC
      architecture document, and
    * It's a non-trivial amount of code.

>2) Looking at the ARM HAL, cache support is in the platform subdirectory,
>whereas for OpenRISC it is in the 'arch' subdirectory. Shouldn't it be in
>the platform subdirectory?
>
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,

    * Cache support is an option in the OpenRISC architecture HAL, so it
      can be turned off.
    * If you accidentally enable eCos cache support on an OpenRISC CPU
      that doesn't have cache HW, it's innocuous. It's also only a few
      instructions worth of code, so it's not likely to be much of a
      bloat factor.

Maybe the right thing to do is to have the code read the CPU config 
registers and disable cache support at run time if it's not supported by 
the CPU HW.

>Out of interest, what template did you use for the port?
>  
>
I picked out useful chunks mostly from MIPS and a little from PowerPC 
and ARM..

-Scott





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

[ECOS] Re: [openrisc] Re: OpenRISC eCos package

[Marko Mlinar]

> >2) Looking at the ARM HAL, cache support is in the platform subdirectory,
> >whereas for OpenRISC it is in the 'arch' subdirectory. Shouldn't it be in
> >the platform subdirectory?
>
> 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,
>
>     * Cache support is an option in the OpenRISC architecture HAL, so it
>       can be turned off.
>     * If you accidentally enable eCos cache support on an OpenRISC CPU
>       that doesn't have cache HW, it's innocuous. It's also only a few
>       instructions worth of code, so it's not likely to be much of a
>       bloat factor.
>
> Maybe the right thing to do is to have the code read the CPU config
> registers and disable cache support at run time if it's not supported by
> the CPU HW.
>
> >Out of interest, what template did you use for the port?
>
> I picked out useful chunks mostly from MIPS and a little from PowerPC
> and ARM..
Is it possible to configure eCos with defines? E.g. as it is done in gdb?

or1k architecture also have some configuration registers, where you can read 
configuration from and configure the system.

or1ksim has an option to generate C header file from sim.cfg. This was created 
just for this kind of purposes.

best regards,
Marko


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

Re: [ECOS] OpenRISC eCos package

[Bart Veer]

>>>>> "Robert" == Robert Cragie <rcc@jennic.com> writes:

    Robert> Hi Scott,
    Robert> I am starting to use the OpenRISC eCos package submitted
    Robert> by you for our custom target. As we are not using cache or
    Robert> MMU, this has raised some issues (note I'm not that
    Robert> familiar with the CDL and have some limited experience of
    Robert> porting, so please bear with me).

    Robert> 1) What's the best way to approach configuration for a
    Robert> 'soft' processor like this whose architecture can be
    Robert> configured? My thoughts are that you could either:
    <snip>

The issue of soft cores and eCos has come up before, although not
necessarily on public mailing lists. The ideal solution is actually
option (c): generate key HAL code/configury based on the specific CPU
that is being synthesized. For example, OpenRISC allows you to select
details such as cache size. A tool could take the definition of the
synthesized CPU, extract the details of the cache, and either generate
hal_cache.h or some other file that is #include'd by hal_cache.h.
Similarly the presence of on-chip peripherals like ethernet would
affect the cdl_target definition that controls which device packages
should get pulled in, and also the memory map and interrupt line
assignments.

The original eCos design did envisage tools along these lines, either
allowing users to provide details of a traditional fixed platform
(facilitating porting), or extracting such information from a HDL
file, or a combination. Unfortunately this area was not considered a
priority at the time, and the current implementation of eCos
configuration technology does not yet provide all the functionality
that would be required.

Bart

-- 
Bart Veer                       eCos Configuration Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts

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

Re: [ECOS] Re: OpenRISC eCos package

[Jonathan Larmour]

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

RE: [ECOS] Re: OpenRISC eCos package

[Robert Cragie]

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@eCosCentric.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

Re: [ECOS] Re: OpenRISC eCos package

[Jonathan Larmour]

[ OpenRISC list de-CC'd ]

Robert Cragie wrote:
> 
> 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.

Difficult to say as generally the best advice is to choose something 
similar in design.

Personally, I would recommend the MIPS HAL, but obviously others will 
differ ;).

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

[ECOS] RE: [openrisc] Re: OpenRISC eCos package

[Scott Furman]

> Is it possible to configure eCos with defines? E.g. as it is done in
gdb?

Yes, although the discussion we were having seemed to be focused on CDL,
which is the constraint-based package definition language used to
configure eCos.  There are both command-line and GUI versions of the
tools that manipulate eCos configurations.

See this link for screen snapshots of the GUI eCos configuration tool:

http://www.wxwindows.org/screen52.htm

> or1ksim has an option to generate C header file from sim.cfg. This was
> created just for this kind of purposes.

That's an excellent idea.  I think we still need to have CDL options,
though, to allow developers to override the hardware description in
sim.cfg, e.g. to use less memory than is available or to disable
peripherals.

-Scott




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