Re: [ECOS] eCos 1.1

[Bart Veer <bartv@cygnus.co.uk>]

>>>>> "jc" == Jimen Ching <jimen@adtech-inc.com> writes:

    jc> Hi all,
    jc> I finally got a chance to take a look at the 1.1 release.  I have a
    jc> few questions, if you don't mind.

    jc> 1.  The installation instructions says I need to build a set of
    jc> cross-compiler tools to use eCos.  Is eCos not usable natively?
    jc> I.e. can I not compile the test programs and run it on Linux/x86,
    jc> for instance?

In the 1.1 release you will need to use either physical hardware or a
simulator. The supplied toolchain contains simulators for the mn10300,
tx39 and powerpc, all of which will work under ix86 Linux. 

As regards running eCos applications natively under Linux, for example
to avoid the performance overheads of using a simulator, I am not able
to give any additional information at this time.

    jc> 2.  Why do version directories exist inside the package directory?
    jc> I.e. packages/kernel/v1_1.  Is there a plan to use
    jc> packages/kernel/v1_2 or packages/kernel/v1_1_1?  What is the
    jc> advantage of this?  Are there plans to use files from different
    jc> versions?

There are indeed plans to support versioning within packages, so there
will be parallel directories v1_1, v1_2, and so on. Currently the host
side tools do not fully support this, but it was desirable to get the
directory structure right from the very beginning.

There are a number of good reasons for doing this. eCos is intended to
support third party packages within the overall configuration system,
and those are not going to be released in lock-step with eCos itself.
Your application may want to use package A from a particular supplier
and that package might only have been tested with the previous release
of eCos itself. On the other hand your application might want to
exploit some functionality provided only by the latest version of
eCos. Being able to manipulate which versions of which package get
used to produce the final image is potentially very powerful.

Another example: an eCos component repository may be shared for
several different applications. One of these might be almost ready for
release, and you would not want to change the OS version at that stage
of the release cycle. Another application has just started
development, and obviously the developers would like to use the latest
and greatest version. Again this requires a directory structure where
different versions of each package can co-exist.

    jc> 3.  Though the win32 configuration tool looks nice and all, is there
    jc> any plans to produce something like the 'make config' tool in
    jc> Linux?  It is a scrolling question and answer tool.

The eCos configuration tool is actually rather more powerful than the
Linux configuration tool. There are two key differences. First, the
eCos tool can handle third party packages as well as the core system.
Second, the tool knows about dependencies between packages and the
options inside those packages. For example, if the user wants a
thread-safe C library but has disabled the kernel option that provides
per-thread data then the tool will detect that there is a conflict and
suggest appropriate actions. This technology allows us to do much more
in terms of fine-grained configurability than is possible with e.g.
Linux' "make config". The extra level of configurability is not
necessarily appropriate for the systems that Linux is aimed at, but it
is very useful for the type of embedded systems that eCos targets.

The intention is to provide a Unix implementation of the eCos
configuration tool, in addition to the existing win32 one. I cannot
give any date for this yet.

    jc> 4.  What's with the eCos/prebuilt directory?  How and where can I
    jc> use these files?  You know it takes up one third of the distribution
    jc> space, right?  ;-)

There was some internal debate about this before the release. The idea
behind the various prebuilts is that it allows people to start playing
with the system immediately, for example they can link and run a
"Hello world" program without having to learn how to configure and
build the system itself. In addition there is one test executable
which can be used straightaway to make sure that the hardware is set
up correctly or to make sure that the simulator has been built
correctly.

We would appreciate some feedback from users to find out whether
anybody has actually made use of these prebuilts, or whether everybody
was quite happy having to rebuild the system first.

    jc> 5.  I am interested in porting eCos to my proprietary system.  It
    jc> does not have an eval board.  I didn't read anywhere that describes
    jc> how to port to a cpu, rather than to a eval board.  Where should I
    jc> start looking?

A good place to start would be the sourceware FAQ, see
http://sourceware.cygnus.com/ecos/faq.html#porting_how_would_I
This contains a pointer to the current HAL specification, which is the
main thing you would need to know about when doing an architecture port.

    jc> That's it for now.  Thanks in advance for any info...

HTH

Bart Veer // eCos net maintainer