On some architectures one can be running a 64-bit kernel with a 32-bit
userland. Such is the case for sparc64 (unsupported) for example and
mips64 with n32 ABI.
Some tools that interface directly with the kernel need to be built
specially for this, so introduce this symbol to tweak their build in
one central kludge to be future-proof.
Example: bug #6602.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Set --with-arch instead of --with-tune for MIPS so that the
generated code will be optimal for the given MIPS ISA.
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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>
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>
