This URL might help:
https://labs.mwrinfosecurity.com/blog/2014/06/18/beaglebone-black-gnu-radio-and-hackrf-one/
Have you tried disabling NEON?
Mike
–
Mike J. M0MIK BSc MIET
Ettus R. Technical Support
Email: [email protected]
Web: http://ettus.com
On 09/19/2014 12:08 PM, Mike J. wrote:
This URL might help:
https://labs.mwrinfosecurity.com/blog/2014/06/18/beaglebone-black-gnu-radio-and-hackrf-one/
Have you tried disabling NEON?
Disabling NEON on this platform is a bad thing. Hopefully one of the
volk guys sees what is going on. I suspect you need to use the native
build toolchain file.
Philip
I’m mobile at the moment, so can’t be detailed… +1 to not disabling
NEON.
I’d rather point people towards the GNU radio wiki resources rather than
random blog posts since they will inevitably be out of date (which this
one
definitely is) because the authors don’t track GR development very
closely.
This page will be much more helpful:
http://gnuradio.org/redmine/projects/gnuradio/wiki/embedded
That said, there were also changes to the build setup for ARM made
yesterday, so it would be good to know what revision your building.
There have been a lot of changes to ARM builds recently, so patience and
feedback are appreciated.
On Saturday, September 20, 2014, Philip B. [email protected]
I’m using the cross compiling environment to take advantage of the
latest updates to ARM VOLK kernels. My build environment is identical to
the one described in the Wiki page for embedded, except that it was
necessary to add “-mtune=cortex-a9” to get the Neon assembly files to
compile in volk. Before adding this flag, I got this error:
[ 0%] Building ASM object
volk/lib/CMakeFiles/volk.dir//kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s.o
/home/snowlan3/pybombs/src/gnuradio/volk/kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s:
Assembler messages:
/home/snowlan3/pybombs/src/gnuradio/volk/kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s:35:
Error: selected processor does not support ARM mode veor realAccQ,realAccQ' /home/snowlan3/pybombs/src/gnuradio/volk/kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s:36: Error: selected processor does not support ARM mode veor
compAccQ,compAccQ’
/home/snowlan3/pybombs/src/gnuradio/volk/kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s:42:
Error: selected processor does not support ARM mode vld1.32 {d4-d5},[taps:128]!' /home/snowlan3/pybombs/src/gnuradio/volk/kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s:43: Error: selected processor does not support ARM mode vld2.32
{d18-d21},[input:128]!’
/home/snowlan3/pybombs/src/gnuradio/volk/kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s:50:
Error: selected processor does not support ARM mode vmul.f32 realMul,tapsVal,inRealVal' /home/snowlan3/pybombs/src/gnuradio/volk/kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s:51: Error: selected processor does not support ARM mode vmul.f32
compMul,tapsVal,inCompVal’
/home/snowlan3/pybombs/src/gnuradio/volk/kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s:52:
Error: selected processor does not support ARM mode vadd.f32 realAccQ,realAccQ,realMul' /home/snowlan3/pybombs/src/gnuradio/volk/kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s:53: Error: selected processor does not support ARM mode vadd.f32
compAccQ,compAccQ,compMul’
/home/snowlan3/pybombs/src/gnuradio/volk/kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s:54:
Error: selected processor does not support ARM mode vld1.32 {d4-d5},[taps:128]!' /home/snowlan3/pybombs/src/gnuradio/volk/kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s:55: Error: selected processor does not support ARM mode vld2.32
{d18-d21},[input:128]!’
/home/snowlan3/pybombs/src/gnuradio/volk/kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s:61:
Error: selected processor does not support ARM mode vpadd.f32 d0,d0,d1' /home/snowlan3/pybombs/src/gnuradio/volk/kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s:62: Error: selected processor does not support ARM mode vpadd.f32 d2,d2,d3’
/home/snowlan3/pybombs/src/gnuradio/volk/kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s:63:
Error: selected processor does not support ARM mode vadd.f32 realAccS,s0,s1' /home/snowlan3/pybombs/src/gnuradio/volk/kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s:64: Error: selected processor does not support ARM mode vadd.f32
compAccS,s4,s5’
/home/snowlan3/pybombs/src/gnuradio/volk/kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s:71:
Error: selected processor does not support ARM mode vld1.32 {d4[0]},[taps]!' /home/snowlan3/pybombs/src/gnuradio/volk/kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s:72: Error: selected processor does not support ARM mode vld2.32
{d5[0],d6[0]},[input]!’
/home/snowlan3/pybombs/src/gnuradio/volk/kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s:73:
Error: selected processor does not support ARM mode vmul.f32 s5,s8,s12' /home/snowlan3/pybombs/src/gnuradio/volk/kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s:74: Error: selected processor does not support ARM mode vmul.f32 s6,s8,s10’
/home/snowlan3/pybombs/src/gnuradio/volk/kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s:75:
Error: selected processor does not support ARM mode vadd.f32 realAccS,realAccS,s5' /home/snowlan3/pybombs/src/gnuradio/volk/kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s:76: Error: selected processor does not support ARM mode vadd.f32
compAccS,compAccS,s6’
/home/snowlan3/pybombs/src/gnuradio/volk/kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s:82:
Error: selected processor does not support ARM mode vst1.32 {d0[0]},[result]!' /home/snowlan3/pybombs/src/gnuradio/volk/kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s:83: Error: selected processor does not support ARM mode vst1.32
{d2[0]},[result]’
make[2]: ***
[volk/lib/CMakeFiles/volk.dir//kernels/volk/asm/neon/volk_32fc_32f_dot_prod_32fc_a_neonasmpipeline.s.o]
Error 1
make[1]: *** [volk/lib/CMakeFiles/volk.dir/all] Error 2
make: *** [all] Error 2
Sean
From: discuss-gnuradio-bounces+sean.nowlan=removed_email_address@domain.invalid
discuss-gnuradio-bounces+sean.nowlan=removed_email_address@domain.invalid on behalf
of West, Nathan [email protected]
Sent: Saturday, September 20, 2014 11:25 AM
To: Philip B.
Cc: GNURadio D.ion List; Mike J.; Michal J.
Subject: Re: [Discuss-gnuradio] Problems building GNURadio
I’m mobile at the moment, so can’t be detailed… +1 to not disabling
NEON. I’d rather point people towards the GNU radio wiki resources
rather than random blog posts since they will inevitably be out of date
(which this one definitely is) because the authors don’t track GR
development very closely. This page will be much more helpful:
http://gnuradio.org/redmine/projects/gnuradio/wiki/embedded
That said, there were also changes to the build setup for ARM made
yesterday, so it would be good to know what revision your building.
There have been a lot of changes to ARM builds recently, so patience and
feedback are appreciated.
On Saturday, September 20, 2014, Philip B.
<[email protected]mailto:[email protected]> wrote:
On 09/19/2014 12:08 PM, Mike J. wrote:
This URL might help:
https://labs.mwrinfosecurity.com/blog/2014/06/18/beaglebone-black-gnu-radio-and-hackrf-one/
Have you tried disabling NEON?
Disabling NEON on this platform is a bad thing. Hopefully one of the
volk guys sees what is going on. I suspect you need to use the native
build toolchain file.
Philip
So disabling NEON is less than optimal solution.
Thanks for the link:
http://gnuradio.org/redmine/projects/gnuradio/wiki/Embedded
IMHO it deserves to be linked to the main gr wiki page.
I can’t tell if it matters, but the SDK prepared for ARMv7hf is CortexA9
and BBB has CortexA8.
Also, if I understood correctly, the SDK is a package designed for
cross-compiling. My OOT modules aren’t big enough to be a problem for
BBB
to compile and as long as I can get Gnuradio working, I will be a very
happy man. The closest I’ve ever gotten to cross-compiling was distcc
and
seeing the wiki page, I can tell that I need to read up on cross
compiling
and OE before I could make use of the information on the wiki.
I’ve naively compiled GR3.7.2 on BBB running Debian (I think it was 7.4)
some time ago with surprisingly little problems (getting it to run on
Raspberry Pi was a nightmare!).
Right now, I’ve downloaded GR7.4 and so far, 37% into compilation, there
are no complaints from BBB.
On Sun, Sep 21, 2014 at 9:40 PM, Douglas G. <
I am curious to hear from folks if the changes made in this commit (
Fix CMake abuse for assembly (.s) files · gnuradio/gnuradio@33a43b4 · GitHub)
has any effect on cross-compiling. I verified it did the correct thing
for
me when using the SDK from the gnuradio wiki (i.e. the one linked to
from
http://gnuradio.org/redmine/projects/gnuradio/wiki/Embedded) targeting a
Cortex-A9 machine, however I’d like to get feedback from other people
using
it. I am also not convinced that it is ‘automagically’ doing the right
thing when native compiling still, but I don’t have hardware in front of
me
to test that use case at the moment. In general I discourage native
compiling something as large as GNURadio on smaller platforms unless
there
is no alternative (especially due to the memory requirements of building
all the SWIG-related objects), but if there is a path to have cmake do
the
correct thing in all cases I think we want to do that.
Doug
On Sun, Sep 21, 2014 at 12:48 PM, Nowlan, Sean
[email protected]
In my original post I was referring to this discussion:
http://lists.gnu.org/archive/html/discuss-gnuradio/2014-08/msg00207.html
The output I’ve put in my first post already used these flags. That was
for
GR 3.7.5
I’ve used distcc to speed up the compilation, but it failed. I’m leaving
the BBB for the night to compile 3.7.4 on it’s own, just in case if
distcc
messed something up. If that doesn’t work, I guess my next few questions
will concern cross compiling and the contents of SDK 
BR,
Michal
On Mon, Sep 22, 2014 at 8:14 PM, Douglas G. <
Certainly you don’t want to disable NEON when compiling for a platform
that has it.
The SDK is designed for cross-compiling - I’ll note that although the
set
of released SDK’s are targetting Cortex-A9’s, the emitted binaries will
run
on any ARMv7a chips (aside from the hf/sf ABI issues you need to
understand).
If you’re determined to native compile, then following the instructions
under
http://gnuradio.org/redmine/projects/gnuradio/wiki/Embedded#Native-Compiling
should do the right thing. If that’s not working for you, please do
speak
up.
I believe it came up during the Embedded WG discussion at GrCon last
week
that the wiki page has gotten to a good enough state that we probably do
want to make it visible on the front page.
Doug
On 09/22/2014 02:13 PM, Tom T. wrote:
I just compiled master-6e1207475b6942a3 natively on Arndale-Linaro
with the following settings. Note the change of CMAKE_ASM-ATT_FLAGS to
CMAKE_ASM_FLAGS to match the previously mentioned cmake commit.cmake …/ -DCMAKE_C_FLAGS="-march=armv7-a -mthumb-interwork
-mfloat-abi=hard -mfpu=neon-vfpv4 -mtune=cortex-a15"
-DCMAKE_ASM_FLAGS="-march=armv7-a -mthumb-interwork -mfloat-abi=hard
-mfpu=neon-vfpv4 -mtune=cortex-a15"
We should add the ASM fags to the toolchain files.
In this case, the native gnuradio build in tmpfs took a very
reasonable, IMO, 42 min 31 sec.
Reasonable for a patient man 
Philip
On Mon, Sep 22, 2014 at 10:39 AM, Michal J. [email protected]
wrote:
In my original post I was referring to this discussion:
http://lists.gnu.org/archive/html/discuss-gnuradio/2014-08/msg00207.html
The output I’ve put in my first post already used these flags. That was for
GR 3.7.5
I’ve used distcc to speed up the compilation, but it failed. I’m leaving the
BBB for the night to compile 3.7.4 on it’s own, just in case if distcc
messed something up. If that doesn’t work, I guess my next few questions
will concern cross compiling and the contents of SDK
I just compiled master-6e1207475b6942a3 natively on Arndale-Linaro
with the following settings. Note the change of CMAKE_ASM-ATT_FLAGS to
CMAKE_ASM_FLAGS to match the previously mentioned cmake commit.
cmake …/ -DCMAKE_C_FLAGS=“-march=armv7-a -mthumb-interwork
-mfloat-abi=hard -mfpu=neon-vfpv4 -mtune=cortex-a15”
-DCMAKE_ASM_FLAGS=“-march=armv7-a -mthumb-interwork -mfloat-abi=hard
-mfpu=neon-vfpv4 -mtune=cortex-a15”
In this case, the native gnuradio build in tmpfs took a very
reasonable, IMO, 42 min 31 sec.
-TT
Damn, I missed the trick with tmpfs. Usually leave it building overnight
on BBB.
On Mon, Sep 22, 2014 at 4:08 PM, Philip B. [email protected]
wrote:
On 09/22/2014 02:13 PM, Tom T. wrote:
cmake …/ -DCMAKE_C_FLAGS=“-march=armv7-a -mthumb-interwork
-mfloat-abi=hard -mfpu=neon-vfpv4 -mtune=cortex-a15”
-DCMAKE_ASM_FLAGS=“-march=armv7-a -mthumb-interwork -mfloat-abi=hard
-mfpu=neon-vfpv4 -mtune=cortex-a15”We should add the ASM fags to the toolchain files.
For native build, the missing piece is architecture detection. Until
that works sufficiently well, some type of setting(s) will need to
feed in manually.
Alternatively, the default gcc target could be setup with reasonable
values. The arndale-linaro image can also compile gnuradio without any
command line switches since the gcc defaults are sane.
–with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard
Not so with the OE based distros.
In this case, the native gnuradio build in tmpfs took a very
reasonable, IMO, 42 min 31 sec.Reasonable for a patient man
And power efficient too!
-TT
On Mon, Sep 22, 2014 at 4:45 PM, Vanush V. [email protected]
wrote:
Damn, I missed the trick with tmpfs. Usually leave it building overnight on BBB.
Note that the Arndale (and most other A15 boards) has 2GB of RAM. With
512 MB, the BBB probably won’t have enough memory headroom to build in
tmpfs effectively.
-TT
On Mon, Sep 22, 2014 at 04:27:13PM -0700, Tom T. wrote:
For native build, the missing piece is architecture detection. Until
that works sufficiently well, some type of setting(s) will need to
feed in manually.
The following works after adjusting for hard/softfp appropriately. The
result is cleaner than the above C and ASM flags, but, regardless, the
selection of CPU and hard-float ABI needs come from the user at some
point.
cmake …/
-DCMAKE_TOOLCHAIN_FILE=…/cmake/Toolchains/arm_cortex_a8_native.cmake
diff --git a/cmake/Toolchains/arm_cortex_a8_native.cmake
b/cmake/Toolchains/arm_cortex_a8_native.cmake
index 8e60eaa…9764577 100644
— a/cmake/Toolchains/arm_cortex_a8_native.cmake
+++ b/cmake/Toolchains/arm_cortex_a8_native.cmake
@@ -6,3 +6,4 @@ set(CMAKE_CXX_COMPILER g++)
set(CMAKE_C_COMPILER gcc)
set(CMAKE_CXX_FLAGS “-march=armv7-a -mtune=cortex-a8 -mfpu=neon
-mfloat-abi=softfp” CACHE STRING “” FORCE)
set(CMAKE_C_FLAGS ${CMAKE_CXX_FLAGS} CACHE STRING “” FORCE) #same flags
for C sources
+set(CMAKE_ASM_FLAGS ${CMAKE_CXX_FLAGS} CACHE STRING “” FORCE) #same
flags for ASM sources
-TT
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs