Commit Graph

339 Commits

Author SHA1 Message Date
Thomas Petazzoni
1a21705e73 arch/Config.in.x86: westmere and silvermont were added in gcc 4.9
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>
2022-01-25 08:41:10 +01:00
Thomas Petazzoni
653fa001f3 arch/Config.in.x86: add "newer" names for several Intel x86 CPU variants
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>
2022-01-25 08:41:08 +01:00
Thomas Petazzoni
73d135a695 arch/Config.in.x86: drastically simplify the BR2_ARCH definition
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>
2022-01-25 08:41:06 +01:00
Thomas Petazzoni
eeace1cc13 arch/Config.in.x86: add support for x86-64-v2, x86-64-v3, x86-64-v4
In the face of the vast amount of x86-64 CPU architecture variants,
Linux distributions have worked together to define "micro-architecture
levels" in the x86-64 psABI, called x86-64-v2, x86-64-v3 and
x86-64-v4. They standardize a set of CPU features, and GCC since its
version 11.x has support for these micro-architecture levels as
-march= options.

It makes sense to support them in Buildroot, especially for those who
want to build toolchains that aim at targeting a reasonably broad
family of x86-64 processors.

It only really makes sense to use as 64-bit CPUs, and not as 32-bit
ones, so we guard them behind BR2_x86_64.

More details:

 https://gitlab.com/x86-psABIs/x86-64-ABI/-/blob/master/x86-64-ABI/low-level-sys-info.tex
 https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-linux-9-for-the-x86-64-v2-microarchitecture-level
 https://www.phoronix.com/scan.php?page=news_item&px=GCC-11-x86-64-Feature-Levels
 https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=59482fa1e7243bd905c7e27c92ae2b89c79fff87

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[yann.morin.1998@free.fr:
  - they are x86-64-only CPUs
  - add gcc commit URL
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-01-09 11:30:26 +01:00
Thomas Petazzoni
d6ce2a1681 arch/Config.in.x86: add option for -march=x86-64
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>
2022-01-09 11:30:26 +01:00
Damien Le Moal
343643fdf1 arch/config: Make RISC-V 64-bits MMU optional
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>
2021-10-27 14:39:01 +02:00
Romain Naour
547d681b45 package/gcc: remove csky version
Remove gcc csky fork since it doesn't build with the latest compilers
(gcc 8, 10, 11 tested) [1].

Removing the csky gcc fork has become unavoidable since the
Buildroot Docker image used by the gitlab CI will switch soon to
Debian bullseye soon [2].

The csky support for csky807 and csky810 has been upstreamed in
gcc 10 [3] and csky860 will be supported by gcc 12 [4]. There is
no info about the csky610. Although the csky architecture is
supported since gcc 10, the support was not enabled in Buildroot.

[1] http://lists.busybox.net/pipermail/buildroot/2021-August/621504.html
[2] 71b8322712
[3] https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=cc7232b999b8336cf4e261407ed9289c77bed1f0
[4] https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=db92bd223e3957ee58b5a0c0fffd8b7766f1def3

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>
2021-10-17 18:59:22 +02:00
Romain Naour
69147f0391 arch/Config.in: disable internal toolchain backend for csky
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>
2021-10-17 18:59:06 +02:00
Romain Naour
b28e598cec arch: add BR2_ARCH_NEEDS_GCC_AT_LEAST_11
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>
2021-06-20 18:46:51 +02:00
Vineet Gupta
aefe5934a4 ARC: Add support for generic HS48 processor
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>
2021-01-16 09:58:26 +01:00
Michael Walle
f33009bbd3 arch/Config.in.powerpc: Drop PPC601 support
Linux support was removed in 5.10 [1]. Since no in-tree defconfig
depends on it, just remove it.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/powerpc?id=f0ed73f3fa2cdca65973659689ec9e46d99a5f60

Reported-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Michael Walle <michael@walle.cc>
[yann.morin.1998@free.fr: reorder legacy entry]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2020-12-15 19:30:03 +01:00
Thomas Petazzoni
6d2f97aabd arch/Config.in.s390x: drop redundant depends on BR2_s390x
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>
2020-09-30 21:36:07 +02:00
Alexander Egorenkov
29353bbef7 toolchain: add support for the internal IBM s390x and Z toolchain
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2020-09-24 22:03:54 +02:00
Alexander Egorenkov
b9a31ea354 arch: add the basic IBM s390x and Z arch support
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>
2020-09-24 22:02:03 +02:00
Romain Naour
b92b727d6f arch/Config.in: add BR2_ARCH_NEEDS_GCC_AT_LEAST_10
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>
2020-06-24 21:57:43 +02:00
Nicolas Robin
f6cd56b9ce arch/x86: adds BR2_X86_CPU_HAS_3DNOW flag
Signed-off-by: Nicolas Robin <nrosfs@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2020-05-15 21:47:50 +02:00
Alexey Brodkin
3cc2c6d19a arch/arc: explicitly set "max-page-size" for GNU LD
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>
2019-12-25 22:09:52 +01:00
Alexey Brodkin
d024d369b8 arch/arc: Accommodate 16 KiB MMU pages
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>
2019-12-22 21:56:21 +01:00
Vineet Gupta
4f115b521a arch/Config.in.arc: introduce the ARC optimized hs38 variant
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>
2019-11-12 21:51:13 +01:00
Mark Corbin
aee39cbf27 arch/riscv: set the default float ABI based on ISA extensions
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>
2019-09-19 21:43:53 +02:00
Evgeniy Didin
81fed0c7db ARC: Add support for ARC HS48 v3.1 processor
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>
2019-08-03 17:30:52 +02:00
Alexey Brodkin
a0835675ae ARC: Add support for ARC HS38 with Quad MAC & FPU
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>
2019-08-01 11:56:39 +02:00
Yann E. MORIN
b8aad93817 arch/csky: restrict ck610 to the C-SKY gcc port
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>
2019-08-01 10:15:17 +02:00
Yann E. MORIN
c568b4f37f arch/arc: always needs -matomic with atomic extensions
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>
2019-07-18 22:54:36 +02:00
Yann E. MORIN
0b630b5bf3 arch/arm: add two new non-cortex-based armv8.2a cores
The Neoverse N1 CPU was supported in GCC earlier through the codename Ares [1].

[1] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=37cf0ddecfd1eb5c6852a44135af5a92e5103931

Build tested:
https://gitlab.com/kubu93/buildroot/pipelines/60318953

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
[Romain: rename BR2_ares to BR2_neoverse_n1]
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
[Arnout: 'aka' instead of 'alias']
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2019-07-13 23:06:23 +02:00
Yann E. MORIN
e65a173e52 arch/arm: add two new cortex-based armv8.2a cores
The cortex-a76 implements the full amrv8.2a extensions, and some
optional extensions from the armv8.3a, armv8.4a, and armv8.5a sets,
but none of their mandatory extensions, which means that it does not
qualify for better than an armv8.2a:
    https://developer.arm.com/products/processors/cortex-a/cortex-a76
    http://infocenter.arm.com/help/topic/com.arm.doc.100798_0301_00_en/giq1479805174793.html
    http://infocenter.arm.com/help/topic/com.arm.doc.100798_0301_00_en/fjv1477559794375.html

Also, gcc fits it in the armv8.2a category, too:
    https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/aarch64/aarch64-cores.def;h=67ce42fb8aacd4c246295f32151a03b1f318ae44;hb=HEAD#l97

Build tested:
https://gitlab.com/kubu93/buildroot/pipelines/60318953

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>
2019-07-13 23:00:47 +02:00
Yann E. MORIN
ae179dd0cc arch/arm: add two new 64-bit-only armv8a cores
Build tested:
https://gitlab.com/kubu93/buildroot/pipelines/60318953

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>
2019-07-13 23:00:33 +02:00
Yann E. MORIN
b22ee8ad88 arch/arm: saphira is in fact an armv8.4a
... 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>
2019-07-13 22:59:31 +02:00
Yann E. MORIN
c0d1730153 arch/arm: some cores have a different name with gcc-9
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>
2019-07-13 22:57:42 +02:00
Yann E. MORIN
9f52763043 arch/arm: move dependency on 64-bit down to individual cores
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>
2019-07-13 22:51:51 +02:00
Romain Naour
16951722d7 arch: add BR2_ARCH_NEEDS_GCC_AT_LEAST_9
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>
2019-06-22 21:38:23 +02:00
Yann E. MORIN
faa13ee580 arch/Config.in.nds32: force syntax colouring to kconfig
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>
2019-06-20 21:27:20 +02:00
Esben Haabendal
97651ce275 arch: Add support for Westmere targets
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>
2019-06-13 21:09:51 +02:00
Esben Haabendal
498a1fabe8 arch: Fix typo breaking use of core-avx2 arch
Signed-off-by: Esben Haabendal <esben@geanix.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2019-06-08 12:04:02 +02:00
Peter Korsgaard
f590097045 Merge branch 'next'
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2019-06-02 22:11:20 +02:00
Romain Naour
eda77e17c1 arch/Config.in.powerpc: remove unused gcc target abi options for powerpc
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>
2019-06-01 14:26:29 +02:00
Guo Ren
6fe2fabdb8 arch/csky: enable internal toolchain support
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>
2019-05-31 23:00:42 +02:00
Guo Ren
20d6e092d8 arch/csky: add support for the ck860 core
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>
2019-05-31 22:59:57 +02:00
Guo Ren
a9b722732d arch/csky: specify BR2_GCC_TARGET_FLOAT_ABI
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>
2019-05-31 22:59:57 +02:00
Guo Ren
d2658caea0 arch/csky: add support for VDSP extensions
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>
2019-05-31 22:59:57 +02:00
Guo Ren
55c6422878 arch/csky: remove BR2_CSKY_DSP option
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>
2019-05-31 22:59:57 +02:00
Guo Ren
d26bd58502 arch/csky: move GCC_TARGET_CPU calculation to arch.mk.csky
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>
2019-05-31 22:59:57 +02:00
Yann E. MORIN
e837837791 arch: force syntax colouring to kconfig in Config.in.*
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>
2019-05-20 22:34:16 +02:00
Nylon Chen
b58a6bf774 package/binutils: fix build error due to architecture name is incomplete
Fixes
  http://autobuild.buildroot.net/results/128/12803a705586e82fdfb49013da2eb3b9879ccd45/

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>
2019-04-20 16:16:39 +02:00
Nylon Chen
1ad1d3d5cf arch: add support for Andes 32-bit (nds32)
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>
2019-04-17 09:03:37 +02:00
Thomas De Schampheleire
18b8d360bb arch/mips: add (Marvell) Octeon III processor
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>
2019-02-04 17:30:18 +01:00
Thomas De Schampheleire
b21e159b5d arch/mips: add (Marvell) Octeon II processor
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>
2019-02-04 17:30:06 +01:00
Thomas De Schampheleire
c49d446767 arch/mips: introduce mips32r3 and mips64r3
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>
2019-02-04 17:28:10 +01:00
Mark Corbin
ae99fa6d64 arch: add support for RISC-V 32-bit (riscv32) architecture
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>
2019-01-06 14:09:31 +01:00
Yann E. MORIN
354781dd96 arch/arm: add an armv8.3a core
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>
2018-12-30 16:10:04 +01:00
Yann E. MORIN
56a315f18f arch/arm: add armv8.2a cortex-based cores
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>
2018-12-30 16:09:17 +01:00
Yann E. MORIN
d9e8c74f0f arch/arm: restrict more armv8a cores to aarch64
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>
2018-12-30 15:37:35 +01:00
Yann E. MORIN
c427ca059d arch/arm: drop useless conditional dependencies for 64-bit-only cores
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>
2018-12-30 15:28:38 +01:00
Thomas Petazzoni
cf2b12cbfb arch: drop BR2_GCC_TARGET_CPU_REVISION option
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>
2018-10-01 14:52:32 +02:00
Mark Corbin
9b3d52b400 arch: add support for RISC-V 64-bit (riscv64) architecture
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>
2018-09-23 23:42:41 +02:00
Thomas Petazzoni
e2b0705743 arch/arch.mk: fix check-package warnings
"make check-package" is not happy with the formatting of the recently
introduced arch.mk:

arch/arch.mk:1: should be 80 hashes (http://nightly.buildroot.org/#writing-rules-mk)
arch/arch.mk:2: should be 1 hash (http://nightly.buildroot.org/#writing-rules-mk)
arch/arch.mk:4: should be 1 hash (http://nightly.buildroot.org/#writing-rules-mk)
arch/arch.mk:5: should be 80 hashes (http://nightly.buildroot.org/#writing-rules-mk)
arch/arch.mk:6: should be a blank line (http://nightly.buildroot.org/#writing-rules-mk)

Let's fix this by adding a comment header that makes check-package
happy.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-09-23 23:41:19 +02:00
Mark Corbin
bd0640a213 arch: allow GCC target options to be optionally overwritten
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>
2018-09-23 22:17:57 +02:00
Yann E. MORIN
58dcd28dfb arch: drop now useless support for FDPIC
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>
2018-07-01 15:17:27 +02:00
Romain Naour
c9216bc1d0 arch: add BR2_ARCH_NEEDS_GCC_AT_LEAST_8
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>
2018-05-30 21:44:01 +02:00
Yann E. MORIN
3e44065ab5 arch/arm: cortex-m7 may have a FPv5 FPU
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-05-20 19:15:07 +02:00
Yann E. MORIN
7ee527dd91 arch/arm: cortex-m4 may have an FPv4 FPU
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-05-20 19:14:14 +02:00
Yann E. MORIN
81d8a25bc8 arch/arm: add options for FPv5 FPU
Contrary to its older brother, the FPv5 comes in two flavours; single-
and double-precision [0] [1]. the two variants are only available for
cortex-m7 cores, and the two variants are known to gcc as fpv5-sp-d16
and fpv5-d16, respectively, since gcc-5 [2].

[0] https://en.wikipedia.org/wiki/ARM_Cortex-M#Cortex-M7
[1] https://developer.arm.com/docs/ddi0489/latest/floating-point-unit
[2] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=a076f99fa702deac764f6e0441b9435ad999f521

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-05-20 19:06:55 +02:00
Yann E. MORIN
09c6e28233 arch/arm: add option for FPv4 FPU
The FPv4-SP FPU is a single-precision FPU with 16 double registers [0]
[1]. It is only available for cortex-m4 cores, and is known to gcc as
fpv4-sp-d16 (note that there is no leading 'v') since gcc-4.5 [2].

[0] https://en.wikipedia.org/wiki/ARM_Cortex-M#Cortex-M4
[1] https://developer.arm.com/docs/ddi0439/latest/floating-point-unit
[2] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=639cb7b789a54bf78d6ae5e2644450f5eb1837a6

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-05-20 19:06:07 +02:00
Yann E. MORIN
7f7701301e arch/arm: introduce generic FPU internal option
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>
2018-05-20 19:01:34 +02:00
Yann E. MORIN
6edfa3bf78 arch/arm: add cortex-m7 core
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>
2018-05-20 18:57:18 +02:00
Thomas Petazzoni
e2ea4157a9 arch: drop BR2_BINFMT_FLAT_SEP_DATA support
This was only used by Blackfin, so there's no good reason to keep it.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-04-15 22:04:09 +02:00
Thomas Petazzoni
325bb37942 arch: remove Blackfin architecture
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>
2018-04-15 22:03:41 +02:00
Yann E. MORIN
01c1889f9f arc/xtensa: store the Xtensa overlay in the per-package DL_DIR
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>
2018-04-02 15:59:30 +02:00
Ricardo Martincoski
9b6b4e36b4 */Config.in*: remove consecutive empty lines
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-04-01 08:48:24 +02:00
Ricardo Martincoski
b2b8a3c3e4 arch/Config.in*: re-wrap help text
... to follow the convention <tab><2 spaces><62 chars>.

Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-04-01 08:00:13 +02:00
Ricardo Martincoski
7e26b8886b arch/Config.in*: fix attributes order
... 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>
2018-04-01 07:59:45 +02:00
Norbert Lange
1eecd462ae arch: add Atom CPUs as Silvermont Architecture target
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>
2018-01-01 13:05:16 +01:00
Yann E. MORIN
ae2ec0ed74 arch/arm: default to Cortex-A53 for AArch64
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>
2017-12-07 22:39:44 +01:00
Yann E. MORIN
6317a199ec arch/arm: add armv8.1a cores
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>
2017-11-24 23:30:43 +01:00
Yann E. MORIN
d632d9e5a9 arch/arm: add some non-cortex armv8a cores
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>
2017-11-24 23:30:36 +01:00
Yann E. MORIN
e9960da6ec arch/arm: add some armv8a cortex variants
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>
2017-11-24 23:18:08 +01:00
Yann E. MORIN
ffc9d60243 arch/arm: add cortex-A32
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>
2017-11-24 23:11:52 +01:00
Yann E. MORIN
003b1f3c74 arch/arm: armv8 is really armv8a
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>
2017-11-24 23:01:41 +01:00
Yann E. MORIN
a9f95de2c0 arch/arm: simplify hiding non 64-bit cores
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>
2017-11-24 23:01:03 +01:00
Yann E. MORIN
52d500aa35 arch/arm: re-order cores choice
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>
2017-11-24 23:00:37 +01:00
Yann E. MORIN
e25d704e10 arch/mips: inverse the mfpxx logic
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>
2017-11-24 22:45:48 +01:00
Yann E. MORIN
31b134a645 arch/mips: inverse the NaN logic
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>
2017-11-24 22:39:56 +01:00
Yann E. MORIN
d08ccb40f5 arch/arm: some variants need different gcc versions
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>
2017-11-24 22:19:14 +01:00
Yann E. MORIN
f82218fcbb arch/mips: some variants need different gcc versions
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>
2017-11-24 22:18:18 +01:00
Yann E. MORIN
6df07bc58e arch/bfin: needs gcc >= 6
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>
2017-11-24 22:17:03 +01:00
Yann E. MORIN
974d97bc26 arch: introduce minimal required gcc version
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>
2017-11-24 22:03:31 +01:00
Yann E. MORIN
29e046d6e3 arc/bfin: remove 60x cores
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>
2017-10-02 21:45:04 +02:00
Yann E. MORIN
d9f61fb4ce arch/bfin: internal backend not suitable for some cores
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>
2017-10-02 21:41:53 +02:00
Yann E. MORIN
5fbbf8a1d1 arch/mips: internal backend not suitable for some cores
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>
2017-10-02 21:41:42 +02:00
Yann E. MORIN
ba00283be8 arch/csky: internal backend not suitable
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>
2017-10-02 21:41:36 +02:00
Yann E. MORIN
31a726122f arch: add option to disable internal toolchain backend
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>
2017-10-02 21:41:29 +02:00
Yann E. MORIN
78c2a9f763 arch/arm: add big.LITTLE cpu variants
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>
2017-07-22 23:29:24 +02:00
Vicente Olivert Riera
087be35e22 arch/mips: add option for toolchains supporting -mfpxx
-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>
2017-07-21 22:49:18 +02:00
Vicente Olivert Riera
0af741187f arch/mips: add option for toolchains supporting -mnan
-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>
2017-07-21 22:48:51 +02:00
Vicente Olivert Riera
f2985125a4 arch/mips: improve help text of FP32 mode option
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-19 21:47:11 +02:00
Vicente Olivert Riera
cfc6f1e9b7 arch/mips: improve help text of NaN option
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-19 21:47:04 +02:00
Vicente Olivert Riera
9a0a0a976b arch/mips: add support for MIPS32 FP mode
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>
2017-07-16 16:45:22 +02:00
Vicente Olivert Riera
2d8f3fc430 arch/mips: add support for MIPS NaN
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>
2017-07-16 16:35:39 +02:00
Yann E. MORIN
9d06e91df8 arch/arm: fix -mcpu default values for AArch64
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>
2017-07-10 18:04:16 +02:00
Max Filippov
3a0a020a2e uboot: apply xtensa overlay
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>
2017-07-09 17:03:45 +02:00