[ECOS] CPU Ports for eCos

[ECOS] CPU Ports for eCos

[Nelson, Charles]

Hi All,
I have been told that trying to do a custom port of eCos without the full
GNU tool chain is not a good idea.  I agree with that.  But where can I find
info on what specific devices are currently supported by the full GNU tool
chain.  And after I do get the info on devices,  where is the info on doing
architectural porting?

Charles Nelson
Wireless Access Group, Glenayre
Tel			: 408 653 2275
Email Pager	: 6532275@skytel.com
Tel Pager		: 1 800 759-8352 pin# 6532275

[ECOS] Re: CPU Ports for eCos

[Bart Veer]

>>>>> "Charles" == Nelson, Charles <charles.nelson@glenayre.com> writes:

    Charles> Hi All, I have been told that trying to do a custom port
    Charles> of eCos without the full GNU tool chain is not a good
    Charles> idea. I agree with that. But where can I find info on
    Charles> what specific devices are currently supported by the full
    Charles> GNU tool chain.

Assuming you start with the sourceware offering of the GNU toolchain,
I am afraid there is no central source of information about which
architectures and platforms are supported. There are a number of
different tools involved (gcc, g++, gdb, binutils, ...) which have
separate maintainers. For example, ELF support is not available in
e.g. the h8300 toolchain because nobody has contributed it yet. Since
eCos makes use of some compiler facilities that are tied to ELF, a
port to an h8300 would be difficult.

One way to find out what is available is to look at the config.sub
file at the toplevel of the toolchain sources and search for the
architecture you are interested in. There is a good chance you will
find it or something like it, giving you the first part of the config
triplet. Then try to configure the toolchain for e.g.
--target=h8300-elf and see what happens. If the configure works then
there is a good chance you will be able to get a usable toolchain,
although there may still be some build problems later on. In the case
of h8300-elf it would fail when configuring the linker. For more
detailed information you would have to examine the documentation for
the various tools.

I should point out that the toolchain currently available via the eCos
web pages has only been validated for mn10300, tx39, and powerpc. It
may work for other architectures as well, but there are no guarantees.

    Charles> And after I do get the info on devices, where is the info
    Charles> on doing architectural porting?

http://sourceware.cygnus.com/ecos/faq.html#porting_how_would_I
provides a starting point.

Bart Veer // eCos net maintainer

Re: [ECOS] Re: CPU Ports for eCos

[Fernando D. Mato Mira]

Somebody (not me) should get the sources for the old
Analog Devices compiler and put their backend stuff
into egcs. Their new compiler is not gcc-based and
is pretty broken. It's really irritating, and motivates
me to specify TI whenever possible.

BTW, the ReplyTo of messages should
be ecos-discuss, not the author.

Fernando D. Mato Mira                                                        
Real-Time SW Engineering & Networking
Advanced Systems Engineering Division                                                               
CSEM - Centre Suisse d'Electronique et de Microtechnique 
Jaquet-Droz 1                                                                    Email:   matomira AT acm DOT org
CH-2007 Neuchatel                                                            Phone:    +41 (32) 720-5157
Switzerland                                                                       FAX:        +41 (32) 720-5720

http://www.csem.ch/         http://www.vrai.com/          http://ligwww.epfl.ch/matomira.html

[ECOS] Re: CPU Ports for eCos

[Bart Veer]

>>>>> "Fernando" == Fernando D Mato Mira <matomira@iname.com> writes:

    Fernando> Somebody (not me) should get the sources for the old
    Fernando> Analog Devices compiler and put their backend stuff into
    Fernando> egcs. Their new compiler is not gcc-based and is pretty
    Fernando> broken. It's really irritating, and motivates me to
    Fernando> specify TI whenever possible.

Probably true, if there are no problems with copyright assignments
etc. For example the gcc port to the MC68HC11 could not be merged
because of assignment problems. Anybody interested in doing this
should contact the egcs maintainers, http://egcs.cygnus.com , to find
out what would be involved. A Cygnus port of eCos to this architecture
is not currently under consideration, so it is unlikely that we will
do this work any time soon.

    Fernando> BTW, the ReplyTo of messages should be ecos-discuss, not
    Fernando> the author.

Not necessarily, http://www.unicom.com/pw/reply-to-harmful.html
gives a different opinion.

Bart Veer // eCos net maintainer

Re: [ECOS] Re: CPU Ports for eCos

[Fernando D. Mato Mira]

At 03:09 PM 4/28/99 +0100, you wrote:

>Probably true, if there are no problems with copyright assignments
>etc. For example the gcc port to the MC68HC11 could not be merged
>because of assignment problems. Anybody interested in doing this
>should contact the egcs maintainers, http://egcs.cygnus.com , to find
>out what would be involved. A Cygnus port of eCos to this architecture
>is not currently under consideration, so it is unlikely that we will
>do this work any time soon.

I don't know about that port, but in this case they were distributing
a derivative of GCC. Whatever their backend was, it was then
infected by the GPL (I guess that's the only reason why you
could order the source code for $200 or something like that).

Somebody seems to be maintaining the old compiler, I saw
it for FTP somewhere, and I actually fetched it.

BTW, their new compiler doesn't even optimize for DSP (or
at least, you can't enable it, because it generates bad code),
so if someone says gcc would not be good enough, don't believe it.
They pumped up the major version number one notch, but it's really
0.x stuff. To make things worse, we were developing using some
prerelease chips (great to have that, nothing else would cut it).
When the time came, overlaying would not work.
People here spent a lot of time looking at the software, and in the end
it was a silicon bug: the external memory interface would not work.
You should definitely not use two broken things at the same time.

Fernando D. Mato Mira                                                        
Real-Time SW Engineering & Networking
Advanced Systems Engineering Division                                                               
CSEM - Centre Suisse d'Electronique et de Microtechnique 
Jaquet-Droz 1                                                                    Email:   matomira AT acm DOT org
CH-2007 Neuchatel                                                            Phone:    +41 (32) 720-5157
Switzerland                                                                       FAX:        +41 (32) 720-5720

http://www.csem.ch/         http://www.vrai.com/          http://ligwww.epfl.ch/matomira.html

[ECOS] Re: CPU Ports for eCos

[Bart Veer]

>>>>> "Fernando" == Fernando D Mato Mira <matomira@iname.com> writes:

    Fernando> At 03:09 PM 4/28/99 +0100, you wrote:
    >> Probably true, if there are no problems with copyright
    >> assignments etc. For example the gcc port to the MC68HC11 could
    >> not be merged because of assignment problems. Anybody
    >> interested in doing this should contact the egcs maintainers,
    >> http://egcs.cygnus.com , to find out what would be involved. A
    >> Cygnus port of eCos to this architecture is not currently under
    >> consideration, so it is unlikely that we will do this work any
    >> time soon.

    Fernando> I don't know about that port, but in this case they were
    Fernando> distributing a derivative of GCC. Whatever their backend
    Fernando> was, it was then infected by the GPL (I guess that's the
    Fernando> only reason why you could order the source code for $200
    Fernando> or something like that).

Copyright assignments and the GPL license are actually separate issues
in this context. The GPL license means (amongst other things) that if
some company or individual X modifies the compiler and makes the
result available to Y then X also has to make the sources available to
Y. Neither X nor Y are obliged to contribute the changes back to the
central maintainers. In practice changes are usually contributed back
because the alternative is merging problems whenever there is a new
release of the main sources (or you get stuck with an old version of
the main sources and you miss out on new optimizations etc.)

For those changes to get accepted into the main sources, a copyright
assignment is needed. The author of any non-trivial changes has to
assign all rights to those changes to the FSF, thus avoiding any
confusion about who owns which bits of the compiler. The GPL does not
impose any obligations in this area, it is a voluntary step, but in
most cases it is worth doing to avoid the merging problems.

As I understand it, in the case of the 68HC11 there were numerous
contributions by different people with no tracking of who contributed
what, and when they wanted to merge the changes into the main sources
there was no way of getting all the people involved to sign the FSF
assignment forms. Hence the maintainers could not accept the code. The
situation for the Analog Devices port may be very different.

More details on the procedures can be found on
http://egcs.cygnus.com/contribute.html 

Bart Veer // eCos net maintainer

Re: [ECOS] Re: CPU Ports for eCos

[Stan Shebs]

   Date: Wed, 28 Apr 1999 19:47:41 +0100
   From: Bart Veer <bartv@cygnus.co.uk>

   For those changes to get accepted into the main sources, a copyright
   assignment is needed. The author of any non-trivial changes has to
   assign all rights to those changes to the FSF, thus avoiding any
   confusion about who owns which bits of the compiler. The GPL does not
   impose any obligations in this area, it is a voluntary step, but in
   most cases it is worth doing to avoid the merging problems.

Just to amplify on Bart's valuable comments, this is just a policy of
the FSF, but it's followed pretty strictly.  From time to time people
offer me pieces of code for GDB that still have somebody else's
copyright on them!  This would certainly lead to a unpleasant legal
imbroglio, if we were to incorporate them in GNU code.  So the rule
is: no assignment, no incorporation.

							Stan

Re: [ECOS] Re: CPU Ports for eCos

[alex]

>Since
>eCos makes use of some compiler facilities that are tied to ELF

Was that a good idea ?

Alex

[ECOS] Re: CPU Ports for eCos

[Bart Veer]

>>>>> "Alex" == alex  <alex@clockwork.freeserve.co.uk> writes:

    >> Since
    >> eCos makes use of some compiler facilities that are tied to ELF

    Alex> Was that a good idea ?

In the medium to long term, yes. Technically ELF is superior to older
object formats such as a.out and COFF, it makes it much easier to
implement facilities such as constructor priority ordering and
selective linking. I believe that just about every new toolchain port
involves ELF as either the only object format or the preferred one.
Older toolchains may get updated because of user demand, partly
because of eCos but also because other systems like Linux use ELF.

In the short term there will be some targets where the ELF dependency
makes an eCos port more difficult. This is unfortunate, but the long
term advantages outweigh this.

Bart Veer // eCos net maintainer

Re: [ECOS] Re: CPU Ports for eCos

[Jonathan Larmour]

In article < 199904281116.MAA32569@sheesh.cygnus.co.uk > you write:
>>>>>> "Alex" == alex  <alex@clockwork.freeserve.co.uk> writes:
>
>    >> Since
>    >> eCos makes use of some compiler facilities that are tied to ELF
>
>    Alex> Was that a good idea ?
>
>In the medium to long term, yes. Technically ELF is superior to older
>object formats such as a.out and COFF, it makes it much easier to
>implement facilities such as constructor priority ordering and
>selective linking.

Just to add my 2p, I believe it would be possible to get things to work
with ECOFF too, but it would require similar modifications to gcc/gld that
were made to the ELF support to support constructor priority ordering. I
believe a.out and vanilla COFF would be as good as impossible to do though.

But as Bart says, since ELF is the way to go in future anyway, there
doesn't seem much point. But if it really was in demand, a volunteer could
implement it.

Jifl
-- 
Cygnus Solutions, 35 Cambridge Place, Cambridge, UK.  Tel: +44 (1223) 728762
"I used to have an open mind but || Want a free open source no-royalty RTOS?
 my brains kept falling out."    || http://sourceware.cygnus.com/ecos
Help fight spam! http://spam.abuse.net/  These opinions are all my own fault

Re: [ECOS] Re: CPU Ports for eCos

[Ian Lance Taylor]

   Date: Wed, 28 Apr 1999 15:59:42 +0100
   From: jlarmour@cygnus.co.uk (Jonathan Larmour)

   >In the medium to long term, yes. Technically ELF is superior to older
   >object formats such as a.out and COFF, it makes it much easier to
   >implement facilities such as constructor priority ordering and
   >selective linking.

   Just to add my 2p, I believe it would be possible to get things to work
   with ECOFF too, but it would require similar modifications to gcc/gld that
   were made to the ELF support to support constructor priority ordering. I
   believe a.out and vanilla COFF would be as good as impossible to do though.

ECOFF can't support arbitrary sections.  ECOFF relocs only support a
limited number of sections.  Look for RELOC_SECTION in
include/coff/ecoff.h in a GNU binutils or gdb release.

Ian