-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>
-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>
-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>
-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>
-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>
-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>
-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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
- 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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
The fuzzy generic x86 variant doesn't make much sense in the context of
Buildroot, and the recent change to use -march instead of -mtune broke it.
From the GCC manual:
https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/i386-and-x86-64-Options.html#i386-and-x86-64-Options:
-mtune=cpu-type
Tune to cpu-type everything applicable about the generated code,
except for the ABI and the set of available instructions. While
picking a specific cpu-type schedules things appropriately for that
particular chip, the compiler does not generate any code that cannot
run on the default machine type unless you use a -march=cpu-type
option. For example, if GCC is configured for i686-pc-linux-gnu then
-mtune=pentium4 generates code that is tuned for Pentium 4 but still
runs on i686 machines.
The choices for cpu-type are the same as for -march. In addition,
-mtune supports 2 extra choices for cpu-type:
‘generic’
Produce code optimized for the most common IA32/AMD64/EM64T
processors. If you know the CPU on which your code will run,
then you should use the corresponding -mtune or -march option
instead of -mtune=generic. But, if you do not know exactly what
CPU users of your application will have, then you should use
this option.
As new processors are deployed in the marketplace, the behavior
of this option will change. Therefore, if you upgrade to a newer
version of GCC, code generation controlled by this option will
change to reflect the processors that are most common at the
time that version of GCC is released.
There is no -march=generic option because -march indicates the
instruction set the compiler can use, and there is no generic
instruction set applicable to all processors. In contrast,
-mtune indicates the processor (or, in this case, collection of
processors) for which the code is optimized.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The BR2_GCC_TARGET_TUNE option is now unused, so we can get rid of it.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
On m68k, we are passing the exact same values of BR2_GCC_TARGET_ARCH
and BR2_GCC_TARGET_TUNE, which is redundant. Therefore, this commit
removes the usage of BR2_GCC_TARGET_TUNE on m68k.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
According to the gcc documentation for PowerPC options:
'-mtune=CPU_TYPE'
Set the instruction scheduling parameters for machine type
CPU_TYPE, but do not set the architecture type, register usage, or
choice of mnemonics, as '-mcpu=CPU_TYPE' would. The same values
for CPU_TYPE are used for '-mtune' as for '-mcpu'. If both are
specified, the code generated will use the architecture, registers,
and mnemonics set by '-mcpu', but the scheduling parameters set by
'-mtune'.
In the case of Buildroot where we only target a specific system, using
-mtune therefore doesn't make much sense, and using -mcpu would be
more appropriate. As a consequence, this patch makes PowerPC use
BR2_GCC_TARGET_CPU instead of BR2_GCC_TARGET_TUNE.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
On SPARC, BR2_GCC_TARGET_TUNE was only used for one specific case, the
BR2_sparc_v8. There is actually no reason to not use
BR2_GCC_TARGET_CPU instead for this, as all values supported for
-mtune are also supported for -mcpu. Therefore, the only
BR2_GCC_TARGET_TUNE case is moved as a BR2_GCC_TARGET_CPU case.
[Peter: fixup merge conflict after 'sparc: Add leon3 cpu type and remove sparc{s,h}fleon{,v8}]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
According to the gcc documentation, -march implies -mtune on x86, so
defining both BR2_GCC_TARGET_ARCH and BR2_GCC_TARGET_TUNE is
redundant. Therefore, this commit removes the definition of
BR2_GCC_TARGET_TUNE on x86.
However, while doing so, it adds one new case for BR2_GCC_TARGET_ARCH:
using -march=generic when BR2_x86_generic is selected.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
On ARM, we were defining both the CPU type and the architecture
variant. However, depending on the version of gcc, a given combination
of (CPU, architecture) may not be the same. Since the architecture
variant is implied by the CPU type, given the former is not necessary,
and we can simply specify the latter.
>From the gcc documentation:
This specifies the name of the target ARM processor. GCC uses this
name to derive the name of the target ARM architecture (as if
specified by -march) and the ARM processor type for which to tune
for performance (as if specified by -mtune). Where this option is
used in conjunction with -march or -mtune, those options take
precedence over the appropriate part of this option.
Note that we verified that for all BR2_GCC_TARGET_ARCH value that
existed, a proper BR2_GCC_TARGET_CPU value is defined.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In commit 88cf3bb917
("arch/Config.in.arm: Use armv6k for arm1136jf-s rev1"), Benoît
Thébaudeau added separate options for the revision 0 and revision 1 of
the ARM1136JF-S processor, so that different -march values could be
used (armv6j for revision 0, armv6k for revision 1).
However, this is preventing the removal of the BR2_GCC_TARGET_ARCH
option, which we need to do to give only the CPU type to gcc, and let
it decide the architecture variant that matches. This is because this
story of revision 0 vs. revision 1 is the only case where -mcpu
doesn't fully define the CPU.
Moreover, a quick test with gcc shows that -march=armv6j
-mcpu=arm1136jf-s is accepted, while -march=armv6k -mcpu=arm1136jf-s
makes gcc complain: " warning: switch -mcpu=arm1136jf-s conflicts with
-march=armv6k switch".
In addition, gcc 5 will apparently no longer allow to pass all of
--with-arch, --with-cpu and --with-tune, so we will anyway have to
rely only on one of them.
As a consequence, this commit basically reverts
88cf3bb917 and provides only one option
for ARM1136JF-S. If the two revisions are really different, then they
should be supported in upstream gcc with different -mcpu values.
Note that the removal of the two options should not break existing
full .config, since the hidden option BR2_arm1136jf_s becomes again a
visible option to select the CPU.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Synopsys has recently announced its new ARC HS38 core that is capable of
running Linux -
http://www.synopsys.com/dw/ipdir.php?ds=arc-hs38-processor
ARC HS38 is based on ARCv2 ISA and requires special settings of gcc and
libc.
Also in case of HS38 atomic extensions (LLOCK/SCOND instructions) are
built-in by default, so enabling atomic extensions in Buildroot as well.
This commit adds support of the core in buildroot.
[Peter: string type, so must be in quotes as noted by Yann]
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Anton Kolesov <anton.kolesov@synopsys.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This separation allows to specify unique options and features for each
CPU.
For example ARC 770D has LLOCK/SCOND instructions built-in by default.
Also this new scheme simplifies selection of proper configuration for
users - preconfigured options now match templates for ARC CPUs.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Anton Kolesov <akolesov@synopsys.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
There is support for -mcpu=leon3 from gcc 4.8.3. Use this for LEON systems
instead of the non-mainline targets sparcsfleon, sparchfleon, sparcsfleonv8, and
sparchfleonv8.
[Thomas: add Config.in.legacy handling for the removed options.]
Signed-off-by: Andreas Larsson <andreas@gaisler.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
In preparation to the removal of BR2_GCC_TARGET_ARCH for ARM, this
commit introduces a number of blind options for each ARM architecture,
so that packages/toolchains that had dependencies using
BR2_GCC_TARGET_ARCH can continue to express their dependencies. It can
also be used to simplify package dependencies that were using the
individual ARM core options.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
The BR2_arm10t option is not correct as it references an ARM family,
while other options indicate a specific ARM core. The ARM cores in
ARM10 family are ARM1020E, ARM1022E and ARM1026EJ-S according to
Wikipedia. However, those are clearly very rare, and Wikipedia only
indicates two Conexant ADSL-related SoC as being part of this family
of ARM cores. Therefore, this commit removes this ARM family.
[Peter: remove nettle.mk reference as pointed out by Yann]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The BR2_GCC_TARGET_CPU defines a value for the BR2_arm920 case, but
this option does not exist. Therefore, this commit removes one line of
dead code.
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 <peter@korsgaard.com>
Due to a kconfig limitation, we can't select a no-prompt symbol that
gets its dependencies by being conditionally re-defined in one or more
if-blocks, like we currently do for BR2_ARCH_HAS_ATOMICS.
As a workaround to this issue, we just redefine that symbol in the arc
if-block, like we do for all other architectures, except that in the arc
case, the default value is conditional.
Reported-by: Anton Kolesov <Anton.Kolesov@synopsys.com>
[yann.morin.1998@free.fr: indepently re-done a patch similar to the one
Thomas made on his own]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Now that all architectures explicitly select this option when it makes
sense, there is no need to have a default value.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Anton Kolesov <Anton.Kolesov@synopsys.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Anton Kolesov <Anton.Kolesov@synopsys.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Anton Kolesov <Anton.Kolesov@synopsys.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Anton Kolesov <Anton.Kolesov@synopsys.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Anton Kolesov <Anton.Kolesov@synopsys.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Anton Kolesov <Anton.Kolesov@synopsys.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Anton Kolesov <Anton.Kolesov@synopsys.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Anton Kolesov <Anton.Kolesov@synopsys.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Anton Kolesov <Anton.Kolesov@synopsys.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Anton Kolesov <Anton.Kolesov@synopsys.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Anton Kolesov <Anton.Kolesov@synopsys.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Anton Kolesov <Anton.Kolesov@synopsys.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
armv6 and above all have one sort of atomic ops or another. For armv5
and below, they are emulated, either as a kernel trap, a kernel VDSO,
or compiler intrinsics.
Aarch64 is just armv8, so make it a single commit. ;-)
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Anton Kolesov <Anton.Kolesov@synopsys.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
It's now been replaced with BR2_ARCH_HAS_ATOMICS, annd all packages have
been changed to use that instead.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Anton Kolesov <Anton.Kolesov@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The fact that atomic operations are available is not really a
specificity of the toolchain, but rather of the architecture.
So, add a new option that architectures that have atomic operations
can select. This in turn selects the current toolchain atomic option,
until all packages have been converted, at which point the old
toolchain option can be removed.
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Anton Kolesov <Anton.Kolesov@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
GCC has several builtin functions that implement atomic operations. Those
functions are architecture specific and may not be implemented by the
specific toolchain. In case of GCC for ARC those functions rely on
LLOCK/SCOND instructions which are optional in ARC CPU's. If ARC CPU doesn't
support those instructions but software tries to use them, then application
will be aborted with Illegal instruction exception. To avoid confusion user
should first specify that their CPU supports atomic extension, which will
allow selection of packages that use builtin atomic functions.
Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The AVR32 architecture from Atmel is obsolete since a long time, not
supported upstream in most of the toolchain components (requires a
special version of gcc, an old version of uClibc, etc.). Until
February, Simon Dawson was making an excellent job at maintaining
AVR32 in Buildroot, and fixing all the issues caused by this
architecture. However, Simon focus has changed, and despite his call
for a new maintainer for AVR32 in Buildroot, nobody stepped up.
The issue of maintaining AVR32 is becoming worse and worse, so this
patch proposes to deprecate it for 2014.08, but keeping the support
around, to remove it for sure in 2014.11.
Cc: Simon Dawson <spdawson@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This enables powerpc64 and powerpc64le. Currently, le needs at least
glibc 2.19 and gcc 4.9.0. For gdb, 7.7.1 works (added in an earlier
patch).
[Peter: also disallow gcc 4.8 for ppc64le]
Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
