Installing GR 3.5.2 on FreeBSD

luislavena · January 17, 2012, 4:06pm

It builds without qtgui and runs dial_tone.py.

I move the USRP1 from a 3.2.2 machine and it shows to be loaded:
ugen4.5: at usbus4

Then I run uhd_rx_nogui.py with proper options, not in an xterm:

FreeBSD 8; GNU C++ version 4.2.2 20070831 prerelease [FreeBSD];
Boost_104500; UH
D_003.004.000-1424488

– Loading firmware image: /usr/home/gr/gr352/usrp1_fw.ihx… done
Traceback (most recent call last):
File “/log/gr/gr352/local/bin/uhd_rx_nogui.py”, line 243, in
main()
File “/log/gr/gr352/local/bin/uhd_rx_nogui.py”, line 236, in main
tb = app_top_block(options)
File “/log/gr/gr352/local/bin/uhd_rx_nogui.py”, line 139, in init
options.calibration) # Frequency offset
File “/log/gr/gr352/local/bin/uhd_rx_nogui.py”, line 92, in init
self._src = uhd.usrp_source(device_addr=args,
stream_args=uhd.stream_args(‘f
c32’))
File
"/log/gr/gr352/local/lib/python2.7/site-packages/gnuradio/uhd/init.py
", line 112, in constructor_interceptor
return old_constructor(*args)
File
"/log/gr/gr352/local/lib/python2.7/site-packages/gnuradio/uhd/uhd_swig.py
", line 2290, in usrp_source
return _uhd_swig.usrp_source(*args)
RuntimeError: LookupError: KeyError: No devices found for ----->
Empty Device Address

The usrp1_fw.ihx firmware is loaded but No devices found.

Run the same command again:

FreeBSD 8; GNU C++ version 4.2.2 20070831 prerelease [FreeBSD];
Boost_104500; UH
D_003.004.000-1424488

– Opening a USRP1 device…
– Loading FPGA image: /usr/home/gr/gr352/usrp1_fpga.rbf… done
– Using FPGA clock rate of 64.000000MHz…

gr_fir_ccf: using SSE
Using gain: 10.0

UHD Warning:
The hardware does not support the requested RX frequency:
Target frequency: 915.000000 MHz
Actual frequency: 19.000000 MHz

gr_fir_ccc: using SSE
gr_fir_fff: using SSE
OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO

The second try loads the usrp1_fpga.rbf file. The failure is due to
not specifying the --spec=“A:0” on the command line.

With that in place:

FreeBSD 8; GNU C++ version 4.2.2 20070831 prerelease [FreeBSD];
Boost_104500; UH
D_003.004.000-1424488

– Opening a USRP1 device…
– Using FPGA clock rate of 64.000000MHz…

gr_fir_ccf: using SSE
Using gain: 50.0
gr_fir_ccc: using SSE
gr_fir_fff: using SSE
OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO

Noise in the speakers, It is running!

The ^C stops the program but does not kill it.

Progress…

–
The computer is supposed to work for YOU, not the other way around.
LRK
gr-user . ovillatx.sytes.net

LRK · January 17, 2012, 4:37pm

I’ve made it a habit to always be explicit about which device (or
device class, at least) I’m going for when I use UHD tools.

So, I
always either specify “–args type=usrp1” or --args
“addr=192.168.10.2” to UHD tools, so that I don’t have to rely on
autodiscovery stuff that might produce weird results. I kind of have
to on one of my systems, because I have both a USRP1 and USRP2 on the
same system.

I vaguely recall from the mists of my memory that there’s
some subtle brokenness with SIGINT handling in *BSD Python and Gnu
Radio, but that’s as much as I remember.

In terms of why it’s
reloading the .ihx, I’m not sure, although I’ll note in the code that
there’s a “force” parameter to the routine that loads the firmware, so
that if “force” is set, the FX2 firmware is reloaded regardless of
whether the local-file and on-board hash match. I’ll also note that the
routine that calls the firmware loader doesn’t actually supply this
parameter, so perhaps there’s actually a bug.

usrp1_impl.cpp:
fx2_ctrl::make(control)->usrp_load_firmware(usrp1_fw_image);

Whereas
the routine is defined here:

void usrp_load_firmware(std::string
filestring, bool force)

I’m not much of a C++ guy (more of a C-only
fossil), but it seems like there may be a mis-match in the args here,
and that maybe on *BSD it just happens that the “force” parameter is
being set by accident.

Perhaps Josh (when he’s awake ) can
comment.

On Tue, 17 Jan 2012 09:05:43 -0600, LRK wrote:

It builds
without qtgui and runs dial_tone.py.

I move the USRP1 from a 3.2.2
machine and it shows to be loaded:
ugen4.5: at usbus4

Then I run
uhd_rx_nogui.py with proper options, not in an xterm:

FreeBSD 8;
GNU C++ version 4.2.2 20070831 prerelease [FreeBSD]; Boost_104500; UH

D_003.004.000-1424488

– Loading firmware image:
/usr/home/gr/gr352/usrp1_fw.ihx… done
Traceback (most recent call
last):
File “/log/gr/gr352/local/bin/uhd_rx_nogui.py”, line 243, in

main()

File “/log/gr/gr352/local/bin/uhd_rx_nogui.py”, line 236, in
main
tb = app_top_block(options)
File
“/log/gr/gr352/local/bin/uhd_rx_nogui.py”, line 139, in init

options.calibration) # Frequency offset

File
“/log/gr/gr352/local/bin/uhd_rx_nogui.py”, line 92, in init

self._src = uhd.usrp_source(device_addr=args,
stream_args=uhd.stream_args('f

c32’))
File
"/log/gr/gr352/local/lib/python2.7/site-packages/gnuradio/uhd/init.py

", line 112, in constructor_interceptor

return
old_constructor(*args)
File
"/log/gr/gr352/local/lib/python2.7/site-packages/gnuradio/uhd/uhd_swig.py

", line 2290, in usrp_source

return _uhd_swig.usrp_source(*args)

RuntimeError: LookupError: KeyError: No devices found for ----->

Empty
Device Address

The usrp1_fw.ihx firmware is loaded but No devices
found.

Run the same command again:

FreeBSD 8; GNU C++ version
4.2.2 20070831 prerelease [FreeBSD]; Boost_104500; UH

D_003.004.000-1424488

– Opening a USRP1 device…
– Loading
FPGA image: /usr/home/gr/gr352/usrp1_fpga.rbf… done
– Using FPGA
clock rate of 64.000000MHz…

gr_fir_ccf: using SSE
Using gain:
10.0 UHD Warning: The hardware does not support the requested RX
frequency: Target frequency: 915.000000 MHz Actual frequency: 19.000000
MHz

gr_fir_ccc: using SSE gr_fir_fff: using SSE

OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO The second try loads the
usrp1_fpga.rbf file. The failure is due to not specifying the
–spec=“A:0” on the command line. With that in place: FreeBSD 8; GNU C++
version 4.2.2 20070831 prerelease [FreeBSD]; Boost_104500; UH
D_003.004.000-1424488 – Opening a USRP1 device… – Using FPGA clock
rate of 64.000000MHz… gr_fir_ccf: usin

5px; border-left:#1010ff
2px solid; margin-left:5px; width:100%">
%">gr_fir_ccc: using SSE
gr_fir_fff: using SSE
OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
Noise in the speakers, It is running! The ^C stops the program but does
not kill it. Progress…

LRK · January 17, 2012, 5:40pm

On 01/17/2012 07:36 AM, [email protected] wrote:

same system.
routine that calls the firmware loader doesn’t actually supply this
parameter, so perhaps there’s actually a bug.

Maybe its because the hash type is a size_t. I will throw this patch at
you to make it fixed at int32: diff --git a/host/lib/usrp/common/fx2_ctrl.cpp b/host/lib/usrp/common/fx2_ctrl.c - Pastebin.com

Now I have to run…

-Josh

LRK · January 17, 2012, 6:15pm

On Tue, 17 Jan 2012 08:39:59 -0800, Josh B. wrote:

On
01/17/2012 07:36 AM, [email protected] [1] wrote:

I’ve made it a
habit to always be explicit about which device (or device class, at
least) I’m going for when I use UHD tools. So, I always either specify
“–args type=usrp1” or --args “addr=192.168.10.2” to UHD tools, so that
I don’t have to rely on autodiscovery stuff that might produce weird
results. I kind of have to on one of my systems, because I have both a
USRP1 and USRP2 on the same system. I vaguely recall from the mists of
my memory that there’s some subtle brokenness with SIGINT handling in
*BSD Python and Gnu Radio, but that’s as much as I remember. In terms of
why it’s reloading the .ihx, I’m not sure, although I’ll note in the
code that there’s a “force” parameter to the routine that loads the
firmware, so that if “force” is set, the FX2 firmware is reloaded
regardless of whether the local-file and on-board hash match. I’ll also
note that the routine that calls the firmware loader doesn’t actually
supply this parameter, so perhaps there’s actually a bug.
Maybe its
because the hash type is a size_t. I will throw this patch at you to
make it fixed at int32: diff --git a/host/lib/usrp/common/fx2_ctrl.cpp b/host/lib/usrp/common/fx2_ctrl.c - Pastebin.com [2] Now I have to
run… -Josh _______________________________________________

Given the
type-punning that goes on “under the covers”, I can see how using a
size_t might not have been the best choice.

But I still wonder about
the “force” parameter on fx2_ctrl_impl::usrp_load_firmware()

Links:

LRK · January 17, 2012, 6:24pm

On Tue, 17 Jan 2012 10:04:06 -0600, LRK wrote:

On Tue, Jan 17,
2012 at 10:36:31AM -0500, [email protected] [1] wrote:

I’ve made it a
habit to always be explicit about which device (or
device class, at
least) I’m going for when I use UHD tools.

So, I
always either
specify “–args type=usrp1” or --args
“addr=192.168.10.2” to UHD tools,
so that I don’t have to rely on
autodiscovery stuff that might produce
weird results. I kind of have
to on one of my systems, because I have
both a USRP1 and USRP2 on the
same system.

It is probably a good habit
but, with a computer, the program should be
able to determine if there
is only one device and use it. Programs need
reasonable defaults as
well.

Well, while in general I agree, the whole concept of “it’s a
computer, it should just guess what I meant, and do the least
astonishing thing”, is generally, in my long experience,
fraught with
danger. UHD might be able to determine which devices you have
connected via USB, and perhaps connect you to the “most obvious one”,
but otherwise, it needs some kind of hint about what you had in mind
(hence the “type=usrp1” hint).

“All I want to do is write some code,
this whole formal syntax and curly-braces thing is for the birds”.

Not too relavant as long as things work. I think my Ubuntu build is
doing
the same things since I often have to execute a program twice
after moving
the USRP1 from the other machine.

That’s an interesting
observation that I’ll have to see if I can reproduce on my Fedora
machines. May be that the FX2 gets all chummy with the USB bus its
connected to, and when you just pull the USB plug without actually
power-cycling the USRP1, it can’t cope.

I don’t use C++ either (same
reason). I feed some GnuRadio bits into a C
program to analyze since I
can’t get time to write GnuRadio blocks.

Always better to do programing
while awake.

I dunno, yesterday at my day job, I was a complete
sleep-deprived zombie. And yet I wrote a pile of fiendishly-clever code
that worked the first time. I’m not sure I’ll understand
a week from
now, how it works

Links:

LRK · January 17, 2012, 5:05pm

On Tue, Jan 17, 2012 at 10:36:31AM -0500, [email protected] wrote:

I’ve made it a habit to always be explicit about which device (or
device class, at least) I’m going for when I use UHD tools.

So, I
always either specify “–args type=usrp1” or --args
“addr=192.168.10.2” to UHD tools, so that I don’t have to rely on
autodiscovery stuff that might produce weird results. I kind of have
to on one of my systems, because I have both a USRP1 and USRP2 on the
same system.

It is probably a good habit but, with a computer, the program should be
able to determine if there is only one device and use it. Programs need
reasonable defaults as well.

I vaguely recall from the mists of my memory that there’s
some subtle brokenness with SIGINT handling in *BSD Python and Gnu
Radio, but that’s as much as I remember.

I don’t recall having a SIGINT problem with older versions. Maybe a
new “feature” (bug).

In terms of why it’s
reloading the .ihx, I’m not sure, although I’ll note in the code that
there’s a “force” parameter to the routine that loads the firmware, so
that if “force” is set, the FX2 firmware is reloaded regardless of
whether the local-file and on-board hash match. I’ll also note that the
routine that calls the firmware loader doesn’t actually supply this
parameter, so perhaps there’s actually a bug.

Not too relavant as long as things work. I think my Ubuntu build is
doing
the same things since I often have to execute a program twice after
moving
the USRP1 from the other machine.

fossil), but it seems like there may be a mis-match in the args here,
and that maybe on *BSD it just happens that the “force” parameter is
being set by accident.

I don’t use C++ either (same reason). I feed some GnuRadio bits into a C
program to analyze since I can’t get time to write GnuRadio blocks.

Perhaps Josh (when he’s awake ) can
comment.

Always better to do programing while awake.

–
The computer is supposed to work for YOU, not the other way around.
LRK
gr-user . ovillatx.sytes.net

LRK · January 17, 2012, 9:31pm

On Tue, Jan 17, 2012 at 02:10:46PM -0500, Marcus D. Leech wrote:

So, the way it works is that it compares the hash on the device to the
hash contained in the appropriate .ihx/.rbf file on the host computer.
If they differ, it reloads. I wonder if the hashes of the .ihx/.rbf
files differ between your two machines?

Indeed I think they are different. One is running GnuRadio 3.2.2 from a
FreeBSD port and the other the latest git clone. Yours are identical so
you would see the two-step load only if you power down the USRP1 between
runs. See if loading uhd_rx_nogui.py is different from uhd_fft.py.

Again, I’m running the old version only because I can’t get the new
stuff
running yet.

–
The computer is supposed to work for YOU, not the other way around.
LRK
gr-user . ovillatx.sytes.net

LRK · January 17, 2012, 10:05pm

On Tue, Jan 17, 2012 at 02:30:29PM -0600, LRK wrote:

FreeBSD port and the other the latest git clone. Yours are identical so
you would see the two-step load only if you power down the USRP1 between
runs. See if loading uhd_rx_nogui.py is different from uhd_fft.py.

Nevermind. Josh beat you to it. Fixed two-step load. Works. Thanks.

–
The computer is supposed to work for YOU, not the other way around.
LRK
gr-user . ovillatx.sytes.net

LRK · January 17, 2012, 8:11pm

On 01/17/2012 12:23 PM, [email protected] wrote:

Not too relavant as long as things work. I think my Ubuntu build is doing
the same things since I often have to execute a program twice after moving
the USRP1 from the other machine.

That’s an interesting observation that I’ll have to see if I can reproduce on my
Fedora machines. May be that the FX2 gets all chummy with the USB bus its
connected to, and when you just pull the USB plug without actually power-cycling
the USRP1, it can’t cope.

Just did that test. Latest Gnu Radio + UHD, two different Fedora
16-64bit machines, two different mobo (and USB controller) types, CPUs,
etc.

Plugged just-powered-up USRP1 into one machine, did a:

uhd_fft.py --args type=usrp1 on one machine. It loaded
firmware and FPGA, and then brought up the app.

Unplugged it, plugged it into second machine, ran:

uhd_fft.py --args type=usrp1 it came up without re-loading
either firmware or FPGA.

Plugged it back into the first machine–ran:

uhd_fft.py --args type=usrp1 it came up without re-loading
firmware or FPGA.

So, the way it works is that it compares the hash on the device to the
hash contained in the appropriate .ihx/.rbf file on the host computer.
If they differ, it reloads. I wonder if the hashes of the .ihx/.rbf
files differ between your two machines?

–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

LRK · January 17, 2012, 11:24pm

Spoke too soon. Worked from power down for uhd_rx_nogui.py but not for
uhd_usrp_probe:

FreeBSD 8; GNU C++ version 4.2.2 20070831 prerelease [FreeBSD]; Boost_104500; UH
D_003.004.000-b071cbc

– Loading firmware image: /usr/home/gr/gr352/usrp1_fw.ihx… done
Error: LookupError: KeyError: No devices found for ----->
Empty Device Address

After the firmware is loaded, the usrp1 re-enumerates, and disappears
from the system for some time. Perhaps that time is longer on your
system?

This patch adds a hilariously long timeout. Let me know if that makes it
always work after firmware load: diff --git a/host/lib/usrp/usrp1/usrp1_impl.cpp b/host/lib/usrp/usrp1/usrp1_impl - Pastebin.com

-Josh

LRK · January 17, 2012, 10:26pm

On Tue, Jan 17, 2012 at 03:04:10PM -0600, LRK wrote:

Nevermind. Josh beat you to it. Fixed two-step load. Works. Thanks.

Spoke too soon. Worked from power down for uhd_rx_nogui.py but not for
uhd_usrp_probe:

FreeBSD 8; GNU C++ version 4.2.2 20070831 prerelease [FreeBSD];
Boost_104500; UH
D_003.004.000-b071cbc

– Loading firmware image: /usr/home/gr/gr352/usrp1_fw.ihx… done
Error: LookupError: KeyError: No devices found for ----->
Empty Device Address

gr% uhd_usrp_probe
FreeBSD 8; GNU C++ version 4.2.2 20070831 prerelease [FreeBSD];
Boost_104500; UH
D_003.004.000-b071cbc

– Opening a USRP1 device…
– Loading FPGA image: /usr/home/gr/gr352/usrp1_fpga.rbf… done
– Using FPGA clock rate of 64.000000MHz…

Strange. Still testing…

–
The computer is supposed to work for YOU, not the other way around.
LRK
gr-user . ovillatx.sytes.net

LRK · January 17, 2012, 11:50pm

On Tue, Jan 17, 2012 at 05:29:15PM -0500, Marcus D. Leech wrote:

But seriously, it’s conceivable that on FreeBSD, the underlying drivers
are doing something to make that re-enumeration cause a
“blackout” for longer than libusb-1.0/UHD is “used to”.

We have only a handful of users on *BSD, and it seems that with the
change from libusb-0.1 in “classic” to libusb-1.0 in UHD, it’s easily
possible that this class of problem could live for a very long time
before anyone really noticed.

I’m sure I saw this while trying to do some studies using Ubuntu. Since
most users do not move the USRP between machines or power them down
often, it would not be noticed. Never happens under GR 3.2.2 on the
other machine.

I still do not understand the logic. If uhd_find_devices is there to
find devices, it seems that it should identify any device it understands
and tell the user it’s status. Instead, if it finds a USRP1, it looks
for
the firmware and errors off if it is not found. The USRP1 may be loaded
with the older stuff but the message says No device found. What is
uhd_find_devices for?

The program that loads firmware should be able to determine if it needs
to be loaded, load it, and check to see if it is okay. Then the same
with the fpga load. Can that info be read from the USRP1?

–
The computer is supposed to work for YOU, not the other way around.
LRK
gr-user . ovillatx.sytes.net

LRK · January 18, 2012, 12:24am

I still do not understand the logic. If uhd_find_devices is there to
find devices, it seems that it should identify any device it understands
and tell the user it’s status. Instead, if it finds a USRP1, it looks for
the firmware and errors off if it is not found. The USRP1 may be loaded
with the older stuff but the message says No device found. What is
uhd_find_devices for?

Well the original intention of the uhd_find_devices was just to spit
errors. Its purely accidental that it prints discovered devices.

We are trying to determine if the re-enumeration delay is longer than
the software expects on freebsd. Do you mind trying the sleep patch to
prove/disprove this idea?

The program that loads firmware should be able to determine if it needs
to be loaded, load it, and check to see if it is okay. Then the same
with the fpga load. Can that info be read from the USRP1?

Recall the hash discussion…thats exactly what the software does.
Firmware and FPGA images are loaded automatically. The user does not
need to worry about it.

Does anyone mind moving this discussion over to usrp-users since its
about the intricacies of fw loading and not about the orginal subject?

-Josh

LRK · January 17, 2012, 11:29pm

On 01/17/2012 05:24 PM, Josh B. wrote:

After the firmware is loaded, the usrp1 re-enumerates, and disappears
from the system for some time. Perhaps that time is longer on your system?

This patch adds a hilariously long timeout. Let me know if that makes it
always work after firmware load: diff --git a/host/lib/usrp/usrp1/usrp1_impl.cpp b/host/lib/usrp/usrp1/usrp1_impl - Pastebin.com

10 seconds? I’m rolling in the aisles

But seriously, it’s conceivable that on FreeBSD, the underlying drivers
are doing something to make that re-enumeration cause a
“blackout” for longer than libusb-1.0/UHD is “used to”.

We have only a handful of users on *BSD, and it seems that with the
change from libusb-0.1 in “classic” to libusb-1.0 in UHD, it’s easily
possible that this class of problem could live for a very long time
before anyone really noticed.

–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium