aboutsummaryrefslogtreecommitdiff
path: root/arch
Commit message (Collapse)AuthorAgeFilesLines
* arch: drop now useless support for FDPICGravatar Yann 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_8Gravatar Romain 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 FPUGravatar Yann 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 FPUGravatar Yann 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 FPUGravatar Yann 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 FPUGravatar Yann 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 optionGravatar Yann 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 coreGravatar Yann 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 supportGravatar Thomas 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 architectureGravatar Thomas 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_DIRGravatar Yann 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 linesGravatar Ricardo 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 textGravatar Ricardo 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 orderGravatar Ricardo 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 targetGravatar Norbert 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 AArch64Gravatar Yann 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 coresGravatar Yann 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 coresGravatar Yann 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 variantsGravatar Yann 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-A32Gravatar Yann 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 armv8aGravatar Yann 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 coresGravatar Yann 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 choiceGravatar Yann 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 logicGravatar Yann 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 logicGravatar Yann 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 versionsGravatar Yann 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 versionsGravatar Yann 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 >= 6Gravatar Yann 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 versionGravatar Yann 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 coresGravatar Yann 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 coresGravatar Yann 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 coresGravatar Yann 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 suitableGravatar Yann 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 backendGravatar Yann 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 variantsGravatar Yann 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 -mfpxxGravatar Vicente 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 -mnanGravatar Vicente 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 optionGravatar Vicente 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 optionGravatar Vicente 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 modeGravatar Vicente 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 NaNGravatar Vicente 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 AArch64Gravatar Yann 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 overlayGravatar Max 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 overlayGravatar Max 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 URLGravatar Yann 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 compressedGravatar Yann 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>
* arch/xtensa: allow specifying path to tarball fileGravatar Yann E. MORIN2017-07-092-21/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | currently, specifying a custom Xtrensa core is done with two variables: - the core name - the directory containing the overlay tarball However, the core name only serves to construct the tarball name, and is not used whatsoever to configure any of the toolchain components (binutils, gcc or gdb), except through the files that are overlayed in their respective source trees. This has two main drawbacks: - the overlay file must be named after the core, - the tarball can not be compressed. Furthermore, it also makes it extremely complex to implement a download of that tarball. So, those two variables can be squeezed into a single variable, that is the complete path of the overlay tarball. Update the qemu-xtensa defconfig accordingly. Note: we do not add a legacy entry for BR2_XTENSA_CORE_NAME, since it was previously a blind option in the last release, and there's been no release since we removed BR2_XTENSA_CUSTOM_NAME. So, we just update the legacy comments for BR2_XTENSA_CUSTOM_NAME, since that's all the user could have seen in any of our releases so far. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* arch/xtensa: get rid of an intermediate blind kconfig optionGravatar Yann E. MORIN2017-07-091-10/+6
| | | | | | | | | | | | | | | | | It is not needed to have an intermediate blind option, we can just hide the prompt behind the same dependency as the non-blind symbol. Update our qemu-xtensa defconfig acordingly (note: it was using different values for both options, which is not possible; the blind option was just set to the non-blind one in the .config). Also remove an unneeded empty default for the BR2_XTENSA_OVERLAY_DIR string option (strings are empty by default). Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* arch, linux, package: remove whitespacesGravatar Bernd Kuhls2017-03-293-10/+10
| | | | | | | | | | | | Whitespaces were searched using the following regex: [ ]{1,}\t and then manually removed in most of the cases. For xserver_xorg-server.mk, tabs before backslashes were removed. Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* arch/xtensa: add macro to extract the overlayGravatar Yann E. MORIN2017-03-261-0/+13
| | | | | | | Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>