Commit Graph

232 Commits

Author SHA1 Message Date
Yann E. MORIN
58dcd28dfb arch: drop now useless support for FDPIC
Now that we dropped support for blackfin, we no longer have any
architecture that supports FDPIC, so BR2_ARCH_HAS_FDPIC_SUPPORT
is never selected, so we can't select BR2_BINFMT_FDPIC.

Drop all of that now.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-07-01 15:17:27 +02:00
Romain Naour
c9216bc1d0 arch: add BR2_ARCH_NEEDS_GCC_AT_LEAST_8
This new symbol will be used by architectures introduced with gcc 8 and
by external toolchains based on gcc 8.

[1] https://gcc.gnu.org/gcc-8/changes.html

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-05-30 21:44:01 +02:00
Yann E. MORIN
3e44065ab5 arch/arm: cortex-m7 may have a FPv5 FPU
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-05-20 19:15:07 +02:00
Yann E. MORIN
7ee527dd91 arch/arm: cortex-m4 may have an FPv4 FPU
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-05-20 19:14:14 +02:00
Yann E. MORIN
81d8a25bc8 arch/arm: add options for FPv5 FPU
Contrary to its older brother, the FPv5 comes in two flavours; single-
and double-precision [0] [1]. the two variants are only available for
cortex-m7 cores, and the two variants are known to gcc as fpv5-sp-d16
and fpv5-d16, respectively, since gcc-5 [2].

[0] https://en.wikipedia.org/wiki/ARM_Cortex-M#Cortex-M7
[1] https://developer.arm.com/docs/ddi0489/latest/floating-point-unit
[2] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=a076f99fa702deac764f6e0441b9435ad999f521

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-05-20 19:06:55 +02:00
Yann E. MORIN
09c6e28233 arch/arm: add option for FPv4 FPU
The FPv4-SP FPU is a single-precision FPU with 16 double registers [0]
[1]. It is only available for cortex-m4 cores, and is known to gcc as
fpv4-sp-d16 (note that there is no leading 'v') since gcc-4.5 [2].

[0] https://en.wikipedia.org/wiki/ARM_Cortex-M#Cortex-M4
[1] https://developer.arm.com/docs/ddi0439/latest/floating-point-unit
[2] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=639cb7b789a54bf78d6ae5e2644450f5eb1837a6

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-05-20 19:06:07 +02:00
Yann E. MORIN
7f7701301e arch/arm: introduce generic FPU internal option
Currently, we consider that any VFP FPU is a superset of VFPv2, and thus
we use VFPv2 as a way to detect that a VFP is used.

However, for Cortex-M cores, the optional FPU is not a superset of
VFPv2; it is even not a VFP [0].

As a consequence, we can no longer consider VFPv2 as a indication that
an FPU is present.

So, we introduce two new internal options, BR2_ARM_CPU_MAYBE_HAS_FPU and
BR2_ARM_CPU_HAS_FPU, which we use to consider the presence of an FPU.

[0] https://en.wikipedia.org/wiki/ARM_Cortex-M#Cortex-M4

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-05-20 19:01:34 +02:00
Yann E. MORIN
6edfa3bf78 arch/arm: add cortex-m7 core
Nothing fancy, just a plain Cortex-M, armv7-M core...

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-05-20 18:57:18 +02:00
Thomas Petazzoni
e2ea4157a9 arch: drop BR2_BINFMT_FLAT_SEP_DATA support
This was only used by Blackfin, so there's no good reason to keep it.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-04-15 22:04:09 +02:00
Thomas Petazzoni
325bb37942 arch: remove Blackfin architecture
The Blackfin architecture has for a long time been complicated to
maintain, with poor support in upstream binutils/gcc. As of April
2018, the Blackfin architecture has been dropped from the upstream
Linux kernel. Also, the Analog Device engineer who used to be in touch
with the Buildroot community also privately said we should drop the
support for this architecture, which Analog Devices is no longer
using, promoting and maintaining.

The BR2_BINFMT_FLAT_SEP_DATA option becomes unselectable, it will be
removed in a future commit.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-04-15 22:03:41 +02:00
Yann E. MORIN
01c1889f9f arc/xtensa: store the Xtensa overlay in the per-package DL_DIR
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2018-04-02 15:59:30 +02:00
Ricardo Martincoski
9b6b4e36b4 */Config.in*: remove consecutive empty lines
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-04-01 08:48:24 +02:00
Ricardo Martincoski
b2b8a3c3e4 arch/Config.in*: re-wrap help text
... to follow the convention <tab><2 spaces><62 chars>.

Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-04-01 08:00:13 +02:00
Ricardo Martincoski
7e26b8886b arch/Config.in*: fix attributes order
... 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>
2018-04-01 07:59:45 +02:00
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