It is too sad when an editor picks up the wrong syntax...
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
... to follow the convention: type, default, depends on, select, help.
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This config option corresponds to the string returned by readelf for
the "Machine" field of the ELF header. It will be used to check if the
architecture of binaries built by Buildroot match the target
architecture.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
It's been deprecated for quite some time now.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Now that BR2_ARCH_HAS_ATOMICS is no longer used anywhere, we can
remove it from arch/Config.in*, as well as from the documentation.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
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>
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>
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>
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>
