crossdev: buildinga toolchain for arm cortex-m4

[tomtom69]

Hi,

I am trying to build a toolchain for an arm cortex M4 device (stellaris launchpad from TI).
So far I suceeded to build a toolchain for the controller in this way:
crossdev -t arm-none-eabi
With this toolchain I am able to build simple programs which actually can be flash programmed and run on the target. So far so good.
However as soon as libc components are used, the programs crash. I found out (using objdump) that the reason is that the libc is in arm mode, but cortex M4 only supports thumb.
So if I use strcmp() the toolchain generates assembly code like:
38a: f001 e99a blx 16c0 <strcmp>
[...]
000016c0 <strcmp>:
16c0: e0202001 eor r2, r0, r1
This looks as the libc (or newlib) function "strcmp" is linked to the code for arm, but not for thumb. The instruction "blx" should change to arm mode but on cortex M4 this results in a usuage failure trap.
Specifying arm-none-eabi surely does not take a "cortex M4 = thumb only" target into account.

But how can I build an arm cross toolchain that includes a libc etc. which is compiled in thumb mode?

tom

[paulj]

Some hints/ideas, as I don't actually know the answer. I came across:

Code: Select all

make CROSS=arm-none-eabi- TARGET_SYS=arm HOST_CC=gcc
TARGET_CFLAGS="-DLUAJIT_USE_SYSMALLOC -mthumb -mcpu=cortex-m4
-mfpu=fpv4-sp-d16 -mfloat-abi=softfp -Wa,-mimplicit-it=thumb"

This suggests to me that you need to set -mthumb (and maybe some other flags) in the CFLAGS for the target. Looking at the gentoo cross development page http://www.gentoo.org/proj/en/base/embe ... opment.xml, it looks like you can set a make.conf for the target.

Worth a try?

[tomtom69]

Surely worth a try
I now built a toolchain with
crossdev -t arm-stellaris-eabi
and modified make.conf (/usr/arm-stellaris-eabi/etc/portage/make.conf) in hope to get newlib compiled for thumb.
I added a line including
MARCH_TUNE="-mthumb -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=softfp -Wa,-mimplicit-it=thumb"
($MARCH_TUNE is included in $CFLAGS two lines below in make.conf). But this had no effect. To be sure that the MARCH_TUNE and CFLAGS are used, I added the bogus option "-mthumbofant" to both of them, but even then newlib always compiled without error.
So I assume the CFLAGS and MARCH_TUNE from my make.conf are not used for the build of newlib, because if it would be used, "-mthumbofant" should throw an error about an illegal command line switch.
I am wondering why the CFLAGS in my make.conf are not used for building the cross "newlib" target.
Or is there a different place to specify the CFLAGS for newlib?

tom

[tomtom69]

Meanwhile I got a solution for the thumb problem.
For everyone who wants to program a TI stellaris launchpad with gentoo linux:
I built a toolchain with
crossdev -t arm-stellaris-eabi --genv 'EXTRA_ECONF="--with-cpu=cortex-m4 --with-tune=cortex-m4 --with-mode=thumb --with-fpu=fpv4-sp-d16 --with-float-abi=softfp"'
I spent much time finding out that MARCH_TUNE in /usr/arm-stellaris-eabi/etc/portage/make.conf does not change anything for the gcc build. So I found the (somewhat brutal) option "EXTRA_ECONF" to influence the gcc compilation.
Compiling works now, however the FPU is not yet used (when I disassemble the code I can see that there is much code for FP emulation, despite of the FPU options given above and -mfpu=fpv4-sp-d16 -mfloat-abi=softfp given in CFLAGS of the target program.

[hackernotcracker]

Meanwhile I got a solution for the thumb problem.
For everyone who wants to program a TI stellaris launchpad with gentoo linux:
I built a toolchain with
crossdev -t arm-stellaris-eabi --genv 'EXTRA_ECONF="--with-cpu=cortex-m4 --with-tune=cortex-m4 --with-mode=thumb --with-fpu=fpv4-sp-d16 --with-float-abi=softfp"'

tomtom69's fix no-longer works, as of Aug 2018.
The EXTRA_ECONF causes crossdev to bomb out.

The reason tomtom69 was getting emulated floating point is because they used --softfloat
Softfloat means "software based floating point"
For hardware floating point instructions, the compiler needs --hardfloat
As of this date AUG 2018, the crossdev toolchains are complied by an eclass script; eg: default location /tmp/portage/eclass/toolchain.eclass

In that program, it assumes newlib is being compiled for any toolchain ending in -eabi.
You can see this in the code commented with: ### Cross-compiler options

Further down in the section labeled, ### arch options

The thumb switch is only set when ARM7-M microcontroller processor is specified.
So, it may not set --thumb for ARM6-M or earlier (eg: cortex M0) processors.

If you still get the bug, which this thread was opened for, and you use armv7.
I assume one of these commands would work for the original thread's question, depending on the processor you actually have:

crossdev armv7m-stellaris-eabi
crossdev armv7m-hardfloat-eabi
crossdev armv7m-softfloat-eabi

If the bug persists, and you have an arm v6 processor, you might be able to solve it by adding two lines after the armv7 detection, to allow armv6 detection as well.
This will cover arm cortex m0 processors...

FILE: /usr/portage/eclass/toolchain.eclass -- at around line #1142, you'll see the following two lines.

Code: Select all

	# Convert armv7{a,r,m} to armv7-{a,r,m}
		[[ ${arm_arch} == armv7? ]] && arm_arch=${arm_arch/7/7-}
	

Immediately after, add these two lines:

Code: Select all

    # Convert armv6{a,r,m} to armv6-{a,r,m}
        [[ ${arm_arch} == armv6? ]] && arm_arch=${arm_arch/6/6-}

And, that will cause crossdev to add these flags to the gcc compile: --arch=armv6-m --with-mode=thumb

Which means you could do:
crossdev armv6m-softfloat-eabi # for thumb code in a cortex m0.