Commit Graph

177 Commits

Author SHA1 Message Date
Peter Korsgaard
933732b82b arch/Config.in.arm: support thumb2 instructions for ARMv8 in 32bit mode
The ARMv8 cores all support thumb2 instructions when running in aarch32 mode.

Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-12-08 22:32:17 +01:00
Peter Korsgaard
0976cd6cd6 arch/Config.in.arm: only enable BR2_ARM_CPU_HAS_NEON for ARMv8 in 32bit mode
A number of packages use BR2_ARM_CPU_HAS_NEON to know if the target handles
aarch32 neon instructions, which is only true for ARMv8 cores when they are
running in 32bit mode.

Notice: These cores do support neon-like instructions using a different
encoding in 64bit mode (it is a required part of ARMv8, similar to the FPU).

Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-12-08 22:32:16 +01:00
Peter Korsgaard
6d97af8763 arch/Config.in.arm: only enable BR2_ARM_CPU_HAS_ARM for ARMv8 in 32bit mode
Fixes:
http://autobuild.buildroot.net/results/5e6/5e67cc067a06f7364cde1a8393ea72608fe7fef1/

A number of packages use BR2_ARM_CPU_HAS_ARM to know if the target handles
classic A32 instructions, which is only true for ARMv8 cores when they are
running in 32bit mode.

Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-12-08 22:32:14 +01:00
Thomas Petazzoni
2131f1b381 arch/Config.in.arm: add Cortex-A57 and Cortex-A72
Add two popular ARM64 cores to the list of supported cores: Cortex-A57
and Cortex-A72.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-12-05 23:07:14 +01:00
Matt Flax
785a73fb8f arch/Config.in.arm: Add Cortex-A53 CPU
Adds the Cortex-A53 CPU to the target architecture variant choice. This
sets the toolchain to use Cortex-A53 as the target. The effect is that
various Cortex-A53 tunings are enabled for the compilation of packages.

Signed-off-by: Matt Flax <flatmax@flatmax.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-12-05 23:07:13 +01:00
Thomas Petazzoni
5e8cb2ee75 arch/Config.in.arm: specify ABI for ARM64
There's currently only one widely supported ABI for ARM64, called lp64,
so we define BR2_GCC_TARGET_ABI to the appropriate value.

Note that there is another ABI for ARM64 being worked on, ilp32, but its
support is not fully upstream in the kernel, so we're not adding support
for it for the moment.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-12-05 23:07:11 +01:00
Thomas Petazzoni
d690b7444a arch/Config.in.arm: add FPU related options for ARMv8 cores
The ARMv8 cores have a mandatory FPU unit called FP-ARMv8, so we:

 - add a new hidden Config.in option for the availability of this
   unit (BR2_ARM_CPU_HAS_FP_ARMV8)

 - allow the selection of a possible choice in the "Floating point
   strategy", and add two new choices: BR2_ARM_FPU_FP_ARMV8 and
   BR2_ARM_FPU_NEON_FP_ARMV8.

 - specify the -mfpu values for BR2_ARM_FPU_FP_ARMV8 and
   BR2_ARM_FPU_NEON_FP_ARMV8 cases, when used on ARM 32 bits (-mfpu
   doesn't exist on ARM64, instead -mcpu modifiers are used, so they
   will be added on a per-core basis).

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[yann.morin.1998@free.fr: drop the FP strategy dependency]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-12-05 23:07:10 +01:00
Yann E. MORIN
743e663912 arch/arm: drop legacy dependency for floating point strategy
The floating point strategy currently depends on EABI || EABIHF. The
reason was that, wayback when we also supported OABI, we only exposed FP
for EABI or EABIHF, and hide it for OABI, which did not support FP.

It's been a while now that we do not support OABI, but the dependency
stuck all along.

Remove it as it is no longer needed, and is always true.

However, the choice is empty for AArch64, as we still have no entry for
their floating point strategy yet.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-12-05 23:07:09 +01:00
Thomas Petazzoni
c37189b35e arch/Config.in.arm: add BR2_ARM_CPU_ARMV8
In order to prepare the addition of ARM64 cores, add the blind
BR2_ARM_CPU_ARMV8 option.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-12-05 23:07:08 +01:00
Thomas Petazzoni
1b61cd38cd arch/Config.in.arm: prepare addition of 64 bits cores
Until now the "Target Architecture Variant" choice was not visible on
AArch64. In order to prepare the addition of the 64 bits core to this
choice, this commit adds a "depends on !BR2_ARCH_IS_64" dependency to
all currently supported cores (that are 32 bits only).

Following this commit, the "Target Architecture Variant" choice appears
on AArch64, but is for now empty.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-12-05 23:07:07 +01:00
Thomas Petazzoni
8b7d8b4a4e arch: merge Config.in.aarch64 into Config.in.arm
The 64 bits ARM processors are capable of running 32 bits ARM code, and
some platforms are indeed using this capability. Due to this, if we were
to keep the separation between Config.in.aarch64 and Config.in.arm, we
would have to duplicate the definition of all 64-bits capable ARM cores
into both files.

Instead of going down this route, let's take the same route as the x86
one: a single Config.in.x86 file, used for both x86 32 bits and x86 64
bits, with the appropriate logic to only show the relevant cores
depending on which architecture is selected.

In order to do this, we:

 - Make the "ARM instruction set" choice only visible on ARM 32 bits,
   since we currently don't support ARM vs. Thumb on AArch64.

 - Add the relevant values for the BR2_ARCH option.

 - Add the relevant values for the BR2_ENDIAN option.

 - Make the "aapcs-linux" BR2_GCC_TARGET_ABI value only used on ARM 32
   bits, since this ABI doesn't mean anything on AArch64.

 - Make the BR2_GCC_TARGET_FPU option depends on ARM 32 bits, since
   there is no -mfpu option on AArch64.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-12-05 23:07:05 +01:00
Vicente Olivert Riera
e5b3fa3ae4 MIPS: rename M6201 core to M6250
m6201 is the -march option for GCC, but the real core name is
M6250.

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-09 22:42:12 +01:00
Vicente Olivert Riera
b2bae3b523 MIPS: rename M5101 core to M5150
m5101 is the -march option for GCC, but the real core name is M5150.

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-09 22:41:51 +01:00
Vicente Olivert Riera
84bd58d5bb MIPS: remove M5100 core
This is a microcontroller class (MCU) core which is not suitable for
running Linux.

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-09 22:41:07 +01:00
Vicente Olivert Riera
240564a693 arch/Config.in.mips: add support for XBurst cores
The Ingenic XBurst is a MIPS32R2 microprocessor.

It has a bug in the FPU that can generate incorrect results in certain
cases. The problem shows up when you have several fused madd
instructions in sequence with dependant operands.

Using the -mno-fused-madd option prevents gcc from emitting these
instructions. This patch adds changes to the toolchain wrapper to use
that option.

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-09 21:36:34 +01:00
Vicente Olivert Riera
1b974425d1 MIPS: add support for M6201 cores
-march=m6201 is not yet supported in GCC upstream, so disabling all
versions when selecting this core.

Note that M6201 implies a MIPS R6 CPU, and some GCC versions are already
disabled for R6, so we don't need to disable those ones for M6201 as
well.

The external Codescape IMG GNU Linux Toolchain has support for this
core.

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-10-19 23:31:29 +02:00
Vicente Olivert Riera
3cfbeb8363 MIPS: add support for P6600 cores
-march=p6600 is not yet supported in GCC upstream, so disabling all
versions when selecting this core.

Note that P6600 implies a MIPS R6 CPU, and some GCC versions are already
disabled for R6, so we don't need to disable those ones for P6600 as
well.

The external Codescape IMG GNU Linux Toolchain has support for this
core.

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-10-15 13:22:17 +02:00
Vicente Olivert Riera
73e1645746 MIPS: add support for P5600 cores
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-10-15 13:22:17 +02:00
Vicente Olivert Riera
ea52e3d01a MIPS: add support for I6400 cores
-march=i6400 support starts from GCC-6, so disable previous versions
when selecting this core.

Note that I6400 implies a MIPS R6 CPU, and some GCC versions are already
disabled for R6, so we don't need to disable those ones for I6400 as
well.

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-10-15 13:22:17 +02:00
Vicente Olivert Riera
55a37eaa91 MIPS: add support for M5101 cores
-march=m5101 support starts from GCC-6, so disable previous versions
when selecting this core.

Note that M5101 implies a MIPS R5 CPU, and some GCC versions are already
disabled for R5, so we don't need to disable those ones for M5101 as
well.

Also disable external toolchains that don't support this core.

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-10-15 13:22:17 +02:00
Vicente Olivert Riera
067a46474a MIPS: add support for M5100 cores
-march=m5100 support starts from GCC-6, so disable previous versions
when selecting this core.

Note that M5100 implies a MIPS R5 CPU, and some GCC versions are already
disabled for R5, so we don't need to disable those ones for M5100 as
well.

Also disable external toolchains that don't support this core.

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-10-15 13:22:17 +02:00
Vicente Olivert Riera
ef3e7323ef MIPS: add support for interAptiv cores
-march=interaptiv support starts from GCC-6, so disable previous
versions when selecting this core.

Also disable external toolchains that don't support this core.

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-10-15 13:22:17 +02:00
Vicente Olivert Riera
7ab9cf251d MIPS: add mips64r5 generic architecture variant
-march=mips64r5 support started from GCC-5, so disable previous versions
when the CPU is R5.

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-10-15 13:22:17 +02:00
Vicente Olivert Riera
1feb1b7756 MIPS: add mips32r5 generic architecture variant
-march=mips32r5 support started from GCC-5, so disable previous versions
when the CPU is R5.

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-10-15 13:22:17 +02:00
Vicente Olivert Riera
e14ce3cf29 MIPS: state that the current architecture variants are generic
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-10-15 13:22:17 +02:00
Vicente Olivert Riera
f62cbd75b7 MIPS: target architecture variants select the appropriate CPU ISA
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-10-15 13:22:17 +02:00
Vicente Olivert Riera
6fae290a94 MIPS: add default CPU ISAs
Meant to be used by the target architecture variants.

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-10-15 13:22:16 +02:00
Gustavo Zacarias
4338a319b7 arch: remove support for sh64
It's been deprecated for quite some time now.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-09-08 22:15:15 +02:00
Waldemar Brodkorb
e732bd1f22 bfin: change default to bf532, internal toolchain !bf6xx
The default Blackfin processor in Buildroot isn't supported by
gcc 6.1.0, so use bf532 as default. Disable any bf6xx processors
for internal toolchain users.

Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-08-27 23:07:11 +02:00
Waldemar Brodkorb
446177237c m68k: disable BR2_BINFMT_FLAT_SEP_DATA for coldfire
BR2_BINFMT_FLAT_SEP_DATA can be used to create XIP userland and works fine
for m68k. Unfortunately a lot of basic packages as pcre are not compileable
because of a CPU or hardware limitation. The reason for failing are very
big functions used in the libraries or application code.

Typical errors are:

Fatal error: Tried to convert PC relative branch to absolute jump
or
error: value -yyyyy out of range

Add kernel patch from 4ec5542679 to make
BR2_BINFMT_FLAT_ONE compiled firmware work fine.

Fixes:
  http://autobuild.buildroot.net/results/20b/20b1586757450d6aad8583ad7a787a7ca11acef1/
  http://autobuild.buildroot.net/results/d31/d311955ada1ffcd7f69e82965c8fe33eabe488cd/

Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
[Thomas: add comment in Config.in file about sep-data existing on m68k,
but being disabled due to build issues with numerous packages.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-08-23 00:08:13 +02:00
Waldemar Brodkorb
f9aee4b581 m68k: flat one memory region works with small kernel patch
Greg Ungerer fixed recently a bug in the Linux kernel, which
allows to use one memory region again.

Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
[Thomas: cherry-picked from next to master, in order to be able to use
BR2_BINFMT_FLAT_ONE by default on m68k, since BR2_BINFMT_FLAT_SEP_DATA
causes too much problems.]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-08-23 00:05:37 +02:00
Waldemar Brodkorb
49d97993d8 arch: define dependencies for the binfmt flat formats
The situation looks like following for elf2flt and binfmt FLAT:

 * Only gcc for bfin/m68k implements
   -msep-data (BR2_BINFMT_FLAT_SEP_DATA) and
   -mid-shared-library (BR2_BINFMT_FLAT_SHARED), so the corresponding
   options are made only visible on those architectures.

 * When the default of BR2_BINFMT_FLAT_ONE is used on m68k, broken
   binaries are produced, which mainly end up in SIGILL, so do not use
   it for m68k.

Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
[Thomas:
 - also add the dependencies on m68k/bfin to BR2_BINFMT_FLAT_SHARED
 - rework commit log.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-07-05 09:48:19 +02:00
Waldemar Brodkorb
eda11417be m68k: remove BR2_GCC_TARGET_ARCH
Setting BR2_GCC_TARGET_ARCH is possible, but breaks
external toolchain users. m68k/cf defconfigs just
working without it.

Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-06-07 13:11:59 +02:00
Waldemar Brodkorb
015322fccb toolchain: add coldfire support
Add support for m68k/coldfire. A gcc patch is required
to avoid gcc ICE.

Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-30 18:50:46 +02:00
Thomas Petazzoni
633f20002e i386: properly define BR2_ARCH for all x86 subarchitectures
We were not defining BR2_ARCH for two of the x86 subarchitecture,
which means the architecture part of the GNU_TARGET_NAME tuple was
empty, leading to weird build failures.

This commit fixes that by defining the appropriate values.

Fixes bug #8861.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-21 23:05:28 +02:00
Thomas Petazzoni
6cb4814c87 arch/x86: remove support for i386
The Linux kernel doesn't even support i386 anymore, there is no NPTL
support for i386 and uClibc-ng only supports NPTL on x86, so there is
essentially no usable thread implementation. Most likely glibc and
musl also don't support i386 either. So it's time to remove the
support for this architecture variant.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-18 23:38:34 +02:00
Thomas Petazzoni
4724343236 arch/arm: add Cortex-M4 entry
This commit adds the option to select the Cortex-M4 ARM core, in the
same family as Cortex-M3. This will be useful to enable the internal
toolchain backend for this ARM core, and provide some defconfigs for
Cortex-M4 platforms.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-03-20 15:37:30 +01:00
Thomas Petazzoni
41bcc440b1 arch/arm: Cortex-M3 provides only Thumb-2
The Cortex-M cores only support Thumb-2, not Thumb. In fact, Thumb-2
is a superset of Thumb, and we could have a single option for both in
Buildroot, since -mthumb on ARMv4/v5 means original Thumb, while
-mthumb on ARMv7 means Thumb 2. However, for clarity, it makes sense
to have two separate options. But in this case, Cortex-M3 should not
advertise that it supports Thumb, as in fact selecting Thumb would
generate Thumb-2 code.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-03-20 15:37:24 +01:00
Thomas Petazzoni
a5152f0cb0 arch/arm: introduce and use BR2_ARM_CPU_ARMV7M
All ARM cores should select a BR2_ARM_CPU_* option. Currently, the
cortex-m3 does not, which this commit fixes by introducing a
BR2_ARM_CPU_ARMV7M option.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-03-20 15:37:07 +01:00
Waldemar Brodkorb
7ea0f64dc3 arch/m68k: re-enable the architecture
This allows to build a m68k toolchain with uClibc.

Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-03-20 15:28:44 +01:00
Ezequiel García
027b7ca0f2 arch/arm: add the cortex A17 variant supported by gcc 5.x
Add the Cortex A17 variant. This core is considered a replacement
of the Cortex A12 and is supported by gcc 5 / binutils 2.25+

Suggested-by: Ross Green <greenfross@netscape.net>
Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-02-22 09:31:42 +01:00
Thomas Petazzoni
4a3f597a0e arch: remove BR2_ARCH_HAS_ATOMICS option
Now that BR2_ARCH_HAS_ATOMICS is no longer used anywhere, we can
remove it from arch/Config.in*, as well as from the documentation.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2016-02-06 11:16:00 +01:00
Sergi Granell
449d7b9127 Add ARM11 MPCore CPU target support
gcc differentiates the mpcore-with-vfp from the mcpore-without-vfp
CPUs. The former is named just 'mpcore', while the latter is named
'mpcorenovfp'.

We only add one entry, 'mpcore' and let the user select whether or
not to use the VFP. We then name the CPU according to the user's
selection.

Signed-off-by: Sergi Granell <xerpi.g.12@gmail.com>
Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-01-03 22:35:22 +01:00
Thomas Petazzoni
bb02e4c0b3 arch/arm: add help text to BR2_ARM_ENABLE_VFP
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-12-27 12:22:43 +01:00
Yann E. MORIN
110fecf1f5 arch/arm: only expose VFP in FP strategy when the CPU *has* a VFP unit
There's no point in offering the user an option to select an FP strategy
when the CPU does not actually have a VFP unit.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-12-27 12:17:48 +01:00
Yann E. MORIN
b08723087d arch/arm: only expose EABIhf when the CPU *has* a VFP unit
There's no point in offering the user an option to select EABIhf when
the CPU does not really have a VFP unit.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-12-27 12:17:36 +01:00
Yann E. MORIN
f52692ed64 arch/arm: add option to enable an optional VFP unit
Currently, the VFP selection for ARM is a little bit muddy:
  - some CPUs definitely do not have a VFP or NEON,
  - some CPUs definitely do have a VFP or NEON,
  - some CPUs may have a VFP or NEON.

However, we currently conflate the availability of the VFP/NEON with the
possibility to use them. Even is the user chooses a floating point
strategy with a 'lower' solution (i.e. VFPv2 when a VFPv3 exists, or not
using NEON when the CPU has it), some packages are still using the
CPU-defined HW availaibility rather thean the usr's selection.

Furthermore, for CPU that may have a VFP/NEON, there is no way for the
user to actually specify that the HW is indeed available; the user can
only specify the floating point strategy. This means that some packages
or some package versions, like nodejs for example, can not be properly
selected on some CPU cores, like Cortex-A9 which only may have a VFP.

Like we have an option to enable an optional NEON unit, add a similar
option to enable an optional VFP unit.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-12-27 12:17:23 +01:00
Yann E. MORIN
b64bcbf5f2 arch/arm: reorder NEON option
Stating whether to use the NEON extensions when it is optional in the
CPU really is completing the definition of the CPU we've just selected.

Move the ENABLE_NEON option just after the choice of the CPU variant,
and before any "software" option (ABI/VFP).

This will make sense in a moment, when we introduce a similar option for
enabling an optional VFP unit.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-12-27 12:16:45 +01:00
Arnout Vandecappelle
b3f7f949f0 arch: add tune options for powerpc e5500 and e6500
These were forgotten when the subarches were added in cd88e49.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Alvaro Gamez <alvaro.gamez@hazent.com>
Cc: Gustavo Zacarias <gustavo@zacarias.com.ar>
Tested-by: Alvaro G. M <alvaro.gamez@hazent.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-11-17 00:16:39 +01:00
Yann E. MORIN
e4b1fa69cd arch/arm: VFP and Thumb1 are not compatible
gcc will refuse to build with both --with-mode=thumb and --with-fpu=vfp,
with error messages during ./configure, like:

    checking for suffix of object files... configure: error: in `/home/ymor
    in/dev/buildroot/O/build/host-gcc-initial-4.9.3/build/arm-buildroot-lin
    ux-uclibcgnueabihf/libgcc':
    configure: error: cannot compute suffix of object files: cannot compile
    See `config.log' for more details.

And config.log informatively contains:

    sorry, unimplemented: Thumb-1 hard-float VFP ABI

This is an error message that comes deep from gcc source files.

If gcc says it does not support VFP with Thumb1, then let's disable that
combination in our menuconfig.

Prefer VFP over Thumb1, i.e. hide Thumb1 when we're not soft-float.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Gustavo Zacarias <gustavo@zacarias.com.ar>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-11-03 23:50:01 +01:00