How to port RTEMS on a Cortex-M3 microcontroller

Gene Smith gds at
Mon Jul 5 17:14:09 UTC 2010

Sebastian Huber wrote, On 07/05/2010 03:09 AM:
> On 07/04/2010 10:51 PM, Gene Smith wrote:
>> Sebastian Huber wrote, On 06/23/2010 04:19 AM:
>>> [...]
>>> Try to compile code for you processor with standard ARM tools
>>> (arm-rtems4.10-{gcc, as, ld}).  If this doesn't work, then file a PR
>>> in the
>>> RTEMS bugzilla.
>> I just built my non-rtems cortex-m3 app with the latest arm-rtem4.10-*
>> toolchain from yum with no errors. I don't have a way to test it right
>> now but at least it builds with no errors. The only arm/cortex-m3
>> options I am using are:
>> -mcpu=cortex-m3 -mthumb
>> (I suspect -mthumb is redundant since cortex-m3 only run thumb-2 code.)
> What do you mean with non-RTEMS application?  Do you use parts of Newlib, e.g.
> memcpy()?

It is just bare-metal code with minimal calls to newlib. It does do some 
soft-floating point arithmetic.

>> My application uses ST Micros's stm32 thumb-2 startup and vector init
>> assembly code. Otherwise it is just c code.
>> I usually build this with codesourcery lite arm-none-eabi-* tool chain.
>> Does this indicate that the rtems toolchain is OK or is runtime
>> verification needed too?
> Since the Thumb-2 instruction set is backward compatible to the Thumb-1
> instruction set it should work.  A missing Thumb-2 multi-lib is probably a
> performance penalty.

I see what you mean. If I called memcpy or other newlib function I would 
be calling into the "thumb" multilib under lib and it would work but slower.

The cs gcc install does have a thumb2 multilib under lib while rtems gcc 
install doesn't. So I guess it needs to be added. I don't know much 
about this but it appears, and you probably know this, that rtems has a 
file called gcc-4.4.4/gcc/configure/arm/t-rtems that contains this:

# Custom rtems multilibs

MULTILIB_OPTIONS     = marm/mthumb
MULTILIB_DIRNAMES    = arm thumb
MULTILIB_MATCHES     = marm=mno-thumb

MULTILIB_OPTIONS    += msoft-float/mhard-float
MULTILIB_EXCEPTIONS += *mthumb/*mhard-float*

While cs-lite contains a similar file called t-cs-eabi-lite that 
contains this:

# We build 4 multilibs:
#  ./		  (default)
#  thumb/	  -mthumb
#  thumb2/	  -mthumb -march=armv7
#  armv6-m/	  -mthumb -march=armv6-m


MULTILIB_OPTIONS      += march=armv7/march=armv6-m
MULTILIB_DIRNAMES     += v7 v6-m
MULTILIB_EXCEPTIONS   += march=armv7*
MULTILIB_MATCHES      += march?armv7=march?armv7-a
MULTILIB_MATCHES      += march?armv7=march?armv7-r
MULTILIB_MATCHES      += march?armv7=march?armv7-m
MULTILIB_MATCHES      += march?armv7=march?armv7e-m
MULTILIB_MATCHES      += march?armv7=mcpu?cortex-a9
MULTILIB_MATCHES      += march?armv7=mcpu?cortex-a8
MULTILIB_MATCHES      += march?armv7=mcpu?cortex-a5
MULTILIB_MATCHES      += march?armv7=mcpu?cortex-r4
MULTILIB_MATCHES      += march?armv7=mcpu?cortex-r4f
MULTILIB_MATCHES      += march?armv7=mcpu?cortex-m4
MULTILIB_MATCHES      += march?armv7=mcpu?cortex-m3

MULTILIB_EXCEPTIONS   += march=armv6-m
MULTILIB_MATCHES      += march?armv6-m=mcpu?cortex-m1
MULTILIB_MATCHES      += march?armv6-m=mcpu?cortex-m1

# FIXME: We need a sane way of doing this.
# This isn't really a multilib, it's a hack to add an extra option
# to the v7-m multilib.
MULTILIB_OPTIONS      += mfix-cortex-m3-ldrd
MULTILIB_DIRNAMES     += broken_ldrd

MULTILIB_EXCEPTIONS   += mfix-cortex-m3-ldrd
MULTILIB_EXCEPTIONS   += mthumb/mfix-cortex-m3-ldrd
MULTILIB_EXCEPTIONS   += *march=armv6-m*mfix-cortex-m3-ldrd


# As of at least 4.2, gcc passes the wrong -L options if some multilibs are
MULTILIB_OSDIRNAMES    = mthumb=!thumb
MULTILIB_OSDIRNAMES   += mthumb/march.armv7/mfix-cortex-m3-ldrd=!thumb2
MULTILIB_OSDIRNAMES   += mthumb/march.armv6-m=!armv6-m

I assume the t-rtems file would need to be updated based on contents 
similar to the above.


More information about the users mailing list