The 68k/Coldfire Update

Dan Smisko dan at
Tue Jan 21 02:10:00 UTC 2003

I have just gone down the update road for the 68k, from
rtems4.5.0/gcc2.95.2/autoconf2.13/automake1.4 to the latest
snapshot and tools, all from source.  So for anyone
contemplating this step, this may help you avoid some trouble.

My program was crashing, and I couldn't figure out why.  So,
let's update.  I downloaded the latest rtems snapshot, and
autoconf and automake start spitting out errors.  And so did
g++.  Oh boy.  New tools.  I have a 2.2.14 kernel, and the
binary rpm's all needed new libc, etc, etc, etc.  I was ready
to update linux, but Joel said that building the tools wasn't
too hard.

First I got the latest automake and autoconf from gnu and
installed them, because they were needed for configuring rtems
and the bsp.  I configured them as m68k-rtems-autoconf, etc.,
and put them in /opt/rtems/bin so they wouldn't collide with
the old versions on the system.  Then I would set AUTOCONF,
etc.  variables when I needed to use the new stuff.  It turns
out that a newer (than 4.0) makeinfo was needed for gcc docs.
However, configure ignores MAKEINFO. So you have to make a
link to m68k-rtems-makeinfo, or whatever, if you want to keep
your old stuff.

Then I downloaded the source for the tools from
Used the "bit" script to build them.  Went smoothly.  "Getting
Started" describes this pretty well.  You don't need any of
the new autoXXXX stuff for this step.  I changed "bit" a
little to suit me.

Then I got all the stuff for gdb 5.2.  I also needed the bdm
patch.  Aaron Grier was very helpful with the 5.0 - 5.2 bdm
changes.  The bit_gdb script needed a tweak for building the
bdm version, or you could just configure and build manually.
Remember to use the --target=m68k-bdm-rtems option for
configure.  I don't know what all the gdb patches are for, but
I threw them in.  You do need the 5.0 bdm driver with gdb 5.x.

Next was moving and for the bsp and
some library code.  I am NOT an expert in autoconf and
friends, so this was not fun.  Fortunately, the other m68k
stuff provided enough examples.  There was much cursing, and
this turned out to be the most time-consuming part.

Acinclude.m4 in the m68k directory has to be changed to
include the bsp, then run $AUTOMAKE and $AUTOCONF. Go to the
bsp directory and run bootstrap.  The bootstrap script had to
be fixed to use the AUTOCONF (and other) environment variables

A few things moved to different directories, library names
changed, etc.  Nothing serious, but usually not found until
some compile/link fails.

Then to rebuild the top-level stuff, which is C++.  The
biggest problem is changes to the "string" type.  It's not in
the global namespace any more, so "using namespace std;"
boilerplate has to be inserted where necessary.  The compiler
also complains about old xxxxx.h headers, but works ok (for
now).  None of this is specific to RTEMS, though.  I just
added the new stuff, like *(.jcr) to linkcmds because it
works.  Also make-cxx-exe needs to be set in
make/custom/<bsp>.cfg, and fix the Makefile to use it.  Then
g++ will do the linking.

Then I got greedy and decided to gather some 2.95.x patches
and put them into 3.2.1.  These include (1) hardware divide
and (2) floating point (courtesy Wayne Deeter) improvements
for coldfire.  The option -m5206e accesses hardware divide,
because that's what I'm using.  This step took quite some

The above description is sanitized for your protection.  There
were many false starts.

Anyway, my application program works and doesn't crash any
more.  Patches available, YMMV.

Hope this is helpful.  If there is something stupid I've done
(more likely) please let me know.

Dan Smisko
Balanced Audio Technology
800 First State Blvd.
Wilmington, DE  19804
(302)999-8818  fax
dan at

More information about the users mailing list