building RTEMS alone

Ahmet Akkas akkas at lucent.com
Wed Aug 2 13:53:07 UTC 2000


Hi,

First, I want to thank Ralf and Joel for their email.



Ralf Corsepius wrote:
> 
> Preliminary note: I don't know anything about lucent processors :)
> 
> Joel Sherrill wrote:
> >
> > If the .h files are in INSTALLPOINT/TARGET/include then RTEMS
> > will automatically see them.
> >
> > The configure line by hand should be something like this:
> >
> > .../rtems-XXX/configure --target=lucent16000-rtems \
> >   --prefix=INSTALLPOINT
> >
> > I don't know what "target" cpu you are calling the 16000.
> AFAIS from poking around at lucent's www-site and into config.sub, I
> think using "dsp16xxx-rtems" or "dsp16000-rtems" might be
> appropriate.
> 
> > I would guess that config.sub has to be modified though.
> Yep. I think tracing and extending how the dsp16xx family is treated
> in config.sub is the closed possible solution. (AFAIU, the dsp16xx
> family is the predecessor of the dsp16xxx family. It may also be the
> case the dsp16000 is a member of the dsp16xx family :).
> 
> >
> > It sounds like you are getting past the intial configure
> > steps though. :)


Yes, you are right. config.sub is already modified to support dsp16k-rtems.


> >
> > I hope this helps.
> >
> > --joel
> >
> > Ahmet Akkas wrote:
> > >
> > > Hi everybody,
> > >
> > > I am working on porting RTEMS to Lucent's 16000 DSP processor by using
> > > Lucent's tools (compiler, assembler, etc.). I have already build newlib
> > > library. Right now I want to build RTEMS without using bit_rtems script
> > > (as you know bit_rtems build gcc and newlib together). I used bare bsp
> > > option only build the kernel.
> > >
> > > Anyway, my question is the following:
> > > I will run configure command with its options under the build directory.
> > > The part I do not know is that even in the configure command, I set --includedir
> > > variable to the library I want to use it, configure command it copies the
> > > content of "includedir" to the Makefiles under the build directory but in
> > > the compilation (it was compiling libc) it still does not include the directory
> > > I specified in configure command.
> 
> In general, includedir and libdir are supposed to point to
> directories were headers and libraries shall be *installed*. From
> autoconf.info:
> > [..]
> > - Variable: includedir
> >      The directory for installing C header files.
> > [..]
> > - Variable: libdir
> >      The directory for installing object code libraries.
> [Building RTEMS does not apply these variables.]
> 
> Instead you need to set up a set of environment variables to let the
> Makefiles find the libraries and header files. Try to track how
> CC_FOR_TARGET, CFLAGS etc. are being setup in make/custom/<bsp>.cfg
> (esp. make/custom/default.cfg and
> make/compilers/gcc-target-default.cfg - Though the name
> "gcc-target-default.cfg" is misleading, this file is supposed not to
> be specific to gcc. It's named this way for historical reasons :).
> 


Here it is. gcc-target-default.cfg file we found yesterday. It has CPPFLAGS
variable and it has the following:

CPPFLAGS += -nostdinc \
  -I$(PROJECT_INCLUDE) \
  -I$(GCC_INCLUDE) \
  -I$(RTEMS_LIBC_DIR)/sys-include \
  -I$(RTEMS_LIBC_DIR)/include

This was the include files I was looking for. I need to find out a way
to able to set last three (GCC_INCLUDE, RTEMS_LIBC_DIR, RTEMS_LIBC_DIR)
include directories correctly by using configure command.


> Something else that will ease porting RTEMS with a non-gnu toolchain
> (And which I recommend to do) is to apply the gnu-toolchain's naming
> conventions to the toolchain's binaries. I.e. to install a copy or
> shell script wrapper of each tool (cc, as, ld etc.) of the toolchain
> as <target>-tool, e.g. copy <path>/lucent/dsp16000/cc to
> <somewhere>/bin/dsp16xxx-rtems-cc and make sure these can be picked
> up from $PATH.


This is done. Thanks anyway.

 
> Additionally you should configure RTEMS with --disable-gcc28 to
> disable building RTEMS using features which are only present in gcc
> >= 2.8. Unfortunately, most actively supported RTEMS ports have only been built/tested with toolchains using gcc >= 2.8, so I would not be surprised this to trigger bugs in RTEMS configuration.
> 


Thanks, I will do that.


> I hope this helps a little.
> 
> Ralf
> 

Sure. It helped. Thanks a lot.


> --
> Ralf Corsepius
> Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung
> (FAW)
> Helmholtzstr. 16, 89081 Ulm, Germany     Tel: +49/731/501-8690
> mailto:corsepiu at faw.uni-ulm.de           FAX: +49/731/501-999
> http://www.faw.uni-ulm.de


Ahmet Akkas



More information about the users mailing list