Re: NetBSD/earm and evbearmv7hf on Cubieboard 2

[Richard Earnshaw <Richard.Earnshaw%foss.arm.com@localhost>]

On 20/07/15 14:26, Martin Husemann wrote:
> On Mon, Jul 20, 2015 at 02:14:23PM +0100, Robert Swindells wrote:
>> There isn't a definition for TEMP_FAILURE_RETRY but the code around
>> this is trying to read /proc/cpuinfo to find out if the CPU supports
>> neon. We just return an empty string for reads of /proc/cpuinfo on ARM
>> so this won't work correctly even with a definition for
>> TEMP_FAILURE_RETRY.
> 
> Patch it to use syctl machdep.neon_present = 1.
> 
>> There is similar code in graphics/libjpeg-turbo that needs a way of
>> detecting whether to use the neon versions of functions or not.
>>
>> It looks as if we don't define __ARM_NEON__ for earmv7hf which is one
>> of the things that libjpeg-turbo tests for.
> 
> Is it guaranteed that all armv7hf have NEON?
> 

It depends on what you, collectively as a community, want to require for
this platform.

There is some hardware out there that supports vfp-D16 (with no neon).
That's a legitimate implementation point in the architecture.  But it's
pretty rare as an implementation point.  Most v7-a HW out there now
supports full vfp-D32 with Neon.

It could be that you'd want to chose the earmv7hf platform to require
Neon.  That's a perfectly reasonable position to take: but it implies
that the small number of systems that come in slightly lower than that
would be force to use the soft-float ABI (perhaps with HW accelerated
library routines).

R.