Commit Graph

30 Commits

Author SHA1 Message Date
Guido Martínez
29563047e0 arch: tidy up mmu config
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-06-09 22:49:39 +02:00
Guido Martínez
a87f5806ed arm: conditionally support regular ARM instructions
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>
2015-02-02 18:32:34 +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
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
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
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
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
Thomas Petazzoni
d3539dd53b arch: pass cpu option instead of tune option on ARM
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-12-26 23:19:04 +01:00
Gustavo Zacarias
79310d3275 arch/arm: add support for thumb(1) mode
[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-18 00:25:07 +02:00
Thomas Petazzoni
8316801f34 arch/arm: update VFPv2 comment to mention ARMv5
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-18 00:25:06 +02:00
Gustavo Zacarias
6b3a0417c4 arch/arm: arm926 may have VFP
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-17 07:29:27 +02:00
Thomas Petazzoni
85d0769ac5 arch/arm: add support for Thumb2
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-16 15:28:03 +02:00
Thomas Petazzoni
5f959a1c61 arch: improve ARM floating point support and add support for EABIhf
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-16 14:42:12 +02:00
Thomas Petazzoni
9b3e72b4fd arch: Refactor BR2_SOFT_FLOAT into per-architecture options
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-16 14:35:07 +02:00
Yann E. MORIN
de1b4f99ae arch/arm: remove setting gcc's apcs-gnu ABI (aka OABI)
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-14 22:11:32 +02:00
Yann E. MORIN
adf9646229 arch/arm: remove OABI option
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-07-14 22:09:45 +02:00
Kelvin Cheung
9d19151351 arm: update processor types
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-06-16 21:12:36 +02:00
Gustavo Zacarias
8f434ff274 toolchain/arm: add support for Marvell PJ4
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-04-29 22:22:49 +02:00
Gustavo Zacarias
9474421da3 toolchain/arm: drop generic and old, add fa526/626, unify strongarm
* 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-04-11 09:22:48 +02:00
Yann E. MORIN
58c2500e2a arch/arm: fix-up the ARM Kconfig warning
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-07 20:39:26 +01:00
Arnout Vandecappelle (Essensium/Mind)
c4cfa85b79 arm: deprecate OABI
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>
2013-02-07 08:44:05 +01:00
Benoît Thébaudeau
88cf3bb917 arch/Config.in.arm: Use armv6k for arm1136jf-s rev1
According to the ARM1136JF-S and ARM1136J-S Revision r1p5 Technical Reference
Manual, from release rev1 (r1pn), the ARM1136JF-S processor implements the ARMv6
instruction set with the ARMv6k additions.

This patch differentiates the ARM1136JF-S revisions 0 and 1 in order to use
either ARMv6j (e.g. on Freescale i.MX31) or ARMv6k (e.g. on Freescale i.MX35).

Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-02-02 08:28:22 +01:00
Peter Korsgaard
f9da98c85d arch/Config.in.arm: Add BR2_ARM_CPU_HAS_NEON similar to how mmx/sse is handled on x86
NEON support is optional on A5/A9, so let the user choose if SoC has it /
wants to use it.

Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2012-12-13 23:25:53 +01:00
Gustavo Zacarias
10d042ad34 arm: update processor types
Update the arm processor types: add the cortex A5 & A15 variants.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2012-12-09 23:07:11 +01:00
Thomas Petazzoni
171075ed4f arch: Config.in string configuration options must be quoted
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>
2012-11-15 16:39:51 +01:00
Thomas Petazzoni
44c04a2b4a arch: improve definition of gcc mtune, mcpu, etc.
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>
2012-11-15 16:12:46 +01:00
Thomas Petazzoni
79ee3c1f84 Split target/Config.in.arch into multiple Config.in.* in arch/
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>
2012-11-04 12:51:38 +01:00