Commit Graph

246 Commits

Author SHA1 Message Date
Vicente Olivert Riera
0af741187f arch/mips: add option for toolchains supporting -mnan
-mnan option was added in gcc-4.9.0 so make sure that users cannot
select the NaN mode when using toolchains that have a gcc older
than 4.9.0, and also make sure that the -mnan option is not passed at
all to the toolchain-wrapper and target cflags.

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-21 22:48:51 +02:00
Vicente Olivert Riera
f2985125a4 arch/mips: improve help text of FP32 mode option
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-19 21:47:11 +02:00
Vicente Olivert Riera
cfc6f1e9b7 arch/mips: improve help text of NaN option
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-19 21:47:04 +02:00
Vicente Olivert Riera
9a0a0a976b arch/mips: add support for MIPS32 FP mode
MIPS32 support different FP modes (32,xx,64), so give the user the
opportunity to choose between them. That will cause host-gcc to be built
using the --with-fp-32=[32|xx|64] configure option. Also the
-mfp[32|xx|64] gcc option will be added to TARGET_CFLAGS and to the
toolchain wrapper.

FP mode option shouldn't be used for soft-float, so we add logic in the
toolchain wrapper if -msoft-float is among the arguments in order to not
append the -fp[[32|xx|64] option, otherwise the compilation may fail.

Information about FP modes here:

- https://sourceware.org/binutils/docs/as/MIPS-Options.html
- https://dmz-portal.imgtec.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinking#5._Generating_modeless_code

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-16 16:45:22 +02:00
Vicente Olivert Riera
2d8f3fc430 arch/mips: add support for MIPS NaN
MIPS supports two different NaN encodings, legacy and 2008. Information
about MIPS NaN encodings can be found here:

  https://sourceware.org/binutils/docs/as/MIPS-NaN-Encodings.html

NaN legacy is the only option available for R2 cores and older.
NaN 2008 is the only option available for R6 cores.
R5 cores can have either NaN legacy or NaN 2008, depending on the
implementation. So, if the user selects a generic R5 target architecture
variant, we show a choice menu with both options available. For well
known R5 cores we directly select the NaN enconding they use.

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-16 16:35:39 +02:00
Yann E. MORIN
9d06e91df8 arch/arm: fix -mcpu default values for AArch64
We have to specify the -mcpu value, even in 64-bit mode.

For AArch64, +fp and +simd are the default, so they are totally useless.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-10 18:04:16 +02:00
Max Filippov
3a0a020a2e uboot: apply xtensa overlay
Xtensa core configuration must be added to U-Boot before it can be
built for that xtensa CPU variant. Extract configuration files from the
xtensa overlay as is done for other packages that need to be configured
for a specific xtensa core.

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-09 17:03:45 +02:00
Max Filippov
b7310c8d07 linux: apply xtensa overlay
Xtensa core configuration must be added to linux before it can be
built for that xtensa CPU variant. Extract configuration files from the
xtensa overlay as is done for other packages that need to be configured
for a specific xtensa core.

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-09 17:03:37 +02:00
Yann E. MORIN
5b80a146af arch/xtensa: accept the overlay to be an URL
It can be interesting to get the overlay from a remote server, rather
than expect it to be present locally.

Since that file can be any URL, we can't know its hash, so we just
exclude it.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
[Thomas: use DL_DIR instead of BR2_DL_DIR.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-09 16:58:03 +02:00
Yann E. MORIN
0645fb8084 arch/xtensa: accept the overlay to be compressed
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-09 15:42:26 +02:00
Yann E. MORIN
b3b6070622 arch/xtensa: allow specifying path to tarball file
currently, specifying a custom Xtrensa core is done with two variables:
  - the core name
  - the directory containing the overlay tarball

However, the core name only serves to construct the tarball name, and is
not used whatsoever to configure any of the toolchain components
(binutils, gcc or gdb), except through the files that are overlayed in
their respective source trees.

This has two main drawbacks:
  - the overlay file must be named after the core,
  - the tarball can not be compressed.

Furthermore, it also makes it extremely complex to implement a download
of that tarball.

So, those two variables can be squeezed into a single variable, that is
the complete path of the overlay tarball.

Update the qemu-xtensa defconfig accordingly.

Note: we do not add a legacy entry for BR2_XTENSA_CORE_NAME, since it
was previously a blind option in the last release, and there's been no
release since we removed BR2_XTENSA_CUSTOM_NAME. So, we just update the
legacy comments for BR2_XTENSA_CUSTOM_NAME, since that's all the user
could have seen in any of our releases so far.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-09 15:41:51 +02:00
Yann E. MORIN
15a96d1aaa arch/xtensa: get rid of an intermediate blind kconfig option
It is not needed to have an intermediate blind option, we can just
hide the prompt behind the same dependency as the non-blind symbol.

Update our qemu-xtensa defconfig acordingly (note: it was using
different values for both options, which is not possible; the blind
option was just set to the non-blind one in the .config).

Also remove an unneeded empty default for the BR2_XTENSA_OVERLAY_DIR
string option (strings are empty by default).

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-09 15:39:24 +02:00
Bernd Kuhls
cc405b4cb3 arch, linux, package: remove whitespaces
Whitespaces were searched using the following regex:

[ ]{1,}\t

and then manually removed in most of the cases. For
xserver_xorg-server.mk, tabs before backslashes were removed.

Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-03-29 23:30:37 +02:00
Yann E. MORIN
8eba8e144c arch/xtensa: add macro to extract the overlay
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-03-26 15:49:54 +02:00
Yann E. MORIN
bcecbed654 arch/xtensa: add definitions for the Xtensa overlay
Currently, we have four packages that need to use the Xtensa overlay:
binutils, gcc-initial, gcc-final and gdb. However, they all use three
different ways to check for, and use the overlay. Furthermore, two of
them define the same variable: XTENSA_CORE_NAME is defined both by
binutils and gdb

In order to sanitise that, have the Xtensa architecture export the
appropriate variables: the name of the core and the path to the overlay
tarball. Packages can then check and use those variables.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-03-26 15:49:12 +02:00
Thomas Petazzoni
69f57593ac arch/Config.in.arc: fix BR2_READELF_ARCH_NAME
On ARC, depending on the CPU selected, the ELF machine number might be
different. Take this into account when defining BR2_READELF_ARCH_NAME.

Fixes:

   http://autobuild.buildroot.net/results/0a1957056e07cedc4839439c0ea8ebd1f646b904/

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-03-22 22:05:54 +01:00
Thomas Petazzoni
d04ea6e4e8 arch: add BR2_READELF_ARCH_NAME hidden config option
This config option corresponds to the string returned by readelf for
the "Machine" field of the ELF header. It will be used to check if the
architecture of binaries built by Buildroot match the target
architecture.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-03-20 22:22:17 +01:00
Guo Ren
f7f568f5e0 arch: add support for the csky architecture
This commit provides basic support for the C-SKY architecture.

Signed-off-by: Guo Ren <ren_guo@c-sky.com>
[Thomas: minor tweaks.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-03-04 14:35:55 +01:00
Waldemar Brodkorb
a818e29e76 arch: add OpenRISC architecture support
Add support for OpenRISC. See here for more details about
OpenRISC http://openrisc.io.

All buildroot included upstream binutils versions are supported.
Gcc support is not upstream, to be able to enable musl C library
support later, we use the branch with musl support.
At the moment it is possible to build a musl based toolchain,
but bootup in Qemu fails.

Gdb is only working to debug bare-metal code, there is no support
for gdbserver/gdb on Linux, yet.

[Peter: drop ?= for GCC_SOURCE]
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Tested-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2017-01-25 22:53:53 +01:00
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
Benoît Thébaudeau
cc0773f2a8 arch/arm: use EABIhf by default with VFP
Set EABIhf as the default target ABI for the ARM processors that have or
may have a VFP unit, since this ABI is the most efficient in that case.
Of course, EABI can still be selected manually if needed.

[Peter: only default to EABIHF when we are sure the CPU has a VFP]
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-10-25 19:56:20 +01:00
Peter Korsgaard
8da1239a12 arch/Config.in.x86: drop trailing dot (.) from x1000 URL
And add an empty line below for clarity.

Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-10-20 11:32:03 +02:00
Ray Kinsella
968f5d5e59 arch/x86: add support for Intel X1000
The Intel X1000 is the Pentium class microprocessor that ships with
Galileo Gen 1/2. This patch adds changes to arch and toolchain-wrapper
to omit the lock prefix for the X1000.

[Thomas: tweak commit log and Config.in help text.]

Signed-off-by: Ray Kinsella <ray.kinsella@intel.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-10-20 10:04:52 +02:00
Vicente Olivert Riera
99122d6780 arch: add support for mips32r6 and mips64r6 variants
- Add support for mips32r6 and mips64r6 target architecture variants
- Disable unsupported gcc versions
- Disable unsupported binutils versions
- Disable unsupported external toolchains
- Disable unsuported C libraries
- Add a hook in order to make glibc compile for MIPS R6.

[Thomas: slightly tweak the glibc hack explanation, to make it
hopefully clearer.]

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-10-12 21:33:56 +02:00
Waldemar Brodkorb
4a92f6754a toolchain: add sparc64 architecture support
Introduce sparc64 architecture to buildroot.

Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Acked-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Tested-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-10-10 12:51:45 +02:00
Vicente Olivert Riera
25677a717c arch/mips: remove some remaining mips1/2/3/4 bits
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Reviewed-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-10-09 23:15:49 +02:00
Peter Korsgaard
7deaa277fd arch/arm: add missing arm1136j-s variant
Identical to arm1136jf-s, except that is doesn't have a vfp unit.

Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-08-24 00:43:12 +02:00
Alexey Brodkin
3720e28d15 ARC: allow selection of MMU page size
Modern ARC cores (those sporting MMU of version 3 and 4) allow selection
of different page sizes (4, 8 or 16 kB) during ASIC design creation.
And it's important to build a toolchain with page size setting that matches
hardware.

Otherwise user-space applications will fail on execution due to
unexpected data layout/alignment etc.

[Thomas: slightly improve help text, fix indentation of help text.]

Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Anton Kolesov <akolesov@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-07-18 14:07:35 +02:00
Thomas Petazzoni
f410de4140 arch: aarch64 always has a MMU
Following the addition of AArch64 big endian, the AArch64 little
endian option had lost its 'select BR2_ARCH_HAS_MMU_MANDATORY', so
let's reintroduce it.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-07-12 18:34:42 +02:00
Bamvor Jian Zhang
827ba46556 aarch64: add big endian(aarch64_be) support
Add aarch64_be support. Note that CONFIG_CPU_BIG_ENDIAN should be
defined in kernel config when building a big endian kernel.

Signed-off-by: Zhang Jian(Bamvor) <bamvor.zhangjian@huawei.com>
Acked-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-07-12 18:32:37 +02:00
Guido Martínez
9971ebfe9d arm: update processor types
Add the Cortex M3 variant. These microcontrollers don't support regular
ARM instructions and don't have an MMU.

Signed-off-by: Guido Martínez <guido@vanguardiasur.com.ar>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-06-28 14:32:25 +02:00
Guido Martínez
22d5501e03 arch: tidy up binary formats config
Instead of (black)listing architectures when deciding the binary format,
we can enable the ELF format only when using an MMU and FLAT only when
we're not. This mimics the logic in the Linux kernel for user binaries
support.

For FDPIC, we introduce a Kconfig option to enable its selection, and
have blackfin select it.

Signed-off-by: Guido Martínez <guido@vanguardiasur.com.ar>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-06-09 22:51:14 +02:00
Guido Martínez
29563047e0 arch: tidy up mmu config
Instead of blacklisting which architectures support MMUs (mandatorily
or optionally), introduce two Kconfig options that are selected by each
architecture in each case.

This simplifies the logic in BR2_USE_MMU.

Signed-off-by: Guido Martínez <guido@vanguardiasur.com.ar>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-06-09 22:49:39 +02:00
Max Filippov
083ec2df6c arch/Config.in.xtensa: provide BR2_ENDIAN symbol
Packages get hints from the buildroot at configure time, e.g.
ac_cv_c_bigendian=yes/no. This particular hint is based on the value of
BR2_ENDIAN and when it doesn't match actual toolchain endiannes the
build may break.
Provide BR2_ENDIAN for xtensa to fix this sort of build errors.

Fixes:
  http://autobuild.buildroot.net/results/31115fe8d88f52d77ed0f2da769eb8896a1b34a2/

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-05-05 22:44:04 +02:00
Waldemar Brodkorb
b49aeacfca sh64: deprecate support for this dead architecture
As discussed on the mailinglist, this should be deprecated
before removal.

[Thomas: don't add to Config.in.legacy.]

Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-04-25 10:32:40 +02:00
Steven Noonan
f92e6219cf arch: add core-avx2
Signed-off-by: Steven Noonan <steven@uplinklabs.net>
Acked-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-04-09 23:34:14 +02:00
Steven Noonan
c060425f67 arch: add corei7-avx
Signed-off-by: Steven Noonan <steven@uplinklabs.net>
Acked-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-04-09 23:34:08 +02:00
Gustavo Zacarias
7428ffe337 arch/sparc: doesn't have atomics
Cores older than v9 don't seem to have atomics so remove it.
Fixes a test build of pulseaudio for example.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-03-30 23:30:28 +02:00
Sonic Zhang
1b171af3b3 arch: BINFMT_FLAT_SHARED is not really shared for buildroot purposes
Although BINFMT_FLAT_SHARED is indeed a shared library format, it does
not support dynamic library loading with dlopen(). So for buildroot
purposes, BR2_STATIC_LIBS shouldn't be selected.

As it happens, the compiler options that are added for
BINFMT_FLAT_SHARED also make the compiler ignore the -static option, so
we can simply force BR2_STATIC_LIBS and things work out perfectly.

Therefore, remove the select of BR2_BINFMT_SUPPORTS_SHARED from
BINFMT_FLAT_SHARED, which in turn makes sure that BR2_STATIC_LIBS is
selected.

[Arnout: rewrite commit message, add explanatory comment]

Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-03-30 23:07:48 +02:00
Gustavo Zacarias
50451998f0 arch: add support for AMD steamroller
Add support for AMD steamroller optimizations, available in gcc 4.8+ as
bdver3.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-03-04 22:16:41 +01:00
Yann E. MORIN
80be8753d5 arch/avr32: decommission for real
Now that we have absolutely zero reference to the avr32 architecture, we
can now really decommission the symbol.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-02-14 17:46:42 +01:00
Yann E. MORIN
a46007daa7 arch: kill avr32
avr32 was slated for removal in 2015.02. Make it so!

This patch only definitively hides the symbol. When all references
to it are eradicated (to come in followup patches), we'll eventually
kill the symbol altogether.

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-02-14 17:39:50 +01:00
Guido Martínez
a87f5806ed arm: conditionally support regular ARM instructions
Until now, all ARM processors supported the original ARM instructions.
However, the Cortex-M variants don't support them, and support only
Thumb/Thumb2 modes.

So, make a Kconfig option for ARM support and use it.

[Thomas:
  - Remove the dependency in the choice between ARM/Thumb/Thumb-2,
    because basically the choice is now always visible.
  - Replace the BR2_ARM_INSTRUCTIONS_ARM_CHOICE choice option directly
    by BR2_ARM_INSTRUCTIONS_ARM, instead of having this blind option
    defined separately. This means the choice is now always visible,
    even when only the ARM instruction set is supported.]

Signed-off-by: Guido Martínez <guido@vanguardiasur.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-02-02 18:32:34 +01:00
Thomas Petazzoni
158001f57b Turn the static lib option into a choice with more options
This commit turns the single static option into a choice, which offers
various possibilities:

 1. Build and use static libraries only;
 2. Build both shared and static libraries, but use shared libraries;
 3. Build and use shared libraries only.

On most platforms, (2) is currently the default, and kept as the
default in this commit. Of course, on certain platforms (Blackfin,
m68k), only option (1) will be available.

In addition to the introduction of the Config.in options, this commit
also:

 * Removes the 'select BR2_STATIC_LIBS' from 'BR2_BINFMT_FLAT', since
   with the use of a choice, we are guaranteed that BR2_STATIC_LIBS
   will be selected when the binary format is BR2_BINFMT_FLAT, since
   BR2_STATIC_LIBS will be the only possible solution in the choice.

 * Changes package/Makefile.in to use the proper
   --{enable,disable}-{shared,static} options for autotools packages.

[Thomas: remove useless empty newline right after 'choice'. Noticed by
Yann E. Morin.]

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2014-12-12 00:09:02 +01:00
Thomas Petazzoni
375c77ad4e arch: remove superfluous arch dependencies on BR2_BINFMT_FLAT_*
As noted by Yann E. Morin, those dependencies are unneeded, since FLAT
can anyway only be used on m68k and Blackfin.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-12-11 22:51:12 +01:00
Thomas Petazzoni
b85837e5d6 arch: introduce BR2_BINFMT_SUPPORTS_SHARED
In preparation for the refactoring of the static/shared library
support, we add a BR2_BINFMT_SUPPORTS_SHARED hidden option that binary
formats supporting shared libraries should select.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2014-12-11 22:50:40 +01:00
Thomas Petazzoni
c1a38829e7 arch: ensure BR2_BINFMT_ELF is really used
Currently, the binary format choice is only shown for the Blackfin and
m68k architectures, since we assume that all other architectures are
using the ELF binary format. However, due to this, the BR2_BINFMT_ELF
symbol is in fact not set to 'y' for those architectures that use the
ELF format.

This will be causing problems for the refactoring of the static/shared
library support, as we will need to know if the binary format supports
shared libraries or not.

Therefore, we simply make the choice visible on all architectures,
even if it means that on many architectures no other choice than ELF
will be available.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2014-12-11 22:49:14 +01:00
Thomas Petazzoni
c149083f93 arch: FDPIC is not supported on m68k
The current binfmt selection in arch/Config.in allows to select FDPIC
on m68k, which is incorrect. This commit fixes that, and makes sure
FDPIC is the default on Blackfin, while FLAT is the default on m68k.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2014-12-11 22:48:57 +01:00
Thomas Petazzoni
665e13c85e Rename BR2_PREFER_STATIC_LIB to BR2_STATIC_LIBS
Since a while, the semantic of BR2_PREFER_STATIC_LIB has been changed
from "prefer static libraries when possible" to "use only static
libraries". The former semantic didn't make much sense, since the user
had absolutely no control/idea of which package would use static
libraries, and which packages would not. Therefore, for quite some
time, we have been starting to enforce that BR2_PREFER_STATIC_LIB
should really build everything with static libraries.

As a consequence, this patch renames BR2_PREFER_STATIC_LIB to
BR2_STATIC_LIBS, and adjust the Config.in option accordingly.

This also helps preparing the addition of other options to select
shared, shared+static or just static.

Note that we have verified that this commit can be reproduced by
simply doing a global rename of BR2_PREFER_STATIC_LIB to
BR2_STATIC_LIBS plus adding BR2_PREFER_STATIC_LIB to Config.in.legacy.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2014-12-11 22:48:13 +01:00
Gustavo Zacarias
cd88e49cd7 arch/powerpc: add fsl e5500 and e6500 support
Add Freescale E5500 and E6500 core support.
These can go in 32 or 64-bit mode.
I'm not aware of these being able to boot in LE mode so filter that out
until we get some feedback on it.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Reviewed-by: "Matt Weber" <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-12-07 23:46:41 +01:00
Gustavo Zacarias
dd45fe0efb arch/mips: remove deprecated mips1/2/3/4 support
Remove the support for generating mips1/2/3/4 code since it has been
deprecated for more than a year now.
Also remove the unnecessary kludges in packages for it.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Acked-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-12-01 20:06:32 +01:00