* [Buildroot] [PATCH 0/3] arch/arm a53 + ARMV8, package/fftw rework @ 2016-08-23 0:53 Matt Flax 2016-08-23 0:53 ` [Buildroot] [PATCH 1/3] arch/arm: Add Cortex-a53 CPU Matt Flax ` (2 more replies) 0 siblings, 3 replies; 11+ messages in thread From: Matt Flax @ 2016-08-23 0:53 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [Buildroot] [PATCH 1/3] arch/arm: Add Cortex-a53 CPU 2016-08-23 0:53 [Buildroot] [PATCH 0/3] arch/arm a53 + ARMV8, package/fftw rework Matt Flax @ 2016-08-23 0:53 ` Matt Flax 2016-08-23 22:03 ` Thomas Petazzoni 2016-08-23 0:53 ` [Buildroot] [PATCH 2/3] package/fftw : Allow all precisions to be installed at the same time Matt Flax 2016-08-23 0:53 ` [Buildroot] [PATCH 3/3] arch/arm: Add ARMV8 (aarch32) toolchain config Matt Flax 2 siblings, 1 reply; 11+ messages in thread From: Matt Flax @ 2016-08-23 0:53 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* [Buildroot] [PATCH 1/3] arch/arm: Add Cortex-a53 CPU 2016-08-23 0:53 ` [Buildroot] [PATCH 1/3] arch/arm: Add Cortex-a53 CPU Matt Flax @ 2016-08-23 22:03 ` Thomas Petazzoni 2016-08-23 23:44 ` Matt Flax 0 siblings, 1 reply; 11+ messages in thread From: Thomas Petazzoni @ 2016-08-23 22:03 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [Buildroot] [PATCH 1/3] arch/arm: Add Cortex-a53 CPU 2016-08-23 22:03 ` Thomas Petazzoni @ 2016-08-23 23:44 ` Matt Flax 2016-08-24 21:20 ` Waldemar Brodkorb 2016-08-24 22:14 ` Thomas Petazzoni 0 siblings, 2 replies; 11+ messages in thread From: Matt Flax @ 2016-08-23 23:44 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [Buildroot] [PATCH 1/3] arch/arm: Add Cortex-a53 CPU 2016-08-23 23:44 ` Matt Flax @ 2016-08-24 21:20 ` Waldemar Brodkorb 2016-08-25 0:55 ` Matt Flax 2016-08-24 22:14 ` Thomas Petazzoni 1 sibling, 1 reply; 11+ messages in thread From: Waldemar Brodkorb @ 2016-08-24 21:20 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [Buildroot] [PATCH 1/3] arch/arm: Add Cortex-a53 CPU 2016-08-24 21:20 ` Waldemar Brodkorb @ 2016-08-25 0:55 ` Matt Flax 0 siblings, 0 replies; 11+ messages in thread From: Matt Flax @ 2016-08-25 0:55 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [Buildroot] [PATCH 1/3] arch/arm: Add Cortex-a53 CPU 2016-08-23 23:44 ` Matt Flax 2016-08-24 21:20 ` Waldemar Brodkorb @ 2016-08-24 22:14 ` Thomas Petazzoni 2016-08-25 0:25 ` Matt Flax 1 sibling, 1 reply; 11+ messages in thread From: Thomas Petazzoni @ 2016-08-24 22:14 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [Buildroot] [PATCH 1/3] arch/arm: Add Cortex-a53 CPU 2016-08-24 22:14 ` Thomas Petazzoni @ 2016-08-25 0:25 ` Matt Flax 0 siblings, 0 replies; 11+ messages in thread From: Matt Flax @ 2016-08-25 0:25 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [Buildroot] [PATCH 2/3] package/fftw : Allow all precisions to be installed at the same time. 2016-08-23 0:53 [Buildroot] [PATCH 0/3] arch/arm a53 + ARMV8, package/fftw rework Matt Flax 2016-08-23 0:53 ` [Buildroot] [PATCH 1/3] arch/arm: Add Cortex-a53 CPU Matt Flax @ 2016-08-23 0:53 ` Matt Flax 2016-08-23 21:32 ` Thomas Petazzoni 2016-08-23 0:53 ` [Buildroot] [PATCH 3/3] arch/arm: Add ARMV8 (aarch32) toolchain config Matt Flax 2 siblings, 1 reply; 11+ messages in thread From: Matt Flax @ 2016-08-23 0:53 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* [Buildroot] [PATCH 2/3] package/fftw : Allow all precisions to be installed at the same time. 2016-08-23 0:53 ` [Buildroot] [PATCH 2/3] package/fftw : Allow all precisions to be installed at the same time Matt Flax @ 2016-08-23 21:32 ` Thomas Petazzoni 0 siblings, 0 replies; 11+ messages in thread From: Thomas Petazzoni @ 2016-08-23 21:32 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [Buildroot] [PATCH 3/3] arch/arm: Add ARMV8 (aarch32) toolchain config. 2016-08-23 0:53 [Buildroot] [PATCH 0/3] arch/arm a53 + ARMV8, package/fftw rework Matt Flax 2016-08-23 0:53 ` [Buildroot] [PATCH 1/3] arch/arm: Add Cortex-a53 CPU Matt Flax 2016-08-23 0:53 ` [Buildroot] [PATCH 2/3] package/fftw : Allow all precisions to be installed at the same time Matt Flax @ 2016-08-23 0:53 ` Matt Flax 2 siblings, 0 replies; 11+ messages in thread From: Matt Flax @ 2016-08-23 0:53 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply related [flat|nested] 11+ messages in thread
end of thread, other threads:[~2016-08-25 0:55 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-08-23 0:53 [Buildroot] [PATCH 0/3] arch/arm a53 + ARMV8, package/fftw rework Matt Flax 2016-08-23 0:53 ` [Buildroot] [PATCH 1/3] arch/arm: Add Cortex-a53 CPU Matt Flax 2016-08-23 22:03 ` Thomas Petazzoni 2016-08-23 23:44 ` Matt Flax 2016-08-24 21:20 ` Waldemar Brodkorb 2016-08-25 0:55 ` Matt Flax 2016-08-24 22:14 ` Thomas Petazzoni 2016-08-25 0:25 ` Matt Flax 2016-08-23 0:53 ` [Buildroot] [PATCH 2/3] package/fftw : Allow all precisions to be installed at the same time Matt Flax 2016-08-23 21:32 ` Thomas Petazzoni 2016-08-23 0:53 ` [Buildroot] [PATCH 3/3] arch/arm: Add ARMV8 (aarch32) toolchain config Matt Flax
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.