As reported by Alexey in:
https://patchwork.ozlabs.org/patch/1087480/https://patchwork.ozlabs.org/patch/1087471/
when BR2_ARC_ATOMIC_EXT is enabled, -matomic needs to always be passed
to the compiler to allow atomic instructions to be used. So instead of
passing them through the command-line CFLAGS, we enforce them in the
toolchain wrapper directly.
Reported-by: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Acked-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
... and not an armv8.3a like previously supposed:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=886d991373e4dc5a746d0a33de64f1b36e61eed9
So, change the correspoding labels and comments.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
In gcc-9, some cores from the ThunderX familly have been renamed to
their marketting names, i.e. OcteonTX. Subsequently, new core names
have been added to gcc, with the old names still being around.
Update the prompts with the new names as alternative to the existing
names. We still keep the kconfig options as-is, so that we do not need
to add legacy handling.
However, since there is no guarantee for how long gcc will retain
compatibility for the older names, we readily switch over to using the
new names when using a gcc 9-or-later, but keep using the older names
with gcc older than 9.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
[Arnout: don't rely on ordering, but make condition explicit]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
It will make it easier to introduce new variants anywhere in the
list, when those variants have different bitness requirements.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
This new symbol will be used by architectures introduced with gcc 9 and
by external toolchains based on gcc 9.
[1] https://gcc.gnu.org/gcc-9/changes.html
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
It is too sad when an editor picks up the wrong syntax...
Like was done in e837837791 for all the other archs, force
syntax to kconfig for nds32 too.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Nylon Chen <nylon7@andestech.com>
Reviewed-by:Nylon Chen <nylon7@andestech.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The westmere line of x86_64 targets lies between nehalem (corei7) and
sandybridge (corei7-avx). Allowing use of -march=westmere enables use of
AES instruction set on these targets.
Signed-off-by: Esben Haabendal <esben@geanix.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
gcc target abi options for powerpc were added by [1] and renamed by [2]
to BR2_PPC_ABI_* but never used. Since always BR2_GCC_TARGET_ABI is empty
when using a powerpc toolchain.
Buildroot currently support SPE and Classic target ABI, nothing seems
to require a specific gcc target abi option.
This patch is a cleanup like commit [3].
[1] 7d8a59b40e
[2] 98175bd43d
[3] fd08153b9d
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Cyril Bur <cyrilbur@gmail.com>
Cc: Sam Bobroff <sam.bobroff@au1.ibm.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Now that we have support for C-SKY in gcc, binutils and glibc, we can
use Buildroot to build a C-SKY toolchain.
Signed-off-by: Guo Ren <ren_guo@c-sky.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
ck860 is newest CPU core of C-SKY with high performance & SMP
supported.
Signed-off-by: Guo Ren <ren_guo@c-sky.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The C-SKY architecture uses two different ABIs, depending on the core
being used:
- "abiv1" is a mcore based ISA with ELF_NUM:39 and does not support
FPU & VDSP. It is used only for the ck610 core.
- "abiv2" is C-SKY's own ISA with ELF_NUM:252 and supports FPU &
VDSP. It is used for the ck807, ck810, ck860 cores.
Since "abiv1" does not support FPU, BR2_GCC_TARGET_FLOAT_ABI will
always have the value "soft" for the ck610 core.
Signed-off-by: Guo Ren <ren_guo@c-sky.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[Thomas: rework commit log]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
VDSP is C-SKY enhanced extension instruction set for SIMD, AI and DSP
operation. It is supported by abiv2, used by the ck807, ck810, ck860
cores.
Signed-off-by: Guo Ren <ren_guo@c-sky.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[Thomas: update help text in Config.in.legacy about the BR2_CSKY_DSP
option.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The DSP extention is in fact no longer used for C-SKY, nor supported
by C-SKY gcc, so we remove it.
Signed-off-by: Guo Ren <ren_guo@c-sky.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[Thomas: split from the VDSP patch, add Config.in.legacy]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Calculating GCC_TARGET_CPU requires combining multiple flags, which
isn't very nicely expressed in Config.in, so let's move this into
arch.mk.csky, similarly to what is done in arch.mk.riscv.
Signed-off-by: Guo Ren <ren_guo@c-sky.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[Thomas: rework commit log]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
It is too sad when an editor picks up the wrong syntax...
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This commit provides basic support for the Andes 32-bit (nds32)
architecture.
Signed-off-by: Che-Wei Chuang <cnoize@andestech.com>
Signed-off-by: Greentime Hu <greentime@andestech.com>
Signed-off-by: Nylon Chen <nylon7@andestech.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The compiler recognizes a specific 'march' value for Octeon III processors,
so create a 'Target Architecture Variant' entry for it in the target menu.
Note: support for '-march=octeon3' was added in gcc 5.x. However, the
official compiler provided by Marvell (Cavium Networks) uses gcc 4.7.x (and
supports -march=octeon3 via their own modifications). For this reason, no
line 'select BR2_ARCH_NEEDS_GCC_AT_LEAST_5' is added.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The compiler recognizes a specific 'march' value for Octeon II processors,
so create a 'Target Architecture Variant' entry for it in the target menu.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
It's unclear why Buildroot only defined MIPS 32/64 releases 1, 2, 5 and 6
while 3 exists as well.
Interesting fact:
"Release 4 was skipped because the number four is perceived as unlucky in
many Asian cultures."
https://en.wikipedia.org/wiki/MIPS_architecture#MIPS32/MIPS64
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This enables a riscv32 system to be built with a Buildroot generated
toolchain (gcc >= 7.x, binutils >= 2.30, glibc only).
This requires a custom version of glibc 2.26 from the riscv-glibc
repository. Note that there are no tags in this repository, so the
glibc version just consists of the 40 character commit id string.
Thanks to Fabrice Bellard for pointing me towards the 32-bit glibc
repository and for providing the necessary patch to get it to build.
Signed-off-by: Mark Corbin <mark.corbin@embecosm.com>
Reviewed-by: Matt Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The armv8.3a generation is a cumulative extension to armv8.2a.
Since gcc correctly enables the appropriate extensions based on the core
name, we don't really need to introduce a separate config for armv8.3a,
and we can piggyback on armv8a.
This new core is AArch64 only.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The armv8.2a generation is a cumulative extension to armv8.1a.
Since gcc correctly enables the appropriate extensions based on the core
name, we don't really need to introduce a separate config for armv8.2a,
and we can piggyback on armv8a.
In theory, gcc supports those cores in arm mode. However, configuring
gcc thusly generates a non-working gcc that constantly whines:
cc1: warning: switch -mcpu=cortex-a55 conflicts with -march=armv8.2-a switch
It is to be noted that the -march flag is internal to gcc. It is not
something that Buildroot did set when configuring gcc; Buildroot only
ever sets --with-cpu (not --with-arch).
Additionally, uClibc fails to build entirely (unsure if this is caused
by the above, or if it is a separate issue, though), with:
#### Your compiler does not support TLS and you are trying to build uClibc-ng
#### with NPTL support. Upgrade your binutils and gcc to versions which
#### support TLS for your architecture. Do not contact uClibc-ng maintainers
#### about this problem.
Glibc and musl have not been tested in arm mode, so maybe we could have
a toolchain that eventually works (or at least, pretends to be working),
but we decided it was not worth the effort.
Thus, we restrict those cores to AArch64 mode only.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Since gcc-8, falkor and qdf24xx have been available only as
AArch64. Indeed, according to upstream commit [1], the released HW has
never supported AArch32.
[1] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=96a411453d39e6583fa4d7008761a1977cdbe7fa
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[Thomas: improve commit log]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Those cores are already guarded by a 64-bit-only condition, so they
can't even select additional options in non-64-bit mode anyway...
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
In commit 325bb37942, support for the
Blackfin architecture was removed. This was our only use of
BR2_GCC_TARGET_CPU_REVISION, and since this config option somewhat
complicates the calculation of the --with-cpu/-mcpu option values,
let's drop it.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This enables a riscv64 system to be built with a Buildroot generated
toolchain (gcc >= 7.x, binutils >= 2.30, glibc only).
This configuration has been used to successfully build a qemu-bootable
riscv-linux-4.15 kernel (https://github.com/riscv/riscv-linux.git).
Signed-off-by: Mark Corbin <mark.corbin@embecosm.com>
[Thomas:
- simplify arch.mk.riscv by directly setting GCC_TARGET_ARCH
- simplify glibc.mk changes by using GLIBC_CONF_ENV.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The BR2_GCC_TARGET_* configuration variables are copied to
corresponding GCC_TARGET_* variables which may then be optionally
modified or overwritten by architecture specific makefiles.
All makefiles must use the new GCC_TARGET_* variables instead
of the BR2_GCC_TARGET_* versions.
Signed-off-by: Mark Corbin <mark.corbin@embecosm.com>
[Thomas: simplify include of arch/arch.mk]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Now that we dropped support for blackfin, we no longer have any
architecture that supports FDPIC, so BR2_ARCH_HAS_FDPIC_SUPPORT
is never selected, so we can't select BR2_BINFMT_FDPIC.
Drop all of that now.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This new symbol will be used by architectures introduced with gcc 8 and
by external toolchains based on gcc 8.
[1] https://gcc.gnu.org/gcc-8/changes.html
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
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>
