eCos Home

RedBoot Home


About eCos

Supported Hardware

Downloading and Installation

Documentation

FAQ

Mailing lists

Problems

Licensing

Anonymous CVS

Contributions and Third Party Projects

eCos
(Category) eCos FAQ
Welcome to the Frequently Asked Questions list for the eCos Real-Time Operating System, and RedBoot bootstrap and debug monitor.

We're still in the process of adding text to the FAQ so bear with us if your questions are not yet answered!

(Category) What is eCos?
(Category) What is RedBoot?

(Category) Installing the eCos distribution
(Category) Using eCos
(Category) Using RedBoot
(Category) Got Problems?
(Category) New User Questions
(Category) Porting eCos and RedBoot to a new target system

(Category) Support
(Category) Contributing back to the eCos community
(Category) Miscellaneous
(Category) Questions not covered you would like answered
(Answer) New Item

(Category) (Category) eCos FAQ :
What is eCos?
What is eCos for and what are its aims?
(Answer) What is eCos?
(Answer) Is eCos Linux?
(Answer) Why have another embedded real-time operating system?
(Answer) Do you provide the source code?
(Answer) What do you mean by configurability?
(Answer) Are there any mailing lists?
(Answer) What are the performance figures?
(Answer) Does eCos support memory management?
(Answer) (Category) eCos FAQ : (Category) What is eCos? :
What is eCos?
eCos (embedded Configurable operating system) is an open-source, royalty-free, highly configurable, application-specific operating system ideal for embedded systems development. eCos is targeted at high-volume applications in consumer electronics, telecommunications, automotive, and other deeply embedded applications. eCos ensures embedded developers have a common software infrastructure for delivering a diverse range of embedded products and enables embedded software developers to focus on delivering better products, instead of developing or maintaining a real-time operating system in addition to the products themselves.
(Answer) (Category) eCos FAQ : (Category) What is eCos? :
Is eCos Linux?
As eCos originated from Red Hat, probably most famous for its distribution of the Linux Operating System, it has become a common misconception that eCos is Linux or in some way based on Linux. However eCos is a completely separate product, with a separate source base. eCos does have an EL/IX level 1 compatibility layer though, allowing it to be compatible with many of the Linux APIs.
(Answer) (Category) eCos FAQ : (Category) What is eCos? :
Why have another embedded real-time operating system?

Even with so many commercially available run-time solutions, more than 50 percent of all embedded projects today are built using in-house proprietary, or "roll your own", real-time technologies (Venture Development Corporation). The original eCos developers (Cygnus Solutions which later became part of Red Hat) partnered with microprocessor vendors and embedded product manufacturing companies to develop eCos around the requirement of an open, technically advanced run-time solution. eCos was designed to address the following fundamental issues that force embedded product manufacturing companies to develop their own run-time technologies:

  • Cost - eCos is royalty free and license cost free. It is portable across chip architectures, which makes it well-suited for software developers of high-volume applications in consumer electronics, telecommunications, automotive and other deeply embedded applications,

  • Control - eCos is an open-source run-time technology which fosters innovation, reduces risk, and places customers in control of their application specific content by enabling programmers on the Internet to read, redistribute, and modify the source code for eCos.

  • Technical Fit - eCos provides source-level configuration (more than 200 configuration points) to exactly match application needs and is tightly integrated with the latest version of GNUPro tools, including highly optimized compilation technology, multi-threaded debugging, graphical configuration, test suites, etc.

(Answer) (Category) eCos FAQ : (Category) What is eCos? :
Do you provide the source code?
Absolutely. eCos is a fully open source project, resulting from the efforts of a large development community on the net. The active eCos developers have many years of experience in this field through their work on other open source projects like Linux, the gcc and g++ compilers, the gdb debugger, and many other tools. The same development model has proved an overwhelming success in many other projects.
(Answer) (Category) eCos FAQ : (Category) What is eCos? :
What do you mean by configurability?

Embedded systems have an amazing range of requirements, from 4 bit controllers up to large radar arrays with a thousand or so top of the range processors. Even if we limit the eCos target market to deeply embedded devices and to processors for which a gcc port is available, it is not possible to write a single system which meets everybody's requirements. The conventional approach forces application developers to adapt their software so that it works within the limitations of the operating system. The eCos approach is to provide a whole range of options and let the developer configure a system that best matches the needs of the application. Typical configuration options include the type of scheduler and the number of priority levels. The current release of the system has over 200 such options, and plenty more will be added as the system evolves.

Code and data size are vitally important for many embedded applications, so configurability must be achieved without adding any overheads. Some of it can be done at link time, but for maximum benefit most of it happens at compile time. It is possible for a configuration option to affect a single line of code, when this is appropriate. On the other hand a single configuration option might control the presence or absence of a complete TCP/IP stack. For system code written in C or C++ the main mechanism that is employed is C preprocessor #ifdef statements, which will be familiar to most embedded application developers.

Using #ifdef statements to provide a small number of configuration options is of course not very original. The critical problem is that configuration options are not independent: for example, changing a kernel option may affect whether or not the C library can provide thread-safe versions of various routines. The key innovation in eCos is that configuration options are treated as data items in their own right, complete with descriptions of all the dependencies between the various options. There is a graphical configuration tool which allows users to conveniently manipulate the various options, understand the various interactions, and check that the resulting configuration is valid.

The configuration framework also serves to componentize the system into different packages. The core system consists of a number of different packages including the kernel, the C library, and the math library. It is possible to enable or disable entire packages, as well as to manipulate configuration options within these packages. It is also possible to add new packages to the system, for example a TCP/IP stack. The key point is that these new packages can specify dependencies on other parts of the system, for example the TCP/IP stack could specify that it needs per-thread data support. The same technology that makes configurability work in the core system allows new packages to be added to the system and readily incorporated into an application. We expect large numbers of these packages to become available over time, and already there are software vendors who want to turn their existing software into eCos packages. We expect that many contributions from the open source community will take the form of ports of existing software or of completely new packages.

The eCos configuration system does not affect how you develop your own application code. It is not necessary to write your application in any special language, or to provide lots of configuration options in your own code, or to use a special development environment. The main output from the configuration system is a library that gets linked with your application code in the usual manner.


(Answer) (Category) eCos FAQ : (Category) What is eCos? :
Are there any mailing lists?

Certainly. There are several mailing lists which anybody can subscribe to. The ecos-announce mailing list is a low-volume moderated list for major announcements. The ecos-discuss mailing list is an unmoderated list for general discussion, both technical and non-technical among eCos users. The ecos-devel mailing list is for more technical discussions among developers of eCos itself. All the core eCos development team read these lists and participate in discussions as appropriate. Other more obscure lists exist to keep track of every detailed change in the eCos project. If you prefer you can subscribe to digest versions of these mailing lists instead.

We strongly recommend you read both the eCos documentation fully and search the above mail archives before asking simple questions on the list, particularly if they are likely to be problems that people would have encountered before.

If you have a question which you do not want to discuss in a public forum then there is a separate ecos-maintainers mail address. However note that general requests for help or information that would be more appropriate to a public list like ecos-discuss may not be answered.


(Answer) (Category) eCos FAQ : (Category) What is eCos? :
What are the performance figures?

A side effect of a fully configurable system is that it is just about impossible to answer questions like "What is the memory footprint of the kernel?" or "What is the interrupt latency?" These figures depend in large part on the configuration options selected by the user. For example if a simple application does not require the kernel at all, directly or indirectly, then the kernel package can be disabled completely and its memory footprint is 0 bytes.

Basic performance characterization data is available as part of the documentation as part of the architecture specific Getting Started manual, together with a description of the tests that were used to obtain this data. The sources for these tests are included with the eCos distribution.


(Answer) (Category) eCos FAQ : (Category) What is eCos? :
Does eCos support memory management?
eCos is a single process, multiple thread operating environment. As such, memory management is not required. Memory management hardware may be used on some platforms where it exists and is required for optimum performance. For example, on PowerPC based platforms, memory management is used in order to enable cache operations (which may not be possible on some PPC chips if the MMU is off).

There is no notion of separate address "spaces" in eCos like there would be in a system like Linux. All threads share the same address space and access capabilities. Note though, that 3G Lab have done some experimental work to provide protected address spaces for the Intel StrongARM SA1110, which can be found at http://www.3glab.org/.

(Category) (Category) eCos FAQ :
What is RedBoot?
What is RedBoot for?
Subcategories:

Answers in this category:
(Answer) What is RedBoot?

(Answer) (Category) eCos FAQ : (Category) What is RedBoot? :
What is RedBoot?

RedBoot, the Red Hat Embedded Debug and Bootstrap firmware, is a complete bootstrap environment for embedded systems. Based on the eCos RTOS Hardware Abstraction Layer, RedBoot inherits eCos' qualities of reliability, compactness, configurability, and portability.

RedBoot allows download and execution of embedded applications via serial or ethernet, including embedded Linux and eCos applications. It can be used for both product development (debug support) and in deplayed products in the field (Flash update and network booting).

Ethernet download and debug support is included, allowing RedBoot to retrieve its IP parameters via BOOTP or DHCP, and program images to be downloaded using TFTP. Images can also be downloaded over serial, using X- or Y-modem.

RedBoot can be used to communicate with GDB (the GNU Debugger) to debug applications via serial or ethernet, including the ability to interrupt a running application started by GDB.

An interactive command-line interface is provided to allow management of the Flash images, image download, RedBoot configuration, etc., accessible via serial or ethernet. For unattended or automated startup, boot scripts can be stored in Flash allowing for example loading of images from Flash or a TFTP server.

RedBoot was originally developed by Red Hat, but is now developed and maintained on the net alongside eCos as an open source project. All sources and documentation for RedBoot, and the eCos operating system on which it is based, are freely available without license or royalties.

For more details about RedBoot, please visit the RedBoot site.


(Category) (Category) eCos FAQ :
Installing the eCos distribution
Installing the eCos distribution onto your development workstation
Subcategories:
(Category) Installing on Windows
(Category) Installing on Linux
(Category) Building the GNU development tools

Answers in this category:
(Answer) What is anonymous CVS?

(Category) (Category) eCos FAQ : (Category) Installing the eCos distribution :
Installing on Windows
Questions about installing eCos on Windows development hosts
Subcategories:

Answers in this category:

(Category) (Category) eCos FAQ : (Category) Installing the eCos distribution :
Installing on Linux
Questions about installing eCos on Linux development hosts
Subcategories:

Answers in this category:

(Category) (Category) eCos FAQ : (Category) Installing the eCos distribution :
Building the GNU development tools
Info about building and installing the GNU development tools (GCC, GDB, and the GNU binary utilities, etc.)
Subcategories:

Answers in this category:

(Answer) (Category) eCos FAQ : (Category) Installing the eCos distribution :
What is anonymous CVS?

CVS is the source code control system used to manage the eCos sources (and the sources for other projects at sourceware.org). The anonymous CVS service at ecos.sourceware.org allows net developers to get hold of an up-to-date set of eCos sources, without having to wait for the next full release of the system. These sources may include new functionality and fixes to various problems. The disadvantage of anoncvs sources compared with full releases is that the latter are given a full QA cycle, whereas there is no guarantee that the anoncvs sources will even build at any one time.


(Category) (Category) eCos FAQ :
Using eCos
Questions about using eCos, its APIs and the many components within it
Subcategories:
(Category) Problems when building eCos itself

Answers in this category:
(Answer) How do I create an application using eCos?

(Category) (Category) eCos FAQ : (Category) Using eCos :
Problems when building eCos itself
This section deals with problems found when building eCos itself, as in the eCos libraries and header files.
jlarmourATredhatDOTcom
Subcategories:

Answers in this category:
(Answer) Linking tests produces the error "section .FOO is not within region ram"

(Answer) (Category) eCos FAQ : (Category) Using eCos : (Category) Problems when building eCos itself :
Linking tests produces the error "section .FOO is not within region ram"
You get this when linking the eCos tests (or your application) and it happens because the defined memory layout for your target indicates that the program image will not fit!

This commonly happens with trying to squeeze the net stack, which is quite big, on RAM constrained targets.

Verify the memory layout to check it does fit your hardware, and generate a linker map to see where the memory is going. This can be done using the option -Wl,-Map,mapfile on the gcc link line to create a file called "mapfile" in the current directory of the build at that point. Note that if you add this to CYGBLD_GLOBAL_LDFLAGS in your ecos.ecc file, then for the eCos tests, the linker map file will be generated in the build tree subdirectory corresponding to the package.

Certainly, many configuration options can reduce the memory usage, including removing entire packages. The linker map gives a better guide as to where the memory is being used. In the case of the net stack for example, it is very wise to try to reduce the size of the buffers, i.e. the CYGPKG_NET_MEM_USAGE option.
jlarmourATredhatDOTcom

(Answer) (Category) eCos FAQ : (Category) Using eCos :
How do I create an application using eCos?
An eCos application is built in two steps.
  • Configure and build eCos kernel
  • Link kernel with application code

The first step is quite fully documented elsewhere. The problem comes with the second step, since it will be unfamiliar to most users. Some additional command line arguments for the C compiler will be necessary in order to link your application with the eCos kernel. The simplest way to set an example up is by using the "build_Makefile" script, which you will find alongside the eCos sample programs.

Assume that the eCos kernel was created in the directory "ECOS" and that the application is in the directory "APP".

  % cd APP
  % SRCS=file.c DST=file build_Makefile ECOS

This script will build a simple Makefile template, using the appropriate eCos tools setup used for building the eCos kernel. This Makefile can then be modified as necessary to handle the actual application code setup.

It uses the default eCos compilation flags. This may include some flags that the application does not require or desire such as warning options. Obviously those flags can just be deleted by editting the generated makefile. Consult the GCC manual to see what the various flags do if you don't already know.

If you are using the graphical configuration tools, these lay out the build directory structure in a slightly different way from the command line ecosconfig tool. This should be fixed eventually, but for the moment it can be worked around. If you created a configuration called example, then when saved there will be:

  example.ecc
  example_build/
  example_install/

So enter the example_build directory and type:
    ln -s ../example_install install

build_Makefile can then be used as before.

Note: build_Makefile is only a starting point. Most applications will require modifications to the resulting Makefile in order to be complete.

(Category) (Category) eCos FAQ :
Using RedBoot
Questions about using the RedBoot monitor and its command line interface
Subcategories:
(Category) Networking
(Category) Downloading programs

Answers in this category:
(Answer) FLASH configuration checksum error

(Category) (Category) eCos FAQ : (Category) Using RedBoot :
Networking
Issues relating to the networking support in RedBoot
jskovATredhatDOTcom
Subcategories:

Answers in this category:
(Answer) I get "Can't get BOOTP info for device !"
(Answer) Is BOOTP required for network debugging

(Answer) (Category) eCos FAQ : (Category) Using RedBoot : (Category) Networking :
I get "Can't get BOOTP info for device !"
This happens if the target has been configured to use BOOTP (see the fconfig options) but there is no BOOTP/DHCP deamons answering the target's request for an IP address.

There are two solutions to this problem:

  1. Make the target use a static IP address using either the CYGDAT_REDBOOT_DEFAULT_IP_ADDR CDL option (in which case that address is built in to the RedBoot binary) or if your target supports FLASH, by using the fconfig command.
  2. Set up a BOOTP/DHCP server on the network

See http://sources.redhat.com/ecos/docs-latest/redboot/configuring-the-redboot-environment.html for details.
jskovATredhatDOTcom, jlarmourATredhatDOTcom

(Answer) (Category) eCos FAQ : (Category) Using RedBoot : (Category) Networking :
Is BOOTP required for network debugging
No, the target's IP address can also be assigned statically. As long as RedBoot's ethernet is working, you should be able to use it for debugging.
jskovATredhatDOTcom
(Category) (Category) eCos FAQ : (Category) Using RedBoot :
Downloading programs
Issues to do with loading applications onto a target using RedBoot, either directly with x/y-modem, TFTP, or disk, or by using GDB.
jlarmourATredhatDOTcom
Subcategories:

Answers in this category:
(Answer) Downloading is slow

(Answer) (Category) eCos FAQ : (Category) Using RedBoot : (Category) Downloading programs :
Downloading is slow
There are a number of factors which influence the speed here. Most RedBoot ports run from FLASH which is often slow. Also, the network stack used by RedBoot was designed to be as simple and small as possible, not necessarily as fast as possible. Also, GDB sends relatively small packets while downloading. This adds a lot of overhead.

The biggest problem with GDB is the size of the packets that GDB uses and the associated overhead. If you use RedBoot to download code directly (using TFTP and the 'load' command), you'll see much faster download times. I just tested it on one of our platforms here and the difference was pretty large:

   GDB - 153k (bits/sec)
   RedBoot via 'load' - 700k (bits/sec)
So the problem is not really with RedBoot's networking code, but the additional overheads involved with the GDB protocol.

However, there are some knobs in gdb which can be used to improve the situation. By default, gdb will send relatively small packets during download.

  (gdb) set download-write-size xxx
asks gdb to try using xxx bytes per download packet. There is interaction with the memory-write-size knob which may limit the download size. For my xscale toolchain, I see:
  (gdb) show remote memory-write-packet-size 
  The memory-write-packet-size is 0. Packets are limited to 399 bytes.
You can force gdb to use a larger memory-write-packet-size with:
 
  (gdb) set remote memory-write-packet-size 800
  The memory-write-packet-size is 800. Packets are limited to 399 bytes.
Notice how gdb still limits it to 399. Force gdb to use the previously entered 800:
  
  (gdb) set remote memory-write-packet-size fixed
  The target may not be able to correctly handle a memory-write-packet-size
  of 800 bytes. Change the packet size? (y or n) y
(gdb) show remote memory-write-packet-size The memory-write-packet-size is 800. Packets are fixed at 800 bytes.
Now the problem is that the target side has to be able to handle packets of up to 800 bytes. Unfortunately, the ARM HAL cannot handle packets larger than (NUMREGBYTES * 2)+32 bytes, where NUMREGBYTES is defined in:
   hal/arm/arch/include/arm_stub.h
As an experiment, I commented out the NUMREGBYTES define in arm_stub.h so that a default gdb stub buffer of 2k was used. I then downloaded an app using the default gdb settings and got 155K/sec. I then used:
  (gdb) set download-write-size 1000
  (gdb) set remote memory-write-packet-size 1000
  (gdb) set remote memory-write-packet-size fixed
  The target may not be able to correctly handle a memory-write-packet-size
  of 1000 bytes. Change the packet size? (y or n) y
I then reloaded the app and saw 320K/sec.
jlarmourATredhatDOTcom
(Answer) (Category) eCos FAQ : (Category) Using RedBoot :
FLASH configuration checksum error
A common message from RedBoot is:
  FLASH configuration checksum error or invalid key

This is not really an error, but just a warning.  RedBoot can keep
configuration information in FLASH (or EEPROM).  This is a database
which must be initialized before use.  The warning simply means
that somehow the database is not valid, probably because it has
never been initialized.

To remedy this, simply initialize the database!  For example:
  RedBoot> fconfig -i
  Initialize non-volatile configuration - continue (y/n)? y
  Run script at boot: false
  Use BOOTP for network configuration: true
  DNS server IP address: 
  Network hardware address [MAC]: 0x00:0x23:0x31:0x37:0x00:0x1C
  GDB connection port: 9000
  Force console for special debug messages: false
  Network debug at boot time: false
  Default network device: at91rm9200_eth
  Update RedBoot non-volatile configuration - continue (y/n)? y

 
garyATmlbassocDOTcom
(Category) (Category) eCos FAQ :
Got Problems?
This section is about problems people frequently encounter building or installing eCos and RedBoot.
Subcategories:
(Category) Toolchain build problems
(Category) Problems building eCos

Answers in this category:
(Answer) Is there a list of known problems?
(Answer) How should I report a problem?

(Category) (Category) eCos FAQ : (Category) Got Problems? :
Toolchain build problems
This section is about problems frequently encountered when building toolchains.
Subcategories:
(Category) Toolchain build problems specific to Linux/Unix hosts
(Category) Toolchain build problems specific to Windows hosts

Answers in this category:
(Answer) General toolchain build problems
(Answer) The assembler reports errors building libgcc
(Answer) System requirements
(Answer) I have problems building the SID simulator on cygwin

(Category) (Category) eCos FAQ : (Category) Got Problems? : (Category) Toolchain build problems :
Toolchain build problems specific to Linux/Unix hosts
This section is about toolchain build problems that are only relevant for Linux or other Unix hosts.
Subcategories:

Answers in this category:
(Answer) RPM package requirements
(Answer) Toolchain build problems on other Unix systems
(Answer) Build problems on Alpha systems
(Answer) Build problems on Solaris systems

(Answer) (Category) eCos FAQ : (Category) Got Problems? : (Category) Toolchain build problems : (Category) Toolchain build problems specific to Linux/Unix hosts :
RPM package requirements

If you have installed only a minimal Linux system then some libraries may be missing. The most likely candidates are the ncurses and ncurses-devel packages, and it will be necessary to install these first. You must also have the glibc-devel package installed, although that is normally the case.


(Answer) (Category) eCos FAQ : (Category) Got Problems? : (Category) Toolchain build problems : (Category) Toolchain build problems specific to Linux/Unix hosts :
Toolchain build problems on other Unix systems

Officially Red Hat Linux is the only supported host Unix system for use with eCos, but in practice it is possible to build the tools on other systems as well. As on all systems care has to be taken care with the position of . in your PATH. In addition you will need to have a reasonable set of existing tools on your Unix machine before you can build a cross-compiler. A good starting point is the gcc compiler.


(Answer) (Category) eCos FAQ : (Category) Got Problems? : (Category) Toolchain build problems : (Category) Toolchain build problems specific to Linux/Unix hosts :
Build problems on Alpha systems

It has been reported that egcs-1.1.2 is not capable of building the eCos host-side tools (ecosconfig, etc.). Alpha users should use at least gcc 2.95.2 to compile these tools.


(Answer) (Category) eCos FAQ : (Category) Got Problems? : (Category) Toolchain build problems : (Category) Toolchain build problems specific to Linux/Unix hosts :
Build problems on Solaris systems

Two problems are occasionally encountered on Solaris systems. One of these relates to the admin command. Another involves termio although this is believed to be fixed in recent tools sources. Solutions to these problems are available via the mailing list archives.


(Category) (Category) eCos FAQ : (Category) Got Problems? : (Category) Toolchain build problems :
Toolchain build problems specific to Windows hosts
This section is about toolchain build problems that are only relevant to Microsoft Windows hosts.
Subcategories:

Answers in this category:
(Answer) Things that are NOT problems
(Answer) Builds resulting in many syntax and parse errors
(Answer) What if the patches fail to apply?
(Answer) Insight 5.0 cannot display my source files, although gdb -nw works
(Answer) I have Cygwin b20.1 and....
(Answer) I'm using Windows 95/98 and...

(Answer) (Category) eCos FAQ : (Category) Got Problems? : (Category) Toolchain build problems : (Category) Toolchain build problems specific to Windows hosts :
Things that are NOT problems

Under windows, running the configure script will output:

    This configuration is not supported in the following directories:
      texinfo
    (Any other directories should still work fine.)
This is normal, and is not an error message.


(Answer) (Category) eCos FAQ : (Category) Got Problems? : (Category) Toolchain build problems : (Category) Toolchain build problems specific to Windows hosts :
Builds resulting in many syntax and parse errors

A common source of problems on Windows is that applying patches may inadvertently lead to CRLFs getting inserted into source files where they are not wanted. When applying the patches you should verify that the /tmp directory (or the directory specified by the TMPDIR, TMP or TEMP environment variables) is mounted in binary mode. If this is not the case the patches will apply, but the build will later fail. You may verify this using the Cygwin mount command. If /tmp is not explicitly listed, the entry for / will be used. If it says "textmode" for this entry, use the following command from a Cygwin bash prompt:

    mount -f -b c:/cygwin/tmp /tmp

You may need to substitute another path for c:/cygwin if Cygwin was installed to another directory.

If you already have a set of sources which may have CRLFs in, then you can use the following command from a cygwin prompt on affected files:

    tr -d '\r' < AFFECTEDFILE > foo
    mv foo AFFECTEDFILE


(Answer) (Category) eCos FAQ : (Category) Got Problems? : (Category) Toolchain build problems : (Category) Toolchain build problems specific to Windows hosts :
What if the patches fail to apply?

Some of the tools patches are against sources that are under continuous development, which may mean that the patches may no longer apply. Analyze the patch reject (.rej) files to determine if this is the case, and if so, send a message to the ecos-discuss mailing list.

If you get a message from the patch utility reporting that it cannot create a file C:\TEMP/xxxx where xxxx is some number, then this probably indicates that the environment variables TMP or TMPDIR have been set to a Windows-style location, such as C:\TEMP rather than a Cygwin-style location, such as /tmp. This may also cause other problems in future so it is highly recommended that you override this environment variable in the cygwin.bat startup file (located in the bin directory of the Cygwin installation) which is executed when the Start Menu is used to start a Cygwin bash shell. This may be done in cygwin.bat with a command such as:

    set TMP=/tmp

Alternatively, after invoking a bash shell, remember to issue the command:

    TMP=/tmp ; export TMP

or similar.


(Answer) (Category) eCos FAQ : (Category) Got Problems? : (Category) Toolchain build problems : (Category) Toolchain build problems specific to Windows hosts :
Insight 5.0 cannot display my source files, although gdb -nw works

You need to apply a patch to the Insight TCL directory. Download the insight-tcl.pat patch to a file and apply it:

    cd /src/gdb/insight-5.0
    tr -d '\r' < insight-tcl.pat | patch -p0

You must now rebuild and reinstall Insight as described in the build instructions you originally used. It is safest to use a new empty build directory rather than reusing the Insight build directory from the previous build.


(Answer) (Category) eCos FAQ : (Category) Got Problems? : (Category) Toolchain build problems : (Category) Toolchain build problems specific to Windows hosts :
I have Cygwin b20.1 and....

Cygwin b20.1 is now obsolete. While it may still be possible to get support on the cygwin and ecos-discuss lists when using this version of Cygwin, it is likely the initial recommended solution will be to upgrade your Cygwin installation to v1.3 or later.


(Answer) (Category) eCos FAQ : (Category) Got Problems? : (Category) Toolchain build problems : (Category) Toolchain build problems specific to Windows hosts :
I'm using Windows 95/98 and...

Building the tools under Windows 95 or 98 is not supported. It may work, but it has proven unreliable in the past. It is recommended to use an Windows NT/2000/XP system instead for the initial toolchain build. On some Windows 95/98 machines it may be possible to get a working toolchain if you install the very latest version of cygwin and try hard enough, but there are no guarantees.


(Answer) (Category) eCos FAQ : (Category) Got Problems? : (Category) Toolchain build problems :
General toolchain build problems

Always make sure that you follow the instructions exactly. A lot of the problems that get reported are caused by some apparently minor deviation from these instructions, but they still take time to track down. Take special care with the target triplets specified during the configure step.

One common problem is lack of disk space. Building a full toolchain requires a lot of disk space, especially on a FAT-based file system. If you come across a strange toolchain build failure then please check there is plenty of disk space available on all the relevant drives.


(Answer) (Category) eCos FAQ : (Category) Got Problems? : (Category) Toolchain build problems :
The assembler reports errors building libgcc

Toolchain builds will fail if you have . in your PATH before the native tools. Specifically, at some points during the build it will execute ./as rather than /usr/bin/as: since ./as will be e.g. a PowerPC assembler it will not be happy when the compiler invokes it with an ix86 intermediate file.


(Answer) (Category) eCos FAQ : (Category) Got Problems? : (Category) Toolchain build problems :
System requirements

Make sure you have at least the estimated amount of disk space required in the toolchain build instructions to build and install the toolchain.

Some toolchains also need a lot of memory to build. If you have less than 64MB of memory free or only a small amount of swap space then you may run into problems, but a lot depends on what else is running on the system at the time.


(Answer) (Category) eCos FAQ : (Category) Got Problems? : (Category) Toolchain build problems :
I have problems building the SID simulator on cygwin
Make sure you use the Cygwin setup program to get the gettext-devel package as well as the gettext package.
(Category) (Category) eCos FAQ : (Category) Got Problems? :
Problems building eCos
Problems frequently encountered when building eCos
Subcategories:

Answers in this category:
(Answer) My newly installed GCC reports "cpp: too many input files"
(Answer) Multiply defined symbols when target is built twice

(Answer) (Category) eCos FAQ : (Category) Got Problems? : (Category) Problems building eCos :
My newly installed GCC reports "cpp: too many input files"
gcc tends to report the error message "cpp: too many input files" when it cannot find tools in the places it expects them to be. One cause is if you configured with a --prefix or a --exec-prefix argument with a trailing slash. You must ensure there are no trailing slashes to the arguments to --prefix and --exec-prefix. Another cause is if you have moved your gcc installation from the location you originally specified when it was configured. This location is determined primarily by the --exec-prefix argument to gcc's configure script.

More recent gcc snapshots do not have this limitation, which is specific to gcc 2.95.2 or earlier. To resolve it, you can: use a more recent gcc snapshot; reconfigure gcc with the intended installation location set correctly; or set up symlinks from the old location to the new one.


(Answer) (Category) eCos FAQ : (Category) Got Problems? : (Category) Problems building eCos :
Multiply defined symbols when target is built twice
(Answer) (Category) eCos FAQ : (Category) Got Problems? :
Is there a list of known problems?

There is a list of known problems and, in most cases, recommended workarounds. It is manually generated from our internal problem report database. Full external access to this problem report database is not currently available because of confidentiality issues.

***Update: The information there is partially obsolete. Please refer to the bug tracking system for details on known bugs.


(Answer) (Category) eCos FAQ : (Category) Got Problems? :
How should I report a problem?

The preferred approach is to use the problem reporting web page, which ensures that the report is in our database. Note that there are a number of commercial organisations who provide high quality eCos support, for a charge. You should choose this option if you need guaranteed turnaround and detailed replies.

Alternatively problems can be reported on the ecos-discuss mailing list. If you have already traced the problem yourself, it is better to create a patch and send it to the ecos-patches mailing list.

Minor problems which are unlikely to be of general interest, for example a spelling mistake on one of the web pages, can be sent to ecos-maintainers@sources.redhat.com.


(Category) (Category) eCos FAQ :
New User Questions
Topics of interest to first-time eCos users
Subcategories:

Answers in this category:

(Category) (Category) eCos FAQ :
Porting eCos and RedBoot to a new target system
Porting eCos and RedBoot to a new target system
(Answer) Does eCos run on processor X?
(Answer) Is there going to be an eCos port to processor X?
(Answer) How would I go about porting eCos to a new processor?
(Answer) Will the eCos maintainers adopt my port?
(Answer) How about porting eCos to a new board?
(Answer) What are the compiler dependencies?
(Answer) (Category) eCos FAQ : (Category) Porting eCos and RedBoot to a new target system :
Does eCos run on processor X?

Refer to the supported targets page for details of the supported architectures. If a particular processor is not listed there then support for that processor is not yet available.


(Answer) (Category) eCos FAQ : (Category) Porting eCos and RedBoot to a new target system :
Is there going to be an eCos port to processor X?

As the eCos project relies on contributions from the net to do porting, a port will only happen if someone is prepared to develop it and contribute it back.

We hope that porters will announce their intentions to port to a specific processor. If someone has done so, search the ecos-discuss list archives to see if one is in the process of development. Alternatively ask on the ecos-discuss list to check.


(Answer) (Category) eCos FAQ : (Category) Porting eCos and RedBoot to a new target system :
How would I go about porting eCos to a new processor?

A sensible first step for this, as for any other non-trivial project involving eCos, would be to find out whether or not anybody else is already working on something similar. One way of doing this is to post a message to the ecos-discuss@sources.redhat.com mailing list. We aim to keep track of every ongoing eCos project that we know about, to avoid duplication of effort.

The next step is to make sure that you have a toolchain that is suitable for your target hardware. This means the compilers gcc and g++, the assembler gas, the linker, and the various binutils such as ar. It will also be necessary to have some way of actually running an executable on the target hardware, an operation which is inherently hardware dependent. On many targets this will already be possible via the debugger gdb, but on other targets it may be necessary to get gdb to work with the board first or to use some other technique.

It should be noted that eCos uses a number of relatively new extensions to the GNU tools, and you may well run into problems if you try to use some other release of the tools. The most important extension is constructor priority ordering, which allows us to control the order in which static C++ objects get constructed. For example it is possible to specify that a scheduler object gets created before any thread objects. This extension is likely to work with any processor that uses the ELF object format, but there will be problems with other object formats: please contact the eCos maintainers if you need more information about this. Another new extension is selective linking, which will result in smaller executables but which is not absolutely required for a working eCos port. This extension requires modifications to the toolchain for each architecture, and is not yet available except for the supported architectures. Work is in progress to make sure that these extensions work correctly for all architectures that use ELF object format, and to make the extensions available as part of the main net releases for the various tools.

Assuming a working toolchain, porting to a new processor mainly involves implementing a new architectural HAL package. There are existing packages for those architectures which are already supported, and these can be used as a starting point. The current specification of the eCos HAL is available online in the eCos Reference Manual. As you might expect, the work involved in porting eCos is very similar to the work involved in porting any embedded operating system: hardware initialization, interrupt handling, processor exceptions, context switching, etc.

In addition to the architectural HAL package it will be necessary to do a platform HAL package, in other words to provide the support for an actual development board. This involves issues such as board initialization, diagnostics, possibly gdb support, and linker scripts. There are existing platform HAL packages for the supported boards, and for various simulators.

See the eCos Porting Guide for more specific details on the porting process.


(Answer) (Category) eCos FAQ : (Category) Porting eCos and RedBoot to a new target system :
Will the eCos maintainers adopt my port?

If somebody produces a port to a new processor but does not wish to maintain it indefinitely then the eCos maintainers may be willing to adopt this port. This involves quite possibly code clean-ups so that it satisfies the coding standards, possibly new documentation, and if hardware is available, testing. In addition we will maintain the port, upgrading it as the HAL specification evolves. The effort involved is considerable, and over time it will be significantly larger than the initial port. Usually the eCos maintainers will only be able to afford to do so if there are likely to be sufficient long-term interest. Also, we would need a ready source of suitable hardware that can be used for the testing, and we would need a copyright assignment for such ports.

However a port does not have to be supported for it to be useful to somebody. If a port (or any other eCos package) does not have an active maintainer then it can still be made available as unsupported software, provided space on our ftp server and suitable links in the web pages. This allows people to download and use such ports. If there are enough users for an unsupported port then perhaps somebody else will take over the maintainership. The same is of course true for any piece of contributed software.


(Answer) (Category) eCos FAQ : (Category) Porting eCos and RedBoot to a new target system :
How about porting eCos to a new board?

As with a processor port, usually the first step is to publicize your intention and make sure that nobody else is already doing this. The second step is to make sure that you have the necessary tools, in particular some way of running an executable on the target board. It is possible that gdb already provides support for that board. Alternatively it may be necessary to add the necessary support to gdb, or to use some other means of running programs.

Assuming a working toolchain, the work involved on the eCos side is to implement a new platform HAL package. This involves issues such as board initialization, diagnostics, possibly gdb support, and linker scripts. There are existing platform HAL packages for the supported boards, and any of these can be used as starting points.


(Answer) (Category) eCos FAQ : (Category) Porting eCos and RedBoot to a new target system :
What are the compiler dependencies?

eCos depends heavily on a number of language extensions provided by the gcc and g++ compilers. In fact a number of these extensions were added to these compilers specifically to support eCos (although they have wider applications as well). The first such extension is C++ constructor priority ordering. When you define several C++ static objects the language does not define the order in which these objects get constructed. g++ now allows static objects to be ordered using the __attribute__ mechanism, so for example it is possible to create a scheduler object before any thread objects. The second extension is selective linking. Traditionally linkers worked in terms of compilation units, in other words entire files: if an application needed a particular function from a library then all other library functions which happened to be in the same source file would become part of the application's executable. Instead the linker will now work at the finer granularity of individual functions or variables.

Other extensions provided by gcc and g++ are used wherever appropriate. For example attributes are used to define some functions with weak linkage and to provide aliases for some functions. Inline assembler is used to establish memory barriers and prevent the compiler from optimizing in places where this would be undesirable, for example in context switch code. Computed goto's may be used during exception handling.

The use of these extensions makes it very difficult to use compilers other than gcc and g++ to build eCos. In addition it is possible that other extensions will be used in future if they prove to be appropriate for the problem at hand. Therefore we recommend against attempting to use any other compiler technology for eCos development.


(Category) (Category) eCos FAQ :
Support

There are two forms of support for eCos. Commercial support from vendors, and (limited) free support from the eCos discussion forum.

Subcategories:

Answers in this category:
(Answer) How do I get support?
(Answer) Commercial
(Answer) Free

(Answer) (Category) eCos FAQ : (Category) Support :
How do I get support?

The previously mentioned mailing lists are open to all to use freely and core eCos developers read and post there. However the scope is limited as to what can be answered, and queries or problems, even simple ones, may be ignored.

Bug reports can be submitted to the bug tracking system which allows the issue to be tracked in a more reliable manner, however prompt replies are still not guaranteed.

Some businesses provide commercial support more suitable for businesses. Contact the eCos maintainers with your requirements and they may be able to put you in touch with an appropriate vendor.


(Answer) (Category) eCos FAQ : (Category) Support :
Commercial

You can buy commercial support for eCos and RedBoot from a number of vendors. The support can be tailored to your needs, covering everything related to embedded development with eCos: porting the toolchain and eCos/RedBoot to a new architecture or platform, adding new features or drivers to eCos, support of the toolchain, support of eCos/RedBoot, training, etc.

Some businesses provide commercial grade support more suitable for those who need fast turnaround with detailed answers. Contact the eCos maintainers with your requirements and they may be able to put you in touch with an appropriate vendor.


(Answer) (Category) eCos FAQ : (Category) Support :
Free

The ecos-discuss mailing list is an open mailing list for discussion of eCos (and RedBoot): everybody can join and there's no moderation.

Core eCos developers also read the list and occasionally reply on questions. Always keep mail on the public mailing lists so that the whole community gets the benefit of solutions to problems, if posted, and so that other members of the community can offer help and gain from your experience. However, while support and advice on the list is free, there is no obligation or guarantee on the part of anyone to respond to mail sent to the list.

Mail followups sent directly to the core eCos developers that are not CC'ed to the list will be ignored, as will unsolicited email also sent directly to the eCos developers. Some developers may offer commercial support packages, and responses would only be guaranteed to their customers.

Posting to the list instead of individuals is an important point, since the list is an open forum where eCos users can help each other. There is no guarantee that your questions will be answered and if your question does go unanswered, consider purchasing a support contract.

There are quite a few questions that go unanswered. A few of the unanswered questions are good questions that nobody knows the answer to or ones that will take significant effort to reply to. However, the majority of unanswered questions stay unanswered because to the regular readers of the mailing list it is clear that the person asking the question did not bother reading the documentation, or try to find the answer on his/her own. So before you ask a question, please read through this FAQ, the mailing list archive, and do read Eric S. Raymond's article on How To Ask Questions The Smart Way. It really does make a difference!


(Category) (Category) eCos FAQ :
Contributing back to the eCos community
Info about contributing code, documentation or anything back into the main eCos distribution
(Answer) Do I have to contribute?
(Answer) Which development model - cathedral or bazaar?
(Answer) How do I contribute?
(Answer) What code contributions would be accepted?
(Answer) Why do I need to sign a copyright assignment?
(Answer) I want to start work today! What should I work on?
(Answer) Will external developers be given write access to the anonymous CVS repository?
(Answer) (Category) eCos FAQ : (Category) Contributing back to the eCos community :
Do I have to contribute?

No. We expect that most people will simply want to use the system as it is (or rather, as it is after they have configured it to meet their specific needs), without changing the core system itself or adding any new packages. Such users are under no obligation to contribute.


(Answer) (Category) eCos FAQ : (Category) Contributing back to the eCos community :
Which development model - cathedral or bazaar?

The bazaar of course. eCos is developed using an open development model. In addition to the full releases anonymous CVS access to the current development sources is provided. Discussions about the system will generally be held in the open ecos-discuss mailing list. However it is necessary to apply a caveat to this: some developers prefer to keep their commercial work confidential, for example due to non-disclosure agreements. It is only when that port is distributed that all the eCos code must be made available under the terms of the GPL.


(Answer) (Category) eCos FAQ : (Category) Contributing back to the eCos community :
How do I contribute?

There are ways of contributing to eCos development which involve very little effort. Providing constructive comments on any part of the system, including the documentation and the web site, helps us to identify areas which need improvement. Reporting a problem gives us a chance to fix it, especially if you provide us with a simple test case and sufficient information to reproduce the problem. Participation in the discussions in the ecos-discuss mailing list gives us a better understanding of the user community, and perhaps some new ideas.

If you wish to contribute to the actual code there are multiple levels of involvement. You can write a new package. This could be a HAL package as part of a port of the system to new hardware. It could be a device driver. It could provide some new functionality such as a graphics library. It could be a port of some existing software that is appropriate for embedded systems. You can enhance an existing package, for example the eCos kernel. If you find a bug in the system then you can provide a patch that fixes it. You may also find a way to rewrite some existing code so that it becomes more efficient and/or needs less memory. You may add new functionality. Contributions to the documentation and to the test suites are particularly welcome, since these areas are often overlooked by contributors.

All patches should be submitted by creating a new Bugzilla report, setting the Component field to Patches and contributions. Discussion of the patch may take place there, and indeed an eCos maintainer may advise you of any mistakes in the patch, or any other reason why the patch may not be included in eCos. For non-trivial patches to the core system we generally require a copyright assignment.


(Answer) (Category) eCos FAQ : (Category) Contributing back to the eCos community :
What code contributions would be accepted?

The most important criterion is that the contribution must enhance the system. If it meets this fundamental criterion then there is a good chance that the contribution will be accepted. More specific criteria include the following:

  1. It must not have undesirable effects in terms of code size, data size, CPU cycles, or determinism of the system. This restriction can be relaxed if the new behavior can only be explicitly enabled by means of one or more configuration options.

  2. It must be portable to all affected platforms. Usually this means that for anything except a new HAL package the code must be fully portable.

  3. It should adhere to the project's coding standards. Most importantly the new code should contain appropriate assertions and comments.

  4. Where appropriate (which is nearly always) it should be accompanied by appropriate test cases and documentation.

  5. There must not be any confusion about licensing or ownership. This may require a copyright assignment.

A contribution need not meet all these requirements immediately. In fact it often makes sense to start with a proposal on the an appropriate mailing list, possibly including an initial patch which is known to be unacceptable, with the understanding that the contributor will make further changes. If there are major problems with the proposed contribution then it is better to detect these early on. If there is existing code elsewhere which does much the same job then it is good to know about this as well, to avoid duplication of effort. There may be better and easier ways to tackle the problem.


(Answer) (Category) eCos FAQ : (Category) Contributing back to the eCos community :
Why do I need to sign a copyright assignment?

If a contribution involves a significant change to part of the core system, for example the kernel, then usually we will need a copyright assignment before we can incorporate the changes into the system. The reason for this is to protect the community at large. In theory there is no need for copyright assignments because all changes to code covered by the eCos public license are also covered by that license. In practice copyright assignment provides a useful extra level of protection.

As an example, consider a scenario where a junior programmer makes a change to the system and releases it without the knowledge or consent of management. Some time later management finds out about the contribution, and decides that it should not have happened. The junior programmer gets severely reprimanded. The company's lawyers now approach various users of eCos, claiming that the contribution violated the company's copyright or quite possibly a patent, and demanding royalties. Until the issue gets resolved there would be a significant amount of fear, uncertainty, and doubt amongst the development community. This would be very harmful. The process of copyright assignment should prevent this and many other scenarios from ever arising, because it includes having a disclaimer signed by an officer of the company or a person with the necessary authority.

We are aware that copyright assignments involve an unpleasant amount of bureaucracy for many contributors, especially since we have to deal with the paperwork at the other end. However, we believe that the additional protection offered is necessary for the eCos user community as a whole.


(Answer) (Category) eCos FAQ : (Category) Contributing back to the eCos community :
I want to start work today! What should I work on?

Our contributions page indicates various projects that people are working on. In the future, these pages will be expanded to include projects that have been suggested but have not yet started. Typically additions to these projects will be proposed on the ecos-discuss mailing list, discussed for a while, and then a summary will be prepared.


(Answer) (Category) eCos FAQ : (Category) Contributing back to the eCos community :
Will external developers be given write access to the anonymous CVS repository?

At this time, the only developers allowed direct write access to the anonymous CVS repository are the eCos maintainers. A developer may be co-opted to become an eCos maintainer if he or she has been a valued contributor in the past.

However, at some future stage, once there are a sufficiently large number of external developers, some of these developers may well be given write access to the CVS server.

For contributed packages which are not in the core system, the intention is eventually to set up a separate area on the anonymous CVS server and give the relevant developers write access to just the relevant directories.


(Category) (Category) eCos FAQ :
Miscellaneous
Questions that don't fit anywhere else!
Subcategories:

Answers in this category:
(Answer) Where can I get hold of printed documentation?
(Answer) How to determine the size of eCos applications
(Answer) Where's the Memory Layout Tool?
(Answer) My simple program should sleep, but it just hangs

(Answer) (Category) eCos FAQ : (Category) Miscellaneous :
Where can I get hold of printed documentation?

Suitable PDF files are available online. The HTML versions of the documentation are included in the main release files, and are also available separately. eCos documentation is not available in hard copy at present.


(Answer) (Category) eCos FAQ : (Category) Miscellaneous :
How to determine the size of eCos applications
A common question asked is "how big is an eCos application", or "why is
'hello world' 2MB?"  Here's a recent discussion which should help.


On Tue, 2003-10-07 at 08:23, James Yates wrote:
> Can anyone tell me what they think should be the approximate footprint 
> size of a basic eCos kernel built on an SH or i386 platform. I am in 
> the process of porting to a new SH2 processor and target platform, but 
> when I build my eCos library libtarget.a comes out at 2924kB. This sounds 
> excessively large to me but I am new to eCos so have no idea of what it 
> should be.

You can't tell anything from the size of libtarget.a - it contains 
*everything* in the kernel, along with massive amounts of debug
information.  Also, the size of your resulting eCos application
will vary with a number of factors, not the least of which are
all of the possible configuration parameters which are under your
control.

The size of an actual kernel+application could be as small as
50KB (not much there, really) up to maybe 200KB if you include
network stacks and such.

There really is no one answer for your question - you'll just
have to see how it plays out.  Just don't forget to look at the
real sizes, not file sizes, as there will be a vast difference
between the two.  Here's an extreme example - a PowerPC based
system, including the VNC server:
  [gthomas@hermes download]$ ls -l vnc-test 
  -rwxr-xr-x    1 gthomas  wheel     5682765 Sep  1 19:33 vnc-test
  [gthomas@hermes download]$ powerpc-eabi-size vnc-test 
     text    data     bss     dec     hex filename
   346184       0  660376 1006560   f5be0 vnc-test
  [gthomas@hermes download]$ ls -l lib/libtarget.a 
  -rw-r--r--    1 gthomas  wheel    14179440 Sep  1 19:33 lib/libtarget.a

With this setup, my libtarget.a is over 14MB! but the resulting
program is ~350KB of code.
garyATmlbassocDOTcom
(Answer) (Category) eCos FAQ : (Category) Miscellaneous :
Where's the Memory Layout Tool?
The original ConfigTool (which ran only on Windows) had a feature called the
Memory Layout Tool which helped describe the memory regions, etc, for a given
platform.  With the change to the new ConfigTool (now written using WxWindows
and running on Linux as well as Windows), support for the MLT has not yet been
implemented.

Sorry, but there is no schedule for when this will be added, so in the meantime
there are two arrproaches for creating & maintaining MLT files:
  * Find a copy of the old ConfigTool [hard, cumbersome]
  * Hand edit your config files.  While this is tedious, it's not difficult.
    Start by copying known working files and edit them, trying to keep things
    synchronized (i.e. the .h and .ldi files reflect what's in the .mlt file)

Volunteers to restore this functionality will be gladly received!
garyATmlbassocDOTcom
(Answer) (Category) eCos FAQ : (Category) Miscellaneous :
My simple program should sleep, but it just hangs
This simple little program may not work.

  #include <stdio.h>
  int main(void) {
    printf("Hello, world!  Now sleeping for 5 seconds.\n");
    cyg_thread_delay(5*100);
    printf("Back from the dead :-)\n");
  }

Why?  Because "cyg_thread_delay()" takes a cyg_tick_count_t argument, which
is typically a "long long" value.  The compiler doesn't know this and without
any sort of prototypes and/or casts, it will send the wrong sort of value
to cyg_thread_delay().  In most cases, this will cause an arbitrarily long
delay!

Solution?  Simply add this line:
  #include <cyg/kernel/kapi.h>
This will define the native eCos kernel API, as well as prototypes for
all of the kernel functions.  et voila!
(Category) (Category) eCos FAQ :
Questions not covered you would like answered
Use this section for questions not covered in the rest of the FAQ but that you think should be answered in it. Not every question is suitable for the FAQ though, especially if it isn't generally applicable. So consider if your question would be better suited to the ecos-discuss mailing list.
Subcategories:

Answers in this category:

(Answer) (Category) eCos FAQ :
New Item
This document is: http://ecos.sourceware.org/fom/ecos?file=1
[Search] [Appearance] [Show Top Category Only]
This is a Faq-O-Matic 2.719.

Send any queries about the contents of this FAQ to the ecos-discuss mailing list
Send any operational queries about this FAQ to the eCos maintainers