summaryrefslogtreecommitdiffstats
path: root/arch
Commit message (Collapse)AuthorAgeFilesLines
...
* 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>
* arch/sparc: get rid of BR2_GCC_TARGET_TUNEThomas Petazzoni2014-11-071-3/+1
| | | | | | | | | | | | | On SPARC, BR2_GCC_TARGET_TUNE was only used for one specific case, the BR2_sparc_v8. There is actually no reason to not use BR2_GCC_TARGET_CPU instead for this, as all values supported for -mtune are also supported for -mcpu. Therefore, the only BR2_GCC_TARGET_TUNE case is moved as a BR2_GCC_TARGET_CPU case. [Peter: fixup merge conflict after 'sparc: Add leon3 cpu type and remove sparc{s,h}fleon{,v8}] 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/x86: get rid of BR2_GCC_TARGET_TUNEThomas Petazzoni2014-11-071-31/+1
| | | | | | | | | | | | | | According to the gcc documentation, -march implies -mtune on x86, so defining both BR2_GCC_TARGET_ARCH and BR2_GCC_TARGET_TUNE is redundant. Therefore, this commit removes the definition of BR2_GCC_TARGET_TUNE on x86. However, while doing so, it adds one new case for BR2_GCC_TARGET_ARCH: using -march=generic when BR2_x86_generic is selected. 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/arm: remove BR2_GCC_TARGET_ARCH definitions on ARMThomas Petazzoni2014-11-071-19/+0
| | | | | | | | | | | | | | | | | | | | | | | 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>
* arch/arm: do not distinguish revisions of ARM1136JF-SThomas Petazzoni2014-11-071-13/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* arc: add support of ARC HS38 coreAlexey Brodkin2014-11-021-1/+5
| | | | | | | | | | | | | | | | | | | | Synopsys has recently announced its new ARC HS38 core that is capable of running Linux - http://www.synopsys.com/dw/ipdir.php?ds=arc-hs38-processor ARC HS38 is based on ARCv2 ISA and requires special settings of gcc and libc. Also in case of HS38 atomic extensions (LLOCK/SCOND instructions) are built-in by default, so enabling atomic extensions in Buildroot as well. This commit adds support of the core in buildroot. [Peter: string type, so must be in quotes as noted by Yann] Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Anton Kolesov <anton.kolesov@synopsys.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* arc: add explicit selection of CPU templates ARC 750D and ARC770DAlexey Brodkin2014-11-021-2/+19
| | | | | | | | | | | | | | | | This separation allows to specify unique options and features for each CPU. For example ARC 770D has LLOCK/SCOND instructions built-in by default. Also this new scheme simplifies selection of proper configuration for users - preconfigured options now match templates for ARC CPUs. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Anton Kolesov <akolesov@synopsys.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* arch: sparc: Add leon3 cpu type and remove sparc{s,h}fleon{,v8}Andreas Larsson2014-10-301-12/+3
| | | | | | | | | | | There is support for -mcpu=leon3 from gcc 4.8.3. Use this for LEON systems instead of the non-mainline targets sparcsfleon, sparchfleon, sparcsfleonv8, and sparchfleonv8. [Thomas: add Config.in.legacy handling for the removed options.] Signed-off-by: Andreas Larsson <andreas@gaisler.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* arch/arm: add blind options to know the ARM architectureThomas Petazzoni2014-10-251-0/+30
| | | | | | | | | | | | 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>
* arch: remove BR2_arm10tThomas Petazzoni2014-09-181-4/+0
| | | | | | | | | | | | | 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>
* arch: remove BR2_arm920 referenceThomas Petazzoni2014-09-181-1/+0
| | | | | | | | | | 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>
* arch/arc: fix atomics selectionYann E. MORIN2014-09-111-1/+3
| | | | | | | | | | | | | | | | | | Due to a kconfig limitation, we can't select a no-prompt symbol that gets its dependencies by being conditionally re-defined in one or more if-blocks, like we currently do for BR2_ARCH_HAS_ATOMICS. As a workaround to this issue, we just redefine that symbol in the arc if-block, like we do for all other architectures, except that in the arc case, the default value is conditional. Reported-by: Anton Kolesov <Anton.Kolesov@synopsys.com> [yann.morin.1998@free.fr: indepently re-done a patch similar to the one Thomas made on his own] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* arch: remove no-longer default on atomics optionYann E. MORIN2014-08-181-1/+0
| | | | | | | | | | Now that all architectures explicitly select this option when it makes sense, there is no need to have a default value. 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>
* arch/xtensa: always has atomic opsYann E. MORIN2014-08-181-0/+3
| | | | | | | 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>
* arch/x86: all x86 but i386 has atomics operationsYann E. MORIN2014-08-181-0/+3
| | | | | | | 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>
* arch/sparc: always has atomic opsYann E. MORIN2014-08-181-0/+3
| | | | | | | 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>
* arch/sh: always has atomic opsYann E. MORIN2014-08-181-0/+3
| | | | | | | 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>
* arch/powerpc: always has atomic opsYann E. MORIN2014-08-181-0/+3
| | | | | | | 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>
* arch/nios2: always has atomic opsYann E. MORIN2014-08-181-0/+3
| | | | | | | 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>
* arch/mips: always has atomic opsYann E. MORIN2014-08-181-0/+3
| | | | | | | 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>
* arch/microblaze: always has atomic opsYann E. MORIN2014-08-181-0/+3
| | | | | | | 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>
* arch/m68k: always has atomic opsYann E. MORIN2014-08-181-0/+3
| | | | | | | 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>
* arch/bfin: always has atomic opsYann E. MORIN2014-08-181-0/+3
| | | | | | | 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>
* arch/avr32: always has atomic opsYann E. MORIN2014-08-181-0/+3
| | | | | | | 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>
* arch/arm: always has atomic opsYann E. MORIN2014-08-182-0/+6
| | | | | | | | | | | | | 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>
* toolchain: drop the now-unused old BR2_TOOLCHAIN_HAS_ATOMIC_INTRINSICSYann E. MORIN2014-08-181-1/+0
| | | | | | | | | | It's now been replaced with BR2_ARCH_HAS_ATOMICS, annd all packages have been changed to use that instead. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Anton Kolesov <Anton.Kolesov@synopsys.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* arch: add an option to specify if the arch has atomic opsYann E. MORIN2014-08-182-1/+7
| | | | | | | | | | | | | | | | The fact that atomic operations are available is not really a specificity of the toolchain, but rather of the architecture. So, add a new option that architectures that have atomic operations can select. This in turn selects the current toolchain atomic option, until all packages have been converted, at which point the old toolchain option can be removed. Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Anton Kolesov <Anton.Kolesov@synopsys.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain: Add config option for atomic intrinsicsAnton Kolesov2014-08-031-0/+5
| | | | | | | | | | | | | | GCC has several builtin functions that implement atomic operations. Those functions are architecture specific and may not be implemented by the specific toolchain. In case of GCC for ARC those functions rely on LLOCK/SCOND instructions which are optional in ARC CPU's. If ARC CPU doesn't support those instructions but software tries to use them, then application will be aborted with Illegal instruction exception. To avoid confusion user should first specify that their CPU supports atomic extension, which will allow selection of packages that use builtin atomic functions. Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* arch: avr32 should only get removed for the 2015.02 releasePeter Korsgaard2014-07-101-1/+1
| | | | | | As discussed on the list. Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* arch: deprecate the AVR32 architectureThomas Petazzoni2014-07-101-0/+6
| | | | | | | | | | | | | | | | | | | The AVR32 architecture from Atmel is obsolete since a long time, not supported upstream in most of the toolchain components (requires a special version of gcc, an old version of uClibc, etc.). Until February, Simon Dawson was making an excellent job at maintaining AVR32 in Buildroot, and fixing all the issues caused by this architecture. However, Simon focus has changed, and despite his call for a new maintainer for AVR32 in Buildroot, nobody stepped up. The issue of maintaining AVR32 is becoming worse and worse, so this patch proposes to deprecate it for 2014.08, but keeping the support around, to remove it for sure in 2014.11. Cc: Simon Dawson <spdawson@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* powerpc: add powerpc64 and powerpc64le supportCody P Schafer2014-05-262-2/+14
| | | | | | | | | | This enables powerpc64 and powerpc64le. Currently, le needs at least glibc 2.19 and gcc 4.9.0. For gdb, 7.7.1 works (added in an earlier patch). [Peter: also disallow gcc 4.8 for ppc64le] Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* powerpc: remove unneeded dependenciesCody P Schafer2014-05-261-2/+0
| | | | | Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* powerpc: add power{4,5,6,7,8} cpusCody P Schafer2014-05-261-0/+18
| | | | | Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* powerpc: mark 32-bit only powerpc cpus to prep for adding powerpc64 supportCody P Schafer2014-05-261-0/+29
| | | | | Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* powerpc: add BR2_POWERPC_CPU_HAS_ALTIVEC to replace adhoc deps/checksCody P Schafer2014-05-261-0/+6
| | | | | Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* powerpc: add BR2_POWERPC_CPU_HAS_SPE to replace adhoc deps/checksCody P Schafer2014-05-261-3/+8
| | | | | Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* Add support for powerpc64leJeff Bailey2014-05-252-4/+14
| | | | | | | | | | | This patch adds support for powerpc64le-linux-gnu. This includes needed patches to fakeroot and gmp. gmp patch is from upstream HG tree. fakeroot patch is from Ubuntu written by Adam Conrad. Signed-off-by: Jeff Bailey <jeffbailey@google.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* arch/arm: drop ARM(7TDMI/720T/740T) supportGustavo Zacarias2014-05-081-11/+0
| | | | | | | | | | | | | | | | 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>
* arch: add support for "corei7" Intel CPU optimisationsBernd Kuhls2014-05-031-0/+12
| | | | | | | | gcc support was added in version 4.6: http://gcc.gnu.org/gcc-4.6/changes.html Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* arm: update processor typesGustavo Zacarias2014-04-241-0/+7
| | | | | | | | 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>
OpenPOWER on IntegriCloud