Changes between Version 23 and Version 24 of Internal/BuildingGNURadioImage

Timestamp:

Feb 2, 2009, 11:05:36 PM (15 years ago)

Author:

ssugrim

Comment:

—

Internal/BuildingGNURadioImage

@@ -164 +164 @@
 Bob seems to think this is caused by the '''Broken libtool on Debian and Ubuntu''' documented in the Ubuntu install docs. 
 
-To fix it we modified the ld.so.conf and ran ldconfig.
+To fix it we modified the '''ld.so.conf''' and ran ldconfig.
 
 {{{
@@ -293 +293 @@
 This downgraded the libraries, but we also had to downgrade the complier it self, and the docs for laughs.
 
-http://packages.debian.org/etch/all/sdcc-doc/download[[BR]]
+http://packages.debian.org/etch/all/sdcc-doc/download [[BR]]
 http://packages.debian.org/etch/i386/sdcc/download
 
-'''Note:''' uname -a says that our architecture is i686, but they only had debs for i386.  The install process was the same. 
-
-Sucess!!! Or at least a glimpse of hope, the usrp module was now listed in the list of shite to be built. 
-
-Image was take, new image name is:
+'''Note:''' uname -a says that our architecture is i686, but they only had debs for i386. We used the i386 ones. The install process was the same as for the libraries. 
+ 
+
+Sucess!!! Or at least a glimpse of hope, the usrp module was now listed in the list of shite to be built after running ./configure again. 
+
+Make and Make check ran through with minimal complaints, mostly barking about locale again. 
+
+An image was taken, new image name is:
 {{{
 ssugrim@repository2:/export/orbit/image$ ls -al | grep james 
@@ -324 +327 @@
 Our first run of :
 {{{
-node1-1:~/gnuradio/gnuradio-examples/python/usrp# ./usrp_benchmark_usb.py 
+# ./usrp_benchmark_usb.py 
 }}}
 
 failed. Jrock had noticed that the console was spitting usb events and "renumbering" the usrp. Each run of lsusb or 
+
 {{{
 # ls -lR /dev/bus/usb | grep usrp
-crw-rw---- 1 root usrp 189, 450 Feb  2 17:14 067 <-- note the 67 instead of 2
-}}}
-
-would get a higher number for the device id. Rebooting the usrp (I guess it was in some kind of loop where it rebooted continously) fixed the problem. 
-
-----
+crw-rw---- 1 root usrp 189, 450 Feb  2 17:14 067 <-- note the 067 instead of 002
+}}}
+
+would get a higher number for the device id. Rebooting the usrp fixed the problem. I guess it was in some kind of loop where it rebooted continuously/ reassociated with the usb controller. The controller then thinking it found a new device, would assign a new number to it. 
 
 After that we had a '''SUCCESSFUL''' run of the benchmark:
@@ -373 +375 @@
 }}}
 
-Ibob says the last set of failures was expected as we've reached the through put limit of the usb controller.
-
-We also ran usrp_sigen.py and were able to sucessfully transmit a signal (although we can't verify it went out, the software didn't complain). 
+Ibob says the last set of failures was ''expected'' as we've reached the through put limit of the usb controller.
+
+We also ran '''usrp_sigen.py''' and were able to sucessfully transmit a signal (although we can't verify it went out, the software didn't complain). 
 
 We're taking an image from this point: