Commit Graph

218 Commits

Author SHA1 Message Date
Norbert Lange
1eecd462ae arch: add Atom CPUs as Silvermont Architecture target
The old Atom target is not really fitting for recent Atom CPUs based
on Silvermont, Airmont or Goldmont. Those have more in common with
older Desktop CPUs than old Atoms.

Signed-off-by: Norbert Lange <norbert.lange@andritz.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2018-01-01 13:05:16 +01:00
Yann E. MORIN
ae2ec0ed74 arch/arm: default to Cortex-A53 for AArch64
Since we re-organised the list of cores (in 52d500aa35) and introduced
some new cores (in e9960da6ec, d632d9e5a9, 6317a199ec), the default for
AArch64 was accidently changed from A53 to A35.

So, restore the default to A53 for AArch64.

Reported-by: daggs <daggs@gmx.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: daggs <daggs@gmx.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2017-12-07 22:39:44 +01:00
Yann E. MORIN
6317a199ec arch/arm: add armv8.1a cores
The armv8.1a generation is a cumulative extension to armv8a. It adds new
extensions, and makes some previously optional ones now mandatory.

Since gcc correctly enables the appropriate extensions based on the core
name, we don't really need to introduce a separate config for armv8.1a,
and we can piggyback on armv8a.

All those new cores are aarch64 only (gcc fails to build in arm mode).

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>
2017-11-24 23:30:43 +01:00
Yann E. MORIN
d632d9e5a9 arch/arm: add some non-cortex armv8a cores
Some need gcc-5, some gcc-6 and some gcc-7.

The thunderx familly does not build in 32-bit mode (gcc complains
that the CPU is unknown, and even gcc master only knows them as
aarch64-only).

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>
2017-11-24 23:30:36 +01:00
Yann E. MORIN
e9960da6ec arch/arm: add some armv8a cortex variants
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>
2017-11-24 23:18:08 +01:00
Yann E. MORIN
ffc9d60243 arch/arm: add cortex-A32
The cortex-A32 is an armv8a core, but it lacks the optional AArch64
extensions, so can only work in 32-bit mode.

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>
2017-11-24 23:11:52 +01:00
Yann E. MORIN
003b1f3c74 arch/arm: armv8 is really armv8a
For armv8, there are different profiles: A, M and R, like there is for
armv7.

So, rename our internal symbol to mirror what we do for armv7.

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>
2017-11-24 23:01:41 +01:00
Yann E. MORIN
a9f95de2c0 arch/arm: simplify hiding non 64-bit cores
Now that the cores are all oredered correctly, we can just enclose all
the non 64-bit cores inside a big if-block, rather than have each of
them have the dependency.

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>
2017-11-24 23:01:03 +01:00
Yann E. MORIN
52d500aa35 arch/arm: re-order cores choice
Currently, the logic for ordering the ARM cores in the choice is all
but obvious. ;-)

Reorder the choice by architecture generation, starting with armv4,
ending with armv8.

Add a comment before each generation, just for ease of use. Add a
separate comment for armv7a and armv7m.

Finally, order cores alphabetically inside the same generation (except
for armv7m cores, listed after all armv7a cores).

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>
2017-11-24 23:00:37 +01:00
Yann E. MORIN
e25d704e10 arch/mips: inverse the mfpxx logic
Currently, the possibility to choose the floating point mode (32, xx or
64) is conditional on having a sufficiently recent gcc version.

Which means that the architecture selection depends on the gcc version.

But that's opposite to what we've always done in Buildroot: the software
versions are conditional to the architecture options. There is nothing
we can do about the hardware: it is there, we can't change it, while we
can restrict ourselves to using software that is working on said
hardware.

Thus, we inverse the logic, to move the condition onto the software
side: whenever mfpxx is selected, we restrict the toolchain selection to
at least a gcc-5.

And now, the blind BR2_TOOLCHAIN_HAS_MFPXX_OPTION symbol is no longer
needed, so we get rid of it.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-11-24 22:45:48 +01:00
Yann E. MORIN
31b134a645 arch/mips: inverse the NaN logic
Currently the possibility to choose the NaN encoding is conditional to
having a sufficiently recent gcc version.

Which means that the architecture selection depends on the gcc version.

But that's opposite to what we've always done in Buildroot: the software
versions are conditional to the architecture options. There is nothing
we can do about the hardware: it is there, we can't change it, while we
can restrict ourselves to using software that is working on said
hardware.

Thus, we inverse the logic, to move the condition onto the software
side: whenever NaN-2008 are selected, we restrict the toolchain
selection to at least a gcc-4.9.

But now, the option with the NaN type is always set, so we must enclose
the code in gcc.mk inside a HAS_NAN_OPTION condition, as is already done
for the external toolchain case.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-11-24 22:39:56 +01:00
Yann E. MORIN
d08ccb40f5 arch/arm: some variants need different gcc versions
Take the conditions currently specified in the gcc version choice.

Also, the conditions explained in the commit log for 78c2a9f7 were not
all properly applied, especially the a57-a53 combo needs gcc-6, but
78c2a9f7 forgot to add the condition to gcc-4.9.

gcc-4.9 was excluded for cortex-a17 and a72, but the CodeSourcery
external toolchain, which uses 4.8, was not excluded for those two
cores. Now it is.

Remove the arch condition from gcc and the external toolchains.

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>
2017-11-24 22:19:14 +01:00
Yann E. MORIN
f82218fcbb arch/mips: some variants need different gcc versions
We use the conditions currently expressed in the gcc version choice.

We leave the musl vs mips64 conditions in gcc, because the "fault"
really is on gcc, which does not recognise the mips64+musl tuples,
so the fix lies within gcc, and the current conditions are fitting.

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>
2017-11-24 22:18:18 +01:00
Yann E. MORIN
6df07bc58e arch/bfin: needs gcc >= 6
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>
2017-11-24 22:17:03 +01:00
Yann E. MORIN
974d97bc26 arch: introduce minimal required gcc version
Some CPU variants require that a recent-enough gcc be selected. For
example, ARM's cortex-a35 requires gcc-5, while cortex-a73 requires
gcc-7. Same goes for other architectures, of course.

Currently, we hard-code every such conditions in the gcc version choice,
as well as in the individual external toolchains.

However, as we add even more CPU variants, the conditions are getting
more and more complex to write and maintain.

Introduce new symbols, that architectures can select if they have a
specific requirement on the gcc version. gcc and external toolchains
can then properly depend on those symbols.

The burden of maintaining the requirements on the gcc version now falls
down to the architeture, instead of being split up in gcc and all the
external toolchains.

As the oldest gcc version to handle, we can either choose gcc-4.9, as
the oldest version we support in our internal toolchain, or choose
gcc-4.8, as the oldest external toolchain we support (except for the
custom ones, but they'll be handled specifically in upcoming changes).
We choose to go back up to gcc-4.8.

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>
2017-11-24 22:03:31 +01:00
Yann E. MORIN
29e046d6e3 arc/bfin: remove 60x cores
Those cores are not supported in upstream gcc, not even in master.

The only toolchain that supported those core was the 2014R1 ADI
rebuilt toolchain, but we removed it in 311bc13 (toolchain: kill
ADI Blackfin toolchain) because there was too many issues with it.
ADI has not released any newer toolchain since then.

There is little hope for those cores now, so remove them.

Support for those cores has been useless and unusable for a while
without nobody noticing, therefore we intentionally skip adding
Config.in.legacy. This would require keeping code in
arch/Config.in.bfin since the options being removed are inside a
choice...endchoice block.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
[Thomas: explain why we don't add the options to Config.in.legacy.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-10-02 21:45:04 +02:00
Yann E. MORIN
d9f61fb4ce arch/bfin: internal backend not suitable for some cores
Some cores are not supported by upstream gcc.

Use the newly-introduced symbol to state so, rather than have the
exclusion in the toolchain choice.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-10-02 21:41:53 +02:00
Yann E. MORIN
5fbbf8a1d1 arch/mips: internal backend not suitable for some cores
Some cores are not supported by upstream gcc.

Use the newly-introduced symbol to state so, rather than have the
exclusion in the toolchain choice.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-10-02 21:41:42 +02:00
Yann E. MORIN
ba00283be8 arch/csky: internal backend not suitable
Upstream gcc does not have support for C-Sky, and we do not have a
vendor tree for it either (yet?).

Use the newly-introduced symbol to state so, rather than have the
exclusion in the toolchain choice.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-10-02 21:41:36 +02:00
Yann E. MORIN
31a726122f arch: add option to disable internal toolchain backend
Some architectures or specific cores do not have support in upstream
gcc. Currently, they are individually listed as exclusions in the
toolchain choice.

This poses a maintainance burden, as the knowledge about what gcc
version supports what architecture is split across many places: the
toolchain choice, the gcc version choice, the external toolchains.

As a first step, add a blind option that architectures or individual
cores may select to indicate they lack support in our internal backend.

Actual use of the option will come in followup patches.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-10-02 21:41:29 +02:00
Yann E. MORIN
78c2a9f763 arch/arm: add big.LITTLE cpu variants
The big.LITTLE configurations can be optimised for by gcc, and a few
users wonder what they should choose when they have such CPUs.

Add new entries for those big.LITTLE configurations.

Note: the various combos were added in various gcc versions, but only
really worked in later versions:

    Variant   | Introduced in | First built in
    ----------+---------------+----------------
    a15-a7    | 4.9           | 4.9
    a17-a7    | 5             | 5
    a57-a53   | 4.9           | 6
    a72-a53   | 5             | 6

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Cc: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-22 23:29:24 +02:00
Vicente Olivert Riera
087be35e22 arch/mips: add option for toolchains supporting -mfpxx
-mfpxx option was added in gcc-5.1.0 so make sure that users cannot
select the "xx" fp32 mode when using toolchains that have a gcc older
than 5.1.0.

-mfp32 and -mfp64 were added in gcc-4.1.0, so given the older gcc
version we support in Buildroot (in the GCC_AT_LEAST options) is 4.3 we
don't need to do anything else for them.

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-21 22:49:18 +02:00
Vicente Olivert Riera
0af741187f arch/mips: add option for toolchains supporting -mnan
-mnan option was added in gcc-4.9.0 so make sure that users cannot
select the NaN mode when using toolchains that have a gcc older
than 4.9.0, and also make sure that the -mnan option is not passed at
all to the toolchain-wrapper and target cflags.

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-21 22:48:51 +02:00
Vicente Olivert Riera
f2985125a4 arch/mips: improve help text of FP32 mode option
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-19 21:47:11 +02:00
Vicente Olivert Riera
cfc6f1e9b7 arch/mips: improve help text of NaN option
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-19 21:47:04 +02:00
Vicente Olivert Riera
9a0a0a976b arch/mips: add support for MIPS32 FP mode
MIPS32 support different FP modes (32,xx,64), so give the user the
opportunity to choose between them. That will cause host-gcc to be built
using the --with-fp-32=[32|xx|64] configure option. Also the
-mfp[32|xx|64] gcc option will be added to TARGET_CFLAGS and to the
toolchain wrapper.

FP mode option shouldn't be used for soft-float, so we add logic in the
toolchain wrapper if -msoft-float is among the arguments in order to not
append the -fp[[32|xx|64] option, otherwise the compilation may fail.

Information about FP modes here:

- https://sourceware.org/binutils/docs/as/MIPS-Options.html
- https://dmz-portal.imgtec.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinking#5._Generating_modeless_code

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-16 16:45:22 +02:00
Vicente Olivert Riera
2d8f3fc430 arch/mips: add support for MIPS NaN
MIPS supports two different NaN encodings, legacy and 2008. Information
about MIPS NaN encodings can be found here:

  https://sourceware.org/binutils/docs/as/MIPS-NaN-Encodings.html

NaN legacy is the only option available for R2 cores and older.
NaN 2008 is the only option available for R6 cores.
R5 cores can have either NaN legacy or NaN 2008, depending on the
implementation. So, if the user selects a generic R5 target architecture
variant, we show a choice menu with both options available. For well
known R5 cores we directly select the NaN enconding they use.

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-16 16:35:39 +02:00
Yann E. MORIN
9d06e91df8 arch/arm: fix -mcpu default values for AArch64
We have to specify the -mcpu value, even in 64-bit mode.

For AArch64, +fp and +simd are the default, so they are totally useless.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-10 18:04:16 +02:00
Max Filippov
3a0a020a2e uboot: apply xtensa overlay
Xtensa core configuration must be added to U-Boot before it can be
built for that xtensa CPU variant. Extract configuration files from the
xtensa overlay as is done for other packages that need to be configured
for a specific xtensa core.

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-09 17:03:45 +02:00
Max Filippov
b7310c8d07 linux: apply xtensa overlay
Xtensa core configuration must be added to linux before it can be
built for that xtensa CPU variant. Extract configuration files from the
xtensa overlay as is done for other packages that need to be configured
for a specific xtensa core.

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-09 17:03:37 +02:00
Yann E. MORIN
5b80a146af arch/xtensa: accept the overlay to be an URL
It can be interesting to get the overlay from a remote server, rather
than expect it to be present locally.

Since that file can be any URL, we can't know its hash, so we just
exclude it.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
[Thomas: use DL_DIR instead of BR2_DL_DIR.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-09 16:58:03 +02:00
Yann E. MORIN
0645fb8084 arch/xtensa: accept the overlay to be compressed
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-09 15:42:26 +02:00
Yann E. MORIN
b3b6070622 arch/xtensa: allow specifying path to tarball file
currently, specifying a custom Xtrensa core is done with two variables:
  - the core name
  - the directory containing the overlay tarball

However, the core name only serves to construct the tarball name, and is
not used whatsoever to configure any of the toolchain components
(binutils, gcc or gdb), except through the files that are overlayed in
their respective source trees.

This has two main drawbacks:
  - the overlay file must be named after the core,
  - the tarball can not be compressed.

Furthermore, it also makes it extremely complex to implement a download
of that tarball.

So, those two variables can be squeezed into a single variable, that is
the complete path of the overlay tarball.

Update the qemu-xtensa defconfig accordingly.

Note: we do not add a legacy entry for BR2_XTENSA_CORE_NAME, since it
was previously a blind option in the last release, and there's been no
release since we removed BR2_XTENSA_CUSTOM_NAME. So, we just update the
legacy comments for BR2_XTENSA_CUSTOM_NAME, since that's all the user
could have seen in any of our releases so far.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-09 15:41:51 +02:00
Yann E. MORIN
15a96d1aaa arch/xtensa: get rid of an intermediate blind kconfig option
It is not needed to have an intermediate blind option, we can just
hide the prompt behind the same dependency as the non-blind symbol.

Update our qemu-xtensa defconfig acordingly (note: it was using
different values for both options, which is not possible; the blind
option was just set to the non-blind one in the .config).

Also remove an unneeded empty default for the BR2_XTENSA_OVERLAY_DIR
string option (strings are empty by default).

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-09 15:39:24 +02:00
Bernd Kuhls
cc405b4cb3 arch, linux, package: remove whitespaces
Whitespaces were searched using the following regex:

[ ]{1,}\t

and then manually removed in most of the cases. For
xserver_xorg-server.mk, tabs before backslashes were removed.

Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-03-29 23:30:37 +02:00
Yann E. MORIN
8eba8e144c arch/xtensa: add macro to extract the overlay
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-03-26 15:49:54 +02:00
Yann E. MORIN
bcecbed654 arch/xtensa: add definitions for the Xtensa overlay
Currently, we have four packages that need to use the Xtensa overlay:
binutils, gcc-initial, gcc-final and gdb. However, they all use three
different ways to check for, and use the overlay. Furthermore, two of
them define the same variable: XTENSA_CORE_NAME is defined both by
binutils and gdb

In order to sanitise that, have the Xtensa architecture export the
appropriate variables: the name of the core and the path to the overlay
tarball. Packages can then check and use those variables.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-03-26 15:49:12 +02:00
Thomas Petazzoni
69f57593ac arch/Config.in.arc: fix BR2_READELF_ARCH_NAME
On ARC, depending on the CPU selected, the ELF machine number might be
different. Take this into account when defining BR2_READELF_ARCH_NAME.

Fixes:

   http://autobuild.buildroot.net/results/0a1957056e07cedc4839439c0ea8ebd1f646b904/

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-03-22 22:05:54 +01:00
Thomas Petazzoni
d04ea6e4e8 arch: add BR2_READELF_ARCH_NAME hidden config option
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>
2017-03-20 22:22:17 +01:00
Guo Ren
f7f568f5e0 arch: add support for the csky architecture
This commit provides basic support for the C-SKY architecture.

Signed-off-by: Guo Ren <ren_guo@c-sky.com>
[Thomas: minor tweaks.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-03-04 14:35:55 +01:00
Waldemar Brodkorb
a818e29e76 arch: add OpenRISC architecture support
Add support for OpenRISC. See here for more details about
OpenRISC http://openrisc.io.

All buildroot included upstream binutils versions are supported.
Gcc support is not upstream, to be able to enable musl C library
support later, we use the branch with musl support.
At the moment it is possible to build a musl based toolchain,
but bootup in Qemu fails.

Gdb is only working to debug bare-metal code, there is no support
for gdbserver/gdb on Linux, yet.

[Peter: drop ?= for GCC_SOURCE]
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Tested-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2017-01-25 22:53:53 +01:00
Peter Korsgaard
933732b82b arch/Config.in.arm: support thumb2 instructions for ARMv8 in 32bit mode
The ARMv8 cores all support thumb2 instructions when running in aarch32 mode.

Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-12-08 22:32:17 +01:00
Peter Korsgaard
0976cd6cd6 arch/Config.in.arm: only enable BR2_ARM_CPU_HAS_NEON for ARMv8 in 32bit mode
A number of packages use BR2_ARM_CPU_HAS_NEON to know if the target handles
aarch32 neon instructions, which is only true for ARMv8 cores when they are
running in 32bit mode.

Notice: These cores do support neon-like instructions using a different
encoding in 64bit mode (it is a required part of ARMv8, similar to the FPU).

Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-12-08 22:32:16 +01:00
Peter Korsgaard
6d97af8763 arch/Config.in.arm: only enable BR2_ARM_CPU_HAS_ARM for ARMv8 in 32bit mode
Fixes:
http://autobuild.buildroot.net/results/5e6/5e67cc067a06f7364cde1a8393ea72608fe7fef1/

A number of packages use BR2_ARM_CPU_HAS_ARM to know if the target handles
classic A32 instructions, which is only true for ARMv8 cores when they are
running in 32bit mode.

Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-12-08 22:32:14 +01:00
Thomas Petazzoni
2131f1b381 arch/Config.in.arm: add Cortex-A57 and Cortex-A72
Add two popular ARM64 cores to the list of supported cores: Cortex-A57
and Cortex-A72.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-12-05 23:07:14 +01:00
Matt Flax
785a73fb8f arch/Config.in.arm: Add Cortex-A53 CPU
Adds the Cortex-A53 CPU to the target architecture variant choice. This
sets the toolchain to use Cortex-A53 as the target. The effect is that
various Cortex-A53 tunings are enabled for the compilation of packages.

Signed-off-by: Matt Flax <flatmax@flatmax.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-12-05 23:07:13 +01:00
Thomas Petazzoni
5e8cb2ee75 arch/Config.in.arm: specify ABI for ARM64
There's currently only one widely supported ABI for ARM64, called lp64,
so we define BR2_GCC_TARGET_ABI to the appropriate value.

Note that there is another ABI for ARM64 being worked on, ilp32, but its
support is not fully upstream in the kernel, so we're not adding support
for it for the moment.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-12-05 23:07:11 +01:00
Thomas Petazzoni
d690b7444a arch/Config.in.arm: add FPU related options for ARMv8 cores
The ARMv8 cores have a mandatory FPU unit called FP-ARMv8, so we:

 - add a new hidden Config.in option for the availability of this
   unit (BR2_ARM_CPU_HAS_FP_ARMV8)

 - allow the selection of a possible choice in the "Floating point
   strategy", and add two new choices: BR2_ARM_FPU_FP_ARMV8 and
   BR2_ARM_FPU_NEON_FP_ARMV8.

 - specify the -mfpu values for BR2_ARM_FPU_FP_ARMV8 and
   BR2_ARM_FPU_NEON_FP_ARMV8 cases, when used on ARM 32 bits (-mfpu
   doesn't exist on ARM64, instead -mcpu modifiers are used, so they
   will be added on a per-core basis).

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[yann.morin.1998@free.fr: drop the FP strategy dependency]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-12-05 23:07:10 +01:00
Yann E. MORIN
743e663912 arch/arm: drop legacy dependency for floating point strategy
The floating point strategy currently depends on EABI || EABIHF. The
reason was that, wayback when we also supported OABI, we only exposed FP
for EABI or EABIHF, and hide it for OABI, which did not support FP.

It's been a while now that we do not support OABI, but the dependency
stuck all along.

Remove it as it is no longer needed, and is always true.

However, the choice is empty for AArch64, as we still have no entry for
their floating point strategy yet.

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>
2016-12-05 23:07:09 +01:00
Thomas Petazzoni
c37189b35e arch/Config.in.arm: add BR2_ARM_CPU_ARMV8
In order to prepare the addition of ARM64 cores, add the blind
BR2_ARM_CPU_ARMV8 option.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-12-05 23:07:08 +01:00