summaryrefslogtreecommitdiffstats
path: root/arch
Commit message (Collapse)AuthorAgeFilesLines
* arch/x86: remove support for i386Thomas Petazzoni2016-04-181-5/+0
| | | | | | | | | | | | 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>
* arch/arm: add Cortex-M4 entryThomas Petazzoni2016-03-201-0/+5
| | | | | | | | | | | | 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>
* arch/arm: Cortex-M3 provides only Thumb-2Thomas Petazzoni2016-03-201-1/+0
| | | | | | | | | | | | | | | 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>
* arch/arm: introduce and use BR2_ARM_CPU_ARMV7MThomas Petazzoni2016-03-201-0/+4
| | | | | | | | | | | 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>
* arch/m68k: re-enable the architectureWaldemar Brodkorb2016-03-202-7/+14
| | | | | | | 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>
* arch/arm: add the cortex A17 variant supported by gcc 5.xEzequiel García2016-02-221-0/+9
| | | | | | | | | 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>
* arch: remove BR2_ARCH_HAS_ATOMICS optionThomas Petazzoni2016-02-0613-40/+0
| | | | | | | | 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>
* Add ARM11 MPCore CPU target supportSergi Granell2016-01-031-0/+9
| | | | | | | | | | | | | | | 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>
* arch/arm: add help text to BR2_ARM_ENABLE_VFPThomas Petazzoni2015-12-271-0/+4
| | | | Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* arch/arm: only expose VFP in FP strategy when the CPU *has* a VFP unitYann E. MORIN2015-12-271-6/+6
| | | | | | | | | 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>
* arch/arm: only expose EABIhf when the CPU *has* a VFP unitYann E. MORIN2015-12-271-1/+1
| | | | | | | | | 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>
* arch/arm: add option to enable an optional VFP unitYann E. MORIN2015-12-271-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* arch/arm: reorder NEON optionYann E. MORIN2015-12-271-9/+9
| | | | | | | | | | | | | | | 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>
* arch: add tune options for powerpc e5500 and e6500Arnout Vandecappelle2015-11-171-0/+2
| | | | | | | | | | 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>
* arch/arm: VFP and Thumb1 are not compatibleYann E. MORIN2015-11-031-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* arch/arm: use EABIhf by default with VFPBenoît Thébaudeau2015-10-251-0/+1
| | | | | | | | | | 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>
* arch/Config.in.x86: drop trailing dot (.) from x1000 URLPeter Korsgaard2015-10-201-1/+2
| | | | | | And add an empty line below for clarity. Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* arch/x86: add support for Intel X1000Ray Kinsella2015-10-201-0/+12
| | | | | | | | | | | | The Intel X1000 is the Pentium class microprocessor that ships with Galileo Gen 1/2. This patch adds changes to arch and toolchain-wrapper to omit the lock prefix for the X1000. [Thomas: tweak commit log and Config.in help text.] Signed-off-by: Ray Kinsella <ray.kinsella@intel.com> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* arch: add support for mips32r6 and mips64r6 variantsVicente Olivert Riera2015-10-121-2/+10
| | | | | | | | | | | | | | | - Add support for mips32r6 and mips64r6 target architecture variants - Disable unsupported gcc versions - Disable unsupported binutils versions - Disable unsupported external toolchains - Disable unsuported C libraries - Add a hook in order to make glibc compile for MIPS R6. [Thomas: slightly tweak the glibc hack explanation, to make it hopefully clearer.] Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain: add sparc64 architecture supportWaldemar Brodkorb2015-10-102-3/+21
| | | | | | | | | Introduce sparc64 architecture to buildroot. Signed-off-by: Waldemar Brodkorb <wbx@openadk.org> Acked-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Tested-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* arch/mips: remove some remaining mips1/2/3/4 bitsVicente Olivert Riera2015-10-091-6/+2
| | | | | | Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Reviewed-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* arch/arm: add missing arm1136j-s variantPeter Korsgaard2015-08-241-0/+6
| | | | | | Identical to arm1136jf-s, except that is doesn't have a vfp unit. Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* ARC: allow selection of MMU page sizeAlexey Brodkin2015-07-181-0/+38
| | | | | | | | | | | | | | | | | | Modern ARC cores (those sporting MMU of version 3 and 4) allow selection of different page sizes (4, 8 or 16 kB) during ASIC design creation. And it's important to build a toolchain with page size setting that matches hardware. Otherwise user-space applications will fail on execution due to unexpected data layout/alignment etc. [Thomas: slightly improve help text, fix indentation of help text.] Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Anton Kolesov <akolesov@synopsys.com> 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: aarch64 always has a MMUThomas Petazzoni2015-07-121-0/+1
| | | | | | | | Following the addition of AArch64 big endian, the AArch64 little endian option had lost its 'select BR2_ARCH_HAS_MMU_MANDATORY', so let's reintroduce it. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* aarch64: add big endian(aarch64_be) supportBamvor Jian Zhang2015-07-122-3/+13
| | | | | | | | | Add aarch64_be support. Note that CONFIG_CPU_BIG_ENDIAN should be defined in kernel config when building a big endian kernel. Signed-off-by: Zhang Jian(Bamvor) <bamvor.zhangjian@huawei.com> Acked-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* arm: update processor typesGuido Martínez2015-06-281-0/+5
| | | | | | | | | 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>
* arch: tidy up binary formats configGuido Martínez2015-06-091-6/+10
| | | | | | | | | | | | | | Instead of (black)listing architectures when deciding the binary format, we can enable the ELF format only when using an MMU and FLAT only when we're not. This mimics the logic in the Linux kernel for user binaries support. For FDPIC, we introduce a Kconfig option to enable its selection, and have blackfin select it. Signed-off-by: Guido Martínez <guido@vanguardiasur.com.ar> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* arch: tidy up mmu configGuido Martínez2015-06-093-0/+47
| | | | | | | | | | | | 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>
* arch/Config.in.xtensa: provide BR2_ENDIAN symbolMax Filippov2015-05-051-0/+17
| | | | | | | | | | | | | | Packages get hints from the buildroot at configure time, e.g. ac_cv_c_bigendian=yes/no. This particular hint is based on the value of BR2_ENDIAN and when it doesn't match actual toolchain endiannes the build may break. Provide BR2_ENDIAN for xtensa to fix this sort of build errors. Fixes: http://autobuild.buildroot.net/results/31115fe8d88f52d77ed0f2da769eb8896a1b34a2/ Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* sh64: deprecate support for this dead architectureWaldemar Brodkorb2015-04-251-0/+1
| | | | | | | | | | As discussed on the mailinglist, this should be deprecated before removal. [Thomas: don't add to Config.in.legacy.] Signed-off-by: Waldemar Brodkorb <wbx@openadk.org> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* arch: add core-avx2Steven Noonan2015-04-091-0/+14
| | | | | | Signed-off-by: Steven Noonan <steven@uplinklabs.net> Acked-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* arch: add corei7-avxSteven Noonan2015-04-091-0/+13
| | | | | | Signed-off-by: Steven Noonan <steven@uplinklabs.net> Acked-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* arch/sparc: doesn't have atomicsGustavo Zacarias2015-03-301-3/+0
| | | | | | | | Cores older than v9 don't seem to have atomics so remove it. Fixes a test build of pulseaudio for example. Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* arch: BINFMT_FLAT_SHARED is not really shared for buildroot purposesSonic Zhang2015-03-301-1/+6
| | | | | | | | | | | | | | | | | | | | Although BINFMT_FLAT_SHARED is indeed a shared library format, it does not support dynamic library loading with dlopen(). So for buildroot purposes, BR2_STATIC_LIBS shouldn't be selected. As it happens, the compiler options that are added for BINFMT_FLAT_SHARED also make the compiler ignore the -static option, so we can simply force BR2_STATIC_LIBS and things work out perfectly. Therefore, remove the select of BR2_BINFMT_SUPPORTS_SHARED from BINFMT_FLAT_SHARED, which in turn makes sure that BR2_STATIC_LIBS is selected. [Arnout: rewrite commit message, add explanatory comment] Signed-off-by: Sonic Zhang <sonic.zhang@analog.com> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* arch: add support for AMD steamrollerGustavo Zacarias2015-03-041-0/+11
| | | | | | | | Add support for AMD steamroller optimizations, available in gcc 4.8+ as bdver3. Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* arch/avr32: decommission for realYann E. MORIN2015-02-142-30/+0
| | | | | | | | Now that we have absolutely zero reference to the avr32 architecture, we can now really decommission the symbol. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* arch: kill avr32Yann E. MORIN2015-02-141-1/+1
| | | | | | | | | | | | avr32 was slated for removal in 2015.02. Make it so! This patch only definitively hides the symbol. When all references to it are eradicated (to come in followup patches), we'll eventually kill the symbol altogether. 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>
* arm: conditionally support regular ARM instructionsGuido Martínez2015-02-021-6/+22
| | | | | | | | | | | | | | | | | | | 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>
* Turn the static lib option into a choice with more optionsThomas Petazzoni2014-12-121-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit turns the single static option into a choice, which offers various possibilities: 1. Build and use static libraries only; 2. Build both shared and static libraries, but use shared libraries; 3. Build and use shared libraries only. On most platforms, (2) is currently the default, and kept as the default in this commit. Of course, on certain platforms (Blackfin, m68k), only option (1) will be available. In addition to the introduction of the Config.in options, this commit also: * Removes the 'select BR2_STATIC_LIBS' from 'BR2_BINFMT_FLAT', since with the use of a choice, we are guaranteed that BR2_STATIC_LIBS will be selected when the binary format is BR2_BINFMT_FLAT, since BR2_STATIC_LIBS will be the only possible solution in the choice. * Changes package/Makefile.in to use the proper --{enable,disable}-{shared,static} options for autotools packages. [Thomas: remove useless empty newline right after 'choice'. Noticed by Yann E. Morin.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
* arch: remove superfluous arch dependencies on BR2_BINFMT_FLAT_*Thomas Petazzoni2014-12-111-2/+0
| | | | | | | As noted by Yann E. Morin, those dependencies are unneeded, since FLAT can anyway only be used on m68k and Blackfin. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* arch: introduce BR2_BINFMT_SUPPORTS_SHAREDThomas Petazzoni2014-12-111-0/+7
| | | | | | | | | In preparation for the refactoring of the static/shared library support, we add a BR2_BINFMT_SUPPORTS_SHARED hidden option that binary formats supporting shared libraries should select. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
* arch: ensure BR2_BINFMT_ELF is really usedThomas Petazzoni2014-12-111-1/+1
| | | | | | | | | | | | | | | | | | | Currently, the binary format choice is only shown for the Blackfin and m68k architectures, since we assume that all other architectures are using the ELF binary format. However, due to this, the BR2_BINFMT_ELF symbol is in fact not set to 'y' for those architectures that use the ELF format. This will be causing problems for the refactoring of the static/shared library support, as we will need to know if the binary format supports shared libraries or not. Therefore, we simply make the choice visible on all architectures, even if it means that on many architectures no other choice than ELF will be available. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
* arch: FDPIC is not supported on m68kThomas Petazzoni2014-12-111-2/+3
| | | | | | | | | The current binfmt selection in arch/Config.in allows to select FDPIC on m68k, which is incorrect. This commit fixes that, and makes sure FDPIC is the default on Blackfin, while FLAT is the default on m68k. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
* Rename BR2_PREFER_STATIC_LIB to BR2_STATIC_LIBSThomas Petazzoni2014-12-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Since a while, the semantic of BR2_PREFER_STATIC_LIB has been changed from "prefer static libraries when possible" to "use only static libraries". The former semantic didn't make much sense, since the user had absolutely no control/idea of which package would use static libraries, and which packages would not. Therefore, for quite some time, we have been starting to enforce that BR2_PREFER_STATIC_LIB should really build everything with static libraries. As a consequence, this patch renames BR2_PREFER_STATIC_LIB to BR2_STATIC_LIBS, and adjust the Config.in option accordingly. This also helps preparing the addition of other options to select shared, shared+static or just static. Note that we have verified that this commit can be reproduced by simply doing a global rename of BR2_PREFER_STATIC_LIB to BR2_STATIC_LIBS plus adding BR2_PREFER_STATIC_LIB to Config.in.legacy. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
* arch/powerpc: add fsl e5500 and e6500 supportGustavo Zacarias2014-12-071-0/+7
| | | | | | | | | | | Add Freescale E5500 and E6500 core support. These can go in 32 or 64-bit mode. I'm not aware of these being able to boot in LE mode so filter that out until we get some feedback on it. Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Reviewed-by: "Matt Weber" <matthew.weber@rockwellcollins.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* arch/mips: remove deprecated mips1/2/3/4 supportGustavo Zacarias2014-12-011-12/+0
| | | | | | | | | | Remove the support for generating mips1/2/3/4 code since it has been deprecated for more than a year now. Also remove the unnecessary kludges in packages for it. Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Acked-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* arch/Config.in.x86: drop BR2_x86_genericPeter Korsgaard2014-11-071-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The fuzzy generic x86 variant doesn't make much sense in the context of Buildroot, and the recent change to use -march instead of -mtune broke it. From the GCC manual: https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/i386-and-x86-64-Options.html#i386-and-x86-64-Options: -mtune=cpu-type Tune to cpu-type everything applicable about the generated code, except for the ABI and the set of available instructions. While picking a specific cpu-type schedules things appropriately for that particular chip, the compiler does not generate any code that cannot run on the default machine type unless you use a -march=cpu-type option. For example, if GCC is configured for i686-pc-linux-gnu then -mtune=pentium4 generates code that is tuned for Pentium 4 but still runs on i686 machines. The choices for cpu-type are the same as for -march. In addition, -mtune supports 2 extra choices for cpu-type: ‘generic’ Produce code optimized for the most common IA32/AMD64/EM64T processors. If you know the CPU on which your code will run, then you should use the corresponding -mtune or -march option instead of -mtune=generic. But, if you do not know exactly what CPU users of your application will have, then you should use this option. As new processors are deployed in the marketplace, the behavior of this option will change. Therefore, if you upgrade to a newer version of GCC, code generation controlled by this option will change to reflect the processors that are most common at the time that version of GCC is released. There is no -march=generic option because -march indicates the instruction set the compiler can use, and there is no generic instruction set applicable to all processors. In contrast, -mtune indicates the processor (or, in this case, collection of processors) for which the code is optimized. Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* arch: remove the BR2_GCC_TARGET_TUNE optionThomas Petazzoni2014-11-071-3/+0
| | | | | | | The BR2_GCC_TARGET_TUNE option is now unused, so we can get rid of it. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* arch/m68k: get rid of BR2_GCC_TARGET_TUNEThomas Petazzoni2014-11-071-8/+0
| | | | | | | | | | On m68k, we are passing the exact same values of BR2_GCC_TARGET_ARCH and BR2_GCC_TARGET_TUNE, which is redundant. Therefore, this commit removes the usage of BR2_GCC_TARGET_TUNE on m68k. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* arch/powerpc: get rid of BR2_GCC_TARGET_TUNEThomas Petazzoni2014-11-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | According to the gcc documentation for PowerPC options: '-mtune=CPU_TYPE' Set the instruction scheduling parameters for machine type CPU_TYPE, but do not set the architecture type, register usage, or choice of mnemonics, as '-mcpu=CPU_TYPE' would. The same values for CPU_TYPE are used for '-mtune' as for '-mcpu'. If both are specified, the code generated will use the architecture, registers, and mnemonics set by '-mcpu', but the scheduling parameters set by '-mtune'. In the case of Buildroot where we only target a specific system, using -mtune therefore doesn't make much sense, and using -mcpu would be more appropriate. As a consequence, this patch makes PowerPC use BR2_GCC_TARGET_CPU instead of BR2_GCC_TARGET_TUNE. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
OpenPOWER on IntegriCloud