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>
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>
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>
Drop stale v9/ultrasparc/niagara variants.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Drop the old Sun-specific variants used in old workstations (pre-1997)
and other useless ones.
The V7 ISA is a very old cpu only used in the first Sun workstations,
the toolchain support is broken: the cpu doesn't do hardware div and
it's not handled elsewhere.
The sparclite is also a very old Fujitsu cpu only used in early 90s Sun
machines (includes f930 & f934).
The sparclet (tsc701) was a microcontroller-variant.
The supersparc and hypersparc are just V8 variants also used in old Sun
workstations/servers.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Suggested by Yann E. Morin.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reported-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
As suggested by Yann E. Morin, there is a better way than our current
big Config.in.common to define the gcc mtune, mcpu, march,
etc. values. We can split the setting of those values in each
architecture file, which makes a lot more sense.
Therefore, the Config.in file now creates empty kconfig variables
BR2_ARCH, BR2_ENDIAN, BR2_GCC_TARGET_TUNE, BR2_GCC_TARGET_ARCH,
BR2_GCC_TARGET_ABI and BR2_GCC_TARGET_CPU. The values of those
variables are set by the individual Config.in.<arch> files. This is
possible because such files are now only conditionally included
depending on the top-level architecture that has been selected.
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>
target/Config.in.arch had become too long, and we want to remove the
target/ directory. So let's move it to arch/ and split it this way:
* An initial Config.in that lists the top-level architecture, and
sources the arch-specific Config.in.<arch> files, as well as
Config.in.common (see below)
* One Config.in.<arch> per architecture, listing the CPU families,
ABI choices, etc.
* One Config.in.common that defines the gcc mtune, march, mcpu values
and other hidden options.
[Peter: space->tab fix, mipsel64 little endian, mips3 as noted by Arnout]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>