[USRP-users] Compiling UHD Host Library: Problem Enabling ARM Neon Support

Philip Balister philip at balister.org
Fri Nov 10 06:52:31 EST 2017


On 11/10/2017 06:41 AM, Philip Balister via USRP-users wrote:
> On 11/10/2017 04:11 AM, Ron Economos via USRP-users wrote:
>> I guess this is a little late, but you can pass in compiler flags on the
>> command line with -DCMAKE_CXX_FLAGS. For example:
>>
>> cmake -DCMAKE_CXX_FLAGS:STRING="-mfloat-abi=hard -mfpu=neon
>> -mtune=cortex-a15" ../
> 
> That would be the preferred way. The patch mentioned assumes that
> anytime you are using a compiler with the neon.h header file, the SoC
> you are compiling for has a neon unit. This is a bad assumption. There
> are a few examples of SoC's around that do not have a neon unit. Now UHD
> will generate neon and create runtime failures.
> 
> Bottom line, in the ARM world, you cannot test compiler features to
> figure out what features the runtime system has.

Also, another quick look suggests neon for aarch64 is no longer built.

Philip


> 
> Philip
> 
> 
>>
>> Ron
>>
>> On 11/10/2017 12:07 AM, Gwenhael Goavec-Merou via USRP-users wrote:
>>> Hello,
>>>
>>> maybe this : https://github.com/EttusResearch/uhd/pull/135
>>> will help you
>>>
>>> Gwen
>>>
>>> On Fri, 10 Nov 2017 00:29:25 -0600
>>> Kevin McGuire via USRP-users <usrp-users at lists.ettus.com> wrote:
>>>
>>>> I was able to get the compiler flags passed in so that the check for
>>>> the header arm_neon.h passes. I added it to the CMakeList root file
>>>> with SET(CMAKE_CXX_FLAGS, "${CMAKE_CXX_FLAGS} -mfloat-abi=softfp
>>>> -mfpu=neon").
>>>>
>>>> Then, it would detect neon. However, I spent considerable time
>>>> cleaning up whatever package problems I had since I ended up with a
>>>> bunch of weird errors.
>>>>
>>>> Once I straightened my packages up (Debian), it is compiling with
>>>> neon! And, hopefully, it will actually use the ARM neon routines.
>>>>
>>>> On Thu, Nov 9, 2017 at 3:22 AM, Kevin McGuire <kmcg3413 at gmail.com>
>>>> wrote:
>>>>
>>>>> I have noticed that neon support for the converter is not enabling.
>>>>> The CMakeError.log has this output. I am not certain as I am not
>>>>> really familiar with ARM and NEON, but I checked my CPU and it does
>>>>> support it. Also, the error message below is saying it is just a
>>>>> matter of passing certain flags.
>>>>>
>>>>> /mnt/extra/usr/lib/gcc/arm-linux-gnueabihf/4.8/include/arm_neon.h:32:2:
>>>>> error: #error You must enable NEON instructions (e.g.
>>>>> -mfloat-abi=softfp -mfpu=neon) to use arm_neon.h
>>>>>   #error You must enable NEON instructions (e.g. -mfloat-abi=softfp
>>>>> -mfpu=neon) to use arm_neon.h
>>>>>
>>>>> Normally, I would just fix it myself and move forward, but me and
>>>>> CMake mix like oil and water. It is kind of embarrassing but I
>>>>> swear it never does what I want it do - such as adding a darn flag.
>>>>> I even tried to force the options, lol, and all be danged if CMake
>>>>> finds some way to error.
>>>>>
>>>>> Will work on this tomorrow, but if anyone has a solution I am all
>>>>> ears. If not then no problem and I will reply when I figure it out.
>>>>>
>>>>> This came about when I noticed what really seemed like abnormally
>>>>> high CPU usage on my ARM code for a simple shuffling of data out of
>>>>> the network packets. I traced what I felt like was the biggest
>>>>> possible hot spot to the converter routine. Anyway, that is my plan
>>>>> right now, to see if NEON might help if the converter is having to
>>>>> swap byte order.
>>> _______________________________________________
>>> USRP-users mailing list
>>> USRP-users at lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users at lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
> 
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 




More information about the USRP-users mailing list