Building RTEMS for an MC68F333

[Joel Sherrill]

On Thu, 21 Aug 1997, Robin Kirkham wrote:

> I'm trying to build an RTEMS BSP for an in-house MC68F333 module. The 68333
> has a CPU32 core. I thought I'd start with the efi332 BSP and work from there.
> 
> During the compile it complains ... HOW DO I INSTALL THE INTERRUPT STACK!!!.
> This warning comes from c/src/exec/score/cpu/m68k/cpu.c. The CPU32 indeed 
> has no separate interrupt stack.
> 
> So: should I ignore this message? I presume the running task's stack gets
> used instead. Or, does it break somewhere? If so, why the message?

This message indicates that for m68k family members without hardware
interrupt stack support, there is no software maintained interrupt
stack.  Here is the comment from cpu_asm.s:

 *  NOTE FOR CPUs WITHOUT HARDWARE INTERRUPT STACK:
 *
 *  After the interrupted codes registers have been saved, it is save
 *  to switch to the software maintained interrupt stack.
 *
 *  PLEASE, if you have a m68k without a dedicated interrupt stack,
 *          implement the stack switching code.
 */

In this case interrupts use the stack of the task they interrupted.

Basically, the message is there to encourage people to look into this
and implement the missing feature.

> Second question: I am compiling using gcc 2.7.2.2 -m68332, since I assume this
> is also right for the 68333, since it is also a CPU32. But I observe in the
> CPU feature definitions in c/src/exec/score/cpu/m68k/m68k.h a distinction is
> ma between the 332 and a CPU32. (I also remember something about gcc CPU32
> support in the cross-gcc list, but the archive seems to have disappeared from
> me). Why is this, and does it matter?

The domain name for the crossgcc archive site recently changed.  I do not
remember the new domain name offhand.

I have not looked at a 68333 manual so nothing I say is definitive.  The
difference you are referring to is the setting of M68K_HAS_PREINDEXING. 
It is quite possible that this is not set correctly for one of the two
CPUs (more than likely the 332).  If the CPU32 core and 332 supports
preindexing address mode, then this field should be 1.  This controls
whatever m68k assembly code uses preindexing mode. 

The toolset issue is broader than just rtems, FSF gcc, and crossgcc.  I
would recommend that you take a look at the snapshots made available by
the EGCS development group (www.cygnus.com/egcs).  We have not had time to
test them yet but they have rtems configurations and are based on the
latest gcc snapshots.  The m68k and coldfire support is better than gcc
2.7.2.2. 

I can forward the EGCS announcement to the list if someone missed my
announcement on comp.realtime.

> Robin Kirkham			CSIRO Manufacturing Science and Technology
> Project Engineer		Locked Bag 9, Preston 3072, Australia
> robin.kirkham at mlb.dmt.csiro.au	Phone: +61 3 9662-7756  Fax: +61 3 9662-7853

When you are using RTEMS on a project, you really should consider
getting a support contract.  This gives you access to better documentation
and newer versions than are available via the Army site.  We now maintain
and enhance RTEMS on our own with no support from the Army as was the
case in the past.  Enhancements/fixes are now customer driven.

Yes, eventually a post-3.6.0 public release will occur but we have to
test it thoroughly and fix problems encountered by customers and
early testers first.  We cannot afford to publicly release a version
which we think will be a support nightmare.  The current working
source includes some very noticeable features including Eric Norum's
port of the KA9Q TCP/IP stack, Chris Johns' C++ class wrappers, and
configuration via GNU autoconf.  <Marketing off>

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