summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2017-01-25arch: add OpenRISC architecture supportWaldemar Brodkorb
Add support for OpenRISC. See here for more details about OpenRISC http://openrisc.io. All buildroot included upstream binutils versions are supported. Gcc support is not upstream, to be able to enable musl C library support later, we use the branch with musl support. At the moment it is possible to build a musl based toolchain, but bootup in Qemu fails. Gdb is only working to debug bare-metal code, there is no support for gdbserver/gdb on Linux, yet. [Peter: drop ?= for GCC_SOURCE] Signed-off-by: Waldemar Brodkorb <wbx@openadk.org> Tested-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-12-08arch/Config.in.arm: support thumb2 instructions for ARMv8 in 32bit modePeter Korsgaard
The ARMv8 cores all support thumb2 instructions when running in aarch32 mode. Signed-off-by: Peter Korsgaard <peter@korsgaard.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-12-08arch/Config.in.arm: only enable BR2_ARM_CPU_HAS_NEON for ARMv8 in 32bit modePeter Korsgaard
A number of packages use BR2_ARM_CPU_HAS_NEON to know if the target handles aarch32 neon instructions, which is only true for ARMv8 cores when they are running in 32bit mode. Notice: These cores do support neon-like instructions using a different encoding in 64bit mode (it is a required part of ARMv8, similar to the FPU). Signed-off-by: Peter Korsgaard <peter@korsgaard.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-12-08arch/Config.in.arm: only enable BR2_ARM_CPU_HAS_ARM for ARMv8 in 32bit modePeter Korsgaard
Fixes: http://autobuild.buildroot.net/results/5e6/5e67cc067a06f7364cde1a8393ea72608fe7fef1/ A number of packages use BR2_ARM_CPU_HAS_ARM to know if the target handles classic A32 instructions, which is only true for ARMv8 cores when they are running in 32bit mode. Signed-off-by: Peter Korsgaard <peter@korsgaard.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-12-05arch/Config.in.arm: add Cortex-A57 and Cortex-A72Thomas Petazzoni
Add two popular ARM64 cores to the list of supported cores: Cortex-A57 and Cortex-A72. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-12-05arch/Config.in.arm: Add Cortex-A53 CPUMatt Flax
Adds the Cortex-A53 CPU to the target architecture variant choice. This sets the toolchain to use Cortex-A53 as the target. The effect is that various Cortex-A53 tunings are enabled for the compilation of packages. Signed-off-by: Matt Flax <flatmax@flatmax.org> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-12-05arch/Config.in.arm: specify ABI for ARM64Thomas Petazzoni
There's currently only one widely supported ABI for ARM64, called lp64, so we define BR2_GCC_TARGET_ABI to the appropriate value. Note that there is another ABI for ARM64 being worked on, ilp32, but its support is not fully upstream in the kernel, so we're not adding support for it for the moment. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-12-05arch/Config.in.arm: add FPU related options for ARMv8 coresThomas Petazzoni
The ARMv8 cores have a mandatory FPU unit called FP-ARMv8, so we: - add a new hidden Config.in option for the availability of this unit (BR2_ARM_CPU_HAS_FP_ARMV8) - allow the selection of a possible choice in the "Floating point strategy", and add two new choices: BR2_ARM_FPU_FP_ARMV8 and BR2_ARM_FPU_NEON_FP_ARMV8. - specify the -mfpu values for BR2_ARM_FPU_FP_ARMV8 and BR2_ARM_FPU_NEON_FP_ARMV8 cases, when used on ARM 32 bits (-mfpu doesn't exist on ARM64, instead -mcpu modifiers are used, so they will be added on a per-core basis). Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> [yann.morin.1998@free.fr: drop the FP strategy dependency] Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-12-05arch/arm: drop legacy dependency for floating point strategyYann E. MORIN
The floating point strategy currently depends on EABI || EABIHF. The reason was that, wayback when we also supported OABI, we only exposed FP for EABI or EABIHF, and hide it for OABI, which did not support FP. It's been a while now that we do not support OABI, but the dependency stuck all along. Remove it as it is no longer needed, and is always true. However, the choice is empty for AArch64, as we still have no entry for their floating point strategy yet. 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>
2016-12-05arch/Config.in.arm: add BR2_ARM_CPU_ARMV8Thomas Petazzoni
In order to prepare the addition of ARM64 cores, add the blind BR2_ARM_CPU_ARMV8 option. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-12-05arch/Config.in.arm: prepare addition of 64 bits coresThomas Petazzoni
Until now the "Target Architecture Variant" choice was not visible on AArch64. In order to prepare the addition of the 64 bits core to this choice, this commit adds a "depends on !BR2_ARCH_IS_64" dependency to all currently supported cores (that are 32 bits only). Following this commit, the "Target Architecture Variant" choice appears on AArch64, but is for now empty. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-12-05arch: merge Config.in.aarch64 into Config.in.armThomas Petazzoni
The 64 bits ARM processors are capable of running 32 bits ARM code, and some platforms are indeed using this capability. Due to this, if we were to keep the separation between Config.in.aarch64 and Config.in.arm, we would have to duplicate the definition of all 64-bits capable ARM cores into both files. Instead of going down this route, let's take the same route as the x86 one: a single Config.in.x86 file, used for both x86 32 bits and x86 64 bits, with the appropriate logic to only show the relevant cores depending on which architecture is selected. In order to do this, we: - Make the "ARM instruction set" choice only visible on ARM 32 bits, since we currently don't support ARM vs. Thumb on AArch64. - Add the relevant values for the BR2_ARCH option. - Add the relevant values for the BR2_ENDIAN option. - Make the "aapcs-linux" BR2_GCC_TARGET_ABI value only used on ARM 32 bits, since this ABI doesn't mean anything on AArch64. - Make the BR2_GCC_TARGET_FPU option depends on ARM 32 bits, since there is no -mfpu option on AArch64. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-09MIPS: rename M6201 core to M6250Vicente Olivert Riera
m6201 is the -march option for GCC, but the real core name is M6250. Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-09MIPS: rename M5101 core to M5150Vicente Olivert Riera
m5101 is the -march option for GCC, but the real core name is M5150. Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-09MIPS: remove M5100 coreVicente Olivert Riera
This is a microcontroller class (MCU) core which is not suitable for running Linux. Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-09arch/Config.in.mips: add support for XBurst coresVicente Olivert Riera
The Ingenic XBurst is a MIPS32R2 microprocessor. It has a bug in the FPU that can generate incorrect results in certain cases. The problem shows up when you have several fused madd instructions in sequence with dependant operands. Using the -mno-fused-madd option prevents gcc from emitting these instructions. This patch adds changes to the toolchain wrapper to use that option. Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-10-19MIPS: add support for M6201 coresVicente Olivert Riera
-march=m6201 is not yet supported in GCC upstream, so disabling all versions when selecting this core. Note that M6201 implies a MIPS R6 CPU, and some GCC versions are already disabled for R6, so we don't need to disable those ones for M6201 as well. The external Codescape IMG GNU Linux Toolchain has support for this core. Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-10-15MIPS: add support for P6600 coresVicente Olivert Riera
-march=p6600 is not yet supported in GCC upstream, so disabling all versions when selecting this core. Note that P6600 implies a MIPS R6 CPU, and some GCC versions are already disabled for R6, so we don't need to disable those ones for P6600 as well. The external Codescape IMG GNU Linux Toolchain has support for this core. Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-10-15MIPS: add support for P5600 coresVicente Olivert Riera
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-10-15MIPS: add support for I6400 coresVicente Olivert Riera
-march=i6400 support starts from GCC-6, so disable previous versions when selecting this core. Note that I6400 implies a MIPS R6 CPU, and some GCC versions are already disabled for R6, so we don't need to disable those ones for I6400 as well. Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-10-15MIPS: add support for M5101 coresVicente Olivert Riera
-march=m5101 support starts from GCC-6, so disable previous versions when selecting this core. Note that M5101 implies a MIPS R5 CPU, and some GCC versions are already disabled for R5, so we don't need to disable those ones for M5101 as well. Also disable external toolchains that don't support this core. Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-10-15MIPS: add support for M5100 coresVicente Olivert Riera
-march=m5100 support starts from GCC-6, so disable previous versions when selecting this core. Note that M5100 implies a MIPS R5 CPU, and some GCC versions are already disabled for R5, so we don't need to disable those ones for M5100 as well. Also disable external toolchains that don't support this core. Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-10-15MIPS: add support for interAptiv coresVicente Olivert Riera
-march=interaptiv support starts from GCC-6, so disable previous versions when selecting this core. Also disable external toolchains that don't support this core. Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-10-15MIPS: add mips64r5 generic architecture variantVicente Olivert Riera
-march=mips64r5 support started from GCC-5, so disable previous versions when the CPU is R5. Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-10-15MIPS: add mips32r5 generic architecture variantVicente Olivert Riera
-march=mips32r5 support started from GCC-5, so disable previous versions when the CPU is R5. Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-10-15MIPS: state that the current architecture variants are genericVicente Olivert Riera
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-10-15MIPS: target architecture variants select the appropriate CPU ISAVicente Olivert Riera
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-10-15MIPS: add default CPU ISAsVicente Olivert Riera
Meant to be used by the target architecture variants. Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-09-08arch: remove support for sh64Gustavo Zacarias
It's been deprecated for quite some time now. Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-08-27bfin: change default to bf532, internal toolchain !bf6xxWaldemar Brodkorb
The default Blackfin processor in Buildroot isn't supported by gcc 6.1.0, so use bf532 as default. Disable any bf6xx processors for internal toolchain users. Signed-off-by: Waldemar Brodkorb <wbx@openadk.org> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-08-23m68k: disable BR2_BINFMT_FLAT_SEP_DATA for coldfireWaldemar Brodkorb
BR2_BINFMT_FLAT_SEP_DATA can be used to create XIP userland and works fine for m68k. Unfortunately a lot of basic packages as pcre are not compileable because of a CPU or hardware limitation. The reason for failing are very big functions used in the libraries or application code. Typical errors are: Fatal error: Tried to convert PC relative branch to absolute jump or error: value -yyyyy out of range Add kernel patch from 4ec5542679264bc06a0356ef92f06ad7a0abe06d to make BR2_BINFMT_FLAT_ONE compiled firmware work fine. Fixes: http://autobuild.buildroot.net/results/20b/20b1586757450d6aad8583ad7a787a7ca11acef1/ http://autobuild.buildroot.net/results/d31/d311955ada1ffcd7f69e82965c8fe33eabe488cd/ Signed-off-by: Waldemar Brodkorb <wbx@openadk.org> [Thomas: add comment in Config.in file about sep-data existing on m68k, but being disabled due to build issues with numerous packages.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-08-23m68k: flat one memory region works with small kernel patchWaldemar Brodkorb
Greg Ungerer fixed recently a bug in the Linux kernel, which allows to use one memory region again. Signed-off-by: Waldemar Brodkorb <wbx@openadk.org> [Thomas: cherry-picked from next to master, in order to be able to use BR2_BINFMT_FLAT_ONE by default on m68k, since BR2_BINFMT_FLAT_SEP_DATA causes too much problems.] Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-07-05arch: define dependencies for the binfmt flat formatsWaldemar Brodkorb
The situation looks like following for elf2flt and binfmt FLAT: * Only gcc for bfin/m68k implements -msep-data (BR2_BINFMT_FLAT_SEP_DATA) and -mid-shared-library (BR2_BINFMT_FLAT_SHARED), so the corresponding options are made only visible on those architectures. * When the default of BR2_BINFMT_FLAT_ONE is used on m68k, broken binaries are produced, which mainly end up in SIGILL, so do not use it for m68k. Signed-off-by: Waldemar Brodkorb <wbx@openadk.org> [Thomas: - also add the dependencies on m68k/bfin to BR2_BINFMT_FLAT_SHARED - rework commit log.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-06-07m68k: remove BR2_GCC_TARGET_ARCHWaldemar Brodkorb
Setting BR2_GCC_TARGET_ARCH is possible, but breaks external toolchain users. m68k/cf defconfigs just working without it. Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Waldemar Brodkorb <wbx@openadk.org> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-30toolchain: add coldfire supportWaldemar Brodkorb
Add support for m68k/coldfire. A gcc patch is required to avoid gcc ICE. Signed-off-by: Waldemar Brodkorb <wbx@openadk.org> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-21i386: properly define BR2_ARCH for all x86 subarchitecturesThomas Petazzoni
We were not defining BR2_ARCH for two of the x86 subarchitecture, which means the architecture part of the GNU_TARGET_NAME tuple was empty, leading to weird build failures. This commit fixes that by defining the appropriate values. Fixes bug #8861. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-18arch/x86: remove support for i386Thomas Petazzoni
The Linux kernel doesn't even support i386 anymore, there is no NPTL support for i386 and uClibc-ng only supports NPTL on x86, so there is essentially no usable thread implementation. Most likely glibc and musl also don't support i386 either. So it's time to remove the support for this architecture variant. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-03-20arch/arm: add Cortex-M4 entryThomas Petazzoni
This commit adds the option to select the Cortex-M4 ARM core, in the same family as Cortex-M3. This will be useful to enable the internal toolchain backend for this ARM core, and provide some defconfigs for Cortex-M4 platforms. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-03-20arch/arm: Cortex-M3 provides only Thumb-2Thomas Petazzoni
The Cortex-M cores only support Thumb-2, not Thumb. In fact, Thumb-2 is a superset of Thumb, and we could have a single option for both in Buildroot, since -mthumb on ARMv4/v5 means original Thumb, while -mthumb on ARMv7 means Thumb 2. However, for clarity, it makes sense to have two separate options. But in this case, Cortex-M3 should not advertise that it supports Thumb, as in fact selecting Thumb would generate Thumb-2 code. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-03-20arch/arm: introduce and use BR2_ARM_CPU_ARMV7MThomas Petazzoni
All ARM cores should select a BR2_ARM_CPU_* option. Currently, the cortex-m3 does not, which this commit fixes by introducing a BR2_ARM_CPU_ARMV7M option. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-03-20arch/m68k: re-enable the architectureWaldemar Brodkorb
This allows to build a m68k toolchain with uClibc. Signed-off-by: Waldemar Brodkorb <wbx@openadk.org> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-02-22arch/arm: add the cortex A17 variant supported by gcc 5.xEzequiel García
Add the Cortex A17 variant. This core is considered a replacement of the Cortex A12 and is supported by gcc 5 / binutils 2.25+ Suggested-by: Ross Green <greenfross@netscape.net> Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-02-06arch: remove BR2_ARCH_HAS_ATOMICS optionThomas Petazzoni
Now that BR2_ARCH_HAS_ATOMICS is no longer used anywhere, we can remove it from arch/Config.in*, as well as from the documentation. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2016-01-03Add ARM11 MPCore CPU target supportSergi Granell
gcc differentiates the mpcore-with-vfp from the mcpore-without-vfp CPUs. The former is named just 'mpcore', while the latter is named 'mpcorenovfp'. We only add one entry, 'mpcore' and let the user select whether or not to use the VFP. We then name the CPU according to the user's selection. Signed-off-by: Sergi Granell <xerpi.g.12@gmail.com> Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-12-27arch/arm: add help text to BR2_ARM_ENABLE_VFPThomas Petazzoni
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-12-27arch/arm: only expose VFP in FP strategy when the CPU *has* a VFP unitYann E. MORIN
There's no point in offering the user an option to select an FP strategy when the CPU does not actually have a VFP unit. 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>
2015-12-27arch/arm: only expose EABIhf when the CPU *has* a VFP unitYann E. MORIN
There's no point in offering the user an option to select EABIhf when the CPU does not really have a VFP unit. 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>
2015-12-27arch/arm: add option to enable an optional VFP unitYann E. MORIN
Currently, the VFP selection for ARM is a little bit muddy: - some CPUs definitely do not have a VFP or NEON, - some CPUs definitely do have a VFP or NEON, - some CPUs may have a VFP or NEON. However, we currently conflate the availability of the VFP/NEON with the possibility to use them. Even is the user chooses a floating point strategy with a 'lower' solution (i.e. VFPv2 when a VFPv3 exists, or not using NEON when the CPU has it), some packages are still using the CPU-defined HW availaibility rather thean the usr's selection. Furthermore, for CPU that may have a VFP/NEON, there is no way for the user to actually specify that the HW is indeed available; the user can only specify the floating point strategy. This means that some packages or some package versions, like nodejs for example, can not be properly selected on some CPU cores, like Cortex-A9 which only may have a VFP. Like we have an option to enable an optional NEON unit, add a similar option to enable an optional VFP unit. 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>
2015-12-27arch/arm: reorder NEON optionYann E. MORIN
Stating whether to use the NEON extensions when it is optional in the CPU really is completing the definition of the CPU we've just selected. Move the ENABLE_NEON option just after the choice of the CPU variant, and before any "software" option (ABI/VFP). This will make sense in a moment, when we introduce a similar option for enabling an optional VFP unit. 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>
2015-11-17arch: add tune options for powerpc e5500 and e6500Arnout Vandecappelle
These were forgotten when the subarches were added in cd88e49. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Alvaro Gamez <alvaro.gamez@hazent.com> Cc: Gustavo Zacarias <gustavo@zacarias.com.ar> Tested-by: Alvaro G. M <alvaro.gamez@hazent.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-16 23:04:49 +0000