summaryrefslogtreecommitdiffstats
path: root/arch
Commit message (Collapse)AuthorAgeFilesLines
* arch/mips: add (Marvell) Octeon III processorThomas De Schampheleire2019-02-041-0/+9
| | | | | | | | | | | | | 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>
* arch/mips: add (Marvell) Octeon II processorThomas De Schampheleire2019-02-041-0/+8
| | | | | | | | 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>
* arch/mips: introduce mips32r3 and mips64r3Thomas De Schampheleire2019-02-041-2/+18
| | | | | | | | | | | | | 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>
* arch: add support for RISC-V 32-bit (riscv32) architectureMark Corbin2019-01-062-4/+31
| | | | | | | | | | | | | | | | 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>
* arch/arm: add an armv8.3a coreYann E. MORIN2018-12-301-0/+12
| | | | | | | | | | | | | | 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>
* arch/arm: add armv8.2a cortex-based coresYann E. MORIN2018-12-301-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* arch/arm: restrict more armv8a cores to aarch64Yann E. MORIN2018-12-301-7/+1
| | | | | | | | | | | | | 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>
* arch/arm: drop useless conditional dependencies for 64-bit-only coresYann E. MORIN2018-12-301-9/+0
| | | | | | | | | 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>
* arch: drop BR2_GCC_TARGET_CPU_REVISION optionThomas Petazzoni2018-10-012-4/+0
| | | | | | | | | | | In commit 325bb37942f8d3826dab9dc6e88b25234e67a2cf, 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>
* arch: add support for RISC-V 64-bit (riscv64) architectureMark Corbin2018-09-233-0/+145
| | | | | | | | | | | | | | 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>
* arch/arch.mk: fix check-package warningsThomas Petazzoni2018-09-231-0/+6
| | | | | | | | | | | | | | | | "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>
* arch: allow GCC target options to be optionally overwrittenMark Corbin2018-09-231-0/+17
| | | | | | | | | | | | | 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>
* arch: drop now useless support for FDPICYann E. MORIN2018-07-011-14/+0
| | | | | | | | | | | | 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>
* arch: add BR2_ARCH_NEEDS_GCC_AT_LEAST_8Romain Naour2018-05-301-0/+4
| | | | | | | | | | | 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>
* arch/arm: cortex-m7 may have a FPv5 FPUYann E. MORIN2018-05-201-0/+1
| | | | | Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
* arch/arm: cortex-m4 may have an FPv4 FPUYann E. MORIN2018-05-201-0/+1
| | | | | Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
* arch/arm: add options for FPv5 FPUYann E. MORIN2018-05-201-0/+37
| | | | | | | | | | | | | | 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>
* arch/arm: add option for FPv4 FPUYann E. MORIN2018-05-201-0/+20
| | | | | | | | | | | | | 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>
* arch/arm: introduce generic FPU internal optionYann E. MORIN2018-05-201-4/+13
| | | | | | | | | | | | | | | | | | | 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>
* arch/arm: add cortex-m7 coreYann E. MORIN2018-05-201-0/+6
| | | | | | | 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>
* arch: drop BR2_BINFMT_FLAT_SEP_DATA supportThomas Petazzoni2018-04-151-12/+0
| | | | | | This was only used by Blackfin, so there's no good reason to keep it. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
* arch: remove Blackfin architectureThomas Petazzoni2018-04-152-118/+2
| | | | | | | | | | | | | | | | | 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>
* arc/xtensa: store the Xtensa overlay in the per-package DL_DIRYann E. MORIN2018-04-021-1/+1
| | | | | | 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>
* */Config.in*: remove consecutive empty linesRicardo Martincoski2018-04-011-1/+0
| | | | | Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
* arch/Config.in*: re-wrap help textRicardo Martincoski2018-04-013-52/+61
| | | | | | | ... 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>
* arch/Config.in*: fix attributes orderRicardo Martincoski2018-04-0111-33/+33
| | | | | | | ... 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>
* arch: add Atom CPUs as Silvermont Architecture targetNorbert Lange2018-01-011-0/+11
| | | | | | | | | 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>
* arch/arm: default to Cortex-A53 for AArch64Yann E. MORIN2017-12-071-0/+1
| | | | | | | | | | | | | | 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>
* arch/arm: add armv8.1a coresYann E. MORIN2017-11-241-0/+35
| | | | | | | | | | | | | | | 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>
* arch/arm: add some non-cortex armv8a coresYann E. MORIN2017-11-241-0/+77
| | | | | | | | | | | | 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>
* arch/arm: add some armv8a cortex variantsYann E. MORIN2017-11-241-0/+40
| | | | | | 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>
* arch/arm: add cortex-A32Yann E. MORIN2017-11-241-0/+11
| | | | | | | | | 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>
* arch/arm: armv8 is really armv8aYann E. MORIN2017-11-241-7/+7
| | | | | | | | | | | 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>
* arch/arm: simplify hiding non 64-bit coresYann E. MORIN2017-11-241-29/+2
| | | | | | | | | | 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>
* arch/arm: re-order cores choiceYann E. MORIN2017-11-241-47/+69
| | | | | | | | | | | | | | | | | | 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>
* arch/mips: inverse the mfpxx logicYann E. MORIN2017-11-241-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* arch/mips: inverse the NaN logicYann E. MORIN2017-11-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* arch/arm: some variants need different gcc versionsYann E. MORIN2017-11-241-0/+6
| | | | | | | | | | | | | | | | | | 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>
* arch/mips: some variants need different gcc versionsYann E. MORIN2017-11-241-0/+7
| | | | | | | | | | | | 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>
* arch/bfin: needs gcc >= 6Yann E. MORIN2017-11-241-0/+1
| | | | | | 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>
* arch: introduce minimal required gcc versionYann E. MORIN2017-11-241-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* arc/bfin: remove 60x coresYann E. MORIN2017-10-021-12/+0
| | | | | | | | | | | | | | | | | | | | | 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>
* arch/bfin: internal backend not suitable for some coresYann E. MORIN2017-10-021-0/+4
| | | | | | | | | | | | 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>
* arch/mips: internal backend not suitable for some coresYann E. MORIN2017-10-021-0/+2
| | | | | | | | | | | | 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>
* arch/csky: internal backend not suitableYann E. MORIN2017-10-021-0/+1
| | | | | | | | | | | | | 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>
* arch: add option to disable internal toolchain backendYann E. MORIN2017-10-021-0/+10
| | | | | | | | | | | | | | | | | | | | 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>
* arch/arm: add big.LITTLE cpu variantsYann E. MORIN2017-07-221-0/+38
| | | | | | | | | | | | | | | | | | | | | | | 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>
* arch/mips: add option for toolchains supporting -mfpxxVicente Olivert Riera2017-07-211-1/+2
| | | | | | | | | | | | | -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>
* arch/mips: add option for toolchains supporting -mnanVicente Olivert Riera2017-07-211-0/+1
| | | | | | | | | | -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>
* arch/mips: improve help text of FP32 mode optionVicente Olivert Riera2017-07-191-1/+4
| | | | | Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
OpenPOWER on IntegriCloud