Difference between revisions of "Panda How to build SDR"

From eLinux.org
Jump to: navigation, search
Line 51: Line 51:
  
 
Another issue that I haven't dug into yet is Jack. It is necessary for
 
Another issue that I haven't dug into yet is Jack. It is necessary for
non hpsdr protocol servers, and I haven't spent any time trying to
+
non-hpsdr protocol servers. Jack2 uses waf (a really old version 1.5.0 at that)
cross-compile it. Pulse audio and Port audio were no problem, but Jack
+
instead of make. I am able to cross compile Jack1 (0.121.3) since it uses make,
has some unusual build issues which still need some work.
+
but Jack2 needs some help. Pulse audio and Port audio were no problem.
  
 
There will be an sd card image that one can "dd" onto a blank card.
 
There will be an sd card image that one can "dd" onto a blank card.
Line 172: Line 172:
 
== ghpsdr3-alex ==
 
== ghpsdr3-alex ==
  
The normal ghpsdr3-alex package needs QtSDK installed as well a lot of graphic specific librarys. At present, this is beyond the scope of this How-To, and it will be left for another day to produce the GUI part of this. The PandaBoard will only be running the minimal code necessary to have a functional SDR server radio. pulseaudio and portaudio are required for non hpsdr protocol servers, and have been built successfully, however at present they are not used for the widget-server and could be eliminated from the build.
+
The normal ghpsdr3-alex package needs QtSDK installed as well a lot of graphic specific librarys. At present, this is beyond the scope of this How-To, and it will be left for another day to produce the GUI part of this, ie. QtRadio. The PandaBoard will only be running the minimal code necessary to have a functional SDR server radio. pulseaudio and portaudio are required for non hpsdr protocol servers, and have been built successfully, however at present they are not used for the widget-server and could be eliminated from the build.
  
  

Revision as of 11:42, 12 February 2012

Introduction

What I have done is still very much a work in progress. The PandaBoard, OMAP4, platform is a very powerful and flexible system, but it has its limitations. I have been doing work with the PandaBoard since about November 2010, so I've seen the kernel and distributions move from barely runable to very capable during that time.

For my SDR work, I run a home built "distro" which I build with buildroot. It has the advantages of Gentoo as everything is built from source, but it is not quite "plug & play". There is a lot of fiddling that I had to do to get all the dependences and libraries that dspserver and widget-server need. I am currently not running QtRadio on the PandaBoard, and don't intend to, for a while at least. The DSP software needs all the CPU power it can get.

The major problem that most folks have run into trying to get SDR software running on a non-x86 platform is dealing with the lack of FPU. Anything without an FPU is just a waste of time, software floating point emulation is just tooooooooo slow. Custom code to do SDR with fixed point arithmetic is possible and has been done. But, most recent efforts to run something like ghpsdr or ghpsdr3-alex have met with dismal failure due to the fact that folks will try to boot up Ubuntu on their platform of choice, install the build-essentials, and try to build the SDR software like they would on their desktop. While this may result in a runnable piece of code, there is currently no support for an FPU. So if the software runs at all, the DSP functions will not be able to keep up with the incoming data.

This is where I diverged from the mainstream. The key event was the availability of FFTW3 3.3.1-beta1 which includes support for the neon FPU that is present on the OMAP4 4430/4460/4470. Unfortunately ARM made this co-processor an option on Cortex-A9 implementations, and Nvidia chose not to have it on Tegra2, so what I wound up with is somewhat Ti specific.

I was able to cross compile fftw3 and run several benchmarks on my PandaBoard ES and was quite impressed with the result vs. what Vesprerix had reported on with their implementation (fork) of fftw3. Once I was convinced that the fft routines on which DTTSP depend were "good enough" I proceeded to put together a buildroot build that was tuned to using "-mcpu=cortex-a9 -mfpu=neon -mfloat-abi=softfp". There are lots of fiddly cross-compiler options and libraries that have to be checked to be sure they actually are using neon (this work has not been completed yet). After the cross environment was working I went about getting dspserver, widget-server and all their dependencies cross-compiled, there were a lot. The most troublesome was Codec2, which I still have to hand tweak to get to cross-compile properly. My first effort has Codec2 support patched out, but the current code does include it.

Another issue that I haven't dug into yet is Jack. It is necessary for non-hpsdr protocol servers. Jack2 uses waf (a really old version 1.5.0 at that) instead of make. I am able to cross compile Jack1 (0.121.3) since it uses make, but Jack2 needs some help. Pulse audio and Port audio were no problem.

There will be an sd card image that one can "dd" onto a blank card.


For SDR work, gcc 4.6.2 is a must.

Software

I build the kernel and u-boot/SPL outside of buildroot, but use the buildroot toolchain. This may change in the near future, as buildroot will soon support the PandaBoard as a target.

Kernel

kernel 3.3-rc2 .config

u-boot/MLO/SPL

Buildroot Internal toolchain with uClibc

patch to add non-supported packages

buildroot .config

busybox .config

uClibc .config

Buildroot Crosstool-ng toolchain with glibc

buildroot .config

crosstool-ng config

uClibc vs glibc size and speed in a real world example

After building the first PandaSDR system, I was curious as to how things might change if I used glibc. The first thing I did was do a bench mark on the floating point performance of both. uClibc was woefully inadequate in sin/cos

http://gruntthepeon.free.fr/ssemath/neon_mathfun.html

with this benchmark compiled with glibc the performance numbers matched closely with the website, however with uClibc the sinf/cosf numbers were off.

Instead of "2.0 millions of vector evaluations/second -> 121 cycles/value" I got ".1 millions of vector evaluations/second -> 1333 cycles/value"

Based on that benchmark, I had buildroot build a new system with a crosstool-ng based toolchain using glibc 2.13. This was somewhat complicated since the gcc 4.6.2 implementation was EXPERIMENTAL. Numerous other problems were encountered, but after a while I was able to get the toolchain built and the packages compiled with neon support for cortex-a9. The SDR software dspserver and widget-server built without problems except for the lack of libgomp in the target rootfs. It ws built ok, and populated into the toolchain's staging area, it just didn't make into the final rootfs. After all was said & done I compared the size of the libraries and executables, glibc's libs were certainly bigger, but there were fewer of them. The packages executables and libs were about the same size. Overall the two rootfs's were very close to the same size at 32MBytes (uClibc), and 40MBytes (glibc), the largest difference being in /usr/share/locale (292KBytes vs 7.7MBytes). In operation the SDR code consumed about the same amount of cpu power too. More to come as I investigate further.

Buildroot with uClibc was certainly easier to get running, but crossstool-ng with glibc more closely compares to what would be available in a "Distro" like ubuntu/angstrom/arch Linux. Performance without neon was not evaluated. Earlier linpack and fftw3 benchmarks showed that without neon floating performance was abysmal. Both builds had fiddly bits, but my lack of programming skill probably weighed in as well.


Packages

alsa-lib-1.0.24.1

alsa-utils-1.0.24.2

busybox-1.19.3

codec2-289

dbus-1.4.16

dbus-glib-0.98

dropbear-2011.54

expat-2.0.1

fftw-3.3.1-beta1

gdb-7.3.1-target

gdbserver-7.3.1

gettext-0.16.1

i2c-tools-3.0.3

input-event-daemon-v0.1.3

json-c-0.9

libconfig-1.4.8

libevent-2.0.14

libglib2-2.28.8

libogg-1.2.2

libsamplerate-0.1.8

libsndfile-1.0.25

libtool-2.2.10

libusb-1.0.8

libusb-compat-0.1.3

libxml2-2.7.8

ncurses-5.7

ortp-0.18.0

portaudio-V19

pulseaudio-1.0

speex-1.2rc1

wireless_tools-29

zlib-1.2.5

rootfs

ghpsdr3-alex

The normal ghpsdr3-alex package needs QtSDK installed as well a lot of graphic specific librarys. At present, this is beyond the scope of this How-To, and it will be left for another day to produce the GUI part of this, ie. QtRadio. The PandaBoard will only be running the minimal code necessary to have a functional SDR server radio. pulseaudio and portaudio are required for non hpsdr protocol servers, and have been built successfully, however at present they are not used for the widget-server and could be eliminated from the build.


dttsp

Makefile

widget-server

patch to orig

Makefile

dspserver

Makefile

QtRadio

Hardware

PandaBoard

SDR Widget Lite Alpha

SoftRock Lite+USB Xtall v9.0

mod to directly control the Si570 from the Widget