Open dslotter opened 4 years ago
You need to set the NEON flags properly.
cmake -DCMAKE_CXX_FLAGS:STRING="-march=armv7-a -mfloat-abi=hard -mfpu=neon -mtune=cortex-a15 -Wno-psabi" -DCMAKE_C_FLAGS:STRING="-march=armv7-a -mfloat-abi=hard -mfpu=neon -mtune=cortex-a15 -Wno-psabi" -DCMAKE_ASM_FLAGS:STRING="-march=armv7-a -mfloat-abi=hard -mfpu=neon -mtune=cortex-a15 -g" ../
Replace -mtune=cortex-a15 with -mtune=cortex-a53 for RPi3 and -mtune=cortex-a72 for RPi4.
@drmpeg When you state, "You need to set the NEON flags properly", it infers that I set them improperly.
I searched the publicly available documentation at https://github.com/EttusResearch/uhd and https://files.ettus.com/manual/page_install.html and could not find any notes with regard to this.
I would suggest to close this bug that either the standard "cmake .." + "make" steps be modified to automatically account for these settings or that instructions be prominently displayed at one or both of the above web links.
Thank you.
-Dave, W3DJS
I'm not an Ettus employee, so I can't help with your suggestions. However, I do have direct experience with this issue and was just trying to help out by providing a fix that I know works.
@drmpeg Thank you for supplying the cmake flags. I am incorporating them into my HamPi image so that hams with Raspberry Pi computers that aren't that computer-savvy can make use of all Soapy framework-supported radios, including UHD.
@drmpeg The Raspberry Pi 3 and 4 are both ARMv8, does that mean the -march flags should be modified accordingly? Just curious.
If you're running a 64-bit OS, then you can try ARMv8 flags. But this issue was about Raspberry Pi OS Buster, which is 32-bit.
On a 64-bit OS, You could try -march=armv8-a -mtune=cortex-a72 -mfpu=neon-fp-armv8 -mfloat-abi=hard. Unfortunately, I don't have an RPi4 to test with.
To see available flags:
gcc -Q --help=target
or what the compiler is detecting as your native architecture:
gcc -march=native -Q --help=target
Thanks for reporting this (and a big thank you to those who chimed in with the right magical invocations). We're looking into how to properly document this so it's easy for users to build UHD on alternate platforms.
@atrnati Thank you so much for recognizing this documentation need. You have my full support. Please let me know if there is anything I can do to assist.
@drmpeg Thanks for the solution!
@dslotter Thanks for reporting! We welcome pull requests for the manual host/docs
or you can submit an Application Note to support@ettus.com for our Knowledge Base (kb.ettus.com).
Marking this as Support because we don't officially support the OS, but we are always interested in removing obstacles for those wanting to build and run on other architectures.
You need to set the NEON flags properly.
cmake -DCMAKE_CXX_FLAGS:STRING="-march=armv7-a -mfloat-abi=hard -mfpu=neon -mtune=cortex-a15 -Wno-psabi" -DCMAKE_C_FLAGS:STRING="-march=armv7-a -mfloat-abi=hard -mfpu=neon -mtune=cortex-a15 -Wno-psabi" -DCMAKE_ASM_FLAGS:STRING="-march=armv7-a -mfloat-abi=hard -mfpu=neon -mtune=cortex-a15 -g" ../
Replace -mtune=cortex-a15 with -mtune=cortex-a53 for RPi3 and -mtune=cortex-a72 for RPi4.
I have noted this for future use, here I am looking for certain flags in the Make files to append...
Issue Description
Compile errors on Raspberry Pi OS Buster 2020-05-27
Setup Details
Using vanilla install of Raspberry Pi OS Buster with cmake installed.
Expected Behavior
Compile to succeed without errors.
Actual Behaviour
Compile failed with error: inlining failed in call to always_inline
Steps to reproduce the problem
Command line operations: sudo apt install cmake gr-osmosdr libfftw3-dev libusb-1.0-0-devpython3-mako python3-ruamel.yaml git clone https://github.com/EttusResearch/uhd cd uhd/host/build cmake .. make
Additional Information
pi@raspberrypi:~/hamradio/uhd/host/build $ uname -a Linux raspberrypi 4.19.118-v7l+ #1311 SMP Mon Apr 27 14:26:42 BST 2020 armv7l GNU/Linux
pi@raspberrypi:~/hamradio/uhd/host/build $ cat /etc/os-release PRETTY_NAME="Raspbian GNU/Linux 10 (buster)" NAME="Raspbian GNU/Linux" VERSION_ID="10" VERSION="10 (buster)" VERSION_CODENAME=buster ID=raspbian ID_LIKE=debian HOME_URL="http://www.raspbian.org/" SUPPORT_URL="http://www.raspbian.org/RaspbianForums" BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
Full build log: pi@raspberrypi:~/hamradio/uhd/host/build $ make [ 2%] Built target uhd_rpclib [ 2%] Built target uhd-resources [ 2%] Building CXX object lib/CMakeFiles/uhd.dir/convert/convert_with_neon.cpp.o In file included from /home/pi/hamradio/uhd/host/lib/convert/convert_with_neon.cpp:10: /usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h: In member function ‘virtual void convert_fc32_1_sc16_item32_le_1_PRIORITY_SIMD::operator()(const input_type&, const output_type&, size_t)’: /usr/lib/gcc/arm-linux-gnueabihf/8/include/arm_neon.h:6740:1: error: inlining failed in call to always_inline ‘float32x4_t vdupq_n_f32(float32_t)’: target specific option mismatch vdupq_n_f32 (float32_t a) ^
~~/home/pi/hamradio/uhd/host/lib/convert/convert_with_neon.cpp:27:33: note: called from here float32x4_t Q0 = vdupq_n_f32(float(scale_factor));