summaryrefslogtreecommitdiff
path: root/arch/Config.in.arm
AgeCommit message (Collapse)Author
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-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-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-03arch/arm: VFP and Thumb1 are not compatibleYann E. MORIN
gcc will refuse to build with both --with-mode=thumb and --with-fpu=vfp, with error messages during ./configure, like: checking for suffix of object files... configure: error: in `/home/ymor in/dev/buildroot/O/build/host-gcc-initial-4.9.3/build/arm-buildroot-lin ux-uclibcgnueabihf/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. And config.log informatively contains: sorry, unimplemented: Thumb-1 hard-float VFP ABI This is an error message that comes deep from gcc source files. If gcc says it does not support VFP with Thumb1, then let's disable that combination in our menuconfig. Prefer VFP over Thumb1, i.e. hide Thumb1 when we're not soft-float. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Gustavo Zacarias <gustavo@zacarias.com.ar> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-10-25arch/arm: use EABIhf by default with VFPBenoît Thébaudeau
Set EABIhf as the default target ABI for the ARM processors that have or may have a VFP unit, since this ABI is the most efficient in that case. Of course, EABI can still be selected manually if needed. [Peter: only default to EABIHF when we are sure the CPU has a VFP] Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-08-24arch/arm: add missing arm1136j-s variantPeter Korsgaard
Identical to arm1136jf-s, except that is doesn't have a vfp unit. Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-06-28arm: update processor typesGuido Martínez
Add the Cortex M3 variant. These microcontrollers don't support regular ARM instructions and don't have an MMU. Signed-off-by: Guido Martínez <guido@vanguardiasur.com.ar> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-06-09arch: tidy up mmu configGuido Martínez
Instead of blacklisting which architectures support MMUs (mandatorily or optionally), introduce two Kconfig options that are selected by each architecture in each case. This simplifies the logic in BR2_USE_MMU. Signed-off-by: Guido Martínez <guido@vanguardiasur.com.ar> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-02-02arm: conditionally support regular ARM instructionsGuido Martínez
Until now, all ARM processors supported the original ARM instructions. However, the Cortex-M variants don't support them, and support only Thumb/Thumb2 modes. So, make a Kconfig option for ARM support and use it. [Thomas: - Remove the dependency in the choice between ARM/Thumb/Thumb-2, because basically the choice is now always visible. - Replace the BR2_ARM_INSTRUCTIONS_ARM_CHOICE choice option directly by BR2_ARM_INSTRUCTIONS_ARM, instead of having this blind option defined separately. This means the choice is now always visible, even when only the ARM instruction set is supported.] Signed-off-by: Guido Martínez <guido@vanguardiasur.com.ar> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-11-07arch/arm: remove BR2_GCC_TARGET_ARCH definitions on ARMThomas Petazzoni
On ARM, we were defining both the CPU type and the architecture variant. However, depending on the version of gcc, a given combination of (CPU, architecture) may not be the same. Since the architecture variant is implied by the CPU type, given the former is not necessary, and we can simply specify the latter. >From the gcc documentation: This specifies the name of the target ARM processor. GCC uses this name to derive the name of the target ARM architecture (as if specified by -march) and the ARM processor type for which to tune for performance (as if specified by -mtune). Where this option is used in conjunction with -march or -mtune, those options take precedence over the appropriate part of this option. Note that we verified that for all BR2_GCC_TARGET_ARCH value that existed, a proper BR2_GCC_TARGET_CPU value is defined. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-11-07arch/arm: do not distinguish revisions of ARM1136JF-SThomas Petazzoni
In commit 88cf3bb91792c9c04586e14f293d89a6e0c13e1d ("arch/Config.in.arm: Use armv6k for arm1136jf-s rev1"), Benoît Thébaudeau added separate options for the revision 0 and revision 1 of the ARM1136JF-S processor, so that different -march values could be used (armv6j for revision 0, armv6k for revision 1). However, this is preventing the removal of the BR2_GCC_TARGET_ARCH option, which we need to do to give only the CPU type to gcc, and let it decide the architecture variant that matches. This is because this story of revision 0 vs. revision 1 is the only case where -mcpu doesn't fully define the CPU. Moreover, a quick test with gcc shows that -march=armv6j -mcpu=arm1136jf-s is accepted, while -march=armv6k -mcpu=arm1136jf-s makes gcc complain: " warning: switch -mcpu=arm1136jf-s conflicts with -march=armv6k switch". In addition, gcc 5 will apparently no longer allow to pass all of --with-arch, --with-cpu and --with-tune, so we will anyway have to rely only on one of them. As a consequence, this commit basically reverts 88cf3bb91792c9c04586e14f293d89a6e0c13e1d and provides only one option for ARM1136JF-S. If the two revisions are really different, then they should be supported in upstream gcc with different -mcpu values. Note that the removal of the two options should not break existing full .config, since the hidden option BR2_arm1136jf_s becomes again a visible option to select the CPU. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Benoît Thébaudeau <benoit.thebaudeau@advansee.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-10-25arch/arm: add blind options to know the ARM architectureThomas Petazzoni
In preparation to the removal of BR2_GCC_TARGET_ARCH for ARM, this commit introduces a number of blind options for each ARM architecture, so that packages/toolchains that had dependencies using BR2_GCC_TARGET_ARCH can continue to express their dependencies. It can also be used to simplify package dependencies that were using the individual ARM core options. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2014-09-18arch: remove BR2_arm10tThomas Petazzoni
The BR2_arm10t option is not correct as it references an ARM family, while other options indicate a specific ARM core. The ARM cores in ARM10 family are ARM1020E, ARM1022E and ARM1026EJ-S according to Wikipedia. However, those are clearly very rare, and Wikipedia only indicates two Conexant ADSL-related SoC as being part of this family of ARM cores. Therefore, this commit removes this ARM family. [Peter: remove nettle.mk reference as pointed out by Yann] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-09-18arch: remove BR2_arm920 referenceThomas Petazzoni
The BR2_GCC_TARGET_CPU defines a value for the BR2_arm920 case, but this option does not exist. Therefore, this commit removes one line of dead code. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-08-18arch/arm: always has atomic opsYann E. MORIN
armv6 and above all have one sort of atomic ops or another. For armv5 and below, they are emulated, either as a kernel trap, a kernel VDSO, or compiler intrinsics. Aarch64 is just armv8, so make it a single commit. ;-) Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Anton Kolesov <Anton.Kolesov@synopsys.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-05-08arch/arm: drop ARM(7TDMI/720T/740T) supportGustavo Zacarias
The toolchain currently doesn't build for nommu ARM and is in need of serious work. Problem is there are no emulation targets and real ARM(7TDMI/720T/740T) hardware that's capable of running linux (enough memory, having a memory controller...) is VERY rare and uses very old versions to make it usable. The ARM nommu focus should go into Cortex M series processors that are obtainable at reasonable cost on modern hardware that has external memory controllers. Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-04-24arm: update processor typesGustavo Zacarias
Update the arm processor types: add the cortex A12 variant supported by gcc 4.9.x Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2013-12-26arch: pass cpu option instead of tune option on ARMThomas Petazzoni
Currently, the ARM Config.in logic specifies values for --with-arch/-march and --with-tune/-mtune, but not for --with-cpu/-mcpu. However, this causes problems on ARMv4, because specifying --with-arch=armv4t isn't enough to make gcc generate ARMv4 code: one should also pass --with-cpu=<some ARMv4 CPU>. Moreover, since Buildroot is generally designed to generate code specifically for the configured target, it makes sense to give our own --with-cpu/-mcpu value instead of relying on the default value used by gcc, and only do small optimizations with -mtune. Reported-by: Adam Hussein <kryme76@yahoo.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2013-07-18arch/arm: add support for thumb(1) modeGustavo Zacarias
[Peter: also adjust BR2_GCC_TARGET_MODE] Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-07-18arch/arm: update VFPv2 comment to mention ARMv5Thomas Petazzoni
Commit 6b3a0417c4 ('arch/arm: arm926 may have VFP') forgot to update the help text of the VFPv2 option to mention ARMv5. This commit fixes that. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-07-17arch/arm: arm926 may have VFPGustavo Zacarias
The VFP9-S FPU (VFPv2) is optional for ARM926EJ-S, see: http://www.arm.com/products/processors/classic/arm9/arm926.php?tab=Specifications+ Real silicon: http://www.nxp.com/documents/data_sheet/LPC3180.pdf Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-07-16arch/arm: add support for Thumb2Thomas Petazzoni
Until now, we were using the default ARM instruction set, as used by the toolchain: the 32 bits ARM instruction set for the internal backend, and for external toolchain, whatever default was chosen when the toolchain was generated. This commit adds support for the Thumb2 instruction set. To do so, it: * provides a menuconfig choice between ARM and Thumb2. The choice is only shown when Thumb2 is supported, i.e on ARMv7-A CPUs. * passes the --with-mode={arm,thumb} option when building gcc in the internal backend. This tells the compiler which type of instructions it should generate. * passes the m{arm,thumb} option in the external toolchain wrapper. ARM and Thumb2 code can freely be mixed together, so the fact that the C library has been built either ARM or Thumb2 and that the rest of the code is built Thumb2 or ARM is not a problem. [Peter: fix empty BR2_GCC_TARGET_MODE check] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-07-16arch: improve ARM floating point support and add support for EABIhfThomas Petazzoni
This commit introduces the support for the EABIhf ABI, next to the existing support we have for EABI and OABI (even though OABI support is deprecated). EABIhf allows to improve performance of floating point workload by using floating point registers to transfer floating point arguments when calling functions, instead of using integer registers to do, as is done in the 'softfp' floating point model of EABI. In addition to this, this commit introduces a list of options for the floating point support: * Software floating point * VFP * VFPv3 * VFPv3-D16 * VFPv4 * VFPv4-D16 and it introduces some logic to make sure the options are only visible when it makes sense, depending on the ARM core being selected. This is however made complicated by the fact that certain VFP capabilities are mandatory on some cores, but optional on some other cores. The kconfig logic tries to achieve the following goals: * Hide options that are definitely not possible. * Use safe default values (i.e for Cortex-A5 and A7, the presence of the VFPv4 unit is optional, so we default on software floating point on these cores).. * Show the available possibilities, even if some of them are not necessarily working on a particular core (again, for the Cortex-A5 and A7 cores, there is no way of knowing whether the particular variant used by the user has VFPv4 or not, so we select software floating point by default, but still show VFP/VFPv3/VFPv4 options). It is worth noting that this commit doesn't add support for all possible -mfpu= values on ARM. We haven't added support for fpa, fpe2, fpe3, maverick (those four are only used on very old ARM cores), for vfpv3-fp16, vfpv3-d16-fp16, vfpv3xd, vfpv3xd-fp16, neon-fp16, vfpv4-sp-d16. They can be added quite easily if needed thanks to the new organization of the Config.in options. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-07-16arch: Refactor BR2_SOFT_FLOAT into per-architecture optionsThomas Petazzoni
As we are going to introduced a more advanced support of floating point options for the ARM architecture, we need to adjust how the soft-float option is handled. We replace the current hidden option BR2_PREFER_SOFT_FLOAT option and the visible BR2_SOFT_FLOAT option by: * A global hidden BR2_SOFT_FLOAT option, defined in arch/Config.in, that tells whether the architecture-specific code is using software emulated floating point. This hidden option can be used throughout Buildroot to determine whether soft float is used or not. * Per-architecture visible BR2_<arch>_SOFT_FLOAT options, for the architecture for which it makes sense, which allows users to select soft float emulation when needed. This change will allow each architecture to have a different way of presenting its floating point capabilities. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-07-14arch/arm: remove setting gcc's apcs-gnu ABI (aka OABI)Yann E. MORIN
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> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-07-14arch/arm: remove OABI optionYann E. MORIN
OABI is more than legacy, it's dead. New developments should go with EABI, since it so much better. >From the Debian EABI page [0] : - floating point performance, with or without an FPU is very much faster - mixing soft and hardfloat code is possible - structure packing is not as painful as it used to be - a more efficient syscall convention - more compatibility with various tools [0] http://wiki.debian.org/ArmEabiPort [Thomas: keep the ABI choice, as we are going to introduce EABIhf later]. 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> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-06-16arm: update processor typesKelvin Cheung
Update arm architecture variant: add the cortex A7. Signed-off-by: Kelvin Cheung <keguang.zhang@gmail.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-04-29toolchain/arm: add support for Marvell PJ4Gustavo Zacarias
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-04-11toolchain/arm: drop generic and old, add fa526/626, unify strongarmGustavo Zacarias
* Add Faraday FA526/626 as suggested on bug #1291 Note however that these cores are v4 and NOT v4t. * Make the sa110 & sa1110 cores -> strongarm since they're the same. * Drop all of the ARM variants lower than v4 including generic, there's no point in supporting obsolete targets. * Fix uClibc USE_BX logic, it was always on, this would break the new FA526/626 support and broke StrongARM since it's a v4 core. Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-02-07arch/arm: fix-up the ARM Kconfig warningYann E. MORIN
Kconfig does not accepts that a symbol that is part of a choice be affected a default value. Fix this by introducing a dummy EABI symbol, and make the real EABI symbol a prompt-less option that depends on !OABI. [Peter: drop arm dependency, rename to EABI_CHOICE] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Peter Korsgaard <jacmet@uclibc.org> Cc: Arnout Vandecappelle <arnout@mind.be> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-02-07arm: deprecate OABIArnout Vandecappelle (Essensium/Mind)
The BR2_ARM_EABI config symbol is still kept in order to minimize the impact. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-11 18:09:15 +0000