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

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


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.

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
> 




More information about the USRP-users mailing list