ARC processors are known for its configurability and one of those
configurable things is MMU page size which might be set to any
power of two from 4 KiB to 16 MiB, though in the Linux kernel we
only support 4, 8 and 16 KiB due to practical considerations.
And the most used setting is 8 KiB thus GNU LD assumes maximum
page size is 8 KiB by default and while this works for smaller
pages (it's OK to align segments by larger value it will be still
peoperly aligned) this breaks execution of user-space apps on HW
with larger pages because Elf sections might very well span across
allocated pages and thus make executable broken.
Simplest example:
------------------------------------>8-----------------------------------
$ arc-linux-gcc test.c
$ arc-linux-readelf --segments a.out
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
...
LOAD 0x000000 0x00010000 0x00010000 0x003e8 0x003e8 R E 0x2000 <-- See
LOAD 0x001f24 0x00013f24 0x00013f24 0x000f0 0x0010c RW 0x2000
------------------------------------>8-----------------------------------
Fortunately we may override default page size settings with "max-page-size"
linker option this way:
------------------------------------>8-----------------------------------
$ arc-linux-gcc test.c -Wl,-z,max-page-size=16384
$ arc-linux-readelf --segments a.out
Elf file type is EXEC (Executable file)
Entry point 0x102c4
There are 8 program headers, starting at offset 52
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
...
LOAD 0x000000 0x00010000 0x00010000 0x003e8 0x003e8 R E 0x4000 <-- See
LOAD 0x001f24 0x00015f24 0x00015f24 0x000f0 0x0010c RW 0x4000
------------------------------------>8-----------------------------------
Which we implement with that change.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
[yann.morin.1998@free.fr: fix comment: s/8196/8192/]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This corresponds to -mcu=hs38 with mpy-option=9 (64-bit multiplier)
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This patch sets the default floating point ABI based on the ISA
extensions that have been selected rather than defaulting to soft
float.
For 64-bit:
ISA 'D' selects lp64d
ISA 'F' selects lp64f
Otherwise select lp64
For 32-bit:
ISA 'D' selects ilp32d
ISA 'F' selects ilp32f
Otherwise select ilp32
This change was proposed by Palmer Dabbelt at SiFive.
Signed-off-by: Mark Corbin <mark.corbin@embecosm.com>
Reviewed-by: Palmer Dabbelt <palmer@sifive.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This patch introduces a recently released significant update to ARC HS
family: ARC HS48.
One of the major ARC HS48 features is dual-issue pipeline which requires a
little bit modified instruction scheduling compared to single-issue cores
(HS38), thus new "-mcpu/--with-cpu=hs4x".
Also to address some peculiarities of early designs based on HS48 we
introduced yet another "-mcpu/--with-cpu=hs4x_rel31" which we're going to use
as well on some of our development boards.
Signed-off-by: Evgeniy Didin <didin@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: arc-buildroot@synopsys.com
[Peter: fixup check-package warnings]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
We used to build everything for pretty much baseline ARC HS capable
of runnig Linux kernel, which was ARC HS38/48 with MMU and caches.
But there's a fully featured ARC HS with additional support for
- Dual & quad integer multiply and MAC operations
- Double-precision floating-point unit
It corresponds to the following ARC HS templates in ARChitect: hs38_slc_full.
In fact existing HSDK board uses exactly this configuration in its SoC
and this is recommended configuration for Linux use-cases.
To make life simpler we have corresponding "-mcpu" and "--with-cpu"
options in ARC GCC port so we're going to use it and get binaries
built accordingly optimized.
And while at it added help message so users may better understand
what they are dealing with.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
As Guo explained, upstream gcc does not support abi-v1 (only abi-v2), but
ck610 needs abi-v1 [0] [1]
To simplify things, we make the whole C-SKY architecture require gcc-9
or later, and add a single exception in gcc to force the ck610 to use
the C-SKY port.
Note that this does not change the default gcc version to be used for
C-SKY: the C-SKY port is still always the default one; the gcc-9 version
is only proposed as an alternative (except for ck610, of course).
[0] http://lists.busybox.net/pipermail/buildroot/2019-July/254386.html
[1] package/Makefile.in#73
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Guo Ren <guoren@kernel.org>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Romain Naour <romain.naour@gmail.com>
Acked-by: Guo Ren <guoren@kernel.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
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>
