Forum: GNU Radio GNU Radio and Gumstix

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
1a83f91809fca8823d094b7ec85575c9?d=identicon&s=25 Dan (Guest)
on 2009-01-15 20:53
(Received via mailing list)
Hi, has anyone had success porting GNU Radio to Gumstix?  I would like
to
install it on the Overo Earth board (OMAP 3503 with ARM Cortex-A8) if
possible.  I searched around but couldn't find much written about this.
It
would nice to connect Gumstix to the USRP at least.

Any help would be appreciated,

Dan
79723aa1b24981dcec2dbf7fd59403c1?d=identicon&s=25 Brian Padalino (Guest)
on 2009-01-15 21:01
(Received via mailing list)
On Thu, Jan 15, 2009 at 2:51 PM, Dan <dan.sdr@gmail.com> wrote:
> Hi, has anyone had success porting GNU Radio to Gumstix?  I would like to
> install it on the Overo Earth board (OMAP 3503 with ARM Cortex-A8) if
> possible.  I searched around but couldn't find much written about this.  It
> would nice to connect Gumstix to the USRP at least.
>
> Any help would be appreciated,

Philip Balister has ported it to the beagle board and Open Embedded.

Some information can be found from this post:

    http://www.mail-archive.com/discuss-gnuradio@gnu.o...

Brian
9c2ab60bcd7045e9acc36aa8074a3336?d=identicon&s=25 Philip Balister (Guest)
on 2009-01-15 22:05
(Received via mailing list)
On Thu, Jan 15, 2009 at 12:51 PM, Dan <dan.sdr@gmail.com> wrote:
> Hi, has anyone had success porting GNU Radio to Gumstix?  I would like to
> install it on the Overo Earth board (OMAP 3503 with ARM Cortex-A8) if
> possible.  I searched around but couldn't find much written about this.  It
> would nice to connect Gumstix to the USRP at least.

If you have OE running for the Overo, running "bitbake gnuradio" should
work :)

There's more to it than that, but I need to set aside some time to
properly answer the question :) Hopefully tonight.

Philip
9c2ab60bcd7045e9acc36aa8074a3336?d=identicon&s=25 Philip Balister (Guest)
on 2009-01-16 04:38
(Received via mailing list)
On Thu, Jan 15, 2009 at 12:51 PM, Dan <dan.sdr@gmail.com> wrote:
> Hi, has anyone had success porting GNU Radio to Gumstix?  I would like to
> install it on the Overo Earth board (OMAP 3503 with ARM Cortex-A8) if
> possible.  I searched around but couldn't find much written about this.  It
> would nice to connect Gumstix to the USRP at least.

At this years SDR Forum I did a demo of Gnu Radio running on the
Beagle Board (http://www.beagleboard.org). The Beagle Board is fairly
close to the gumstix overo product line.

You should be able to build gnuradio radio for the overo via
OpenEmbedded. I haven't had time to try this, but I plan to in
February, if I can get some free time (as in no other paying work).

The list of issues at the moment:

1) GNU Radio is obsessed with floating point :) For my demo, I
converted one of the FIR filters to use the NEON co-processor. GCC is
not real good at genereating good code for NEON, so I used GCC inline
assembly. The patch is here :

2) The USRP code depends on knowing internal structures of
libusb-0.12. Angstrom is using the libusb-1.0 code which breaks the
USRP. I can build Angstrom with libusb-01.12, but it is a "nuisance".
We need to work though this issue anyway for GNU Radio to run as
distros convert to libusb-1.0 anyway.

3) The Overos have an EHCI host, which is the best place to attach the
USRP, but you will need a hardware mod to make this interface work.
Expect an email from Gumstix about this. In the past, I've had some
success on the MUSB port also. This needs work.

4) We need to add support in GNU Radio based on the patch in 1.

5) I can run bits of "make check" by mounting the OE build dir via
NFS, but there are some libtool issues to resolve.

6) Convert more floating point to use NEON.

7) Add better support to GNU Radio for suing data types other than
float. (Maybe not as critical for the OMAP3, but there are some
interesting platforms that would benefit from this)

8) Future Gumstix products may use the OMAP3 with the DSP. (The Beagle
already has the DSP) Moving algorithms to the DSP should be
interesting. This DSP is not floating point, see 7.

Hopefully, this gives people an idea of how to migrate GNU Radio off
"big iron" onto smaller, lower power, hardware. I'm glad to answer
specific questions and do plan to work on OMAP3 support as I have
time.

Philip
1a83f91809fca8823d094b7ec85575c9?d=identicon&s=25 Dan (Guest)
on 2009-01-16 14:01
(Received via mailing list)
Okay, thanks for the help, we'll start looking into it and maybe
purchase a
beagle board for evaluation.

By the way, there doesn't seem to be a link to the patch in 1)  (unless
I am
slow and this is some dark humor ;)

Dan

On Thu, Jan 15, 2009 at 10:37 PM, Philip Balister
<philip.balister@gmail.com
9c2ab60bcd7045e9acc36aa8074a3336?d=identicon&s=25 Philip Balister (Guest)
on 2009-01-16 14:23
(Received via mailing list)
On Fri, Jan 16, 2009 at 5:59 AM, Dan <dan.sdr@gmail.com> wrote:
> Okay, thanks for the help, we'll start looking into it and maybe purchase a
> beagle board for evaluation.
>
> By the way, there doesn't seem to be a link to the patch in 1)  (unless I am
> slow and this is some dark humor ;)

I am slow ....

http://cgit.openembedded.net/cgit.cgi?url=openembe...

I tested this on the Beagle Board, it should also work on the Gumstix
product. Hopefully, there is a Gumstix board with DSP at some point.

http://www.gumstix.net/User/view/Product-Roadmaps/...

The 3530 part has the c64 based dsp.

The rev B Beagle (available now) does not have a working EHCI port.
Rev C (available around the end of March) will.

Philip
1a83f91809fca8823d094b7ec85575c9?d=identicon&s=25 Dan (Guest)
on 2009-01-16 14:35
(Received via mailing list)
On Fri, Jan 16, 2009 at 8:21 AM, Philip Balister
<philip.balister@gmail.com>wrote:

> >
> >The rev B Beagle (available now) does not have a working EHCI port.
> >Rev C (available around the end of March) will.
>
Great, thanks again for the help, this should give us a good starting
point.

Dan
9c2ab60bcd7045e9acc36aa8074a3336?d=identicon&s=25 Philip Balister (Guest)
on 2009-01-19 17:18
(Received via mailing list)
On Fri, Jan 16, 2009 at 6:21 AM, Philip Balister
<philip.balister@gmail.com> wrote:
>
> I tested this on the Beagle Board, it should also work on the Gumstix
> product. Hopefully, there is a Gumstix board with DSP at some point.

I did take a quick look at this over the weekend. We can build
gnuradio 3.1.2 with OE, but not the version in subversion, which I use
for adding the NEON code. I need to debug a problem finding python
headers or something.

Philip
9c2ab60bcd7045e9acc36aa8074a3336?d=identicon&s=25 Philip Balister (Guest)
on 2009-01-29 21:50
(Received via mailing list)
On Thu, Jan 15, 2009 at 2:51 PM, Dan <dan.sdr@gmail.com> wrote:
> Hi, has anyone had success porting GNU Radio to Gumstix?  I would like to
> install it on the Overo Earth board (OMAP 3503 with ARM Cortex-A8) if
> possible.  I searched around but couldn't find much written about this.  It
> would nice to connect Gumstix to the USRP at least.
>
> Any help would be appreciated,

OK, I've updated oe.dev so that you can build gnuradio (r10302) with
NEON implementation of the fff dotprod. I'm told the files should flow
into the overo build system soon also.

To build, (short form for people who can build their own sw), Edit the
gnuradio_svn.bb and boost_1.36.bb files and comment out the
DEFAULT_PREFERENCE="-1" lines with a #.

bitbake gnuradio-image

wait a long time. After you get it loaded, start testing :)
dial_tone.py should work and the benchmark for the fff dotproduct
should give you something like this:

balister@beagleboard:~/oe/tmp/work/armv7a-angstrom-linux-gnueabi/gnuradio-3.1.3+svnr10302-r6/trunk/gnuradio-core/src/tests$
./benchmark_dotprod_fff
   generic: taps:  256  input: 4e+07  cpu: 1269.242  taps/sec:
8.068e+06
 cortex_a8: taps:  256  input: 4e+07  cpu: 49.156  taps/sec:  2.083e+08

Note, I NFS mounted my home dir on teh beagle and ran the benchmark
command on the build machine first. This needs work :)

Philip
1a83f91809fca8823d094b7ec85575c9?d=identicon&s=25 Dan (Guest)
on 2009-01-30 15:23
(Received via mailing list)
On Thu, Jan 29, 2009 at 3:49 PM, Philip Balister
<philip.balister@gmail.com>wrote:

> wait a long time. After you get it loaded, start testing :)
> command on the build machine first. This needs work :)
>
> Philip
>


Okay, thanks again for the help, we will start looking into this
procedure
and hopefully have some good results :)

Dan
This topic is locked and can not be replied to.