Re: [Discuss-gnuradio] Problems building GNURadio
/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=gtri.gatech@gnu.org
discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org on behalf
of West, Nathan n...@ostatemail.okstate.edu
*Sent:* Saturday, September 20, 2014 11:25 AM
*To:* Philip Balister
*Cc:* GNURadio Discussion List; Mike Jameson; Michal Jakubiak
*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 Balister phi...@balister.org
wrote:
On 09/19/2014 12:08 PM, Mike Jameson 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
Mike
--
Mike Jameson M0MIK BSc MIET
Ettus Research Technical Support
Email: supp...@ettus.com http://owa/
Web: http://ettus.com
On Fri, Sep 19, 2014 at 4:29 PM, Michal Jakubiak meho...@gmail.com
http://owa/ wrote:
I'm refreshing this one since I have a very similar problem. I'm
trying to
build gr on BeagleBone Black, which is also an ARMv7. I'm using the
build-gnuradio script.
[ 4%] Building C object volk/lib/CMakeFiles/volk.dir/volk_cpu.c.o
[ 4%] Building C object
volk/lib/CMakeFiles/volk.dir/volk_machines.c.o
[ 4%] Building C object
volk/lib/CMakeFiles/volk.dir/volk_machine_generic_orc.c.o
[ 4%] Building C object
volk/lib/CMakeFiles/volk.dir/volk_machine_neon_hardfp_orc.c.o
Linking C shared library libvolk.so
[ 4%] Built target volk
[ 4%] Building CXX object
volk/lib/CMakeFiles/test_all.dir/testqa.cc.o
[ 4%] Building CXX object
volk/lib/CMakeFiles/test_all.dir/qa_utils.cc.o
Linking CXX executable test_all
libvolk.so.0.0.0: undefined reference to
`volk_32fc_x2_multiply_32fc_neonasm'
libvolk.so.0.0.0: undefined reference
Re: [Discuss-gnuradio] Problems building GNURadio
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 Geiger doug.gei...@bioradiation.net wrote: 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 Mon, Sep 22, 2014 at 9:04 AM, Michal Jakubiak meho...@gmail.com wrote: 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 Geiger doug.gei...@bioradiation.net wrote: I am curious to hear from folks if the changes made in this commit ( https://github.com/gnuradio/gnuradio/commit/33a43b42c7ea3c318cbad3fe9372a32bc2bd127e) 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 -- Doug Geiger doug.gei...@bioradiation.net ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problems building GNURadio
I'm refreshing this one since I have a very similar problem. I'm trying to build gr on BeagleBone Black, which is also an ARMv7. I'm using the build-gnuradio script. [ 4%] Building C object volk/lib/CMakeFiles/volk.dir/volk_cpu.c.o [ 4%] Building C object volk/lib/CMakeFiles/volk.dir/volk_machines.c.o [ 4%] Building C object volk/lib/CMakeFiles/volk.dir/volk_machine_generic_orc.c.o [ 4%] Building C object volk/lib/CMakeFiles/volk.dir/volk_machine_neon_hardfp_orc.c.o Linking C shared library libvolk.so [ 4%] Built target volk [ 4%] Building CXX object volk/lib/CMakeFiles/test_all.dir/testqa.cc.o [ 4%] Building CXX object volk/lib/CMakeFiles/test_all.dir/qa_utils.cc.o Linking CXX executable test_all libvolk.so.0.0.0: undefined reference to `volk_32fc_x2_multiply_32fc_neonasm' libvolk.so.0.0.0: undefined reference to `volk_16i_max_star_horizontal_16i_neonasm' libvolk.so.0.0.0: undefined reference to `volk_32fc_32f_dot_prod_32fc_a_neonasm' libvolk.so.0.0.0: undefined reference to `volk_32f_x2_dot_prod_32f_neonasm_opts' libvolk.so.0.0.0: undefined reference to `volk_32fc_32f_dot_prod_32fc_a_neonpipeline' libvolk.so.0.0.0: undefined reference to `volk_32f_x2_dot_prod_32f_neonasm' collect2: ld returned 1 exit status make[2]: *** [volk/lib/test_all] Error 1 make[1]: *** [volk/lib/CMakeFiles/test_all.dir/all] Error 2 make: *** [all] Error 2 make failed Exiting Gnu Radio build/install I've edited the cmake command in the script: cmake -DENABLE_BAD_BOOST=ON -DCMAKE_BUILD_TYPE=RelWithDebInfo $CMAKE_FLAG1 $CMAKE_FLAG2 $CMF1 $CMF2 -DCMAKE_C_FLAGS=-march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 -DCMAKE_ASM-ATT_FLAGS=-march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon ../ $LOGDEV 21 Unfortunately, it had no effect. I'm out of ideas over here :/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] ctest freezes in random moments on my OOT
Hello,
I've written a simple block that takes a c34vector message as input and
outputs a message containing average mag^2 of the samples in the vector.
I've added the QA code in Python and it seems to be working except the test
never finishes. I've added a few print statements to see whats up. From
what I can gather:
- The freeze doesn't use up CPU (at least nothing noticeable)
- Random number of messages are processed before the freeze occurs,
sometimes none are sent
Could someone give me a hint on that? I've added the relevant code in the
attachment.
BR,
Michal
/* -*- c++ -*- */
/*
* Copyright 2014 +YOU OR YOUR COMPANY+.
*
* This is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 3, or (at your option)
* any later version.
*
* This software is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this software; see the file COPYING. If not, write to
* the Free Software Foundation, Inc., 51 Franklin Street,
* Boston, MA 02110-1301, USA.
*/
#ifdef HAVE_CONFIG_H
#include config.h
#endif
#include gnuradio/io_signature.h
#include burst_to_power_impl.h
namespace gr {
namespace gsm_measure {
burst_to_power::sptr
burst_to_power::make()
{
return gnuradio::get_initial_sptr
(new burst_to_power_impl());
}
/*
* The private constructor
*/
burst_to_power_impl::burst_to_power_impl()
: gr::block(burst_to_power,
gr::io_signature::make(0,0,0),
gr::io_signature::make(0,0,0))
{
message_port_register_in(pmt::mp(bursts));
message_port_register_out(pmt::mp(power));
set_msg_handler(pmt::mp(bursts), boost::bind(burst_to_power_impl::to_power, this, _1));
}
/*
* Our virtual destructor.
*/
burst_to_power_impl::~burst_to_power_impl()
{
}
void burst_to_power_impl::to_power(pmt::pmt_t pmt_vector){
std::vector gr_complex burst;
double power = 0;
if (pmt::is_c32vector(pmt_vector)){
//std::cout It's a c32vector, computing power std::endl;
burst = pmt::c32vector_elements(pmt_vector);
for (int i = 0; i burst.size(); i++){
power = power + std::norm(burst.at(i));
}
power = power/burst.size();
message_port_pub(pmt::mp(power), pmt::from_double(power));
}
else std::cout Not a c32vector!!! Check your flowgraph std::endl;
}
} /* namespace gsm_measure */
} /* namespace gr */
#!/usr/bin/env python
# -*- coding: utf-8 -*-
#
# Copyright 2014 +YOU OR YOUR COMPANY+.
#
# This is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3, or (at your option)
# any later version.
#
# This software is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this software; see the file COPYING. If not, write to
# the Free Software Foundation, Inc., 51 Franklin Street,
# Boston, MA 02110-1301, USA.
#
from gnuradio import gr, gr_unittest
from gnuradio import blocks
import gsm_measure_swig as gsm_measure
import pmt
import numpy as np
# Simple block to consume messages
class message_consumer(gr.sync_block):
def __init__(self):
gr.sync_block.__init__(
self,
name = message consumer,
in_sig = None,
out_sig = None
)
self.msg_list = []
self.message_port_register_in(pmt.intern('in_port'))
self.set_msg_handler(pmt.intern('in_port'),
self.handle_msg)
def handle_msg(self, msg):
# Create a new PMT from double and put in list
print(Message received)
self.msg_list.append(pmt.from_double(pmt.to_double(msg)))
# Simple block to generate messages
class message_generator(gr.sync_block):
def __init__(self, msg_list, msg_interval):
gr.sync_block.__init__(
self,
name = message generator,
in_sig = [np.float32],
out_sig = None
)
self.msg_list = msg_list
self.msg_interval = msg_interval
self.msg_ctr = 0
self.message_port_register_out(pmt.intern('out_port'))
def work(self, input_items, output_items):
inLen = len(input_items[0])
while self.msg_ctr
Re: [Discuss-gnuradio] ctest freezes in random moments on my OOT
On Thu, Aug 14, 2014 at 4:15 PM, Tom Rondeau t...@trondeau.com wrote:
On Thu, Aug 14, 2014 at 6:38 AM, Michal Jakubiak meho...@gmail.com
wrote:
Hello,
I've written a simple block that takes a c34vector message as input and
outputs a message containing average mag^2 of the samples in the vector.
I've added the QA code in Python and it seems to be working except the
test never finishes. I've added a few print statements to see whats up.
From what I can gather:
- The freeze doesn't use up CPU (at least nothing noticeable)
- Random number of messages are processed before the freeze occurs,
sometimes none are sent
Could someone give me a hint on that? I've added the relevant code in the
attachment.
BR,
Michal
What version of GNU Radio are you using? There is a known problem with
message-only apps not properly shutting down. This should be fixed in the
latest 3.7.4 release, but I think 3.7.3 is still buggy on this one.
Tom
I was on 3.7.2, I believe. I used the build-gnuradio script to update to
3.7.4. My problem persists. However, odd things happen. I doubt it is
relevant to my actual problem, but here it goes:
5: ==
5: FAIL: test_001_t (__main__.qa_burst_to_power)
5: --
5: Traceback (most recent call last):
5: File
/home/mehow/projects/gr-gsm_measure/python/qa_burst_to_power.py, line
124, in test_001_t
5: msg_pow.message_ports_in(), 0)), 'bursts')
5: AssertionError: 'system' != 'bursts'
5:
5: --
5: Ran 1 test in 0.005s
I don't have a port called 'system'. This happened only once and made me
tweak with the assertion statements. Now, when I check the message ports
against their actual names ('bursts' and 'power'), the assertion is passed,
but when I change the name to check against in the QA code I get (for both
of my ports):
5: AssertionError: 'system' != 'whatever_name_I_put_there'
Other than this oddity, I get exactly the same thing as at the beginning.
Could this happen because I have some leftovers of the previous version of
gnuradio after using the script?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Posting messages from outside the work function in Python
Hello, I would like to write a block in Python that is a message source (no IO ports, only message port). I've found a few examples in C++ of blocks that don't do signal processing and don't rely on the work() function, but what would be the equivalent in python? If it is possible, how would I handle posting messages without relying on the work() function? BR, Michal ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Extra line in a module with python blocks
Hi there, I'm writing an OOT module. For now, the only block I've made is written in Python. I follow the guide and everythins is ok until I run the top_block and get this error: File /usr/local/lib/python2.7/dist-packages/mavlink/__init__.py, line 45, in module from mavlink_swig import * FYI, mavlink is the name of my module. Now, if I comment that line out everything seems to work fine. Is this a serious issue or can I just go on using it this way? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
