newbie questions

[Joel Sherrill]

Wulf Hofbauer wrote:
> 
> Hi again,
> 
> On Tue, Oct 08, 2002 at 06:51:35AM +0200, Ralf Corsepius wrote:
> > Am Die, 2002-10-08 um 04.00 schrieb Till Straumann:
> > RTEMS 4.5.0 is ancient and so are its docs ;)
> 
> What would be the best version to get started with RTEMS? 4.5.0
> is the most recent stable version I found.
> My main focus is on getting an initial version of my application
> up and running before I can think about hacking development
> versions.

RTEMS development snapshots are generally well tested.  They are
not random daily drops cut automatically.  With few exceptions,
every BSP is compiled and a handful tested before each snapshot.

> > gcc-3.2 and binutils-2.13 probably won't work with rtems-4.5.0.
> 
> But... WHY? As long as you can translate the C and assembly
> routines and link them, it shouldn't really matter, no? Gcc and
> binutils aren't THAT buggy either ...

It isn't gcc or binutils in particular.  It is the delicate dance
of gcc+newlib+binutils+gdb+rtems.  Each has to agree on the 
object format for the CPU, who owns which header files, how
debug information is generated, which cpu model arguments
get passed to as and ld, etc.  There are actually a lot of
small integration details that can go wrong.

> Is there a real problem with the toolchain, or is it simply the
> building procedure that is so highly version dependent?

RTEMS and newlib versions go hand in hand.  For a complete
POSIX/libc set of .h's each owns particular slices of the pie. 
The set of who owns what has shifted at least twice in a 
significant way.  

> > 2. There exists a bootstrap/"hen and egg" problem between newlib, RTEMS
> > and gcc, which is difficult to solve: RTEMS implements the lowlevel
> > OS-related parts of libc, newlib implements a set of general mid-level
> > parts of libc, RTEMS implements another set of these mid-level parts and
> > even worse, gcc also implements a certain set of libc-related parts
> > (libgcc rsp. libgcc_s).
> 
> This sounds pretty messy to me (isn't that a maintainance
> nightmare?). To me, it looks like an exercise in frustration
> to get all the specific tools + patches together in order
> to build the kernel (before even doing anything useful).
> It's definitely a deterrent factor to using RTEMS.

It isn't that difficult to get started.   Pick a version and
use the tools that went with that version.  

If you are on Linux, grab the latest snapshot and the 
tool versions documented there in a file in the release
directory.  Load the RPMs and build.  10 minutes to code
on a target.

If you have your own BSP, use the autoconf/automake
versions that match RTEMS.  You do NOT have to bootstrap
unless you add/delete files.

> > > Hmm I wouldn't expect a clean separation between the layers
> > > but rather quite some amount of glue...
> > Exactly, this is one essental part core of the problem. But, ... RTEMS
> > has evolved, newlib has evolved, gcc has evolved and binutils has
> > evolved => "the glue" is in permanent motion.
> 
> I understand glue is needed to interface newlib to RTEMS (and
> that glue would then be part of newlib, not RTEMS), but I
> fail to see why newlib is required to build RTEMS itself.
> For applications on top of RTEMS, a C library can be useful,
> but why for the kernel? 

We like to use memset/memcpy also. :)

Also the balance is bit different than you see.  RTEMS actually provides
a lot of the C library routines such as file IO and reentrant 
functions itself.

> And why does it have to be newlib?

What is the free alternative?  The RTEMS Project does not believe
pure GPL'ed code is appropriate for inclusion on embedded systems.
So ignoring how big glibc is, glibc is out based upon licensing
issues.  We do not force license compliance requirements on end users.

> > > Well, AFAIK, RTEMS implements parts of the C library (e.g.
> > > lowlevel-malloc, reentrancy, ...). Hence, you'd expect it to
> > > certainly depend on the newlibc headers.
> 
> Newlib glue code may depend on the RTEMS headers, but I don't see
> why it should be the other way round.

Actually newlib doesn't depend upon RTEMS to be installed.  You must
have newlib installed to build RTEMS though.

> > This is not any different from other OSes, eg. Linux where interfacing
> > glibc2 and gcc is a similar problem (You might have heared about the "To
> > whom does /usr/include/[linux|asm] (aka. the kernel-headers) belong
> > issue).
> 
> Well, AFAIK Linux doesn't depend on any C library at all. The
> kernel is self-contained (as it should be), and libc is built on
> top if it is needed. You can choose which C library you want, if
> any.

RTEMS is not UNIX -- it is a link in real-time kernel/executive/OS.

> > Try to build a linux from scratch and from sources only (without
> > having a linux c-compiler or glibc binary, you will encounter the same
> > issues then.
> 
> Linux doesn't limit me to a specifically patched rigidly specified
> version of gcc or binutils for one ...

I think it does more than you realize.   The Linux kernel folks 
complained enormously that it couldn't be compiled because
it tripped bugs in gcc.  I also recall that the deprecation 
of multi-line inline assembly statements caused quite
a stir.

There is a certain of version options even on Linux.  Do you
remember the initial transition to elf?  The glibc1 to 
glibc2 transition?  

The RTEMS Project kept a RedHat 5.2 box alive for years to
build RPMs on to give compatability until even those wouldn't
broke somewhere around RedHat 7.x.  Eventually we got into
both version problems on support libraries and RPM itself.

> I'm still hoping to be able to use RTEMS, but so far the
> "out-of-the box experience" has been less than encouraging.
> For an OS hacker, that may be appealing, but I have a real world
> instrumentation problem to solve ...

And why didn't you just grab the tools that matched the RTEMS 
version?  Start at
ftp://ftp.oarcorp.com/pub/rtems/snapshots/rtems/current
(should be ss-20021007) and use the tool versions listed with the
snapshot.

Do you have a custom BSP?  If no, then you don't have to bootstrap.
Just configure, build, install and work.

> - Wulf

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985