arch: introduce BR2_GCC_TARGET_{FPU, FLOAT_ABI}

Buildroot already has the BR2_GCC_TARGET_{TUNE,ARCH,ABI,CPU} hidden
kconfig strings that allow per-architecture Config.in files to feed
the appropriate values of --with-{tune,arch,abi-cpu} when building
gcc, or the appropriate flags for the external toolchain wrapper.

This commit has two additional options:
BR2_GCC_TARGET_{FPU,FLOAT_ABI}, that allows to define the
--with-{fpu,float} gcc configure options for the internal backend, or
the -m{fpu,float-abi} options for the flags of the external toolchain
wrapper.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
arch: Refactor BR2_SOFT_FLOAT into per-architecture options

As we are going to introduced a more advanced support of floating
point options for the ARM architecture, we need to adjust how the
soft-float option is handled. We replace the current hidden option
BR2_PREFER_SOFT_FLOAT option and the visible BR2_SOFT_FLOAT option by:

 * A global hidden BR2_SOFT_FLOAT option, defined in arch/Config.in,
   that tells whether the architecture-specific code is using software
   emulated floating point. This hidden option can be used throughout
   Buildroot to determine whether soft float is used or not.

 * Per-architecture visible BR2_<arch>_SOFT_FLOAT options, for the
   architecture for which it makes sense, which allows users to select
   soft float emulation when needed.

This change will allow each architecture to have a different way of
presenting its floating point capabilities.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
arch: improve ARM floating point support and add support for EABIhf

This commit introduces the support for the EABIhf ABI, next to the
existing support we have for EABI and OABI (even though OABI support
is deprecated). EABIhf allows to improve performance of floating point
workload by using floating point registers to transfer floating point
arguments when calling functions, instead of using integer registers
to do, as is done in the 'softfp' floating point model of EABI.

In addition to this, this commit introduces a list of options for the
floating point support:
 * Software floating point
 * VFP
 * VFPv3
 * VFPv3-D16
 * VFPv4
 * VFPv4-D16

and it introduces some logic to make sure the options are only visible
when it makes sense, depending on the ARM core being selected. This is
however made complicated by the fact that certain VFP capabilities are
mandatory on some cores, but optional on some other cores. The kconfig
logic tries to achieve the following goals:

 * Hide options that are definitely not possible.

 * Use safe default values (i.e for Cortex-A5 and A7, the presence of
   the VFPv4 unit is optional, so we default on software floating
   point on these cores)..

 * Show the available possibilities, even if some of them are not
   necessarily working on a particular core (again, for the Cortex-A5
   and A7 cores, there is no way of knowing whether the particular
   variant used by the user has VFPv4 or not, so we select software
   floating point by default, but still show VFP/VFPv3/VFPv4 options).

It is worth noting that this commit doesn't add support for all
possible -mfpu= values on ARM. We haven't added support for fpa, fpe2,
fpe3, maverick (those four are only used on very old ARM cores), for
vfpv3-fp16, vfpv3-d16-fp16, vfpv3xd, vfpv3xd-fp16, neon-fp16,
vfpv4-sp-d16. They can be added quite easily if needed thanks to the
new organization of the Config.in options.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
binutils: exclude binutils versions that don't support EABIhf

The ARM EABIhf support was introduced in Binutils 2.22, so earlier
versions should not be selected when EABIhf is used.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
gcc: take into account ARM floating point capabilities

The ARM EABIhf support was introduced in gcc 4.6.x, so versions
earlier than this one should not be used when EABIhf is selected.

The ARM VFPv4 support was introduced in gcc 4.5.x, so versions earlier
than this one should not be used when VFPv4 is used.

[Peter: drop OABI dependencies]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
toolchain: remove the old BR2_VFP_FLOAT option

Now that we have a much better way of selecting between the various
VFP versions and capabilities, the BR2_VFP_FLOAT version no longer
makes sense. This commit gets rid of it, and adds the appropriate
Config.in.legacy code.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
configs: update defconfigs after VFP option changes

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
toolchain-external: update config options after EABIhf introduction

The introduction of the EABIhf ABI requires a few updates to the
configuration options for external toolchains, in order to ensure that
the user doesn't do any invalid selection. In detail:

 * The Linaro ARM toolchains now depend on BR2_ARM_EABIHF, because
   that's the ABI they use, and it is incompatible with EABI. The
   comment about the availability of Linaro toolchains is updated to
   inform users selecting EABI that they should select EABIhf if they
   want to see Linaro toolchains.

 * The Sourcery CodeBench toolchains now depend on BR2_ARM_EABI,
   because that's the ABI they use. A comment is added to inform users
   that have selected EABIhf that Sourcery CodeBench are only
   available when EABI is used.

 * The Arago toolchains now depend on BR2_ARM_EABI, because that's the
   ABI they use. The description of the ARMv7 Arago toolchain is also
   slightly improved.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
gcc: create symbolic link to ld-linux in EABIhf/gcc 4.7/eglibc

When using eglibc, the ld-linux loader is installed as
ld-linux-armhf.so.3, but gcc 4.7.x was not yet updated, and generates
binaries that reference ld-linux.so.3. This was fixed starting with
gcc 4.8.x. In order to be able to use gcc 4.7, we create the
appropriate symbolic link.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
arch/arm: add support for Thumb2

Until now, we were using the default ARM instruction set, as used by
the toolchain: the 32 bits ARM instruction set for the internal
backend, and for external toolchain, whatever default was chosen when
the toolchain was generated.

This commit adds support for the Thumb2 instruction set. To do so, it:

 * provides a menuconfig choice between ARM and Thumb2. The choice is
   only shown when Thumb2 is supported, i.e on ARMv7-A CPUs.

 * passes the --with-mode={arm,thumb} option when building gcc in the
   internal backend. This tells the compiler which type of
   instructions it should generate.

 * passes the m{arm,thumb} option in the external toolchain
   wrapper. ARM and Thumb2 code can freely be mixed together, so the
   fact that the C library has been built either ARM or Thumb2 and
   that the rest of the code is built Thumb2 or ARM is not a problem.

[Peter: fix empty BR2_GCC_TARGET_MODE check]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
uclibc: use numbered patches for 0.9.33.2

In preparation to the addition of more patches that require a correct
ordering, rename uClibc 0.9.33.2 patches.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
uclibc: add Thumb2 fixes

This commit adds three patches to uClibc that are needed to make
Thumb2 support work properly:

 uclibc-0006-arm-clone-restore-stack-pointer-just-after-return-fr.patch
 uclibc-0007-arm-clone.S-Add-missing-IT-instruction-for-Thumb2.patch
 uclibc-0008-arm-move-check-for-BX-to-its-own-header.patch

The first one is a necessary dependency of the second one. Both of
those patches have already been merged upstream, after 0.9.33.2. The
third one hasn't been merged upstream yet, but it has already been
submitted a while ago by Yann E. Morin, without receiving attention
from upstream.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
arch: use tabs instead of spaces in Config.in files

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
configs: use new EABIhf option for beaglebone_defconfig

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
arch/arm: arm926 may have VFP

The VFP9-S FPU (VFPv2) is optional for ARM926EJ-S, see:
http://www.arm.com/products/processors/classic/arm9/arm926.php?tab=Specifications+
Real silicon:
http://www.nxp.com/documents/data_sheet/LPC3180.pdf

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
gcc-final: ensure TARGET_DIR/usr/lib exists before copying to it

Got dropped in the toolchain/gcc -> package/gcc conversion.

Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
pkg-autotools.mk: also use QUIET for host configure runs

Similar to how we do it for target configure runs. For make -s invocations.

Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
toolchain/helpers: don't use the x$(...) = x"value" syntax

As noted by Yann E. Morin, the x$(...) = x"value" syntax is old and
ugly, and the easier to read "$(...)" = "value" can now be used
without problems.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
toolchain: check ARM EABI vs. EABIhf for external toolchains

Following the introduction of the support of EABIhf as a second ARM
ABI, it is important to check whether the external toolchain provided
by the user actually uses the ABI that has been selected in the
Buildroot configuration. This commit introduces such a check by
looking at the 'Tag_ABI_VFP_args' tag of the architecture-specific
section of the ELF headers. This assumes that ELF is the binary format
used on ARM, which may not be the case on ARM noMMU systems (they use
the FLAT binary format), but Buildroot doesn't have support for such
systems at the moment.

Also ensure the correct CFLAGS are passed to the cross compiler for the
test, so the correct variant is used in case the toolchain is multilib.

[Peter: mention CFLAGS change]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
toolchain/toolchain-external: don't use x$(...) construct or ==

With modern shells, we can simply do test using the "$(...)" = "value"
form. This commit gets rid of the x$(...) = x"value" constructs and
replaces == by =, which is the correct operator to test the equality
of two strings with the test program.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>