If you select the proper armv4t core in "Target Architecture Variant" and have the BR2_SOFT_FLOAT option enabled, then we are normally already passing those two flags to Xenomai ./configure script.

Yes I'm using those two options:
BR2_arm920t=y
BR2_PREFER_SOFT_FLOAT=y
BR2_SOFT_FLOAT=y

I noted they were missing when I saw the config.log in the build/xenomai-2.6.0/ directory.  This is how it looks now after adding them manually in the xenomai.mk recipe:

  $ ./configure --target=arm-linux --host=arm-linux --build=i686-pc-linux-gnu --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --program-prefix= --disable-gtk-doc --enable-ipv6 --enable-static --enable-shared --includedir=/usr/include/xenomai/ CFLAGS=-march=armv4t -msoft-float LDFLAGS=-march=armv4t -msoft-float

Notice the CFLAGS and LDFLAGS at the end ...

(In reply to comment #1)
> If you select the proper armv4t core in "Target Architecture Variant" and have
> the BR2_SOFT_FLOAT option enabled, then we are normally already passing those
> two flags to Xenomai ./configure script.

They are in fact not necessarily present on the command line because since you use the internal backend, we build gcc to generate armv4t code by default, so it's not useful to pass -march=armv4t all the time.

Is Xenomai actually checking the presence of those command line flags directly?

I asked the Xenomai team and this is their response:

Xenomai does not do anything special, it uses the autotools default
which is:
- if you pass CFLAGS and LDFLAGS on the right hand of the configure
command line, the generated makefiles are hardcoded with these flags
values, and you need not do anything special later on to get these flags
used for all the compilations. This has been the recommended way of
passing CFLAGS and LDFLAGS when building autotools-based projects for
many years.

- if you want to pass them as environment variables (so, on the left
hand of the configure command line), the makefiles are not generated
with these flags, so, you have to pass them in the environment of the
"make" command.

Maybe buildroot passes the parameters differently ??

(In reply to comment #3)
> They are in fact not necessarily present on the command line because since you
> use the internal backend, we build gcc to generate armv4t code by default, so
> it's not useful to pass -march=armv4t all the time.
> 
> Is Xenomai actually checking the presence of those command line flags directly?

I tried reproducing this issue. Since I don't have a target board to test with, I have to resort to checking the parameters passed to the compilation.

Since I believe that the FPU support check you are referring to in the testsuite originates from the 'switchtest', I checked with strace which parameters are passed to the real compiler (by the compiler wrapper):

execve("/home/tdescham/repo/contrib/buildroot-reproduce/output/host/opt/ext-toolchain/bin/arm-none-linux-gnueabi-gcc", ["/home/tdescham/repo/contrib/buildroot-reproduce/output/host/opt/ext-toolchain/bin/arm-none-linux-gnueabi-gcc", "--sysroot", "/home/tdescham/repo/contrib/buildroot-reproduce/output/host/usr/arm-buildroot-linux-gnueabi/sysroot", "-mabi=aapcs-linux", "-msoft-float", "-marm", "-pipe", "-mfloat-abi=soft", "-march=armv4t", "-mcpu=arm920t", "-DHAVE_CONFIG_H", "-I.", "-I../../../src/include", "-I../../../include/posix", "-O2", "-D_GNU_SOURCE", "-D_REENTRANT", "-Wall", "-Werror-implicit-function-declaration", "-pipe", "-D__XENO__", "-D__IN_XENO__", "-Wstrict-prototypes", "-g", "-I../../../include", "-D_LARGEFILE_SOURCE", "-D_LARGEFILE64_SOURCE", "-D_FILE_OFFSET_BITS=64", "-D_LARGEFILE_SOURCE", "-D_LARGEFILE64_SOURCE", "-D_FILE_OFFSET_BITS=64", "-pipe", "-Os", "-MT", "switchtest-switchtest.o", "-MD", "-MP", "-MF", ".deps/switchtest-switchtest.Tpo", "-c", "-o", "switchtest-switchtest.o", "switchtest.c"], [/* 54 vars */]) = 0



This shows that the requested flags are effectively passed to the compilation, so I don't expect issues. 

This was checked with an external sourcery toolchain. The defconfig (buildroot 2014.05-git) is:

BR2_arm=y
BR2_arm920t=y
BR2_DL_DIR="~/repo/contrib/dl"
BR2_TOOLCHAIN_EXTERNAL=y
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_DEFCONFIG="mx1"
BR2_LINUX_KERNEL_EXT_XENOMAI=y

(don't mind the kernel defconfig, it is bogus).

So at this point, we believe that there is no issue.

If you do believe there is an issue, then please:
- provide a .config for us to reproduce
- provide more details / confirmation about the test that fails (switchtest?)
- verify the output of strace as I did above

Hello,

I was working with xenomai in 2012 with the mini2440, and I still have it :)

I don't think the bug report is relevant with this board.

I tried to add this line in xenomai.mk:
XENOMAI_CONF_OPT += CFLAGS="-march=armv4t -msoft-float" LDFLAGS="-march=armv4t -msoft-float"

I always get the following message:
# switchtest
== Testing FPU check routines...
== FPU check routines: unimplemented, skipping FPU switches tests.
[...]

That's because the VFP support (CONFIG_VFP) is not enabled in the linux kernel.

config VFP
	bool "VFP-format floating point maths"
	depends on CPU_V6 || CPU_V6K || CPU_ARM926T || CPU_V7 || CPU_FEROCEON

None of these requirements are met with the s3c2440.

So, in the check_fpu_thread() the check (check != 1) is always false.

xenomai-2.6/src/testsuite/switchtest/switchtest.c:
from check_fpu_thread():

check = fp_regs_check(2);
if (check != 1) {
	fprintf(stderr,
		"== FPU check routines: unimplemented, "
		"skipping FPU switches tests.\n");
	return NULL;
}

fp_regs_check() is defined in xenomai-2.6/include/asm-arm/fptest.h:

static inline unsigned fp_regs_check(unsigned val)
{
	unsigned result = val;

	if (have_vfp) {
	[snip]
	}

	return result;
}

And have_vfp depends on CONFIG_VFP

#ifdef CONFIG_VFP
#define have_vfp (elf_hwcap & HWCAP_VFP)
#else /* !CONFIG_VFP */
#define have_vfp (0)
#endif /* !CONFIG_VFP */

So, I'm agree with ThomasDS, this is not a buildroot issue.

Note: I'm using Buildroot 2014.05-git, xenomai-2.6.3 and linux kernel 3.5.7 and 3.8.13.

Based on my observations, the feedback from Romain, and the missing feedback of the original submitter, I'm closing this bug report.