[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

ANNOUNCE: CORBA for RTEMS --- omniORB2.7.1 ported to RTEMS

I am happy to announce the porting of omniORB2 to RTEMS.

Please visit this site for more information:


Regards, Rosimildo.
| ConnectTel, Inc. - Austin, Texas.
| Phone : 512-338-1111 - Fax : 512-918-0449
| Email : devl at connecttel.com  or mkting at connecttel.com
| Site  : http://www.connecttel.com

         omniORB2 for RTEMS - Embedded System

This file contains information on installing, building, and using
omniORB2 with RTEMS a Real-Time Operating System for Multiprocessors.
This initial port was tested with RTEMS running on a PC ( pc386 BSP ).

OmniORB2 for RTEMS has been tested with the following
software configuration:

- HOST OS           : NT 4.0 - Cygnus-b20.1 and Linux
- RTOS                  : RTEMS-19990528
- omniORB2         : omniORB-2.7.1
- Architecture        : i386-elf and BSP = pc386
- Cross Compiler  : egcs 1.1.2, binutils-2.9.1, newlib 1.8.1   + RTEMS

NOTE: Access to private RTEMS snapshots is required.

Extra "fixes" are necessary to get EGCS and RTEMS ready to
handle C++ code. They fix Global Ctors/Dtors and C++
exception handling. Please, go to ConnectTel web site
to get these patches. If you are not familiar with the EGCS toolset,
we would recommend you to wait these patches to become integrated
into their distributions.

After applying the patches, use the CDTEST example that comes with
RTEMS to make sure that the cross compiler that you use it is ready
to handle C++ code.

Everything regarding RTEMS, and RTEMS' cross compiler can be
downloaded from OARCorp web site.

For more recent news about this porting or more information about
CORBA on embedded systems, please go to:


This file accompanies a RTEMS adaption kit for omniORB 2.7.1. As such,
it does not contain the complete set of omniORB source files.
These must be obtained from the omniORB web site at

RTEMS and all tools needed to develop for it can be downloaded
from OARCorp web site at: http://www.oarcorp.com

The adaption kit contains:

a) Modified versions of a small number of original omniORB source files;
b) New source files to adapt omniORB examples to run on RTEMS.
   The new files are necessary to provide RTEMS'configuration
   tables, and setup of the Init Task.

At this point, the adaption kit supports building:

a) The orb-run-time ( all libs );
b) all examples;

What has been tested ?

  - All "thread" examples have been tested.
  - Three of "echo" examples have been tested:  eg1, eg3_impl and eg3_clt
  - All others examples compile and link properly, but they have not
    been tested.

What was changed ?

  - ORB run-time( lib ):

    a) C++ source code, three files got changed: omnithread.h,
       omniInternal.h and posix.cc.
    b) Most of the changes on the run-time were to the
       makefiles( dir.mk ).

  - omniORB examples:

    a) change to rename the "main()" routine to "cc_main()",
       when compiling for RTEMS,  to all modules that has a main().
    b) change to all makefiles( dir.mk ) to include the necessary
       modules specific to RTEMS.
    c) new directory called "rtems" was added to the examples
       to hold all files specific to RTEMS.

So, that was it !!!!.
I am fairly confident that the result of this porting is as
reliable as is omniORB and RTEMS.


The archive containing this document and the kit components
reflects the folder hierachy used by the omniORB distribution
itself, except for the root directory. The root directory
for this kit is created as "rtems".


   - Obtain the omniORB2 distribution from the web site above and
     install it somewhere on your development machine.

   - Using tar, install this kit at the same directory level
     you used to install omniORB2.

   - Copy everything from the "rtems" tree to the omniORB
     tree hierachy. Do this with extreme care.
     Make backups of any files that you have changed
     on the original omniORB hierachy.

     For Windows NT:
         xcopy  rtems\*.* omniORB-2.7.1\*.* /s/v/e

   - Update the native IDL compiler on your new omniORB tree.


Before you start building the system, you need to change the makefile
mk/rtems.mk to match your RTEMS' cross compiler and corresponding
RTEMS tree.

Most likely the following macros needs to be udapted:

RTEMS_BUILD        = $(HOME)/tools/build-i386-elf-rtems
This macro is set to the location of the RTEMS build.

RTEMS_INSTALL_POINT = $(HOME)/gcc-i386-elf-rtems
This macro is set to the location of the RTEMS' cross compiler

RTEMS_CC_PREFIX     = i386-rtemself-
This macro is set to the prefix of the RTEMS cross compiler

RTEMS_BSP           = pc386
This macro is set to the name of the RTEMS BSP.

HOSTBINDIR = bin/x86_win32
The HOSTBINDIR variable is used to locate the HOST IDL compiler.
Somehow you have to get the IDL compiler ready before you start
building omniORB2.

IMPORTANT NOTE: It is required to have a native omniORB IDL
  compiler ( omniidl2 ) for the host machine.

A few other macros might need to be changed for your environment,
but the aboves will cover most of the cases.

How to get Started ?

- Get started with the examples that comes with the
  omniORB2 distribution.
- Make sure that you have a working environment.
  Use the omniORB examples on your native host for that.
- Make sure that a Naming Service is configured and
  working properly.
- Check if RTEMS and its TCP/IP stack is configured
  and working. Use RTEMS' network examples for that.

If you managed to get all of the above configured and working
correctly, you will not have problems getting the omniORB
examples running on your environment.

IMPORTANT: After you apply the porting changes to the
           omniORB tree, modify the file
           "src/examples/rtems/net_cfg.h" to match the
           network configuration of your RTEMS system.

System Requirements

omniORB2 seems to be one of the smallest ORBs around.
But, for embedded system standards, it still has a
large footprint. The smallest application using omniORB
run-time would require around 800K of code space and 65K
of data space, plus all the dynamic memory needed( heap ).

So, targets with less than 1 Meg of Code Space and
0.5 Meg of RAM for data space, would certainly not
be good candidates to run CORBA applications.


  - a working standard CORBA Naming Service --> omniNames
  - omniORB2 IDL compiler      --> omniidl2
  - a working TCP/IP Stack between the machine running
    the CORBA Naming Service and the RTEMS target.
  - Cross Compiler for RTEMS with Global Ctor/Dtor and
    C++ exceptions working.
  - TCP/IP naming service - DNS
    NOTE: If you do not have a DNS up and running,
          you can use the file no_dns.c ( examples/rtems )
          to fake a few of the RTEMS routines. If you use
          this file, you must edit it to match your
          network settings.


- Memory
     - Code Space --> 766 K bytes
     - Data Space --> 512 K bytes

- TCP/IP stack configured and working properly.

- Stack Sizes
  The default size of the stacks of the threads created by
  the omniORB run-time is 16K. You can try to reduce
  this size, but be aware that no test has been done
  with smaller stacks.

See some comparative numbers for code and data spaces for
a small CORBA sample and a plain RTEMS sample to get an idea
of the footprint required by omniORB.

CASE #1 - RTEMS' cdtest example without iostream support:

   text    data     bss     dec     hex filename
138933    5399   22700  167032   28c78 cdtest.obj

CODE --> 138K
DATA -->   5K
BSS  -->  23K

CASE #2 - RTEMS' cdtest example with iostream support:

   text    data     bss     dec     hex filename
193301    6327   23148  222776   36638 cdtest.obj

CODE --> 193K
DATA -->   6K
BSS  -->  23K

CASE #3 - omniORB eg3_impl example:

   text    data     bss     dec     hex filename
765789   34239   30068  830096   caa90 eg3_impl.elf32

CODE --> 766K
DATA -->  34K
BSS  -->  30K

As you can see, omniORB adds a footprint of 650K for a
minimal application.


Issues to be addressed later:


About the Examples

All of the original omniORB examples have been modified a little
bit because RTEMS requires an "Init" task to be created. This is
accomplished using a new module called "init.cc" that does all
RTEMS initialization and invokes a C++ routine called
cc_main( int argc, char **argv ).

All "thread" and some of "echo" examples have been tested
with the following configurations:

   RTEMS  <----------------------->   NT 4.0     NT 4.0
   eg3_clt        eg3_impl   omniNames
   eg3_Impl        eg3_clt    omniNames

   RTEMS  <----------------------->   Linux      NT 4.0
   eg3_clt        eg3_impl   omniNames
   eg3_Impl        eg3_clt    omniNames

RTEMS running on a PC 486DX  --> BSP pc386

NOTE2: no_dns.c
  - This was included to support test environments that do not
    have a DNS available.  For setups that have a working DNS,
    this file should be removed from the makefiles.


There are some file under src/examples/rtems that are used for

NOTE:  This is specific to PC386 BSP.

    cmds       - a list of directory with source files; commands to
                 link to the remote target using a com port.
    gdb_glue.c - file with initialization to GDB on the target.
     It helps for remote debugging.
     This is for pc386 only.

timerticks.* - this class provides a hi-resolution timer class
that could be used to measure timeouts and
intervals( resolution < 1uSec ). It uses the PC timer.
Specific to PC386 BSP.


Thanks to all participants of the RTEMS and omniORB's lists
for all your help.

I'd like to make special mention of:

  ( RTEMS' list )
  - Joel Sherrill       <joel at oarcorp.com>
  - Erik Ivanenko    <erik.ivanenko at utoronto.ca>
  - Ian Lance Taylor     <ian at zembu.com>
  - D. V. Henkel-Wallace <gumby at zembu.com>

  ( omniORB's list )
  - David Riddoch  <djr at uk.research.att.com>
  - Sai-Lai Lo   <S.Lo at uk.research.att.com>


Rosimildo da Silva    <rdasilva at connecttel.com>
ConnectTel, Inc.