Commit Graph

98 Commits

Author SHA1 Message Date
Gustavo Zacarias
cd88e49cd7 arch/powerpc: add fsl e5500 and e6500 support
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>
2014-12-07 23:46:41 +01:00
Gustavo Zacarias
dd45fe0efb arch/mips: remove deprecated mips1/2/3/4 support
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>
2014-12-01 20:06:32 +01:00
Peter Korsgaard
80e4060908 arch/Config.in.x86: drop BR2_x86_generic
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>
2014-11-07 19:51:06 +01:00
Thomas Petazzoni
bc48f2312e arch: remove the BR2_GCC_TARGET_TUNE option
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>
2014-11-07 00:16:47 +01:00
Thomas Petazzoni
db5e6d6c14 arch/m68k: get rid of BR2_GCC_TARGET_TUNE
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>
2014-11-07 00:14:13 +01:00
Thomas Petazzoni
75418c4cf6 arch/powerpc: get rid of BR2_GCC_TARGET_TUNE
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>
2014-11-07 00:13:49 +01:00
Thomas Petazzoni
a5023c5204 arch/sparc: get rid of BR2_GCC_TARGET_TUNE
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>
2014-11-07 00:13:08 +01:00
Thomas Petazzoni
6bec1d5191 arch/x86: get rid of BR2_GCC_TARGET_TUNE
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>
2014-11-07 00:09:21 +01:00
Thomas Petazzoni
fd828fd98f arch/arm: remove BR2_GCC_TARGET_ARCH definitions on ARM
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-07 00:07:34 +01:00
Thomas Petazzoni
24dfbe71e0 arch/arm: do not distinguish revisions of ARM1136JF-S
In commit 88cf3bb917
("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
88cf3bb917 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-11-07 00:05:11 +01:00
Alexey Brodkin
f787b51af5 arc: add support of ARC HS38 core
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>
2014-11-02 22:25:27 +01:00
Alexey Brodkin
11f078c22f arc: add explicit selection of CPU templates ARC 750D and ARC770D
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>
2014-11-02 22:20:22 +01:00
Andreas Larsson
43b78e7285 arch: sparc: Add leon3 cpu type and remove sparc{s,h}fleon{,v8}
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>
2014-10-30 21:28:39 +01:00
Thomas Petazzoni
ece7daaa10 arch/arm: add blind options to know the ARM architecture
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-10-25 12:35:00 +02:00
Thomas Petazzoni
d60489a6e5 arch: remove BR2_arm10t
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-18 22:09:05 +02:00
Thomas Petazzoni
ad0e217bb2 arch: remove BR2_arm920 reference
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-09-18 22:05:11 +02:00
Yann E. MORIN
21c8f1e947 arch/arc: fix atomics selection
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>
2014-09-11 22:53:08 +02:00
Yann E. MORIN
a690fea1ac arch: remove no-longer default on atomics option
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>
2014-08-18 11:03:36 +02:00
Yann E. MORIN
6a1f8b712d arch/xtensa: always has atomic ops
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-08-18 11:03:28 +02:00
Yann E. MORIN
4f07578a86 arch/x86: all x86 but i386 has atomics operations
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-08-18 11:03:16 +02:00
Yann E. MORIN
da86e94f80 arch/sparc: always has atomic ops
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-08-18 11:03:09 +02:00
Yann E. MORIN
5d22b6e06c arch/sh: always has atomic ops
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-08-18 11:03:02 +02:00
Yann E. MORIN
84e8a337d5 arch/powerpc: always has atomic ops
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-08-18 11:02:57 +02:00
Yann E. MORIN
700080c494 arch/nios2: always has atomic ops
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-08-18 11:02:51 +02:00
Yann E. MORIN
4e99ab9bd7 arch/mips: always has atomic ops
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-08-18 11:02:41 +02:00
Yann E. MORIN
85da209efb arch/microblaze: always has atomic ops
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-08-18 11:02:31 +02:00
Yann E. MORIN
0d79bc13ec arch/m68k: always has atomic ops
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-08-18 11:01:40 +02:00
Yann E. MORIN
5b98309f59 arch/bfin: always has atomic ops
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-08-18 11:01:31 +02:00
Yann E. MORIN
116f63f4d7 arch/avr32: always has atomic ops
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-08-18 11:01:22 +02:00
Yann E. MORIN
b8a8263858 arch/arm: always has atomic ops
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-08-18 11:00:51 +02:00
Yann E. MORIN
6172ceb3cf toolchain: drop the now-unused old BR2_TOOLCHAIN_HAS_ATOMIC_INTRINSICS
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>
2014-08-18 10:57:55 +02:00
Yann E. MORIN
1b5f0fc8df arch: add an option to specify if the arch has atomic ops
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>
2014-08-18 10:56:35 +02:00
Anton Kolesov
cbffd50561 toolchain: Add config option for atomic intrinsics
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>
2014-08-03 11:20:47 +02:00
Peter Korsgaard
c2444e94ce arch: avr32 should only get removed for the 2015.02 release
As discussed on the list.

Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-07-10 22:05:55 +02:00
Thomas Petazzoni
01efcf84fe arch: deprecate the AVR32 architecture
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>
2014-07-10 16:49:36 +02:00
Cody P Schafer
7e674dfa4f powerpc: add powerpc64 and powerpc64le support
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>
2014-05-26 21:48:33 +02:00
Cody P Schafer
32a471824b powerpc: remove unneeded dependencies
Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-05-26 21:22:09 +02:00
Cody P Schafer
71badded4b powerpc: add power{4,5,6,7,8} cpus
Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-05-26 21:18:10 +02:00
Cody P Schafer
32025e99dd powerpc: mark 32-bit only powerpc cpus to prep for adding powerpc64 support
Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-05-26 21:17:26 +02:00
Cody P Schafer
40e58dab0c powerpc: add BR2_POWERPC_CPU_HAS_ALTIVEC to replace adhoc deps/checks
Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-05-26 21:14:08 +02:00
Cody P Schafer
b4c824562b powerpc: add BR2_POWERPC_CPU_HAS_SPE to replace adhoc deps/checks
Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-05-26 14:28:59 +02:00
Jeff Bailey
a426a91973 Add support for powerpc64le
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>
2014-05-25 23:24:09 +02:00
Gustavo Zacarias
befab216a2 arch/arm: drop ARM(7TDMI/720T/740T) support
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-05-08 16:53:49 +02:00
Bernd Kuhls
affb6a3853 arch: add support for "corei7" Intel CPU optimisations
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>
2014-05-03 03:39:29 +02:00
Gustavo Zacarias
a8b3db9d3e arm: update processor types
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>
2014-04-24 13:45:32 +02:00
Vicente Olivert Riera
574fa145d8 Disable o32 ABI for MIPS64 architectures
Building o32 ELF files for MIPS64 is an exotic configuration that nobody
should be using. If o32 is required, then is better if it's built for
MIPS 32-bit cores so only 32-bit instructions will be used leading to a
more efficient o32 usage.

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-03-28 12:51:46 +01:00
Jan Drazil
c220581c78 Fix microblize little endian toolchain
Buildroot toolchain creates big endian binaries instead of little endian
ones for microblaze architecture. The reason is wrong BR2_ARCH string.
KERNEL_ARCH must contain microblaze in both cases.

Signed-off-by: Jan Drazil <xdrazi00@stud.fit.vutbr.cz>
Signed-off-by: Jan Viktorin <xvikto03@stud.fit.vutbr.cz>
Acked-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Tested-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-03-20 16:46:29 +01:00
Thomas Petazzoni
e543f5a104 arch: remove sh2, sh3 and sh3eb support
This patch removes the sh2, sh3 and sh3eb support, because the user
base is inexistent, and the Linux support for these architectures is
poor. The sh2a support is preserved, because at least one user
expressed interest in this architecture, and is actually using it:

  http://lists.busybox.net/pipermail/buildroot/2013-April/070399.html

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-02-05 12:05:58 +01:00
Thomas Petazzoni
dd712eb31c arch: remove incorrect condition for endian definition on SuperH
Probably due to some copy/paste mistake, Config.in.sh was defining
BR2_ENDIAN to "LITTLE" when the architecture is BR2_x86_64. Due to the
fact that Config.in.sh is never included when we are building for
x86_64, this is a no-op, but is certainly good to clean up.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-02-04 15:15:11 +01:00
Adrien Béraud
485f07dd4c arch: use BR2_X86_CPU_HAS_SSE4, SSE42 with jaguar
This follow-up commit adds support for SSE 4 and SSE 4.2 to
the jaguar architecture.

Signed-off-by: Adrien Béraud <adrien.beraud@savoirfairelinux.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-01-20 22:21:11 +01:00