[Buildroot] [PATCH 0/3] arch/arm a53 + ARMV8, package/fftw rework

[Buildroot] [PATCH 0/3] arch/arm a53 + ARMV8, package/fftw rework

[Matt Flax]

These commits :
Firstly add cortex-a53 to arch/Config.in.arm
Secondly rework the fftw package to allow multiple precision installation.
Thirdly add ARMV8 to arch/Config.in.arm, which depends on the first patch
being applied.

Matt Flax (3):
  arch/arm: Add Cortex-a53 CPU
  package/fftw : Allow all precisions to be installed at the same time.
  arch/arm: Add ARMV8 (aarch32) toolchain config.

 arch/Config.in.arm               | 21 +++++++++++-
 package/fftw/Config.in           | 69 +++++++---------------------------------
 package/fftw/fftw-common.mk      | 44 +++++++++++++++++++++++++
 package/fftw/fftw.mk             | 45 ++------------------------
 package/fftw/fftw/Config.in      |  7 ++++
 package/fftw/fftw/fftw.hash      |  1 +
 package/fftw/fftw/fftw.mk        | 21 ++++++++++++
 package/fftw/fftwf/Config.in     |  8 +++++
 package/fftw/fftwf/fftwf.hash    |  1 +
 package/fftw/fftwf/fftwf.mk      | 21 ++++++++++++
 package/fftw/fftwl/Config.in     |  8 +++++
 package/fftw/fftwl/fftwl.hash    |  1 +
 package/fftw/fftwl/fftwl.mk      | 21 ++++++++++++
 package/fftw/fftwq/Config.in     |  7 ++++
 package/fftw/fftwq/fftwq.hash    |  1 +
 package/fftw/fftwq/fftwq.mk      | 21 ++++++++++++
 package/gnuradio/Config.in       |  4 +--
 package/gnuradio/gnuradio.mk     |  2 +-
 package/liquid-dsp/liquid-dsp.mk | 10 ++++--
 19 files changed, 205 insertions(+), 108 deletions(-)
 create mode 100644 package/fftw/fftw-common.mk
 create mode 100644 package/fftw/fftw/Config.in
 create mode 120000 package/fftw/fftw/fftw.hash
 create mode 100644 package/fftw/fftw/fftw.mk
 create mode 100644 package/fftw/fftwf/Config.in
 create mode 120000 package/fftw/fftwf/fftwf.hash
 create mode 100644 package/fftw/fftwf/fftwf.mk
 create mode 100644 package/fftw/fftwl/Config.in
 create mode 120000 package/fftw/fftwl/fftwl.hash
 create mode 100644 package/fftw/fftwl/fftwl.mk
 create mode 100644 package/fftw/fftwq/Config.in
 create mode 120000 package/fftw/fftwq/fftwq.hash
 create mode 100644 package/fftw/fftwq/fftwq.mk

-- 
2.7.4

[Buildroot] [PATCH 1/3] arch/arm: Add Cortex-a53 CPU

[Matt Flax]

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>
---
 arch/Config.in.arm | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/Config.in.arm b/arch/Config.in.arm
index ee612f5..72bb744 100644
--- a/arch/Config.in.arm
+++ b/arch/Config.in.arm
@@ -170,6 +170,13 @@ config BR2_cortex_a17
 	select BR2_ARM_CPU_HAS_THUMB2
 	select BR2_ARM_CPU_ARMV7A
 	select BR2_ARCH_HAS_MMU_OPTIONAL
+config BR2_cortex_a53
+	bool "cortex-A53"
+	select BR2_ARM_CPU_HAS_ARM
+	select BR2_ARM_CPU_HAS_NEON
+	select BR2_ARM_CPU_HAS_VFPV4
+	select BR2_ARM_CPU_ARMV7A
+	select BR2_ARCH_HAS_MMU_OPTIONAL
 config BR2_cortex_m3
 	bool "cortex-M3"
 	select BR2_ARM_CPU_HAS_THUMB2
@@ -458,6 +465,7 @@ config BR2_GCC_TARGET_CPU
 	default "cortex-a12"	if BR2_cortex_a12
 	default "cortex-a15"	if BR2_cortex_a15
 	default "cortex-a17"	if BR2_cortex_a17
+	default "cortex-a53"	if BR2_cortex_a53
 	default "cortex-m3"	if BR2_cortex_m3
 	default "cortex-m4"	if BR2_cortex_m4
 	default "fa526"		if BR2_fa526
-- 
2.7.4

[Buildroot] [PATCH 1/3] arch/arm: Add Cortex-a53 CPU

[Thomas Petazzoni]

Hello,

On Tue, 23 Aug 2016 10:53:21 +1000, Matt Flax wrote:
> 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>

Thanks, but as I said, I don't want to duplicate definitions of 64 bits
ARM cores between Config.in.arm and Config.in.aarch64. So I've pushed
at
http://git.free-electrons.com/users/thomas-petazzoni/buildroot/log/?h=aarch64
a branch that does the necessary rework: it merges Config.in.aarch64
into Config.in.arm, does a few preparation steps, and finally adds your
commit on top of that. Could you have a look and let me know what you
think?

I haven't yet looked in detail at your PATCH 3/3 about the FPU support
for ARMv8. It's still a bit unclear to me what level of FPU support is
mandatory/optional in ARMv8, and whether we can just use
crypto-neon-fp-armv8 all the time, or whether we should allow using
fp-armv8, neon-fp-armv8 and crypto-neon-fp-armv8. Do you have some more
detailed information about which feature is mandatory/optional in the
various ARM64 cores?

Also, it is worth reminding that there are some ARMv8-A cores that are
32-bits only: the Cortex-A32 is one example. So ARMv8-A is not equal to
64 bits support.

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH 1/3] arch/arm: Add Cortex-a53 CPU

[Matt Flax]

On 24/08/16 08:03, Thomas Petazzoni wrote:
> Hello,
>
> On Tue, 23 Aug 2016 10:53:21 +1000, Matt Flax wrote:
>> 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>
> Thanks, but as I said, I don't want to duplicate definitions of 64 bits
> ARM cores between Config.in.arm and Config.in.aarch64. So I've pushed
> at
> http://git.free-electrons.com/users/thomas-petazzoni/buildroot/log/?h=aarch64
> a branch that does the necessary rework: it merges Config.in.aarch64
> into Config.in.arm, does a few preparation steps, and finally adds your
> commit on top of that. Could you have a look and let me know what you
> think?
Looks good. One thing though, my original Cortex-A53 patch selected 
VFPV4 which is now incorrect,
that should be removed ... however that wouldn't enable any HF settings ...
Also I don't understand why we need "select BR2_ARCH_HAS_MMU_OPTIONAL" 
but as I mentioned,
uclibc doesn't compile cleanly without it ... seems like a deep rooted 
problem.


> I haven't yet looked in detail at your PATCH 3/3 about the FPU support
> for ARMv8. It's still a bit unclear to me what level of FPU support is
> mandatory/optional in ARMv8, and whether we can just use
> crypto-neon-fp-armv8 all the time, or whether we should allow using
> fp-armv8, neon-fp-armv8 and crypto-neon-fp-armv8. Do you have some more
> detailed information about which feature is mandatory/optional in the
> various ARM64 cores?

I am not sure about the fine detail, but it seems that ARMV8 extends 
VFPV4, perhaps there should be an extension of VFPV4 which is similar to 
the extension of VFPV3 to VFPV4 ?
The "- mcpu" flag is the same between aarch32 and aarch64, so that 
simplifies the BR2_GCC_TARGET_CPU to being the same for both.
However aarch64 and aarch32 seem to require different BR2_GCC_TARGET_FPU 
lines. I am pretty certain that we need the aarch32 BR2_GCC_TARGET_FPU 
line to include at least "neon" in some way.
I have inspected the gcc definitions of the FPU setups (below) ... 
fp-armv8 doesn't include neon and neon-fp-armv8 doesn't include the 
crypto extensions. I guess the base state should be neon-fp-armv8 ... 
would be good to have options to include the crypto features to speed up 
crc32, AES, sha1 and sha2
 From gcc :
#define ARM_FPU(NAME, MODEL, REV, VFP_REGS, NEON, FP16, CRYPTO)
ARM_FPU("fp-armv8",    ARM_FP_MODEL_VFP, 8, VFP_REG_D32, false, true, false)
ARM_FPU("neon-fp-armv8",ARM_FP_MODEL_VFP, 8, VFP_REG_D32, true, true, false)
ARM_FPU("crypto-neon-fp-armv8", ARM_FP_MODEL_VFP, 8, VFP_REG_D32, true, 
true, true)


> Also, it is worth reminding that there are some ARMv8-A cores that are
> 32-bits only: the Cortex-A32 is one example. So ARMv8-A is not equal to
> 64 bits support.
Actually I think all ARMv8-A cores are 64bit, but can be run in aarch32 
mode for backwards compatability. " In ARMv8-A there are some additions 
to A32 and T32 to maintain alignment with the A64 instruction set." from 
here :
http://www.arm.com/products/processors/armv8-architecture.php

 From our perspective the differences we need to handle between aarch32 
and aarch64 is more significant ... but turn out to be simple ...

The aarch32 requires a "-fpu" setting to specify "neon-fp-armv8" as my 
suggested default.
The aarch64 requires a "-mcpu"  setting to specify the cpu with feature 
suffixes ... I note however that fp and simd are on by default when we 
select the cpu option. Is it necessary to enable these to be turned off 
? If not necessary and we don't desire crypto, then we don't need to 
specify more for the cpu other then the cpu name, i.e. cortex-a53

In other words, with defaults enabled for aarch64 specifying 
BR2_GCC_TARGET_CPU is sufficient to enable some default hardware 
speedups. For aarch32 we need both BR2_GCC_TARGET_CPU and 
BR2_GCC_TARGET_FPU specified.

Perhaps we can start like this as it is very simple and allow crypto to 
be added later for both aarch32 and aarch64 ?

thanks
Matt

> Thanks,
>
> Thomas

[Buildroot] [PATCH 1/3] arch/arm: Add Cortex-a53 CPU

[Waldemar Brodkorb]

Hi Matt,
Matt Flax wrote,

> On 24/08/16 08:03, Thomas Petazzoni wrote:
> >Hello,
> >
> >On Tue, 23 Aug 2016 10:53:21 +1000, Matt Flax wrote:
> >>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>
> >Thanks, but as I said, I don't want to duplicate definitions of 64 bits
> >ARM cores between Config.in.arm and Config.in.aarch64. So I've pushed
> >at
> >http://git.free-electrons.com/users/thomas-petazzoni/buildroot/log/?h=aarch64
> >a branch that does the necessary rework: it merges Config.in.aarch64
> >into Config.in.arm, does a few preparation steps, and finally adds your
> >commit on top of that. Could you have a look and let me know what you
> >think?
> Looks good. One thing though, my original Cortex-A53 patch selected VFPV4
> which is now incorrect,
> that should be removed ... however that wouldn't enable any HF settings ...
> Also I don't understand why we need "select BR2_ARCH_HAS_MMU_OPTIONAL" but
> as I mentioned,
> uclibc doesn't compile cleanly without it ... seems like a deep rooted
> problem.

Can you provide a simple .config for this failure?
I use uClibc-ng on rpi3 with cortex-A53 optimization and fixed a
problem some releases ago. 
So I am wondering what kind of problem you have.

best regards
 Waldemar

[Buildroot] [PATCH 1/3] arch/arm: Add Cortex-a53 CPU

[Matt Flax]

On 25/08/16 07:20, Waldemar Brodkorb wrote:
> Hi Matt,
> Matt Flax wrote,
>
>> On 24/08/16 08:03, Thomas Petazzoni wrote:
>>> Hello,
>>>
>>> On Tue, 23 Aug 2016 10:53:21 +1000, Matt Flax wrote:
>>>> 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>
>>> Thanks, but as I said, I don't want to duplicate definitions of 64 bits
>>> ARM cores between Config.in.arm and Config.in.aarch64. So I've pushed
>>> at
>>> http://git.free-electrons.com/users/thomas-petazzoni/buildroot/log/?h=aarch64
>>> a branch that does the necessary rework: it merges Config.in.aarch64
>>> into Config.in.arm, does a few preparation steps, and finally adds your
>>> commit on top of that. Could you have a look and let me know what you
>>> think?
>> Looks good. One thing though, my original Cortex-A53 patch selected VFPV4
>> which is now incorrect,
>> that should be removed ... however that wouldn't enable any HF settings ...
>> Also I don't understand why we need "select BR2_ARCH_HAS_MMU_OPTIONAL" but
>> as I mentioned,
>> uclibc doesn't compile cleanly without it ... seems like a deep rooted
>> problem.
> Can you provide a simple .config for this failure?
> I use uClibc-ng on rpi3 with cortex-A53 optimization and fixed a
> problem some releases ago.
> So I am wondering what kind of problem you have.

Perhaps when MMU is removed, it is compiling code it doesn't really 
need. This is probably a red-herring problem.

I don't want to waste your time, however if you want to investigate ...

Please find attached a defconfig which sets up the cortex-a53 build to 
replicate the problem.
Please also find attached my Config.in.arm in its current state. Note 
that the Config.in.arm has commented out "select 
BR2_ARCH_HAS_MMU_OPTIONAL" on line 181.
Try and build this and uclibc will complain about swp assembly calls.
Uncomment line 181 and try to build ... will build cleanly !

Matt

> best regards
>   Waldemar

-------------- next part --------------
BR2_DL_DIR="$(BASE_DIR)/../../buildroot.dl"

BR2_cortex_a53=y
BR2_ARM_FPU_NEON_ARMV8=y
BR2_arm=y
BR2_ARM_EABIHF=y
#BR2_PTHREADS_NATIVE=y

-------------- next part --------------
# arm cpu features
config BR2_ARM_CPU_HAS_NEON
	bool

# for some cores, NEON support is optional
config BR2_ARM_CPU_MAYBE_HAS_NEON
	bool

# for some cores, VFPv2 is optional
config BR2_ARM_CPU_MAYBE_HAS_VFPV2
	bool

config BR2_ARM_CPU_HAS_VFPV2
	bool

# for some cores, VFPv3 is optional
config BR2_ARM_CPU_MAYBE_HAS_VFPV3
	bool
	select BR2_ARM_CPU_MAYBE_HAS_VFPV2

config BR2_ARM_CPU_HAS_VFPV3
	bool
	select BR2_ARM_CPU_HAS_VFPV2

# for some cores, VFPv4 is optional
config BR2_ARM_CPU_MAYBE_HAS_VFPV4
	bool
	select BR2_ARM_CPU_MAYBE_HAS_VFPV3

config BR2_ARM_CPU_HAS_VFPV4
	bool
	select BR2_ARM_CPU_HAS_VFPV3

config BR2_ARM_CPU_HAS_ARMV8
	bool

config BR2_ARM_CPU_HAS_ARM
	bool

config BR2_ARM_CPU_HAS_THUMB
	bool

config BR2_ARM_CPU_HAS_THUMB2
	bool

config BR2_ARM_CPU_ARMV4
	bool

config BR2_ARM_CPU_ARMV5
	bool

config BR2_ARM_CPU_ARMV6
	bool

config BR2_ARM_CPU_ARMV7A
	bool

config BR2_ARM_CPU_ARMV7M
	bool

choice
	prompt "Target Architecture Variant"
	depends on BR2_arm || BR2_armeb
	default BR2_arm926t
	help
	  Specific CPU variant to use

config BR2_arm920t
	bool "arm920t"
	select BR2_ARM_CPU_HAS_ARM
	select BR2_ARM_CPU_HAS_THUMB
	select BR2_ARM_CPU_ARMV4
	select BR2_ARCH_HAS_MMU_OPTIONAL
config BR2_arm922t
	bool "arm922t"
	select BR2_ARM_CPU_HAS_ARM
	select BR2_ARM_CPU_HAS_THUMB
	select BR2_ARM_CPU_ARMV4
	select BR2_ARCH_HAS_MMU_OPTIONAL
config BR2_arm926t
	bool "arm926t"
	select BR2_ARM_CPU_HAS_ARM
	select BR2_ARM_CPU_MAYBE_HAS_VFPV2
	select BR2_ARM_CPU_HAS_THUMB
	select BR2_ARM_CPU_ARMV5
	select BR2_ARCH_HAS_MMU_OPTIONAL
config BR2_arm1136j_s
	bool "arm1136j-s"
	select BR2_ARM_CPU_HAS_ARM
	select BR2_ARM_CPU_HAS_THUMB
	select BR2_ARM_CPU_ARMV6
	select BR2_ARCH_HAS_MMU_OPTIONAL
config BR2_arm1136jf_s
	bool "arm1136jf-s"
	select BR2_ARM_CPU_HAS_ARM
	select BR2_ARM_CPU_HAS_VFPV2
	select BR2_ARM_CPU_HAS_THUMB
	select BR2_ARM_CPU_ARMV6
	select BR2_ARCH_HAS_MMU_OPTIONAL
config BR2_arm1176jz_s
	bool "arm1176jz-s"
	select BR2_ARM_CPU_HAS_ARM
	select BR2_ARM_CPU_HAS_THUMB
	select BR2_ARM_CPU_ARMV6
	select BR2_ARCH_HAS_MMU_OPTIONAL
config BR2_arm1176jzf_s
	bool "arm1176jzf-s"
	select BR2_ARM_CPU_HAS_ARM
	select BR2_ARM_CPU_HAS_VFPV2
	select BR2_ARM_CPU_HAS_THUMB
	select BR2_ARM_CPU_ARMV6
	select BR2_ARCH_HAS_MMU_OPTIONAL
config BR2_arm11mpcore
	bool "mpcore"
	select BR2_ARM_CPU_HAS_ARM
	select BR2_ARM_CPU_MAYBE_HAS_VFPV2
	select BR2_ARM_CPU_HAS_THUMB
	select BR2_ARM_CPU_ARMV6
	select BR2_ARCH_HAS_MMU_OPTIONAL
config BR2_cortex_a5
	bool "cortex-A5"
	select BR2_ARM_CPU_HAS_ARM
	select BR2_ARM_CPU_MAYBE_HAS_NEON
	select BR2_ARM_CPU_MAYBE_HAS_VFPV4
	select BR2_ARM_CPU_HAS_THUMB2
	select BR2_ARM_CPU_ARMV7A
	select BR2_ARCH_HAS_MMU_OPTIONAL
config BR2_cortex_a7
	bool "cortex-A7"
	select BR2_ARM_CPU_HAS_ARM
	select BR2_ARM_CPU_HAS_NEON
	select BR2_ARM_CPU_HAS_VFPV4
	select BR2_ARM_CPU_HAS_THUMB2
	select BR2_ARM_CPU_ARMV7A
	select BR2_ARCH_HAS_MMU_OPTIONAL
config BR2_cortex_a8
	bool "cortex-A8"
	select BR2_ARM_CPU_HAS_ARM
	select BR2_ARM_CPU_HAS_NEON
	select BR2_ARM_CPU_HAS_VFPV3
	select BR2_ARM_CPU_HAS_THUMB2
	select BR2_ARM_CPU_ARMV7A
	select BR2_ARCH_HAS_MMU_OPTIONAL
config BR2_cortex_a9
	bool "cortex-A9"
	select BR2_ARM_CPU_HAS_ARM
	select BR2_ARM_CPU_MAYBE_HAS_NEON
	select BR2_ARM_CPU_MAYBE_HAS_VFPV3
	select BR2_ARM_CPU_HAS_THUMB2
	select BR2_ARM_CPU_ARMV7A
	select BR2_ARCH_HAS_MMU_OPTIONAL
config BR2_cortex_a12
	bool "cortex-A12"
	select BR2_ARM_CPU_HAS_ARM
	select BR2_ARM_CPU_HAS_NEON
	select BR2_ARM_CPU_HAS_VFPV4
	select BR2_ARM_CPU_HAS_THUMB2
	select BR2_ARM_CPU_ARMV7A
	select BR2_ARCH_HAS_MMU_OPTIONAL
config BR2_cortex_a15
	bool "cortex-A15"
	select BR2_ARM_CPU_HAS_ARM
	select BR2_ARM_CPU_HAS_NEON
	select BR2_ARM_CPU_HAS_VFPV4
	select BR2_ARM_CPU_HAS_THUMB2
	select BR2_ARM_CPU_ARMV7A
	select BR2_ARCH_HAS_MMU_OPTIONAL
config BR2_cortex_a17
	bool "cortex-A17"
	select BR2_ARM_CPU_HAS_ARM
	select BR2_ARM_CPU_HAS_NEON
	select BR2_ARM_CPU_HAS_VFPV4
	select BR2_ARM_CPU_HAS_THUMB2
	select BR2_ARM_CPU_ARMV7A
	select BR2_ARCH_HAS_MMU_OPTIONAL
config BR2_cortex_a53
	bool "cortex-A53"
	select BR2_ARM_CPU_HAS_ARM
	select BR2_ARM_CPU_HAS_NEON
	select BR2_ARM_CPU_HAS_ARMV8
#	select BR2_ARCH_HAS_MMU_OPTIONAL
config BR2_cortex_m3
	bool "cortex-M3"
	select BR2_ARM_CPU_HAS_THUMB2
	select BR2_ARM_CPU_ARMV7M
config BR2_cortex_m4
	bool "cortex-M4"
	select BR2_ARM_CPU_HAS_THUMB2
	select BR2_ARM_CPU_ARMV7M
config BR2_fa526
	bool "fa526/626"
	select BR2_ARM_CPU_HAS_ARM
	select BR2_ARM_CPU_ARMV4
	select BR2_ARCH_HAS_MMU_OPTIONAL
config BR2_pj4
	bool "pj4"
	select BR2_ARM_CPU_HAS_ARM
	select BR2_ARM_CPU_HAS_VFPV3
	select BR2_ARM_CPU_ARMV7A
	select BR2_ARCH_HAS_MMU_OPTIONAL
config BR2_strongarm
	bool "strongarm sa110/sa1100"
	select BR2_ARM_CPU_HAS_ARM
	select BR2_ARM_CPU_ARMV4
	select BR2_ARCH_HAS_MMU_OPTIONAL
config BR2_xscale
	bool "xscale"
	select BR2_ARM_CPU_HAS_ARM
	select BR2_ARM_CPU_HAS_THUMB
	select BR2_ARM_CPU_ARMV5
	select BR2_ARCH_HAS_MMU_OPTIONAL
config BR2_iwmmxt
	bool "iwmmxt"
	select BR2_ARM_CPU_HAS_ARM
	select BR2_ARM_CPU_ARMV5
	select BR2_ARCH_HAS_MMU_OPTIONAL
endchoice

config BR2_ARM_ENABLE_NEON
	bool "Enable NEON SIMD extension support"
	depends on BR2_ARM_CPU_MAYBE_HAS_NEON
	select BR2_ARM_CPU_HAS_NEON
	help
	  For some CPU cores, the NEON SIMD extension is optional.
	  Select this option if you are certain your particular
	  implementation has NEON support and you want to use it.

config BR2_ARM_ENABLE_VFP
	bool "Enable VFP extension support"
	depends on BR2_ARM_CPU_MAYBE_HAS_VFPV2
	select BR2_ARM_CPU_HAS_VFPV4 if BR2_ARM_CPU_MAYBE_HAS_VFPV4
	select BR2_ARM_CPU_HAS_VFPV3 if BR2_ARM_CPU_MAYBE_HAS_VFPV3
	select BR2_ARM_CPU_HAS_VFPV2 if BR2_ARM_CPU_MAYBE_HAS_VFPV2
	help
	  For some CPU cores, the VFP extension is optional. Select
	  this option if you are certain your particular
	  implementation has VFP support and you want to use it.

choice
	prompt "Target ABI"
	depends on BR2_arm || BR2_armeb
	default BR2_ARM_EABIHF if BR2_ARM_CPU_HAS_VFPV2
	default BR2_ARM_EABI
	help
	  Application Binary Interface to use. The Application Binary
	  Interface describes the calling conventions (how arguments
	  are passed to functions, how the return value is passed, how
	  system calls are made, etc.).

config BR2_ARM_EABI
	bool "EABI"
	help
	  The EABI is currently the standard ARM ABI, which is used in
	  most projects. It supports both the 'soft' floating point
	  model (in which floating point instructions are emulated in
	  software) and the 'softfp' floating point model (in which
	  floating point instructions are executed using an hardware
	  floating point unit, but floating point arguments to
	  functions are passed in integer registers).

	  The 'softfp' floating point model is link-compatible with
	  the 'soft' floating point model, i.e you can link a library
	  built 'soft' with some other code built 'softfp'.

	  However, passing the floating point arguments in integer
	  registers is a bit inefficient, so if your ARM processor has
	  a floating point unit, and you don't have pre-compiled
	  'soft' or 'softfp' code, using the EABIhf ABI will provide
	  better floating point performances.

	  If your processor does not have a floating point unit, then
	  you must use this ABI.

config BR2_ARM_EABIHF
	bool "EABIhf"
	depends on BR2_ARM_CPU_HAS_VFPV2 || BR2_ARM_CPU_HAS_ARMV8
	help
	  The EABIhf is an extension of EABI which supports the 'hard'
	  floating point model. This model uses the floating point
	  unit to execute floating point instructions, and passes
	  floating point arguments in floating point registers.

	  It is more efficient than EABI for floating point related
	  workload. However, it does not allow to link against code
	  that has been pre-built for the 'soft' or 'softfp' floating
	  point models.

	  If your processor has a floating point unit, and you don't
	  depend on existing pre-compiled code, this option is most
	  likely the best choice.

endchoice

choice
	prompt "Floating point strategy"
	depends on BR2_ARM_EABI || BR2_ARM_EABIHF
	default BR2_ARM_FPU_NEON_ARMV8 if BR2_ARM_CPU_HAS_ARMV8
	default BR2_ARM_FPU_VFPV4D16 if BR2_ARM_CPU_HAS_VFPV4
	default BR2_ARM_FPU_VFPV3D16 if BR2_ARM_CPU_HAS_VFPV3
	default BR2_ARM_FPU_VFPV2 if BR2_ARM_CPU_HAS_VFPV2
	default BR2_ARM_SOFT_FLOAT if !BR2_ARM_CPU_HAS_VFPV2

config BR2_ARM_SOFT_FLOAT
	bool "Soft float"
	depends on BR2_ARM_EABI
	select BR2_SOFT_FLOAT
	help
	  This option allows to use software emulated floating
	  point. It should be used for ARM cores that do not include a
	  Vector Floating Point unit, such as ARMv5 cores (ARM926 for
	  example) or certain ARMv6 cores.

config BR2_ARM_FPU_VFPV2
	bool "VFPv2"
	depends on BR2_ARM_CPU_HAS_VFPV2
	help
	  This option allows to use the VFPv2 floating point unit, as
	  available in some ARMv5 processors (ARM926EJ-S) and some
	  ARMv6 processors (ARM1136JF-S, ARM1176JZF-S and ARM11
	  MPCore).

	  Note that this option is also safe to use for newer cores
	  such as Cortex-A, because the VFPv3 and VFPv4 units are
	  backward compatible with VFPv2.

config BR2_ARM_FPU_VFPV3
	bool "VFPv3"
	depends on BR2_ARM_CPU_HAS_VFPV3
	help
	  This option allows to use the VFPv3 floating point unit, as
	  available in some ARMv7 processors (Cortex-A{8, 9}). This
	  option requires a VFPv3 unit that has 32 double-precision
	  registers, which is not necessarily the case in all SOCs
	  based on Cortex-A{8, 9}. If you're unsure, use VFPv3-D16
	  instead, which is guaranteed to work on all Cortex-A{8, 9}.

	  Note that this option is also safe to use for newer cores
	  that have a VFPv4 unit, because VFPv4 is backward compatible
	  with VFPv3. They must of course also have 32
	  double-precision registers.

config BR2_ARM_FPU_VFPV3D16
	bool "VFPv3-D16"
	depends on BR2_ARM_CPU_HAS_VFPV3
	help
	  This option allows to use the VFPv3 floating point unit, as
	  available in some ARMv7 processors (Cortex-A{8, 9}). This
	  option requires a VFPv3 unit that has 16 double-precision
	  registers, which is generally the case in all SOCs based on
	  Cortex-A{8, 9}, even though VFPv3 is technically optional on
	  Cortex-A9. This is the safest option for those cores.

	  Note that this option is also safe to use for newer cores
	  such that have a VFPv4 unit, because the VFPv4 is backward
	  compatible with VFPv3.

config BR2_ARM_FPU_VFPV4
	bool "VFPv4"
	depends on BR2_ARM_CPU_HAS_VFPV4
	help
	  This option allows to use the VFPv4 floating point unit, as
	  available in some ARMv7 processors (Cortex-A{5, 7, 12,
	  15}). This option requires a VFPv4 unit that has 32
	  double-precision registers, which is not necessarily the
	  case in all SOCs based on Cortex-A{5, 7, 12, 15}. If you're
	  unsure, you should probably use VFPv4-D16 instead.

	  Note that if you want binary code that works on all ARMv7
	  cores, including the earlier Cortex-A{8, 9}, you should
	  instead select VFPv3.

config BR2_ARM_FPU_NEON_ARMV8
	bool "ARMV8"
	depends on BR2_ARM_CPU_HAS_ARMV8
	help
	  This option allows to use the ARMV8 floating point unit, as
	  available in some ARMv8 processors (Cortex-A53).

config BR2_ARM_FPU_VFPV4D16
	bool "VFPv4-D16"
	depends on BR2_ARM_CPU_HAS_VFPV4
	help
	  This option allows to use the VFPv4 floating point unit, as
	  available in some ARMv7 processors (Cortex-A{5, 7, 12,
	  15}). This option requires a VFPv4 unit that has 16
	  double-precision registers, which is always available on
	  Cortex-A12 and Cortex-A15, but optional on Cortex-A5 and
	  Cortex-A7.

	  Note that if you want binary code that works on all ARMv7
	  cores, including the earlier Cortex-A{8, 9}, you should
	  instead select VFPv3-D16.

config BR2_ARM_FPU_NEON
	bool "NEON"
	depends on BR2_ARM_CPU_HAS_NEON
	help
	  This option allows to use the NEON SIMD unit, as available
	  in some ARMv7 processors, as a floating-point unit. It
	  should however be noted that using NEON for floating point
	  operations doesn't provide a complete compatibility with the
	  IEEE 754.

config BR2_ARM_FPU_NEON_VFPV4
	bool "NEON/VFPv4"
	depends on BR2_ARM_CPU_HAS_VFPV4
	depends on BR2_ARM_CPU_HAS_NEON
	help
	  This option allows to use both the VFPv4 and the NEON SIMD
	  units for floating point operations. Note that some ARMv7
	  cores do not necessarily have VFPv4 and/or NEON support, for
	  example on Cortex-A5 and Cortex-A7, support for VFPv4 and
	  NEON is optional.

endchoice

choice
	prompt "ARM instruction set"

config BR2_ARM_INSTRUCTIONS_ARM
	bool "ARM"
	depends on BR2_ARM_CPU_HAS_ARM
	help
	  This option instructs the compiler to generate regular ARM
	  instructions, that are all 32 bits wide.

config BR2_ARM_INSTRUCTIONS_THUMB
	bool "Thumb"
	depends on BR2_ARM_CPU_HAS_THUMB
	# Thumb-1 and VFP are not compatible
	depends on BR2_ARM_SOFT_FLOAT
	help
	  This option instructions the compiler to generate Thumb
	  instructions, which allows to mix 16 bits instructions and
	  32 bits instructions. This generally provides a much smaller
	  compiled binary size.

comment "Thumb1 is not compatible with VFP"
	depends on BR2_ARM_CPU_HAS_THUMB
	depends on !BR2_ARM_SOFT_FLOAT

config BR2_ARM_INSTRUCTIONS_THUMB2
	bool "Thumb2"
	depends on BR2_ARM_CPU_HAS_THUMB2
	help
	  This option instructions the compiler to generate Thumb2
	  instructions, which allows to mix 16 bits instructions and
	  32 bits instructions. This generally provides a much smaller
	  compiled binary size.

endchoice

config BR2_ARCH
	default "arm"	if BR2_arm
	default "armeb"	if BR2_armeb

config BR2_ENDIAN
	default "LITTLE" if BR2_arm
	default "BIG"	 if BR2_armeb

config BR2_GCC_TARGET_CPU
	default "arm920t"	if BR2_arm920t
	default "arm922t"	if BR2_arm922t
	default "arm926ej-s"	if BR2_arm926t
	default "arm1136j-s"	if BR2_arm1136j_s
	default "arm1136jf-s"	if BR2_arm1136jf_s
	default "arm1176jz-s"	if BR2_arm1176jz_s
	default "arm1176jzf-s"	if BR2_arm1176jzf_s
	default "mpcore"	if BR2_arm11mpcore && BR2_ARM_CPU_HAS_VFPV2
	default "mpcorenovfp"	if BR2_arm11mpcore
	default "cortex-a5"	if BR2_cortex_a5
	default "cortex-a7"	if BR2_cortex_a7
	default "cortex-a8"	if BR2_cortex_a8
	default "cortex-a9"	if BR2_cortex_a9
	default "cortex-a12"	if BR2_cortex_a12
	default "cortex-a15"	if BR2_cortex_a15
	default "cortex-a17"	if BR2_cortex_a17
	default "cortex-a53"	if BR2_cortex_a53
	default "cortex-m3"	if BR2_cortex_m3
	default "cortex-m4"	if BR2_cortex_m4
	default "fa526"		if BR2_fa526
	default "marvell-pj4"	if BR2_pj4
	default "strongarm"	if BR2_strongarm
	default "xscale"	if BR2_xscale
	default "iwmmxt"	if BR2_iwmmxt

config BR2_GCC_TARGET_ABI
	default "aapcs-linux"

config BR2_GCC_TARGET_FPU
	default "vfp"		if BR2_ARM_FPU_VFPV2
	default "vfpv3"		if BR2_ARM_FPU_VFPV3
	default "vfpv3-d16" 	if BR2_ARM_FPU_VFPV3D16
	default "vfpv4" 	if BR2_ARM_FPU_VFPV4
	default "vfpv4-d16" 	if BR2_ARM_FPU_VFPV4D16
	default "neon" 		if BR2_ARM_FPU_NEON
	default "neon-vfpv4" 	if BR2_ARM_FPU_NEON_VFPV4
	default "crypto-neon-fp-armv8" 	if BR2_ARM_FPU_NEON_ARMV8

config BR2_GCC_TARGET_FLOAT_ABI
	default "soft"		if BR2_ARM_SOFT_FLOAT
	default "softfp"	if !BR2_ARM_SOFT_FLOAT && BR2_ARM_EABI
	default "hard"		if !BR2_ARM_SOFT_FLOAT && BR2_ARM_EABIHF

config BR2_GCC_TARGET_MODE
	default "arm"		if BR2_ARM_INSTRUCTIONS_ARM
	default "thumb"		if BR2_ARM_INSTRUCTIONS_THUMB || BR2_ARM_INSTRUCTIONS_THUMB2

[Buildroot] [PATCH 1/3] arch/arm: Add Cortex-a53 CPU

[Thomas Petazzoni]

Matt,

Please Cc: me on your replies. There's a lot of traffic on the
Buildroot mailing list, so if you want me to be reactive on this
discussion, you'd better Cc: me.

On Wed, 24 Aug 2016 09:44:22 +1000, Matt Flax wrote:

> Looks good. One thing though, my original Cortex-A53 patch selected 
> VFPV4 which is now incorrect,
> that should be removed ... however that wouldn't enable any HF settings ...

I've added a new patch that adds a BR2_ARM_CPU_HAS_FP_ARMV8 hidden
option, and the related FPU options. For now, I'm only supporting the
fp-armv8 and neon-fp-armv8 cases. It seems pretty clear that the FPU
and NEON are mandatory on all ARMv8 cores, at least to date.

I haven't taken into account the crypto-neon-fp-armv8 case, since it's
not clear whether the crypto instructions are mandatory or not on all
cores.

> Also I don't understand why we need "select BR2_ARCH_HAS_MMU_OPTIONAL" 
> but as I mentioned,
> uclibc doesn't compile cleanly without it ... seems like a deep rooted 
> problem.

If you don't select BR2_ARCH_HAS_MMU_OPTIONAL, then the BR2_USE_MMU
option is never set to 'y', so Buildroot configures uClibc as if it was
building for a noMMU platform.

However, for ARMv8, I believe we should probably be using
BR2_ARCH_HAS_MMU_MANDATORY instead, since I don't think running an
ARM64 without the MMU enabled is supported.

> I am not sure about the fine detail, but it seems that ARMV8 extends 
> VFPV4, perhaps there should be an extension of VFPV4 which is similar to 
> the extension of VFPV3 to VFPV4 ?

That's what I've done with BR2_ARM_CPU_HAS_FP_ARMV8.

> The "- mcpu" flag is the same between aarch32 and aarch64, so that 
> simplifies the BR2_GCC_TARGET_CPU to being the same for both.

No, it's not the same. On ARM 32 bits you have separate -mcpu and -mfpu
options. On ARM 64 bits, you only have the -mcpu option with its
modifier mechanism. I've handled this in my new version of the patch
series.

> However aarch64 and aarch32 seem to require different BR2_GCC_TARGET_FPU 
> lines. I am pretty certain that we need the aarch32 BR2_GCC_TARGET_FPU 
> line to include at least "neon" in some way.

ARM64 cannot have a BR2_GCC_TARGET_FPU line, because there's no -mfpu
option, at least according to the gcc documentation at
https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/AArch64-Options.html#AArch64-Options.

> > Also, it is worth reminding that there are some ARMv8-A cores that are
> > 32-bits only: the Cortex-A32 is one example. So ARMv8-A is not equal to
> > 64 bits support.  
> Actually I think all ARMv8-A cores are 64bit,

No: the Cortex-A32 is 32 bits only. See
http://www.arm.com/products/processors/cortex-a/cortex-a32-processor.php.

> The aarch32 requires a "-fpu" setting to specify "neon-fp-armv8" as my 
> suggested default.

I've used fp-armv8 as the default, because NEON is not always good for
FPU operations. From the gcc documentation:

   If the selected floating-point hardware includes the NEON extension
   (e.g. -mfpu=?neon?), note that floating-point operations are not
   generated by GCC's auto-vectorization pass unless
   -funsafe-math-optimizations is also specified. This is because NEON
   hardware does not fully implement the IEEE 754 standard for
   floating-point arithmetic (in particular denormal values are treated
   as zero), so the use of NEON instructions may lead to a loss of
   precision.

> The aarch64 requires a "-mcpu"  setting to specify the cpu with feature 
> suffixes ... I note however that fp and simd are on by default when we 
> select the cpu option. Is it necessary to enable these to be turned off 
> ? If not necessary and we don't desire crypto, then we don't need to 
> specify more for the cpu other then the cpu name, i.e. cortex-a53

I've for now used:

+	default "cortex-a53"		if (BR2_cortex_a53 && !BR2_ARCH_IS_64)
+	default "cortex-a53+fp"		if (BR2_cortex_a53 && BR2_ARCH_IS_64 && BR2_ARM_FPU_FP_ARMV8)
+	default "cortex-a53+fp+simd" 	if (BR2_cortex_a53 && BR2_ARCH_IS_64 && BR2_ARM_FPU_NEON_FP_ARMV8)
 
I.e:

 -mcpu=cortex-a53 for Cortex-A53 used in ARM 32 bits mode

 -mcpu=cortex-a53+fp when Cortex-A53 used in ARM 64 bits mode and BR2_ARM_FPU_FP_ARMV8 is selected

 -mcpu=cortex-a53+fp+simd when Cortex-A53 used in ARM 64 bits mode and BR2_ARM_FPU_NEON_FP_ARMV8 is selected

Can you have a look at my updated branch at
http://git.free-electrons.com/users/thomas-petazzoni/buildroot/log/?h=aarch64
and let me know what you think? If you're starting to be happy with it,
I can post it on the mailing list for proper review.

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH 1/3] arch/arm: Add Cortex-a53 CPU

[Matt Flax]

On 25/08/16 08:14, Thomas Petazzoni wrote:
> Matt,
>
> Please Cc: me on your replies. There's a lot of traffic on the
> Buildroot mailing list, so if you want me to be reactive on this
> discussion, you'd better Cc: me.
>
> On Wed, 24 Aug 2016 09:44:22 +1000, Matt Flax wrote:
>
>> Looks good. One thing though, my original Cortex-A53 patch selected
>> VFPV4 which is now incorrect,
>> that should be removed ... however that wouldn't enable any HF settings ...
> I've added a new patch that adds a BR2_ARM_CPU_HAS_FP_ARMV8 hidden
> option, and the related FPU options. For now, I'm only supporting the
> fp-armv8 and neon-fp-armv8 cases. It seems pretty clear that the FPU
> and NEON are mandatory on all ARMv8 cores, at least to date.
>
> I haven't taken into account the crypto-neon-fp-armv8 case, since it's
> not clear whether the crypto instructions are mandatory or not on all
> cores.
>
>> Also I don't understand why we need "select BR2_ARCH_HAS_MMU_OPTIONAL"
>> but as I mentioned,
>> uclibc doesn't compile cleanly without it ... seems like a deep rooted
>> problem.
> If you don't select BR2_ARCH_HAS_MMU_OPTIONAL, then the BR2_USE_MMU
> option is never set to 'y', so Buildroot configures uClibc as if it was
> building for a noMMU platform.
>
> However, for ARMv8, I believe we should probably be using
> BR2_ARCH_HAS_MMU_MANDATORY instead, since I don't think running an
> ARM64 without the MMU enabled is supported.
>
>> I am not sure about the fine detail, but it seems that ARMV8 extends
>> VFPV4, perhaps there should be an extension of VFPV4 which is similar to
>> the extension of VFPV3 to VFPV4 ?
> That's what I've done with BR2_ARM_CPU_HAS_FP_ARMV8.
>
>> The "- mcpu" flag is the same between aarch32 and aarch64, so that
>> simplifies the BR2_GCC_TARGET_CPU to being the same for both.
> No, it's not the same. On ARM 32 bits you have separate -mcpu and -mfpu
> options. On ARM 64 bits, you only have the -mcpu option with its
> modifier mechanism. I've handled this in my new version of the patch
> series.
>
>> However aarch64 and aarch32 seem to require different BR2_GCC_TARGET_FPU
>> lines. I am pretty certain that we need the aarch32 BR2_GCC_TARGET_FPU
>> line to include at least "neon" in some way.
> ARM64 cannot have a BR2_GCC_TARGET_FPU line, because there's no -mfpu
> option, at least according to the gcc documentation at
> https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/AArch64-Options.html#AArch64-Options.
>
>>> Also, it is worth reminding that there are some ARMv8-A cores that are
>>> 32-bits only: the Cortex-A32 is one example. So ARMv8-A is not equal to
>>> 64 bits support.
>> Actually I think all ARMv8-A cores are 64bit,
> No: the Cortex-A32 is 32 bits only. See
> http://www.arm.com/products/processors/cortex-a/cortex-a32-processor.php.
>
>> The aarch32 requires a "-fpu" setting to specify "neon-fp-armv8" as my
>> suggested default.
> I've used fp-armv8 as the default, because NEON is not always good for
> FPU operations. From the gcc documentation:
>
>     If the selected floating-point hardware includes the NEON extension
>     (e.g. -mfpu=?neon?), note that floating-point operations are not
>     generated by GCC's auto-vectorization pass unless
>     -funsafe-math-optimizations is also specified. This is because NEON
>     hardware does not fully implement the IEEE 754 standard for
>     floating-point arithmetic (in particular denormal values are treated
>     as zero), so the use of NEON instructions may lead to a loss of
>     precision.
>
>> The aarch64 requires a "-mcpu"  setting to specify the cpu with feature
>> suffixes ... I note however that fp and simd are on by default when we
>> select the cpu option. Is it necessary to enable these to be turned off
>> ? If not necessary and we don't desire crypto, then we don't need to
>> specify more for the cpu other then the cpu name, i.e. cortex-a53
> I've for now used:
>
> +	default "cortex-a53"		if (BR2_cortex_a53 && !BR2_ARCH_IS_64)
> +	default "cortex-a53+fp"		if (BR2_cortex_a53 && BR2_ARCH_IS_64 && BR2_ARM_FPU_FP_ARMV8)
> +	default "cortex-a53+fp+simd" 	if (BR2_cortex_a53 && BR2_ARCH_IS_64 && BR2_ARM_FPU_NEON_FP_ARMV8)
>   
> I.e:
>
>   -mcpu=cortex-a53 for Cortex-A53 used in ARM 32 bits mode
>
>   -mcpu=cortex-a53+fp when Cortex-A53 used in ARM 64 bits mode and BR2_ARM_FPU_FP_ARMV8 is selected
>
>   -mcpu=cortex-a53+fp+simd when Cortex-A53 used in ARM 64 bits mode and BR2_ARM_FPU_NEON_FP_ARMV8 is selected
>
> Can you have a look at my updated branch at
> http://git.free-electrons.com/users/thomas-petazzoni/buildroot/log/?h=aarch64
> and let me know what you think? If you're starting to be happy with it,
> I can post it on the mailing list for proper review.

I think we are almost there.
The three selections for "-mcpu" above may be equivalent. On their 
aarch64 gcc options page, GNU say that both fp and simd are "on by 
default for all possible values for options -march and -mcpu. ".
If you think it is important to disable them by default, then you may 
need to use :

default "cortex-a53" 		if (BR2_cortex_a53 && !BR2_ARCH_IS_64)
default "cortex-a53+fp+nosimd"	if (BR2_cortex_a53 && BR2_ARCH_IS_64 && BR2_ARM_FPU_FP_ARMV8)
default "cortex-a53+fp+simd" 	if (BR2_cortex_a53 && BR2_ARCH_IS_64 && BR2_ARM_FPU_NEON_FP_ARMV8)

Perhaps we should start thinking about including a crypto option for 
ARMV8 in the future ... this should speed up encryption and key 
generation ... may have drastic performance increases when using 
encrypted storage as root or home or otherwise.

Matt

[Buildroot] [PATCH 2/3] package/fftw : Allow all precisions to be installed at the same time.

[Matt Flax]

This updates the current fftw package to allow the installation and selection
of one more of the fftw precisions onto the system. Previously, you could
only choose one prevision at a time, however there are many use cases where
different precisions are required on the same system. Further, various packages
selected BR2_PACKAGE_FFTW assuming the double precision version would be
compile, which was a buggy assumption.

Following previous suggestions and discussions, a common fftw mk file is used.
The hash file is symbolically linked against. To preserve the previous behavior,
if BR2_PACKAGE_FFTW is selected, this defaults to the double precision version.
Other available precisions are now BR2_PACKAGE_FFTWF, BR2_PACKAGE_FFTWL,
BR2_PACKAGE_FFTWQ which is the fftw standard for singe, long double and quad
precisions.

The following packages have been updated : liquid-dsp, gnuradio
These packages required single precision installations.
Other packages : libvips, pulseaudio, httping, imagemagick, alsa-utils
implicitly required double precision without enforcing it, merely assuming
this would happen by default. This was not the case when the user selected a
different precision.

Signed-off-by: Matt Flax <flatmax@flatmax.org>
---
 package/fftw/Config.in           | 69 +++++++---------------------------------
 package/fftw/fftw-common.mk      | 44 +++++++++++++++++++++++++
 package/fftw/fftw.mk             | 45 ++------------------------
 package/fftw/fftw/Config.in      |  7 ++++
 package/fftw/fftw/fftw.hash      |  1 +
 package/fftw/fftw/fftw.mk        | 21 ++++++++++++
 package/fftw/fftwf/Config.in     |  8 +++++
 package/fftw/fftwf/fftwf.hash    |  1 +
 package/fftw/fftwf/fftwf.mk      | 21 ++++++++++++
 package/fftw/fftwl/Config.in     |  8 +++++
 package/fftw/fftwl/fftwl.hash    |  1 +
 package/fftw/fftwl/fftwl.mk      | 21 ++++++++++++
 package/fftw/fftwq/Config.in     |  7 ++++
 package/fftw/fftwq/fftwq.hash    |  1 +
 package/fftw/fftwq/fftwq.mk      | 21 ++++++++++++
 package/gnuradio/Config.in       |  4 +--
 package/gnuradio/gnuradio.mk     |  2 +-
 package/liquid-dsp/liquid-dsp.mk | 10 ++++--
 18 files changed, 185 insertions(+), 107 deletions(-)
 create mode 100644 package/fftw/fftw-common.mk
 create mode 100644 package/fftw/fftw/Config.in
 create mode 120000 package/fftw/fftw/fftw.hash
 create mode 100644 package/fftw/fftw/fftw.mk
 create mode 100644 package/fftw/fftwf/Config.in
 create mode 120000 package/fftw/fftwf/fftwf.hash
 create mode 100644 package/fftw/fftwf/fftwf.mk
 create mode 100644 package/fftw/fftwl/Config.in
 create mode 120000 package/fftw/fftwl/fftwl.hash
 create mode 100644 package/fftw/fftwl/fftwl.mk
 create mode 100644 package/fftw/fftwq/Config.in
 create mode 120000 package/fftw/fftwq/fftwq.hash
 create mode 100644 package/fftw/fftwq/fftwq.mk

diff --git a/package/fftw/Config.in b/package/fftw/Config.in
index ef11384..7f21344 100644
--- a/package/fftw/Config.in
+++ b/package/fftw/Config.in
@@ -1,66 +1,20 @@
-config BR2_PACKAGE_FFTW
-	bool "fftw"
-	help
-	  Library for computing Fast Fourier Transforms.
-
-	  This library computes Fast Fourier Transforms (FFT) in one
-	  or more dimensions. It is extremely fast. This package
-	  contains the shared library version of the fftw libraries in
-	  double precision.
+menu "FFTW precision and options"
 
-	  http://www.fftw.org
-
-if BR2_PACKAGE_FFTW
+source "package/fftw/fftw/Config.in"
+source "package/fftw/fftwf/Config.in"
+source "package/fftw/fftwl/Config.in"
+source "package/fftw/fftwq/Config.in"
 
 config BR2_PACKAGE_FFTW_USE_SSE
-	bool
+	bool "use SSE"
+	depends on BR2_X86_CPU_HAS_SSE
 
 config BR2_PACKAGE_FFTW_USE_SSE2
-	bool
+	bool "use SSE2"
+	depends on BR2_X86_CPU_HAS_SSE
 
 config BR2_PACKAGE_FFTW_USE_NEON
-	bool
-
-choice
-	prompt "fftw precision"
-	default BR2_PACKAGE_FFTW_PRECISION_DOUBLE
-	help
-	  Selects fftw precision
-
-config BR2_PACKAGE_FFTW_PRECISION_SINGLE
-	bool "single"
-	select BR2_PACKAGE_FFTW_USE_SSE if BR2_X86_CPU_HAS_SSE
-	select BR2_PACKAGE_FFTW_USE_SSE2 if BR2_X86_CPU_HAS_SSE2
-	select BR2_PACKAGE_FFTW_USE_NEON if BR2_ARM_CPU_HAS_NEON && !BR2_ARM_SOFT_FLOAT
-	help
-	  Compile fftw in single precision, i.e. use 'float' for floating
-	  point type.
-
-config BR2_PACKAGE_FFTW_PRECISION_DOUBLE
-	bool "double"
-	select BR2_PACKAGE_FFTW_USE_SSE2 if BR2_X86_CPU_HAS_SSE2
-	help
-	  Compile fftw in double precision (the default), i.e. use 'double'
-	  for floating point type.
-
-config BR2_PACKAGE_FFTW_PRECISION_LONG_DOUBLE
-	bool "long double"
-	# long-double precision require long-double trigonometric routines
-	depends on !(BR2_TOOLCHAIN_BUILDROOT_UCLIBC && \
-		(BR2_arm || BR2_mips || BR2_mipsel))
-	help
-	  Compile fftw in long double precision, i.e. use 'long double'
-	  for floating point type.
-
-config BR2_PACKAGE_FFTW_PRECISION_QUAD
-	bool "quad"
-	# quad-precision needs to have a gcc with libquadmath
-	depends on (BR2_i386 || BR2_x86_64) && BR2_USE_WCHAR
-	help
-	  Compile fftw in quadruple precision, i.e. use '__float128' for
-	  floating point type.
-
-endchoice
+	bool "use NEON"
 
 config BR2_PACKAGE_FFTW_FAST
 	bool "optimise for speed over accuracy"
@@ -74,5 +28,4 @@ config BR2_PACKAGE_FFTW_FAST
 	  This basically uses gcc's -Ofast optimisation level, which in
 	  turn is basically using gcc's -ffast-math. See the gcc manual
 	  for what this means.
-
-endif
+endmenu
diff --git a/package/fftw/fftw-common.mk b/package/fftw/fftw-common.mk
new file mode 100644
index 0000000..4d8deef
--- /dev/null
+++ b/package/fftw/fftw-common.mk
@@ -0,0 +1,44 @@
+################################################################################
+#
+# fftw
+#
+################################################################################
+
+FFTW_COMMON_VERSION = 3.3.4
+FFTW_COMMON_SITE = http://www.fftw.org
+FFTW_COMMON_INSTALL_STAGING = YES
+FFTW_COMMON_LICENSE = GPLv2+
+FFTW_COMMON_LICENSE_FILES = COPYING
+
+# fortran support only enables generation and installation of fortran sources
+ifeq ($(BR2_TOOLCHAIN_HAS_FORTRAN),y)
+FFTW_COMMON_CONF_OPTS += --enable-fortran
+FFTW_COMMON_CONF_ENV += FLIBS="-lgfortran -lm"
+else
+FFTW_COMMON_CONF_OPTS += --disable-fortran
+endif
+
+FFTW_COMMON_CFLAGS = $(TARGET_CFLAGS)
+ifeq ($(BR2_PACKAGE_FFTW_COMMON_FAST),y)
+FFTW_COMMON_CFLAGS += -O3 -ffast-math
+endif
+
+# x86 optimisations
+FFTW_COMMON_CONF_OPTS += $(if $(BR2_PACKAGE_FFTW_USE_SSE),--enable,--disable)-sse
+FFTW_COMMON_CONF_OPTS += $(if $(BR2_PACKAGE_FFTW_USE_SSE2),--enable,--disable)-sse2
+
+# ARM optimisations
+FFTW_COMMON_CONF_OPTS += $(if $(BR2_PACKAGE_FFTW_USE_NEON),--enable,--disable)-neon
+FFTW_COMMON_CFLAGS += $(if $(BR2_PACKAGE_FFTW_USE_NEON),-mfpu=neon)
+
+# Generic optimisations
+ifeq ($(BR2_TOOLCHAIN_HAS_THREADS),y)
+FFTW_COMMON_CONF_OPTS += --enable-threads
+FFTW_COMMON_CONF_OPTS += $(if $(BR2_GCC_ENABLE_OPENMP),--without,--with)-combined-threads
+else
+FFTW_COMMON_CONF_OPTS += --disable-threads
+endif
+FFTW_COMMON_CONF_OPTS += $(if $(BR2_GCC_ENABLE_OPENMP),--enable,--disable)-openmp
+
+FFTW_COMMON_CONF_OPTS += CFLAGS="$(FFTW_COMMON_CFLAGS)"
+
diff --git a/package/fftw/fftw.mk b/package/fftw/fftw.mk
index 5bd39a8..c33278f 100644
--- a/package/fftw/fftw.mk
+++ b/package/fftw/fftw.mk
@@ -4,46 +4,5 @@
 #
 ################################################################################
 
-FFTW_VERSION = 3.3.4
-FFTW_SITE = http://www.fftw.org
-FFTW_INSTALL_STAGING = YES
-FFTW_LICENSE = GPLv2+
-FFTW_LICENSE_FILES = COPYING
-
-# fortran support only enables generation and installation of fortran sources
-ifeq ($(BR2_TOOLCHAIN_HAS_FORTRAN),y)
-FFTW_CONF_OPTS += --enable-fortran
-FFTW_CONF_ENV += FLIBS="-lgfortran -lm"
-else
-FFTW_CONF_OPTS += --disable-fortran
-endif
-
-FFTW_CONF_OPTS += $(if $(BR2_PACKAGE_FFTW_PRECISION_SINGLE),--enable,--disable)-single
-FFTW_CONF_OPTS += $(if $(BR2_PACKAGE_FFTW_PRECISION_LONG_DOUBLE),--enable,--disable)-long-double
-FFTW_CONF_OPTS += $(if $(BR2_PACKAGE_FFTW_PRECISION_QUAD),--enable,--disable)-quad-precision
-
-FFTW_CFLAGS = $(TARGET_CFLAGS)
-ifeq ($(BR2_PACKAGE_FFTW_FAST),y)
-FFTW_CFLAGS += -O3 -ffast-math
-endif
-
-# x86 optimisations
-FFTW_CONF_OPTS += $(if $(BR2_PACKAGE_FFTW_USE_SSE),--enable,--disable)-sse
-FFTW_CONF_OPTS += $(if $(BR2_PACKAGE_FFTW_USE_SSE2),--enable,--disable)-sse2
-
-# ARM optimisations
-FFTW_CONF_OPTS += $(if $(BR2_PACKAGE_FFTW_USE_NEON),--enable,--disable)-neon
-FFTW_CFLAGS += $(if $(BR2_PACKAGE_FFTW_USE_NEON),-mfpu=neon)
-
-# Generic optimisations
-ifeq ($(BR2_TOOLCHAIN_HAS_THREADS),y)
-FFTW_CONF_OPTS += --enable-threads
-FFTW_CONF_OPTS += $(if $(BR2_GCC_ENABLE_OPENMP),--without,--with)-combined-threads
-else
-FFTW_CONF_OPTS += --disable-threads
-endif
-FFTW_CONF_OPTS += $(if $(BR2_GCC_ENABLE_OPENMP),--enable,--disable)-openmp
-
-FFTW_CONF_OPTS += CFLAGS="$(FFTW_CFLAGS)"
-
-$(eval $(autotools-package))
+include package/fftw/fftw-common.mk
+include $(sort $(wildcard package/fftw/*/*.mk))
diff --git a/package/fftw/fftw/Config.in b/package/fftw/fftw/Config.in
new file mode 100644
index 0000000..a91d519
--- /dev/null
+++ b/package/fftw/fftw/Config.in
@@ -0,0 +1,7 @@
+config BR2_PACKAGE_FFTW
+	bool "fftw"
+	select BR2_PACKAGE_FFTW_USE_SSE2 if BR2_X86_CPU_HAS_SSE2
+	select BR2_PACKAGE_FFTW_USE_NEON if BR2_ARM_CPU_HAS_NEON && !BR2_ARM_SOFT_FLOAT && (BR2_cortex_a53 || BR2_aarch64)
+	help
+	  Compile fftw in double precision (the default), i.e. use 'double'
+	  for floating point type.
diff --git a/package/fftw/fftw/fftw.hash b/package/fftw/fftw/fftw.hash
new file mode 120000
index 0000000..3ee7ecb
--- /dev/null
+++ b/package/fftw/fftw/fftw.hash
@@ -0,0 +1 @@
+../fftw.hash
\ No newline at end of file
diff --git a/package/fftw/fftw/fftw.mk b/package/fftw/fftw/fftw.mk
new file mode 100644
index 0000000..f09d890
--- /dev/null
+++ b/package/fftw/fftw/fftw.mk
@@ -0,0 +1,21 @@
+################################################################################
+#
+# fftw
+#
+################################################################################
+
+FFTW_VERSION = $(FFTW_COMMON_VERSION)
+FFTW_SOURCE = fftw-$(FFTW_VERSION).tar.gz
+FFTW_SITE = $(FFTW_COMMON_SITE)
+FFTW_INSTALL_STAGING = $(FFTW_COMMON_INSTALL_STAGING)
+FFTW_LICENSE = $(FFTW_COMMON_LICENSE)
+FFTW_LICENSE_FILES = $(FFTW_COMMON_LICENSE_FILES)
+
+FFTW_CONF_ENV = $(FFTW_COMMON_CONF_ENV)
+
+FFTW_CONF_OPTS=$(subst enable-neon, disable-neon, $(FFTW_COMMON_CONF_OPTS))
+
+FFTW_CFLAGS = $(FFTW_COMMON_CFLAGS)
+
+
+$(eval $(autotools-package))
diff --git a/package/fftw/fftwf/Config.in b/package/fftw/fftwf/Config.in
new file mode 100644
index 0000000..1995fd1
--- /dev/null
+++ b/package/fftw/fftwf/Config.in
@@ -0,0 +1,8 @@
+config BR2_PACKAGE_FFTWF
+	bool "fftwf"
+	select BR2_PACKAGE_FFTW_USE_SSE if BR2_X86_CPU_HAS_SSE
+	select BR2_PACKAGE_FFTW_USE_SSE2 if BR2_X86_CPU_HAS_SSE2
+	select BR2_PACKAGE_FFTW_USE_NEON if BR2_ARM_CPU_HAS_NEON && !BR2_ARM_SOFT_FLOAT
+	help
+	  Compile fftw in single precision, i.e. use 'float' for floating
+	  point type.
diff --git a/package/fftw/fftwf/fftwf.hash b/package/fftw/fftwf/fftwf.hash
new file mode 120000
index 0000000..3ee7ecb
--- /dev/null
+++ b/package/fftw/fftwf/fftwf.hash
@@ -0,0 +1 @@
+../fftw.hash
\ No newline at end of file
diff --git a/package/fftw/fftwf/fftwf.mk b/package/fftw/fftwf/fftwf.mk
new file mode 100644
index 0000000..c4f5182
--- /dev/null
+++ b/package/fftw/fftwf/fftwf.mk
@@ -0,0 +1,21 @@
+################################################################################
+#
+# fftwf
+#
+################################################################################
+
+FFTWF_VERSION = $(FFTW_COMMON_VERSION)
+FFTWF_SOURCE = fftw-$(FFTWF_VERSION).tar.gz
+FFTWF_SITE = $(FFTW_COMMON_SITE)
+FFTWF_INSTALL_STAGING = $(FFTW_COMMON_INSTALL_STAGING)
+FFTWF_LICENSE = $(FFTW_COMMON_LICENSE)
+FFTWF_LICENSE_FILES = $(FFTW_COMMON_LICENSE_FILES)
+
+FFTWF_CONF_ENV = $(FFTW_COMMON_CONF_ENV)
+
+FFTWF_CONF_OPTS = $(FFTW_COMMON_CONF_OPTS)
+FFTWF_CONF_OPTS += --enable-single
+
+FFTWF_CFLAGS = $(FFTW_COMMON_CFLAGS)
+
+$(eval $(autotools-package))
diff --git a/package/fftw/fftwl/Config.in b/package/fftw/fftwl/Config.in
new file mode 100644
index 0000000..2c791e1
--- /dev/null
+++ b/package/fftw/fftwl/Config.in
@@ -0,0 +1,8 @@
+config BR2_PACKAGE_FFTWL
+	bool "fftwl"
+	# long-double precision require long-double trigonometric routines
+	depends on !(BR2_TOOLCHAIN_BUILDROOT_UCLIBC && \
+		(BR2_arm || BR2_mips || BR2_mipsel))
+	help
+	  Compile fftw in long double precision, i.e. use 'long double'
+	  for floating point type.
diff --git a/package/fftw/fftwl/fftwl.hash b/package/fftw/fftwl/fftwl.hash
new file mode 120000
index 0000000..3ee7ecb
--- /dev/null
+++ b/package/fftw/fftwl/fftwl.hash
@@ -0,0 +1 @@
+../fftw.hash
\ No newline at end of file
diff --git a/package/fftw/fftwl/fftwl.mk b/package/fftw/fftwl/fftwl.mk
new file mode 100644
index 0000000..150a958
--- /dev/null
+++ b/package/fftw/fftwl/fftwl.mk
@@ -0,0 +1,21 @@
+################################################################################
+#
+# fftwl
+#
+################################################################################
+
+FFTWL_VERSION = $(FFTW_COMMON_VERSION)
+FFTWL_SOURCE = fftw-$(FFTWL_VERSION).tar.gz
+FFTWL_SITE = $(FFTW_COMMON_SITE)
+FFTWL_INSTALL_STAGING = $(FFTW_COMMON_INSTALL_STAGING)
+FFTWL_LICENSE = $(FFTW_COMMON_LICENSE)
+FFTWL_LICENSE_FILES = $(FFTW_COMMON_LICENSE_FILES)
+
+FFTWL_CONF_ENV = $(FFTW_COMMON_CONF_ENV)
+
+FFTWL_CONF_OPTS=$(subst enable-neon, disable-neon, $(FFTW_COMMON_CONF_OPTS))
+FFTWL_CONF_OPTS += --enable-long-double
+
+FFTWL_CFLAGS = $(FFTW_COMMON_CFLAGS)
+
+$(eval $(autotools-package))
diff --git a/package/fftw/fftwq/Config.in b/package/fftw/fftwq/Config.in
new file mode 100644
index 0000000..2811701
--- /dev/null
+++ b/package/fftw/fftwq/Config.in
@@ -0,0 +1,7 @@
+config BR2_PACKAGE_FFTWQ
+	bool "fftwq"
+	# quad-precision needs to have a gcc with libquadmath
+	depends on (BR2_i386 || BR2_x86_64) && BR2_USE_WCHAR
+	help
+	  Compile fftw in quadruple precision, i.e. use '__float128' for
+	  floating point type.
diff --git a/package/fftw/fftwq/fftwq.hash b/package/fftw/fftwq/fftwq.hash
new file mode 120000
index 0000000..3ee7ecb
--- /dev/null
+++ b/package/fftw/fftwq/fftwq.hash
@@ -0,0 +1 @@
+../fftw.hash
\ No newline at end of file
diff --git a/package/fftw/fftwq/fftwq.mk b/package/fftw/fftwq/fftwq.mk
new file mode 100644
index 0000000..a53a91d
--- /dev/null
+++ b/package/fftw/fftwq/fftwq.mk
@@ -0,0 +1,21 @@
+################################################################################
+#
+# fftwq
+#
+################################################################################
+
+FFTWQ_VERSION = $(FFTW_COMMON_VERSION)
+FFTWQ_SOURCE = fftw-$(FFTWQ_VERSION).tar.gz
+FFTWQ_SITE = $(FFTW_COMMON_SITE)
+FFTWQ_INSTALL_STAGING = $(FFTW_COMMON_INSTALL_STAGING)
+FFTWQ_LICENSE = $(FFTW_COMMON_LICENSE)
+FFTWQ_LICENSE_FILES = $(FFTW_COMMON_LICENSE_FILES)
+
+FFTWQ_CONF_ENV = $(FFTW_COMMON_CONF_ENV)
+
+FFTWQ_CONF_OPTS=$(subst enable-neon, disable-neon, $(FFTW_COMMON_CONF_OPTS))
+FFTWQ_CONF_OPTS += --enable-quad-precision
+
+FFTWQ_CFLAGS = $(FFTW_COMMON_CFLAGS)
+
+$(eval $(autotools-package))
diff --git a/package/gnuradio/Config.in b/package/gnuradio/Config.in
index 50f5e7f..b07831d 100644
--- a/package/gnuradio/Config.in
+++ b/package/gnuradio/Config.in
@@ -68,9 +68,9 @@ config BR2_PACKAGE_GNURADIO_UTILS
 	  Misc python utilities
 
 comment "gr-fft, -filter, -analog, -channels, -digital, -trellis, -pager, -qtgui depends fftw's single precision"
-	depends on !BR2_PACKAGE_FFTW_PRECISION_SINGLE
+	depends on !BR2_PACKAGE_FFTWF
 
-if BR2_PACKAGE_FFTW_PRECISION_SINGLE
+if BR2_PACKAGE_FFTWF
 
 config BR2_PACKAGE_GNURADIO_ANALOG
 	bool "gr-analog support"
diff --git a/package/gnuradio/gnuradio.mk b/package/gnuradio/gnuradio.mk
index 972f7a4..045a112 100644
--- a/package/gnuradio/gnuradio.mk
+++ b/package/gnuradio/gnuradio.mk
@@ -95,7 +95,7 @@ GNURADIO_CONF_OPTS += -DENABLE_GR_FEC=OFF
 endif
 
 ifeq ($(BR2_PACKAGE_GNURADIO_FFT),y)
-GNURADIO_DEPENDENCIES += fftw
+GNURADIO_DEPENDENCIES += fftwf
 GNURADIO_CONF_OPTS += -DENABLE_GR_FFT=ON
 else
 GNURADIO_CONF_OPTS += -DENABLE_GR_FFT=OFF
diff --git a/package/liquid-dsp/liquid-dsp.mk b/package/liquid-dsp/liquid-dsp.mk
index b5fb44c..921d97d 100644
--- a/package/liquid-dsp/liquid-dsp.mk
+++ b/package/liquid-dsp/liquid-dsp.mk
@@ -30,7 +30,7 @@ LIQUID_DSP_CFLAGS += -ffast-math
 endif
 
 # use FFTW instead of built-in FFT
-ifeq ($(BR2_PACKAGE_FFTW_PRECISION_SINGLE),y)
+ifeq ($(BR2_PACKAGE_FFTWF),y)
 LIQUID_DSP_LDFLAGS += -lfftw3f
 endif
 
@@ -39,14 +39,18 @@ ifeq ($(BR2_powerpc)$(BR2_powerpc64),y)
 LIQUID_DSP_CONF_OPTS += --enable-simdoverride
 endif
 
-ifeq ($(BR2_PACKAGE_FFTW_PRECISION_DOUBLE),y)
+ifeq ($(BR2_PACKAGE_FFTW),y)
 LIQUID_DSP_LDFLAGS += -lfftw3
 endif
 
-ifeq ($(BR2_PACKAGE_FFTW_PRECISION_LONG_DOUBLE),y)
+ifeq ($(BR2_PACKAGE_FFTWL),y)
 LIQUID_DSP_LDFLAGS += -lfftw3l
 endif
 
+ifeq ($(BR2_PACKAGE_FFTWQ),y)
+LIQUID_DSP_LDFLAGS += -lfftw3q
+endif
+
 LIQUID_DSP_CONF_OPTS += \
 	CFLAGS="$(LIQUID_DSP_CFLAGS)" \
 	LDFLAGS="$(LIQUID_DSP_LDFLAGS)"
-- 
2.7.4

[Buildroot] [PATCH 2/3] package/fftw : Allow all precisions to be installed at the same time.

[Thomas Petazzoni]

Hello,

Why is this patch part of the patch series about adding support for
Cortex-A53 and other ARM related details? They should be independent.

Several other comments below. It's a pretty complicated change you are
doing here, it will most likely take several iterations to get
everything right and in good shape. Let me know if you need
help/assistance.

On Tue, 23 Aug 2016 10:53:22 +1000, Matt Flax wrote:
> This updates the current fftw package to allow the installation and selection
> of one more of the fftw precisions onto the system. Previously, you could
> only choose one prevision at a time, however there are many use cases where
> different precisions are required on the same system. Further, various packages
> selected BR2_PACKAGE_FFTW assuming the double precision version would be
> compile, which was a buggy assumption.
> 
> Following previous suggestions and discussions, a common fftw mk file is used.
> The hash file is symbolically linked against. To preserve the previous behavior,
> if BR2_PACKAGE_FFTW is selected, this defaults to the double precision version.
> Other available precisions are now BR2_PACKAGE_FFTWF, BR2_PACKAGE_FFTWL,
> BR2_PACKAGE_FFTWQ which is the fftw standard for singe, long double and quad
> precisions.

I believe you should keep a top-level BR2_PACKAGE_FFTW option, and then
as sub-options have the four packages named:

	fftw-double
	fftw-single
	fftw-quad
	fftw-long-double

with the corresponding sub-options.

If you want to preserve backward compatibility, you can add:

config BR2_PACKAGE_FFTW
	bool "fftw"
	select BR2_PACKAGE_FFTW_DOUBLE if \
		!BR2_PACKAGE_FFTW_SINGLE && \
		!BR2_PACKAGE_FFTW_QUAD && \
		!BR2_PACKAGE_FFTW_LONG_DOUBLE


> The following packages have been updated : liquid-dsp, gnuradio
> These packages required single precision installations.
> Other packages : libvips, pulseaudio, httping, imagemagick, alsa-utils
> implicitly required double precision without enforcing it, merely assuming
> this would happen by default. This was not the case when the user selected a
> different precision.

If they require double precision, then they should be updated to:

	select BR2_PACKAGE_FFTW
	select BR2_PACKAGE_FFTW_DOUBLE

and their <pkg>_DEPENDENCIES variable should be changed to depend on
fftw-double.

>  package/fftw/Config.in           | 69 +++++++---------------------------------
>  package/fftw/fftw-common.mk      | 44 +++++++++++++++++++++++++
>  package/fftw/fftw.mk             | 45 ++------------------------

In fact, put the contents of fftw-common.mk directly in fftw.mk.

>  package/fftw/fftw/Config.in      |  7 ++++
>  package/fftw/fftw/fftw.hash      |  1 +
>  package/fftw/fftw/fftw.mk        | 21 ++++++++++++

Having the naming proposed above will clarify things since we will no
longer have two fftw.mk files.

>  config BR2_PACKAGE_FFTW_USE_SSE
> -	bool
> +	bool "use SSE"
> +	depends on BR2_X86_CPU_HAS_SSE
>  
>  config BR2_PACKAGE_FFTW_USE_SSE2
> -	bool
> +	bool "use SSE2"
> +	depends on BR2_X86_CPU_HAS_SSE
>  
>  config BR2_PACKAGE_FFTW_USE_NEON
> -	bool

Please don't make this prompt options. Instead, add a first patch that
simply removes them, they are unnecessary. Just do:

ifeq ($(BR2_X86_CPU_HAS_SSE),y)
FFTW_CONF_OPTS += --enable-sse
else
FFTW_CONF_OPTS += --disable-sse
endif

ifeq ($(BR2_X86_CPU_HAS_SSE2),y)
FFTW_CONF_OPTS += --enable-sse2
else
FFTW_CONF_OPTS += --disable-sse2
endif

ifeq ($(BR2_ARM_CPU_HAS_NEON):$(BR2_ARM_SOFT_FLOAT),y:)
FFTW_CONF_OPTS += --enable-neon
FFTW_CFLAGS += -mfpu=neon
else
FFTW_CONF_OPTS += --disable-neon
endif

But please do this in a *separate* patch, prior to the fftw package
split.

> -config BR2_PACKAGE_FFTW_PRECISION_LONG_DOUBLE
> -	bool "long double"
> -	# long-double precision require long-double trigonometric routines
> -	depends on !(BR2_TOOLCHAIN_BUILDROOT_UCLIBC && \
> -		(BR2_arm || BR2_mips || BR2_mipsel))

Not your fault, but this BR2_TOOLCHAIN_BUILDROOT_UCLIBC dependency is
wrong: it should use BR2_TOOLCHAIN_USES_UCLIBC. I'll send a patch
fixing that, as it's also a bug on master.

> +FFTW_COMMON_CFLAGS = $(TARGET_CFLAGS)
> +ifeq ($(BR2_PACKAGE_FFTW_COMMON_FAST),y)

This option doesn't exist anywhere, it's still named
BR2_PACKAGE_FFTW_FAST in your code:

Config.in:config BR2_PACKAGE_FFTW_FAST
fftw-common.mk:ifeq ($(BR2_PACKAGE_FFTW_COMMON_FAST),y)

I think the name BR2_PACKAGE_FFTW_FAST is good.

> +# Generic optimisations
> +ifeq ($(BR2_TOOLCHAIN_HAS_THREADS),y)
> +FFTW_COMMON_CONF_OPTS += --enable-threads
> +FFTW_COMMON_CONF_OPTS += $(if $(BR2_GCC_ENABLE_OPENMP),--without,--with)-combined-threads
> +else
> +FFTW_COMMON_CONF_OPTS += --disable-threads
> +endif
> +FFTW_COMMON_CONF_OPTS += $(if $(BR2_GCC_ENABLE_OPENMP),--enable,--disable)-openmp
> +
> +FFTW_COMMON_CONF_OPTS += CFLAGS="$(FFTW_COMMON_CFLAGS)"

This last line is also wrong (but not your fault). Could you introduce
another preliminary patch that changes it to:

FFTW_CONF_ENV += CFLAGS="$(TARGET_CFLAGS) $(FFTW_CFLAGS)"

that's the proper way of passing additional CFLAGS.

> diff --git a/package/fftw/fftw/Config.in b/package/fftw/fftw/Config.in
> new file mode 100644
> index 0000000..a91d519
> --- /dev/null
> +++ b/package/fftw/fftw/Config.in
> @@ -0,0 +1,7 @@
> +config BR2_PACKAGE_FFTW
> +	bool "fftw"
> +	select BR2_PACKAGE_FFTW_USE_SSE2 if BR2_X86_CPU_HAS_SSE2
> +	select BR2_PACKAGE_FFTW_USE_NEON if BR2_ARM_CPU_HAS_NEON && !BR2_ARM_SOFT_FLOAT && (BR2_cortex_a53 || BR2_aarch64)

Please get rid of those selects, and don't handle the
Cortex-A53/AArch64 question in the same patch. This patch should *only*
do the package split. All other changes should be in separate patches
(but submitted all in the same series).

> +FFTW_VERSION = $(FFTW_COMMON_VERSION)
> +FFTW_SOURCE = fftw-$(FFTW_VERSION).tar.gz
> +FFTW_SITE = $(FFTW_COMMON_SITE)
> +FFTW_INSTALL_STAGING = $(FFTW_COMMON_INSTALL_STAGING)
> +FFTW_LICENSE = $(FFTW_COMMON_LICENSE)
> +FFTW_LICENSE_FILES = $(FFTW_COMMON_LICENSE_FILES)
> +
> +FFTW_CONF_ENV = $(FFTW_COMMON_CONF_ENV)
> +
> +FFTW_CONF_OPTS=$(subst enable-neon, disable-neon, $(FFTW_COMMON_CONF_OPTS))

Why are you doing this?

> +
> +FFTW_CFLAGS = $(FFTW_COMMON_CFLAGS)

This line has no effect.

> diff --git a/package/fftw/fftwf/Config.in b/package/fftw/fftwf/Config.in
> new file mode 100644
> index 0000000..1995fd1
> --- /dev/null
> +++ b/package/fftw/fftwf/Config.in
> @@ -0,0 +1,8 @@
> +config BR2_PACKAGE_FFTWF
> +	bool "fftwf"
> +	select BR2_PACKAGE_FFTW_USE_SSE if BR2_X86_CPU_HAS_SSE
> +	select BR2_PACKAGE_FFTW_USE_SSE2 if BR2_X86_CPU_HAS_SSE2
> +	select BR2_PACKAGE_FFTW_USE_NEON if BR2_ARM_CPU_HAS_NEON && !BR2_ARM_SOFT_FLOAT

Drop all those selects, see what I suggested above to handle
SSE/SSE2/NEON.

> +FFTWQ_CONF_OPTS=$(subst enable-neon, disable-neon, $(FFTW_COMMON_CONF_OPTS))

Why?

> diff --git a/package/gnuradio/Config.in b/package/gnuradio/Config.in
> index 50f5e7f..b07831d 100644
> --- a/package/gnuradio/Config.in
> +++ b/package/gnuradio/Config.in
> @@ -68,9 +68,9 @@ config BR2_PACKAGE_GNURADIO_UTILS
>  	  Misc python utilities
>  
>  comment "gr-fft, -filter, -analog, -channels, -digital, -trellis, -pager, -qtgui depends fftw's single precision"
> -	depends on !BR2_PACKAGE_FFTW_PRECISION_SINGLE
> +	depends on !BR2_PACKAGE_FFTWF

We should now replace this dependency with a select. We had to use a
"depends on" because you can't select "choice" entries. Now that we
have separate packages for the various precisions, we should use this
capability and simplify things by using a select. So basically, remove
the if BR2_PACKAGE_FFTW_PRECISION_SINGLE condition, and make the
BR2_PACKAGE_GNURADIO_FFT option:

	select BR2_PACKAGE_FFTW
	select BR2_PACKAGE_FFTW_SINGLE

>  # use FFTW instead of built-in FFT
> -ifeq ($(BR2_PACKAGE_FFTW_PRECISION_SINGLE),y)
> +ifeq ($(BR2_PACKAGE_FFTWF),y)
>  LIQUID_DSP_LDFLAGS += -lfftw3f
>  endif
>  
> @@ -39,14 +39,18 @@ ifeq ($(BR2_powerpc)$(BR2_powerpc64),y)
>  LIQUID_DSP_CONF_OPTS += --enable-simdoverride
>  endif
>  
> -ifeq ($(BR2_PACKAGE_FFTW_PRECISION_DOUBLE),y)
> +ifeq ($(BR2_PACKAGE_FFTW),y)
>  LIQUID_DSP_LDFLAGS += -lfftw3
>  endif
>  
> -ifeq ($(BR2_PACKAGE_FFTW_PRECISION_LONG_DOUBLE),y)
> +ifeq ($(BR2_PACKAGE_FFTWL),y)
>  LIQUID_DSP_LDFLAGS += -lfftw3l
>  endif
>  
> +ifeq ($(BR2_PACKAGE_FFTWQ),y)
> +LIQUID_DSP_LDFLAGS += -lfftw3q
> +endif

What happens if several fftw implementation are selected? We will pass
-lfftw3 -lfftw3f -lfftw3l -lfftw3q as LDFLAGS. Is this correct? Is this
useful? Should those case be mutually exclusive instead?

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH 3/3] arch/arm: Add ARMV8 (aarch32) toolchain config.

[Matt Flax]

This commit configures the toolchain to use the ARMV8 hardware features.
This commit also cleans up and adds to the previous cortex-a53 commit.

This commit adds BR2_ARM_CPU_HAS_ARMV8 to arch/Config.in.arm and cleans up
the BR2_cortex_a53 config to remove redundant selections relating to VFPV4 and
ARMV7A. The commit also adds BR2_ARM_CPU_HAS_ARMV8 to BR2_ARM_EABIHF which
allows the selection of hard float (HF) activating the toolchain for whatever
specific ARMV8 hardware features are possible. It also adds the
BR2_ARM_FPU_NEON_ARMV8 HF tuning (crypto-neon-fp-armv8).

The cortex-a53 BR2_ARCH_HAS_MMU_OPTIONAL selection ensures that uclibc successfully
compiles without non-compliant swp assembly calls.

Signed-off-by: Matt Flax <flatmax@flatmax.org>
---
 arch/Config.in.arm | 17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/arch/Config.in.arm b/arch/Config.in.arm
index 72bb744..c01daf6 100644
--- a/arch/Config.in.arm
+++ b/arch/Config.in.arm
@@ -31,6 +31,9 @@ config BR2_ARM_CPU_HAS_VFPV4
 	bool
 	select BR2_ARM_CPU_HAS_VFPV3
 
+config BR2_ARM_CPU_HAS_ARMV8
+	bool
+
 config BR2_ARM_CPU_HAS_ARM
 	bool
 
@@ -174,8 +177,7 @@ config BR2_cortex_a53
 	bool "cortex-A53"
 	select BR2_ARM_CPU_HAS_ARM
 	select BR2_ARM_CPU_HAS_NEON
-	select BR2_ARM_CPU_HAS_VFPV4
-	select BR2_ARM_CPU_ARMV7A
+	select BR2_ARM_CPU_HAS_ARMV8
 	select BR2_ARCH_HAS_MMU_OPTIONAL
 config BR2_cortex_m3
 	bool "cortex-M3"
@@ -271,7 +273,7 @@ config BR2_ARM_EABI
 
 config BR2_ARM_EABIHF
 	bool "EABIhf"
-	depends on BR2_ARM_CPU_HAS_VFPV2
+	depends on BR2_ARM_CPU_HAS_VFPV2 || BR2_ARM_CPU_HAS_ARMV8
 	help
 	  The EABIhf is an extension of EABI which supports the 'hard'
 	  floating point model. This model uses the floating point
@@ -292,6 +294,7 @@ endchoice
 choice
 	prompt "Floating point strategy"
 	depends on BR2_ARM_EABI || BR2_ARM_EABIHF
+	default BR2_ARM_FPU_NEON_ARMV8 if BR2_ARM_CPU_HAS_ARMV8
 	default BR2_ARM_FPU_VFPV4D16 if BR2_ARM_CPU_HAS_VFPV4
 	default BR2_ARM_FPU_VFPV3D16 if BR2_ARM_CPU_HAS_VFPV3
 	default BR2_ARM_FPU_VFPV2 if BR2_ARM_CPU_HAS_VFPV2
@@ -366,6 +369,13 @@ config BR2_ARM_FPU_VFPV4
 	  cores, including the earlier Cortex-A{8, 9}, you should
 	  instead select VFPv3.
 
+config BR2_ARM_FPU_NEON_ARMV8
+	bool "ARMV8"
+	depends on BR2_ARM_CPU_HAS_ARMV8
+	help
+	  This option allows to use the ARMV8 floating point unit, as
+	  available in some ARMv8 processors (Cortex-A53).
+
 config BR2_ARM_FPU_VFPV4D16
 	bool "VFPv4-D16"
 	depends on BR2_ARM_CPU_HAS_VFPV4
@@ -485,6 +495,7 @@ config BR2_GCC_TARGET_FPU
 	default "vfpv4-d16" 	if BR2_ARM_FPU_VFPV4D16
 	default "neon" 		if BR2_ARM_FPU_NEON
 	default "neon-vfpv4" 	if BR2_ARM_FPU_NEON_VFPV4
+	default "crypto-neon-fp-armv8" 	if BR2_ARM_FPU_NEON_ARMV8
 
 config BR2_GCC_TARGET_FLOAT_ABI
 	default "soft"		if BR2_ARM_SOFT_FLOAT
-- 
2.7.4

[Buildroot] [PATCH 3/3] arch/arm: Add ARMV8 (aarch32) toolchain config.

[Matt Flax]

This commit configures the toolchain to use the ARMV8 hardware features.
This commit also cleans up and adds to the previous cortex-a53 commit.

This commit adds BR2_ARM_CPU_HAS_ARMV8 to arch/Config.in.arm and cleans up
the BR2_cortex_a53 config to remove redundant selections relating to VFPV4 and
ARMV7A. The commit also adds BR2_ARM_CPU_HAS_ARMV8 to BR2_ARM_EABIHF which
allows the selection of hard float (HF) activating the toolchain for whatever
specific ARMV8 hardware features are possible. It also adds the
BR2_ARM_FPU_NEON_ARMV8 HF tuning (crypto-neon-fp-armv8).

The cortex-a53 BR2_ARCH_HAS_MMU_OPTIONAL selection ensures that uclibc successfully
compiles without non-compliant swp assembly calls.

Signed-off-by: Matt Flax <flatmax@flatmax.org>
---
 arch/Config.in.arm | 17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/arch/Config.in.arm b/arch/Config.in.arm
index 72bb744..c01daf6 100644
--- a/arch/Config.in.arm
+++ b/arch/Config.in.arm
@@ -31,6 +31,9 @@ config BR2_ARM_CPU_HAS_VFPV4
 	bool
 	select BR2_ARM_CPU_HAS_VFPV3
 
+config BR2_ARM_CPU_HAS_ARMV8
+	bool
+
 config BR2_ARM_CPU_HAS_ARM
 	bool
 
@@ -174,8 +177,7 @@ config BR2_cortex_a53
 	bool "cortex-A53"
 	select BR2_ARM_CPU_HAS_ARM
 	select BR2_ARM_CPU_HAS_NEON
-	select BR2_ARM_CPU_HAS_VFPV4
-	select BR2_ARM_CPU_ARMV7A
+	select BR2_ARM_CPU_HAS_ARMV8
 	select BR2_ARCH_HAS_MMU_OPTIONAL
 config BR2_cortex_m3
 	bool "cortex-M3"
@@ -271,7 +273,7 @@ config BR2_ARM_EABI
 
 config BR2_ARM_EABIHF
 	bool "EABIhf"
-	depends on BR2_ARM_CPU_HAS_VFPV2
+	depends on BR2_ARM_CPU_HAS_VFPV2 || BR2_ARM_CPU_HAS_ARMV8
 	help
 	  The EABIhf is an extension of EABI which supports the 'hard'
 	  floating point model. This model uses the floating point
@@ -292,6 +294,7 @@ endchoice
 choice
 	prompt "Floating point strategy"
 	depends on BR2_ARM_EABI || BR2_ARM_EABIHF
+	default BR2_ARM_FPU_NEON_ARMV8 if BR2_ARM_CPU_HAS_ARMV8
 	default BR2_ARM_FPU_VFPV4D16 if BR2_ARM_CPU_HAS_VFPV4
 	default BR2_ARM_FPU_VFPV3D16 if BR2_ARM_CPU_HAS_VFPV3
 	default BR2_ARM_FPU_VFPV2 if BR2_ARM_CPU_HAS_VFPV2
@@ -366,6 +369,13 @@ config BR2_ARM_FPU_VFPV4
 	  cores, including the earlier Cortex-A{8, 9}, you should
 	  instead select VFPv3.
 
+config BR2_ARM_FPU_NEON_ARMV8
+	bool "ARMV8"
+	depends on BR2_ARM_CPU_HAS_ARMV8
+	help
+	  This option allows to use the ARMV8 floating point unit, as
+	  available in some ARMv8 processors (Cortex-A53).
+
 config BR2_ARM_FPU_VFPV4D16
 	bool "VFPv4-D16"
 	depends on BR2_ARM_CPU_HAS_VFPV4
@@ -485,6 +495,7 @@ config BR2_GCC_TARGET_FPU
 	default "vfpv4-d16" 	if BR2_ARM_FPU_VFPV4D16
 	default "neon" 		if BR2_ARM_FPU_NEON
 	default "neon-vfpv4" 	if BR2_ARM_FPU_NEON_VFPV4
+	default "crypto-neon-fp-armv8" 	if BR2_ARM_FPU_NEON_ARMV8
 
 config BR2_GCC_TARGET_FLOAT_ABI
 	default "soft"		if BR2_ARM_SOFT_FLOAT
-- 
2.7.4

[Buildroot] [PATCH 3/3] arch/arm: Add ARMV8 (aarch32) toolchain config.

[Thomas Petazzoni]

Hello,

On Mon, 22 Aug 2016 20:12:28 +1000, Matt Flax wrote:

> @@ -174,8 +177,7 @@ config BR2_cortex_a53
>  	bool "cortex-A53"

It seems like this patch makes the assumption the previous Cortex-A53
patch has been applied.

Could you instead send a patch series that includes both patches
together. Don't *merge* the patches, just send them together in the
same series. It will also be less confusing than this standalone patch
labeled PATCH 3/3.

Also, I believe we need to merge arch/Config.in.aarch64 back into
arch/Config.in.arm in order to handle both 32 bits and 64 bits ARM
cores in the same Config.in.arm file, like we're doing for
Config.in.x86. Otherwise, we will end up duplicating all the ARM core
definitions for the 64 bits capable ones.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH 3/3] arch/arm: Add ARMV8 (aarch32) toolchain config.

[Matt Flax]

OK, will do.

I understand the difficulty in getting ARMV8 setup for both aarch32 and 
aarch64 and appreciate your openness to making that happen.


Matt


On 23/08/16 00:36, Thomas Petazzoni wrote:
> Hello,
>
> On Mon, 22 Aug 2016 20:12:28 +1000, Matt Flax wrote:
>
>> @@ -174,8 +177,7 @@ config BR2_cortex_a53
>>   	bool "cortex-A53"
> It seems like this patch makes the assumption the previous Cortex-A53
> patch has been applied.
>
> Could you instead send a patch series that includes both patches
> together. Don't *merge* the patches, just send them together in the
> same series. It will also be less confusing than this standalone patch
> labeled PATCH 3/3.
>
> Also, I believe we need to merge arch/Config.in.aarch64 back into
> arch/Config.in.arm in order to handle both 32 bits and 64 bits ARM
> cores in the same Config.in.arm file, like we're doing for
> Config.in.x86. Otherwise, we will end up duplicating all the ARM core
> definitions for the 64 bits capable ones.
>
> Thanks!
>
> Thomas