Currently, we consider that any VFP FPU is a superset of VFPv2, and thus
we use VFPv2 as a way to detect that a VFP is used.
However, for Cortex-M cores, the optional FPU is not a superset of
VFPv2; it is even not a VFP [0].
As a consequence, we can no longer consider VFPv2 as a indication that
an FPU is present.
So, we introduce two new internal options, BR2_ARM_CPU_MAYBE_HAS_FPU and
BR2_ARM_CPU_HAS_FPU, which we use to consider the presence of an FPU.
[0] https://en.wikipedia.org/wiki/ARM_Cortex-M#Cortex-M4
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Nothing fancy, just a plain Cortex-M, armv7-M core...
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The Blackfin architecture has for a long time been complicated to
maintain, with poor support in upstream binutils/gcc. As of April
2018, the Blackfin architecture has been dropped from the upstream
Linux kernel. Also, the Analog Device engineer who used to be in touch
with the Buildroot community also privately said we should drop the
support for this architecture, which Analog Devices is no longer
using, promoting and maintaining.
The BR2_BINFMT_FLAT_SEP_DATA option becomes unselectable, it will be
removed in a future commit.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
... to follow the convention: type, default, depends on, select, help.
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The old Atom target is not really fitting for recent Atom CPUs based
on Silvermont, Airmont or Goldmont. Those have more in common with
older Desktop CPUs than old Atoms.
Signed-off-by: Norbert Lange <norbert.lange@andritz.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since we re-organised the list of cores (in 52d500aa35) and introduced
some new cores (in e9960da6ec, d632d9e5a9, 6317a199ec), the default for
AArch64 was accidently changed from A53 to A35.
So, restore the default to A53 for AArch64.
Reported-by: daggs <daggs@gmx.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: daggs <daggs@gmx.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The armv8.1a generation is a cumulative extension to armv8a. It adds new
extensions, and makes some previously optional ones now mandatory.
Since gcc correctly enables the appropriate extensions based on the core
name, we don't really need to introduce a separate config for armv8.1a,
and we can piggyback on armv8a.
All those new cores are aarch64 only (gcc fails to build in arm mode).
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>
Some need gcc-5, some gcc-6 and some gcc-7.
The thunderx familly does not build in 32-bit mode (gcc complains
that the CPU is unknown, and even gcc master only knows them as
aarch64-only).
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>
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>
The cortex-A32 is an armv8a core, but it lacks the optional AArch64
extensions, so can only work in 32-bit mode.
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>
For armv8, there are different profiles: A, M and R, like there is for
armv7.
So, rename our internal symbol to mirror what we do for armv7.
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>
Now that the cores are all oredered correctly, we can just enclose all
the non 64-bit cores inside a big if-block, rather than have each of
them have the dependency.
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 logic for ordering the ARM cores in the choice is all
but obvious. ;-)
Reorder the choice by architecture generation, starting with armv4,
ending with armv8.
Add a comment before each generation, just for ease of use. Add a
separate comment for armv7a and armv7m.
Finally, order cores alphabetically inside the same generation (except
for armv7m cores, listed after all armv7a cores).
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 possibility to choose the floating point mode (32, xx or
64) is conditional on having a sufficiently recent gcc version.
Which means that the architecture selection depends on the gcc version.
But that's opposite to what we've always done in Buildroot: the software
versions are conditional to the architecture options. There is nothing
we can do about the hardware: it is there, we can't change it, while we
can restrict ourselves to using software that is working on said
hardware.
Thus, we inverse the logic, to move the condition onto the software
side: whenever mfpxx is selected, we restrict the toolchain selection to
at least a gcc-5.
And now, the blind BR2_TOOLCHAIN_HAS_MFPXX_OPTION symbol is no longer
needed, so we get rid of it.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Currently the possibility to choose the NaN encoding is conditional to
having a sufficiently recent gcc version.
Which means that the architecture selection depends on the gcc version.
But that's opposite to what we've always done in Buildroot: the software
versions are conditional to the architecture options. There is nothing
we can do about the hardware: it is there, we can't change it, while we
can restrict ourselves to using software that is working on said
hardware.
Thus, we inverse the logic, to move the condition onto the software
side: whenever NaN-2008 are selected, we restrict the toolchain
selection to at least a gcc-4.9.
But now, the option with the NaN type is always set, so we must enclose
the code in gcc.mk inside a HAS_NAN_OPTION condition, as is already done
for the external toolchain case.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Take the conditions currently specified in the gcc version choice.
Also, the conditions explained in the commit log for 78c2a9f7 were not
all properly applied, especially the a57-a53 combo needs gcc-6, but
78c2a9f7 forgot to add the condition to gcc-4.9.
gcc-4.9 was excluded for cortex-a17 and a72, but the CodeSourcery
external toolchain, which uses 4.8, was not excluded for those two
cores. Now it is.
Remove the arch condition from gcc and the external toolchains.
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>
We use the conditions currently expressed in the gcc version choice.
We leave the musl vs mips64 conditions in gcc, because the "fault"
really is on gcc, which does not recognise the mips64+musl tuples,
so the fix lies within gcc, and the current conditions are fitting.
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>
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>
Some CPU variants require that a recent-enough gcc be selected. For
example, ARM's cortex-a35 requires gcc-5, while cortex-a73 requires
gcc-7. Same goes for other architectures, of course.
Currently, we hard-code every such conditions in the gcc version choice,
as well as in the individual external toolchains.
However, as we add even more CPU variants, the conditions are getting
more and more complex to write and maintain.
Introduce new symbols, that architectures can select if they have a
specific requirement on the gcc version. gcc and external toolchains
can then properly depend on those symbols.
The burden of maintaining the requirements on the gcc version now falls
down to the architeture, instead of being split up in gcc and all the
external toolchains.
As the oldest gcc version to handle, we can either choose gcc-4.9, as
the oldest version we support in our internal toolchain, or choose
gcc-4.8, as the oldest external toolchain we support (except for the
custom ones, but they'll be handled specifically in upcoming changes).
We choose to go back up to gcc-4.8.
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>
Those cores are not supported in upstream gcc, not even in master.
The only toolchain that supported those core was the 2014R1 ADI
rebuilt toolchain, but we removed it in 311bc13 (toolchain: kill
ADI Blackfin toolchain) because there was too many issues with it.
ADI has not released any newer toolchain since then.
There is little hope for those cores now, so remove them.
Support for those cores has been useless and unusable for a while
without nobody noticing, therefore we intentionally skip adding
Config.in.legacy. This would require keeping code in
arch/Config.in.bfin since the options being removed are inside a
choice...endchoice block.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
[Thomas: explain why we don't add the options to Config.in.legacy.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Some cores are not supported by upstream gcc.
Use the newly-introduced symbol to state so, rather than have the
exclusion in the toolchain choice.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Some cores are not supported by upstream gcc.
Use the newly-introduced symbol to state so, rather than have the
exclusion in the toolchain choice.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Upstream gcc does not have support for C-Sky, and we do not have a
vendor tree for it either (yet?).
Use the newly-introduced symbol to state so, rather than have the
exclusion in the toolchain choice.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Some architectures or specific cores do not have support in upstream
gcc. Currently, they are individually listed as exclusions in the
toolchain choice.
This poses a maintainance burden, as the knowledge about what gcc
version supports what architecture is split across many places: the
toolchain choice, the gcc version choice, the external toolchains.
As a first step, add a blind option that architectures or individual
cores may select to indicate they lack support in our internal backend.
Actual use of the option will come in followup patches.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The big.LITTLE configurations can be optimised for by gcc, and a few
users wonder what they should choose when they have such CPUs.
Add new entries for those big.LITTLE configurations.
Note: the various combos were added in various gcc versions, but only
really worked in later versions:
Variant | Introduced in | First built in
----------+---------------+----------------
a15-a7 | 4.9 | 4.9
a17-a7 | 5 | 5
a57-a53 | 4.9 | 6
a72-a53 | 5 | 6
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Cc: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-mfpxx option was added in gcc-5.1.0 so make sure that users cannot
select the "xx" fp32 mode when using toolchains that have a gcc older
than 5.1.0.
-mfp32 and -mfp64 were added in gcc-4.1.0, so given the older gcc
version we support in Buildroot (in the GCC_AT_LEAST options) is 4.3 we
don't need to do anything else for them.
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
-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>
-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>
