How to port RTEMS on a Cortex-M3 microcontroller
Gene Smith
gds at chartertn.net
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_EXCEPTIONS =
MULTILIB_MATCHES = marm=mno-thumb
MULTILIB_OPTIONS += msoft-float/mhard-float
MULTILIB_DIRNAMES += soft fpu
MULTILIB_EXCEPTIONS += *mthumb/*mhard-float*
<eof>
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 = mthumb
MULTILIB_DIRNAMES = thumb
MULTILIB_EXCEPTIONS =
MULTILIB_MATCHES =
MULTILIB_ALIASES =
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
MULTILIB_ALIASES +=
mthumb/march?armv7/mfix-cortex-m3-ldrd=mthumb/march?armv7
# As of at least 4.2, gcc passes the wrong -L options if some multilibs are
# omitted from MULTILIB_OSDIRNAMES
MULTILIB_OSDIRNAMES = mthumb=!thumb
MULTILIB_OSDIRNAMES += mthumb/march.armv7/mfix-cortex-m3-ldrd=!thumb2
MULTILIB_OSDIRNAMES += mthumb/march.armv6-m=!armv6-m
<eof>
I assume the t-rtems file would need to be updated based on contents
similar to the above.
-gene
More information about the users
mailing list