They are loosely ordered according to the ordering of the gcc
documentation. It is not entirely correct as the generic x86-64,
x86-64-v2, x86-64-v3 and x86-64-v4 are listed before i386 in the gcc
documentation, but this nevertheless gives a good explanation for the
overall ordering of the list.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
These were added in gcc 9.x. The goldmont, goldmont-plus and tremont
are for the low-power CPUs. While cascadelake and tigerlake are for
the high-end ones.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Both skylake and skylake-avx512 were added in gcc 6.x. According to
https://en.wikipedia.org/wiki/Skylake_(microarchitecture) the early
Skylake processors indeed did not have AVX512 support, while the later
ones did, hence the separate gcc options.
Due to this being the first CPU we support with AVX512, this commit
adds BR2_X86_CPU_HAS_AVX512.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
These were added in gcc commit
d3c11974032e21121a051d423a1d71097edf752f ("Use proper Intel processor
names for -march=/-mtune=") which was merged in gcc 4.9.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
In gcc commit d3c11974032e21121a051d423a1d71097edf752f ("Use proper
Intel processor names for -march=/-mtune="), which was merged in gcc
4.9, the following replacements were made:
* corei7 -> nehalem
* corei7-avx -> sandybridge
* core-avx-i -> ivybridge
* core-avx2 -> haswell
* atom -> bonnel
* slm -> silvermont
So this commit marks the Buildroot options BR2_x86_corei7,
BR2_x86_corei7_avx, BR2_x86_core_avx2 and BR2_x86_atom as deprecated,
and adds the four corresponding options with the newer names.
Note that the older options are still kept because the new option
names are only supported starting gcc 4.9, and we theoretically still
supports targets gcc as old as gcc 4.3.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The BR2_ARCH definition is like this:
* i486 for the i486 platform
* i586 for a small number of platforms
* i686 for all other x86 platforms when used in 32-bit, but we
enumerate their entire list
* x86_64 for all x86 64-bit platforms
The list for i686 is long and needs to be extended everytime a new
platform is added, with no added value.
So this commit simplifies that by replacing this long list with just:
default "i686" if BR2_i386
This works because Kconfig guarantees us that if an i386 platform
matches an earlier case (i486 or one of the i586 platforms), the i486
and i586 earlier in the list will match.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
We already have support for a wide range of x86-64 CPUs, but we don't
have any option to build for the most generic possible x86-64 CPU, as
made available by the -march=x86-64 GCC option.
This commit makes this option available in Buildroot.
It only really makes sense to use as a 64-bit CPU, and not as a 32-bit
one, so we guard it behind BR2_x86_64.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[yann.morin.1998@free.fr: it's an x86-64-only CPU]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Linux supports No-MMU RISC-V 64-bits since kernel version 5.8. Make
MMU optional to enable building for RISC-V 64-bits boards that do not
have one. MMU use of RISC-V 32-bits builds remains mandatory for now.
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
We are going to remove the gcc fork for csky, first disable
the internal toolchain backend.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Guo Ren <ren_guo@c-sky.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Asked-by: Guo Ren <guoren@kernel.org>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This new symbol will be used by architectures introduced with gcc 11.
[1] https://gcc.gnu.org/gcc-11/changes.html
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
For the HS48 processor, BR currently builds with -mcpu=hs4x_rel31 which
generates suboptimal code as it inhibits delay slot and back-back ST and so on.
Enable a new variant to build with -mcpu=hs4x for normal codegen.
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
[yann.morin.1998@free.fr:
- simplify dependencies on MMU page size
- wrap long lines
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The whole arch/Config.in.s390x file is only included by arch/Config.in
if BR2_s390x=y, so having "depends on" conditions on each options of
the choice doesn't make much sense.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[yann.morin.1998@free.fr: drop first, empty line]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
[yann.morin.1998@free.fr: drop supperfluous depends on s390x in choice]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This new symbol will be used by architectures introduced with gcc 10.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Back in the day we relied on a default value that used to be 8KiB
and it worked perfectly fine for ARC's default 8KiB page as well as
4 KiB ones, but not for 16 KiB, see [1] for more details.
So that we fixed by setting "max-page-size" if 16KiB pages are in use by
commit d024d369b8 ("arch/arc: Accommodate 16 KiB MMU pages").
But as Yann very rightfully mentioned here [2] we should be setting this
thing explicitly for all page sizes because:
1. Defaults might change unexpectedly
2. Explicitly set stuff is better understood
3. We act similarly to all settings but not only addressing some corner cases
[1] https://git.buildroot.org/buildroot/commit/?id=d024d369b82d2d3d9d4d75489c19e9488202bca0
[2] https://patchwork.ozlabs.org/patch/1212544/#2330647
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
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>
