usrp-users@lists.ettus.com
Discussion and technical support related to USRP, UHD, RFNoC
View all threadsRe: [EXT] Re: RFNOC block name?
Ok I had it up in /usr/lib but I moved it down to the root folder and it basically gave the same thing with additional errors:
Kind of look like it is still not finding it. Did I set it wrong?
root@ni-e320-31DCD15:/usr/lib# export UHD_MODULE_PATH=~/
root@ni-e320-31DCD15:/usr/lib# uhd_find_devices
Error: EnvironmentError: OSError: dlopen failed to load "/home/root/.viminfo"
Error: EnvironmentError: OSError: dlopen failed to load "/home/root/e320.bit"
Error: EnvironmentError: OSError: dlopen failed to load "/home/root/librfnoc-txcore.so"
Error: EnvironmentError: OSError: dlopen failed to load "/home/root/.bash_history"
[INFO] [UHD] linux; GNU C++ version 9.2.0; Boost_107100; UHD_4.0.0.0-0-g90ce6062
-- UHD Device 0
Device Address:
serial: 31DCD15
claimed: False
mgmt_addr: 127.0.0.1
product: e320
type: e3xx
root@ni-e320-31DCD15:/usr/lib# uhd_usrp_probe
Error: EnvironmentError: OSError: dlopen failed to load "/home/root/.viminfo"
Error: EnvironmentError: OSError: dlopen failed to load "/home/root/e320.bit"
Error: EnvironmentError: OSError: dlopen failed to load "/home/root/librfnoc-txcore.so"
Error: EnvironmentError: OSError: dlopen failed to load "/home/root/.bash_history"
[INFO] [UHD] linux; GNU C++ version 9.2.0; Boost_107100; UHD_4.0.0.0-0-g90ce6062
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=127.0.0.1,type=e3xx,product=e320,serial=31DCD15,claimed=False
[INFO] [MPM.PeriphManager] init() called with device args `mgmt_addr=127.0.0.1,product=e320'.
[INFO] [0/Radio#0] Performing CODEC loopback test on channel 0 ...
[INFO] [0/Radio#0] CODEC loopback test passed
[INFO] [0/Radio#0] Performing CODEC loopback test on channel 1 ...
[INFO] [0/Radio#0] CODEC loopback test passed
[INFO] [0/DmaFIFO#0] BIST passed (Estimated Minimum Throughput: 1361 MB/s)
[INFO] [0/DmaFIFO#0] BIST passed (Estimated Minimum Throughput: 1361 MB/s)
[WARNING] [RFNOC::BLOCK_FACTORY] Could not find block with Noc-ID 0xde30, 0xffff
/
| Device: E300-Series Device
| _____________________________________________________
| /
| | Mboard: ni-e320-31DCD15
| | eeprom_version: 3
| | fs_version: 20200914014807
| | mender_artifact: v4.0.0.0_e320
| | mpm_sw_version: 4.0.0.0-g90ce6062
| | pid: 58144
| | product: e320
| | rev: 5
| | rpc_connection: local
| | serial: 31DCD15
| | type: e3xx
| | MPM Version: 3.0
| | FPGA Version: 6.0
| | FPGA git hash: 75f2ba9.clean
| |
| | Time sources: internal, external, gpsdo
| | Clock sources: external, internal, gpsdo
| | Sensors: ref_locked, gps_locked, fan, temp_fpga, temp_internal, temp_rf_channelA, temp_rf_channelB, temp_main_power, gps_gpgga, gps_sky, gps_time, gps_tpv
| _____________________________________________________
| /
| | RFNoC blocks on this device:
| |
| | * 0/Block#0
| | * 0/DDC#0
| | * 0/DUC#0
| | * 0/DmaFIFO#0
| | * 0/Radio#0
| _____________________________________________________
| /
| | Static connections on this device:
| |
| | * 0/SEP#0:0==>0/DUC#0:0
| | * 0/DUC#0:0==>0/Radio#0:0
| | * 0/Radio#0:0==>0/DDC#0:0
| | * 0/DDC#0:0==>0/SEP#0:0
| | * 0/SEP#1:0==>0/DUC#0:1
| | * 0/DUC#0:1==>0/Radio#0:1
| | * 0/Radio#0:1==>0/DDC#0:1
| | * 0/DDC#0:1==>0/SEP#1:0
| | * 0/SEP#2:0==>0/DmaFIFO#0:0
| | * 0/DmaFIFO#0:0==>0/SEP#2:0
| | * 0/SEP#3:0==>0/DmaFIFO#0:1
| | * 0/DmaFIFO#0:1==>0/SEP#3:0
| | * 0/SEP#4:0==>0/Block#0:0
| | * 0/Block#0:0==>0/SEP#4:0
| _____________________________________________________
| /
| | TX Dboard: dboard
| | _____________________________________________________
| | /
| | | TX Frontend: 0
| | | Name: E3xx
| | | Antennas: TX/RX
| | | Freq range: 47.000 to 6000.000 MHz
| | | Gain range PGA: 0.0 to 89.8 step 0.2 dB
| | | Bandwidth range: 20000000.0 to 40000000.0 step 0.0 Hz
| | | Connection Type: IQ
| | | Uses LO offset: No
| | _____________________________________________________
| | /
| | | TX Frontend: 1
| | | Name: E3xx
| | | Antennas: TX/RX
| | | Freq range: 47.000 to 6000.000 MHz
| | | Gain range PGA: 0.0 to 89.8 step 0.2 dB
| | | Bandwidth range: 20000000.0 to 40000000.0 step 0.0 Hz
| | | Connection Type: IQ
| | | Uses LO offset: No
| _____________________________________________________
| /
| | RX Dboard: dboard
| | _____________________________________________________
| | /
| | | RX Frontend: 0
| | | Name: E3xx
| | | Antennas: RX2, TX/RX
| | | Freq range: 70.000 to 6000.000 MHz
| | | Gain range PGA: 0.0 to 76.0 step 1.0 dB
| | | Bandwidth range: 20000000.0 to 40000000.0 step 0.0 Hz
| | | Connection Type: IQ
| | | Uses LO offset: No
| | _____________________________________________________
| | /
| | | RX Frontend: 1
| | | Name: E3xx
| | | Antennas: RX2, TX/RX
| | | Freq range: 70.000 to 6000.000 MHz
| | | Gain range PGA: 0.0 to 76.0 step 1.0 dB
| | | Bandwidth range: 20000000.0 to 40000000.0 step 0.0 Hz
| | | Connection Type: IQ
| | | Uses LO offset: No
From: Brian Padalino bpadalino@gmail.com
Sent: Friday, May 14, 2021 4:29 PM
To: Jeffrey P Long jplong@mitre.org
Cc: usrp-users@lists.ettus.com
Subject: [EXT] Re: [USRP-users] RFNOC block name?
On Fri, May 14, 2021 at 4:22 PM Jeffrey P Long <jplong@mitre.orgmailto:jplong@mitre.org> wrote:
I am going through the examples in
Getting Started with RFNoC in UHD 4.0 - Ettus Knowledge Basehttps://kb.ettus.com/Getting_Started_with_RFNoC_in_UHD_4.0
And I thought maybe I had messed something up but I noticed in the example the real block name is not there either
| _____________________________________________________
| /
| | RFNoC blocks on this device:
...
| | * 0/Block#0
...
| _____________________________________________________
| /
| | Static connections on this device:
...
| | * 0/SEP#4:0==>0/Block#0:0
| | * 0/Block#0:0==>0/SEP#4:0
...
Is there a reason why this does not get reflected in the usrp probe?
I am running it on a E320. I built my bit image using the OOT approach. Moved it over and the .so created for my block.
Do I need to bring over the block yml file or something?
Try setting the UHD_MODULE_PATH environment variable to the location of your .so file for your block and re-run the probe.
Brian
On Fri, May 14, 2021 at 5:48 PM Jeffrey P Long jplong@mitre.org wrote:
Ok I had it up in /usr/lib but I moved it down to the root folder and it
basically gave the same thing with additional errors:
Kind of look like it is still not finding it. Did I set it wrong?
root@ni-e320-31DCD15:/usr/lib# export UHD_MODULE_PATH=~/
root@ni-e320-31DCD15:/usr/lib# uhd_find_devices
Error: EnvironmentError: OSError: dlopen failed to load
"/home/root/.viminfo"
Error: EnvironmentError: OSError: dlopen failed to load
"/home/root/e320.bit"
Error: EnvironmentError: OSError: dlopen failed to load
"/home/root/librfnoc-txcore.so"
Error: EnvironmentError: OSError: dlopen failed to load
"/home/root/.bash_history"
[INFO] [UHD] linux; GNU C++ version 9.2.0; Boost_107100;
UHD_4.0.0.0-0-g90ce6062
-- UHD Device 0
Device Address:
serial: 31DCD15
claimed: False
mgmt_addr: 127.0.0.1
product: e320
type: e3xx
Maybe looks like it's compiled for a different architecture?
Specifically looking at:
Error: EnvironmentError: OSError: dlopen failed to load
"/home/root/librfnoc-txcore.so"
Guessing that .so is x86 and not arm?
Compile it for the target architecture it runs on?
Brian
Brian-
Ok I made sure I compiled for the ARM and to be honest I lost track of which terminal window I had sourced the SDK in so I was not sure and decided to redo it.
But you can see the cmake and make seem successful further down below.
Then I moved it to /usr/share/uhd/modules since I saw somewhere that it should load it from there but just in case I also set the module path for that.
root@ni-e320-31DCD15:/usr/share/uhd/modules# export UHD_MODULE_PATH=/usr/share/uhd/modules
and this time I got more info back about it not finding the block ID. I noticed in /usr/share/uhd there is a rfnoc directory with yml files for the blocks.
Do I need to put my blocks yml in there or something?
By the way is there an ettus tutorial on how to do OOT modules for an embedded target like the E320?
Thanks for your help on this.
Jeff
root@ni-e320-31DCD15:/usr/share/uhd/modules# uhd_usrp_probe
[INFO] [UHD] linux; GNU C++ version 9.2.0; Boost_107100; UHD_4.0.0.0-0-g90ce6062
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=127.0.0.1,type=e3xx,product=e320,serial=31DCD15,claimed=False
[INFO] [MPM.PeriphManager] init() called with device args `mgmt_addr=127.0.0.1,product=e320'.
[INFO] [0/Radio#0] Performing CODEC loopback test on channel 0 ...
[INFO] [0/Radio#0] CODEC loopback test passed
[INFO] [0/Radio#0] Performing CODEC loopback test on channel 1 ...
[INFO] [0/Radio#0] CODEC loopback test passed
[INFO] [0/DmaFIFO#0] BIST passed (Estimated Minimum Throughput: 1361 MB/s)
[INFO] [0/DmaFIFO#0] BIST passed (Estimated Minimum Throughput: 1361 MB/s)
[WARNING] [RFNOC::BLOCK_FACTORY] Could not find block with Noc-ID 0xde30, 0xffff
jplong@mm241897-pc:~/proj/ettus_e320/rfnoc-txcore/build-e320$ cmake -DUHD_FPGA_DIR=~/proj/uhd/fpga/ ../
-- Toolchain file defaulted to '/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/share/cmake/OEToolchainConfig.cmake'
-- The CXX compiler identification is GNU 9.2.0
-- The C compiler identification is GNU 9.2.0
-- Check for working CXX compiler: /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe-linux-gnueabi/arm-oe-linux-gnueabi-g++
-- Check for working CXX compiler: /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe-linux-gnueabi/arm-oe-linux-gnueabi-g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Check for working C compiler: /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe-linux-gnueabi/arm-oe-linux-gnueabi-gcc
-- Check for working C compiler: /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe-linux-gnueabi/arm-oe-linux-gnueabi-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Found UnixCommands: /usr/bin/bash
-- Found bash interpreter: /usr/bin/bash
-- Found PkgConfig: /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/pkg-config (found version "0.29.2")
-- Found UHD: /usr/local/oecore-x86_64/sysroots/cortexa9t2hf-neon-oe-linux-gnueabi/usr/lib/libuhd.so
-- Found UHD:
-- * INCLUDES = /usr/local/oecore-x86_64/sysroots/cortexa9t2hf-neon-oe-linux-gnueabi/usr/include
-- * LIBS = /usr/local/oecore-x86_64/sysroots/cortexa9t2hf-neon-oe-linux-gnueabi/usr/lib/libuhd.so
-- * rfnoc_image_builder = /usr/local/bin/rfnoc_image_builder
-- Checking FPGA source directory...
-- Using FPGA source directory: /home/jplong/proj/uhd/fpga
-- Registering RFNoC block: rfnoc_block_txcore
-- Adding testbench target: rfnoc_block_txcore_tb
-- Adding image core target: e320_rfnoc_image_core
-- Found Boost: /usr/local/oecore-x86_64/sysroots/cortexa9t2hf-neon-oe-linux-gnueabi/usr/lib/cmake/Boost-1.71.0/BoostConfig.cmake (found suitable version "1.71.0", minimum required is "1.58") found components: program_options system
-- Configuring done
-- Generating done
-- Build files have been written to: /home/jplong/proj/ettus_e320/rfnoc-txcore/build-e320
jplong@mm241897-pc:~/proj/ettus_e320/rfnoc-txcore/build-e320$ make -j8
Scanning dependencies of target rfnoc-txcore
[ 25%] Building CXX object lib/CMakeFiles/rfnoc-txcore.dir/txcore_block_control.cpp.o
[ 50%] Linking CXX shared library librfnoc-txcore.so
[ 50%] Built target rfnoc-txcore
Scanning dependencies of target txcore_block
[ 75%] Building CXX object apps/CMakeFiles/txcore_block.dir/txcore_block.cpp.o
[100%] Linking CXX executable txcore_block
[100%] Built target txcore_block
From: Brian Padalino bpadalino@gmail.com
Sent: Friday, May 14, 2021 6:04 PM
To: Jeffrey P Long jplong@mitre.org
Cc: usrp-users@lists.ettus.com
Subject: Re: [EXT] Re: [USRP-users] RFNOC block name?
On Fri, May 14, 2021 at 5:48 PM Jeffrey P Long <jplong@mitre.orgmailto:jplong@mitre.org> wrote:
Ok I had it up in /usr/lib but I moved it down to the root folder and it basically gave the same thing with additional errors:
Kind of look like it is still not finding it. Did I set it wrong?
root@ni-e320-31DCD15:/usr/lib# export UHD_MODULE_PATH=~/
root@ni-e320-31DCD15:/usr/lib# uhd_find_devices
Error: EnvironmentError: OSError: dlopen failed to load "/home/root/.viminfo"
Error: EnvironmentError: OSError: dlopen failed to load "/home/root/e320.bit"
Error: EnvironmentError: OSError: dlopen failed to load "/home/root/librfnoc-txcore.so"
Error: EnvironmentError: OSError: dlopen failed to load "/home/root/.bash_history"
[INFO] [UHD] linux; GNU C++ version 9.2.0; Boost_107100; UHD_4.0.0.0-0-g90ce6062
-- UHD Device 0
Device Address:
serial: 31DCD15
claimed: False
mgmt_addr: 127.0.0.1
product: e320
type: e3xx
Maybe looks like it's compiled for a different architecture?
Specifically looking at:
Error: EnvironmentError: OSError: dlopen failed to load "/home/root/librfnoc-txcore.so"
Guessing that .so is x86 and not arm?
Compile it for the target architecture it runs on?
Brian
Brian-
As a further test I moved the whole OOT module directory over to the device and cmake/make/install right on the device to see if it had some special sauce but no luck.
OK maybe this is a real problem that Ettus is not going to resolve for custom C++ work?
OOT RFNoC Block not propagating action in UHD4 · Issue #406 · EttusResearch/uhd · GitHubhttps://github.com/EttusResearch/uhd/issues/406
The solution according to this issue is to use gr-ettus etc.
I don’t use GNU radio and hoped to finally try RFNOC for real but it seems to still not be fully functional.
I am guessing that since my controller is looking for the real name or something its getting confused?
I have seen work arounds posted related to naming your OOT module “block” instead of something custom which seems limited. Also something about building the block controller in-tree. I suppose I could do that but I guess I would have to rebuild UHD and move it over.
What’s funny is that even in their OOT example on getting started with UHD 4.0 their gain block shows up generically as “block”. Somehow they did not notice that?
This is disappointing because I saw that press release where they claimed it’s the most tested release ever.
Jeff
From: Jeffrey P Long jplong@mitre.org
Sent: Saturday, May 15, 2021 6:07 PM
To: Brian Padalino bpadalino@gmail.com
Cc: usrp-users@lists.ettus.com
Subject: [USRP-users] Re: [EXT] Re: RFNOC block name?
Brian-
Ok I made sure I compiled for the ARM and to be honest I lost track of which terminal window I had sourced the SDK in so I was not sure and decided to redo it.
But you can see the cmake and make seem successful further down below.
Then I moved it to /usr/share/uhd/modules since I saw somewhere that it should load it from there but just in case I also set the module path for that.
root@ni-e320-31DCD15:/usr/share/uhd/modules# export UHD_MODULE_PATH=/usr/share/uhd/modules
and this time I got more info back about it not finding the block ID. I noticed in /usr/share/uhd there is a rfnoc directory with yml files for the blocks.
Do I need to put my blocks yml in there or something?
By the way is there an ettus tutorial on how to do OOT modules for an embedded target like the E320?
Thanks for your help on this.
Jeff
root@ni-e320-31DCD15:/usr/share/uhd/modules# uhd_usrp_probe
[INFO] [UHD] linux; GNU C++ version 9.2.0; Boost_107100; UHD_4.0.0.0-0-g90ce6062
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=127.0.0.1,type=e3xx,product=e320,serial=31DCD15,claimed=False
[INFO] [MPM.PeriphManager] init() called with device args `mgmt_addr=127.0.0.1,product=e320'.
[INFO] [0/Radio#0] Performing CODEC loopback test on channel 0 ...
[INFO] [0/Radio#0] CODEC loopback test passed
[INFO] [0/Radio#0] Performing CODEC loopback test on channel 1 ...
[INFO] [0/Radio#0] CODEC loopback test passed
[INFO] [0/DmaFIFO#0] BIST passed (Estimated Minimum Throughput: 1361 MB/s)
[INFO] [0/DmaFIFO#0] BIST passed (Estimated Minimum Throughput: 1361 MB/s)
[WARNING] [RFNOC::BLOCK_FACTORY] Could not find block with Noc-ID 0xde30, 0xffff
jplong@mm241897-pc:~/proj/ettus_e320/rfnoc-txcore/build-e320$ cmake -DUHD_FPGA_DIR=~/proj/uhd/fpga/ ../
-- Toolchain file defaulted to '/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/share/cmake/OEToolchainConfig.cmake'
-- The CXX compiler identification is GNU 9.2.0
-- The C compiler identification is GNU 9.2.0
-- Check for working CXX compiler: /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe-linux-gnueabi/arm-oe-linux-gnueabi-g++
-- Check for working CXX compiler: /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe-linux-gnueabi/arm-oe-linux-gnueabi-g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Check for working C compiler: /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe-linux-gnueabi/arm-oe-linux-gnueabi-gcc
-- Check for working C compiler: /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe-linux-gnueabi/arm-oe-linux-gnueabi-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Found UnixCommands: /usr/bin/bash
-- Found bash interpreter: /usr/bin/bash
-- Found PkgConfig: /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/pkg-config (found version "0.29.2")
-- Found UHD: /usr/local/oecore-x86_64/sysroots/cortexa9t2hf-neon-oe-linux-gnueabi/usr/lib/libuhd.so
-- Found UHD:
-- * INCLUDES = /usr/local/oecore-x86_64/sysroots/cortexa9t2hf-neon-oe-linux-gnueabi/usr/include
-- * LIBS = /usr/local/oecore-x86_64/sysroots/cortexa9t2hf-neon-oe-linux-gnueabi/usr/lib/libuhd.so
-- * rfnoc_image_builder = /usr/local/bin/rfnoc_image_builder
-- Checking FPGA source directory...
-- Using FPGA source directory: /home/jplong/proj/uhd/fpga
-- Registering RFNoC block: rfnoc_block_txcore
-- Adding testbench target: rfnoc_block_txcore_tb
-- Adding image core target: e320_rfnoc_image_core
-- Found Boost: /usr/local/oecore-x86_64/sysroots/cortexa9t2hf-neon-oe-linux-gnueabi/usr/lib/cmake/Boost-1.71.0/BoostConfig.cmake (found suitable version "1.71.0", minimum required is "1.58") found components: program_options system
-- Configuring done
-- Generating done
-- Build files have been written to: /home/jplong/proj/ettus_e320/rfnoc-txcore/build-e320
jplong@mm241897-pc:~/proj/ettus_e320/rfnoc-txcore/build-e320$ make -j8
Scanning dependencies of target rfnoc-txcore
[ 25%] Building CXX object lib/CMakeFiles/rfnoc-txcore.dir/txcore_block_control.cpp.o
[ 50%] Linking CXX shared library librfnoc-txcore.so
[ 50%] Built target rfnoc-txcore
Scanning dependencies of target txcore_block
[ 75%] Building CXX object apps/CMakeFiles/txcore_block.dir/txcore_block.cpp.o
[100%] Linking CXX executable txcore_block
[100%] Built target txcore_block
From: Brian Padalino <bpadalino@gmail.commailto:bpadalino@gmail.com>
Sent: Friday, May 14, 2021 6:04 PM
To: Jeffrey P Long <jplong@mitre.orgmailto:jplong@mitre.org>
Cc: usrp-users@lists.ettus.commailto:usrp-users@lists.ettus.com
Subject: Re: [EXT] Re: [USRP-users] RFNOC block name?
On Fri, May 14, 2021 at 5:48 PM Jeffrey P Long <jplong@mitre.orgmailto:jplong@mitre.org> wrote:
Ok I had it up in /usr/lib but I moved it down to the root folder and it basically gave the same thing with additional errors:
Kind of look like it is still not finding it. Did I set it wrong?
root@ni-e320-31DCD15:/usr/lib# export UHD_MODULE_PATH=~/
root@ni-e320-31DCD15:/usr/lib# uhd_find_devices
Error: EnvironmentError: OSError: dlopen failed to load "/home/root/.viminfo"
Error: EnvironmentError: OSError: dlopen failed to load "/home/root/e320.bit"
Error: EnvironmentError: OSError: dlopen failed to load "/home/root/librfnoc-txcore.so"
Error: EnvironmentError: OSError: dlopen failed to load "/home/root/.bash_history"
[INFO] [UHD] linux; GNU C++ version 9.2.0; Boost_107100; UHD_4.0.0.0-0-g90ce6062
-- UHD Device 0
Device Address:
serial: 31DCD15
claimed: False
mgmt_addr: 127.0.0.1
product: e320
type: e3xx
Maybe looks like it's compiled for a different architecture?
Specifically looking at:
Error: EnvironmentError: OSError: dlopen failed to load "/home/root/librfnoc-txcore.so"
Guessing that .so is x86 and not arm?
Compile it for the target architecture it runs on?
Brian
On Sat, May 15, 2021 at 7:17 PM Jeffrey P Long jplong@mitre.org wrote:
Brian-
As a further test I moved the whole OOT module directory over to the
device and cmake/make/install right on the device to see if it had some
special sauce but no luck.
OK maybe this is a real problem that Ettus is not going to resolve for
custom C++ work?
OOT RFNoC Block not propagating action in UHD4 · Issue #406 ·
EttusResearch/uhd · GitHub
https://github.com/EttusResearch/uhd/issues/406
The solution according to this issue is to use gr-ettus etc.
I don’t use GNU radio and hoped to finally try RFNOC for real but it seems
to still not be fully functional.
I am guessing that since my controller is looking for the real name or
something its getting confused?
I have seen work arounds posted related to naming your OOT module “block”
instead of something custom which seems limited. Also something about
building the block controller in-tree. I suppose I could do that but I
guess I would have to rebuild UHD and move it over.
These are all possibilities, but I am not a huge fan of them. I have been
successful using the UHD_MODULE_PATH way with my block controller defined
in the library.
What’s funny is that even in their OOT example on getting started with UHD
4.0 their gain block shows up generically as “block”. Somehow they did not
notice that?
The reason is because the C++ block really defines the block name, and the
YAML is not scanned during every load of UHD unlike the old RFNoC way where
the XML files were scanned every time UHD was loaded to build the registry
of blocks and names. It was a known design choice from what I understand.
Not sure why you can't get it to show up when the library is appropriately
defined and UHD_MODULE_PATH is also appropriately defined. What does your
txcore_block.cpp look like?
Brian
Brian-
I think I am getting closer here. I actually just went back to using network mode so I could debug my issues without the extra challenge of the crossdev. That is a real nice thing about the E320.
So I think the usrp probe will always come back with that error because there is no controller for your custom block in that usrp probe code (Sorry my terminology is probably wrong here). As you mention the generic name is just a fact of life however I really think the getting started guide should point that out so people know what to expect. With the proper block controller called with the correct noc ID registered it seems to work now.
Embedded mode should probably work now too however I think I am just going to continue in network till I get my custom design into the FPGA and then move it over.
Thanks for your help on this.
Jeff
From: Brian Padalino bpadalino@gmail.com
Sent: Monday, May 17, 2021 10:10 AM
To: Jeffrey P Long jplong@mitre.org
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Re: [EXT] Re: RFNOC block name?
On Sat, May 15, 2021 at 7:17 PM Jeffrey P Long <jplong@mitre.orgmailto:jplong@mitre.org> wrote:
Brian-
As a further test I moved the whole OOT module directory over to the device and cmake/make/install right on the device to see if it had some special sauce but no luck.
OK maybe this is a real problem that Ettus is not going to resolve for custom C++ work?
OOT RFNoC Block not propagating action in UHD4 · Issue #406 · EttusResearch/uhd · GitHubhttps://github.com/EttusResearch/uhd/issues/406
The solution according to this issue is to use gr-ettus etc.
I don’t use GNU radio and hoped to finally try RFNOC for real but it seems to still not be fully functional.
I am guessing that since my controller is looking for the real name or something its getting confused?
I have seen work arounds posted related to naming your OOT module “block” instead of something custom which seems limited. Also something about building the block controller in-tree. I suppose I could do that but I guess I would have to rebuild UHD and move it over.
These are all possibilities, but I am not a huge fan of them. I have been successful using the UHD_MODULE_PATH way with my block controller defined in the library.
What’s funny is that even in their OOT example on getting started with UHD 4.0 their gain block shows up generically as “block”. Somehow they did not notice that?
The reason is because the C++ block really defines the block name, and the YAML is not scanned during every load of UHD unlike the old RFNoC way where the XML files were scanned every time UHD was loaded to build the registry of blocks and names. It was a known design choice from what I understand.
Not sure why you can't get it to show up when the library is appropriately defined and UHD_MODULE_PATH is also appropriately defined. What does your txcore_block.cpp look like?
Brian
On Mon, May 17, 2021 at 11:04 AM Jeffrey P Long jplong@mitre.org wrote:
Brian-
I think I am getting closer here. I actually just went back to using
network mode so I could debug my issues without the extra challenge of the
crossdev. That is a real nice thing about the E320.
So I think the usrp probe will always come back with that error because
there is no controller for your custom block in that usrp probe code (Sorry
my terminology is probably wrong here). As you mention the generic name is
just a fact of life however I really think the getting started guide should
point that out so people know what to expect. With the proper block
controller called with the correct noc ID registered it seems to work now.
Embedded mode should probably work now too however I think I am just going
to continue in network till I get my custom design into the FPGA and then
move it over.
Thanks for your help on this.
Just to be clear, you were able to utilize the UHD_MODULE_PATH environment
variable to point to the shared library holding your controller code for
your custom block, and uhd_usrp_probe was able to come back with your
custom name instead of just Block. Correct?
Thanks,
Brian
Brian-
As I mentioned I have not gone back to the embedded mode and have been running in network mode. Since I am building directly on the x86 machine I just make install it and everything seems to be fine. Are you saying that if I also set that variable even in network mode I should see the correct block name come up? I can try that in a little bit.
Thanks
Jeff
From: Brian Padalino bpadalino@gmail.com
Sent: Monday, May 17, 2021 11:08 AM
To: Jeffrey P Long jplong@mitre.org
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Re: [EXT] Re: RFNOC block name?
On Mon, May 17, 2021 at 11:04 AM Jeffrey P Long <jplong@mitre.orgmailto:jplong@mitre.org> wrote:
Brian-
I think I am getting closer here. I actually just went back to using network mode so I could debug my issues without the extra challenge of the crossdev. That is a real nice thing about the E320.
So I think the usrp probe will always come back with that error because there is no controller for your custom block in that usrp probe code (Sorry my terminology is probably wrong here). As you mention the generic name is just a fact of life however I really think the getting started guide should point that out so people know what to expect. With the proper block controller called with the correct noc ID registered it seems to work now.
Embedded mode should probably work now too however I think I am just going to continue in network till I get my custom design into the FPGA and then move it over.
Thanks for your help on this.
Just to be clear, you were able to utilize the UHD_MODULE_PATH environment variable to point to the shared library holding your controller code for your custom block, and uhd_usrp_probe was able to come back with your custom name instead of just Block. Correct?
Thanks,
Brian
Brian-
OK just tried it and it does resolve the names now. In network mode the .so is installed in /usr/local/lib so it throws a bunch of errors trying to load everything else in that directory but when usrp probe does finally start executing it shows the correct block names. I suppose on the embedded target I could put the .so somewhere else to avoid all these other load attempts. Do you have a recommendation?
Thanks
Jeff
From: Brian Padalino bpadalino@gmail.com
Sent: Monday, May 17, 2021 11:08 AM
To: Jeffrey P Long jplong@mitre.org
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Re: [EXT] Re: RFNOC block name?
On Mon, May 17, 2021 at 11:04 AM Jeffrey P Long <jplong@mitre.orgmailto:jplong@mitre.org> wrote:
Brian-
I think I am getting closer here. I actually just went back to using network mode so I could debug my issues without the extra challenge of the crossdev. That is a real nice thing about the E320.
So I think the usrp probe will always come back with that error because there is no controller for your custom block in that usrp probe code (Sorry my terminology is probably wrong here). As you mention the generic name is just a fact of life however I really think the getting started guide should point that out so people know what to expect. With the proper block controller called with the correct noc ID registered it seems to work now.
Embedded mode should probably work now too however I think I am just going to continue in network till I get my custom design into the FPGA and then move it over.
Thanks for your help on this.
Just to be clear, you were able to utilize the UHD_MODULE_PATH environment variable to point to the shared library holding your controller code for your custom block, and uhd_usrp_probe was able to come back with your custom name instead of just Block. Correct?
Thanks,
Brian
On Mon, May 17, 2021 at 5:30 PM Jeffrey P Long jplong@mitre.org wrote:
Brian-
OK just tried it and it does resolve the names now. In network mode the
.so is installed in /usr/local/lib so it throws a bunch of errors trying to
load everything else in that directory but when usrp probe does finally
start executing it shows the correct block names. I suppose on the embedded
target I could put the .so somewhere else to avoid all these other load
attempts. Do you have a recommendation?
Probably some shared location that only has .so module files that UHD
should load for both network and embedded mode.
Since it's an environment variable you set, it can be anywhere.
I'm glad it works for you.
Brian