summaryrefslogtreecommitdiffstats
path: root/arch
Commit message (Collapse)AuthorAgeFilesLines
* 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>
* arch/mips: improve help text of NaN optionVicente Olivert Riera2017-07-191-1/+3
| | | | | Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* arch/mips: add support for MIPS32 FP modeVicente Olivert Riera2017-07-162-0/+27
| | | | | | | | | | | | | | | | | | | | 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>
* arch/mips: add support for MIPS NaNVicente Olivert Riera2017-07-162-0/+38
| | | | | | | | | | | | | | | | | 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>
* arch/arm: fix -mcpu default values for AArch64Yann E. MORIN2017-07-101-9/+3
| | | | | | | | | | | 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>
* uboot: apply xtensa overlayMax Filippov2017-07-091-1/+2
| | | | | | | | | | 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>
* linux: apply xtensa overlayMax Filippov2017-07-091-1/+1
| | | | | | | | | | Xtensa core configuration must be added to linux 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>
* arch/xtensa: accept the overlay to be an URLYann E. MORIN2017-07-091-1/+9
| | | | | | | | | | | | | It can be interesting to get the overlay from a remote server, rather than expect it to be present locally. Since that file can be any URL, we can't know its hash, so we just exclude it. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> [Thomas: use DL_DIR instead of BR2_DL_DIR.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* arch/xtensa: accept the overlay to be compressedYann E. MORIN2017-07-091-1/+3
| | | | | | Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
OpenPOWER on IntegriCloud