Re: [Buildroot] [PATCH 02/28] configs/acmesystems_acqua_a5_512mb_defconfig: enable NEON/VFPV4 FPU strategy

[Edgar Bonet <bonet@grenoble.cnrs.fr>]

Hi!

[Replying to list only, hoping it is the right etiquette.]

Giulio Benetti wrote:
> --- a/configs/acmesystems_acqua_a5_512mb_defconfig
> +++ b/configs/acmesystems_acqua_a5_512mb_defconfig
> @@ -1,6 +1,7 @@
>  BR2_arm=y
>  BR2_cortex_a5=y
>  BR2_ARM_ENABLE_VFP=y
> +BR2_ARM_FPU_NEON_VFPV4=y
>  BR2_ARM_INSTRUCTIONS_THUMB2=y
>  BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_5_4=y
>  BR2_SYSTEM_DHCP="eth0"

I think this may be missing some dependencies, as this change does not
survive `save defconfig'. I tried the following from a clean tree:

    git pull # from master
    git am ~/tmp/saved-patch.email  # the patch above
    make acmesystems_acqua_a5_512mb_defconfig
    make nconfig
        # no changes to configuration
        <F6> Save
        <F9> Exit
    make savedefconfig
    git diff

And git showed me that the patch had just been reverted on the worktree.
According to arch/Config.in.arm, BR2_ARM_FPU_NEON_VFPV4 depends on
BR2_ARM_CPU_HAS_NEON, which is not mentioned in my .config. It also
appears that BR2_ARM_ENABLE_NEON selects BR2_ARM_CPU_HAS_NEON. Would
BR2_ARM_ENABLE_NEON be the canonical way of making
BR2_ARM_FPU_NEON_VFPV4 acceptable? I am a bit confused by the VFP
selection logic in arch/Config.in.arm, so I am not sure that would be
the right approach.

As a follow up question, if this issue is fixed, what would be the
simplest way of testing the floating point implementation on the board?
I was thinking about adding gnuplot, which doesn't have any
dependencies, and having it do some computations. I do not know,
however, whether this would exercise the NEON SIMD extensions.

Best regards,

Edgar.
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot