Nevermind. I think I resolved my issue. The CHDR interface with int0 was coming up fine, I did something dumb on the FPGA side where the n3xx_db_fe_core ctrl port connections were disconnected from the Radio core. Hence the error:
> *[ERROR] [RFNOC::GRAPH] Caught exception while initializing graph: > RfnocError: OpTimeout: Control operation timed out waiting for ACK* > Best, Ryan On Fri, Mar 19, 2021 at 1:50 PM Ryan Marlow <[email protected]> wrote: > Related to my previous inquiry so continuing this thread... > Trying to get UHD to find the CHDR endpoint at the internal_eth core and > thinking I understand how UHD 4.0 works but struggling to see what's going > wrong. I remember encountering this situation in past N3xx experience but > can't remember exactly how it was resolved and that was years ago (pre UHD > 4.0) > I have UHD installed on the N3xx itself. Running into a roadblock on my > setup. The end result error is the following: > >> >> *[ERROR] [RFNOC::GRAPH] Error during initialization of block >> 0/Radio#0![ERROR] [RFNOC::GRAPH] Caught exception while initializing graph: >> RfnocError: OpTimeout: Control operation timed out waiting for ACK* >> > When I run uhd_find_devices I get the following response: > > -------------------------------------------------- >> -- UHD Device 0 >> -------------------------------------------------- >> Device Address: >> serial: 31DDAA2 >> claimed: False >> mgmt_addr: 127.0.0.1 >> product: n310 >> type: n3xx >> >> This indicates UHD connects to the mpm session but not the internal eth > interface right? > If I run uhd_usrp_probe (how I get the error above), I seem to get some > trace messages that indicate the CHDR interface over int0 is getting > established. See snippets below > > First I see this trace a few times: > >> [TRACE] [MPM.PeriphManager.UDP.UDP] Testing available interfaces out of >> `[]' >> [INFO] [MPM.PeriphManager.UDP.UDP] No CHDR interfaces found! >> > But then shortly after I see this: > >> [TRACE] [RFNOC::GRAPH] Initializing MB controllers... >> [TRACE] [RFNOC::GRAPH] Initializing GSM... >> [TRACE] [RFNOC::GRAPH] Creating packet factory with CHDR width 64 bits >> and endianness LITTLE >> [TRACE] [RFNOC::GRAPH] Found a total of 1 links. >> [TRACE] [UDP] Created UDP link to 169.254.0.2:49153 >> [TRACE] [UDP] Local UDP socket endpoint: 169.254.0.1:59692 >> > [TRACE] [UDP] Target/actual recv sock buff size: 2500000/2500000 bytes >> [TRACE] [UDP] Target/actual send sock buff size: 2500000/2500000 bytes >> [DEBUG] [RFNOC::MGMT] Starting topology discovery from device:2/sep:1 >> [DEBUG] [RFNOC::MGMT] Discovered node device:1/xport:0 >> [DEBUG] [RFNOC::MGMT] Initialized node device:1/xport:0 >> [DEBUG] [RFNOC::MGMT] Discovered node device:1/xbar:0 >> [DEBUG] [RFNOC::MGMT] Initialized node device:1/xbar:0 >> [TRACE] [RFNOC::MGMT] * device:1/xbar:0 has 3 ports, 1 transports and we >> are hooked up on port 0 >> [DEBUG] [RFNOC::MGMT] Discovered node device:1/sep:0 >> [DEBUG] [RFNOC::MGMT] Initialized node device:1/sep:0 >> [DEBUG] [RFNOC::MGMT] Discovered node device:1/sep:1 >> [DEBUG] [RFNOC::MGMT] Initialized node device:1/sep:1 >> [DEBUG] [RFNOC::MGMT] The following endpoints are reachable from >> device:2/sep:1 >> [DEBUG] [RFNOC::MGMT] * 1:0 >> [DEBUG] [RFNOC::MGMT] * 1:1 >> [TRACE] [RFNOC::GRAPH] Initializing blocks for MB 0... >> >> > These messages indicate there are packets going across the CHDR interface > right? I think all that topology stuff is CHDR traffic. I can see on > tcpdump that there's a lot of udp traffic going to/from the 169.254.0.2 > fpga IP address. > > Even eventually getting to some Radio0 trace msgs: > > [TRACE] [RFNOC::GRAPH] Flushing and resetting blocks on mboard 0 >> [DEBUG] [RFNOC] Created ctrlport endpoint for port 2 on EPID 1 >> [TRACE] [0/Radio#0] Using timebase clock: `radio_clk'. Current frequency: >> 122.88 MHz >> [TRACE] [0/Radio#0] Using ctrlport clock: `bus_clk'. Current frequency: >> 200 MHz >> [DEBUG] [0/Radio#0] Checking compat number for FPGA component >> `0/Radio#0': Expecting 0.0, actual: 0.0. >> [TRACE] [0/Radio#0] Loading radio with SPC=1, num_inputs=2, num_outputs=2 >> [TRACE] [0/Radio#0] Sending async messages to EPID 1, remote port 2, xbar >> port 1 >> [TRACE] [0/Radio#0] Entering magnesium_radio_control_impl ctor... >> > > And this msg that indicates that the int0 interface was identified as a > CHDR interface: > >> [TRACE] [MPM.PeriphManager.UDP.UDP] Testing available interfaces out of >>> `['int0']' >>> [DEBUG] [MPM.PeriphManager.UDP.UDP] Found CHDR interfaces: `int0' >>> [DEBUG] [MPM.misc-enet-int-regs] Setting my own IP address to >>> `169.254.0.1' >>> [TRACE] [MPM.lib] [MMAP_REGS_IFACE] [UIO /dev/uio11] Opened >>> mmap_regs_iface >>> [TRACE] [MPM.lib] [MMAP_REGS_IFACE] [UIO /dev/uio11] Closed >>> mmap_regs_iface >>> [TRACE] [MPM.lib] [MMAP_REGS_IFACE] [UIO /dev/uio11] Opened >>> mmap_regs_iface >>> [DEBUG] [MPM.misc-enet-int-regs] Setting internal MAC address to >>> `00:01:02:03:04:05' >>> [TRACE] [MPM.misc-enet-int-regs] Writing to address 0x0010: 0x2030405 >>> [TRACE] [MPM.misc-enet-int-regs] Writing to address 0x0014: 0x0001 >>> [DEBUG] [MPM.misc-enet-int-regs] Setting internal IP address to >>> `169.254.0.2' >>> [DEBUG] [MPM.misc-enet-int-regs] Setting internal Mode >>> >> > I guess what I'm getting at is what are some of the possible root causes > of this sort of error? Looking for any general advice. > It's worth noting that I removed both SFP connections from the chdr > crossbar. The only interface to the chdr network in my setup is the int0 > interface. I'm fairly certain my crossbar and static routing file are > configured correctly, I am working with a topology right now that is > similar to the E310. > > Thanks, > Ryan > > > On Tue, Mar 16, 2021 at 12:54 PM Martin Braun <[email protected]> > wrote: > >> You can't ping it using the 'ping' command (as you've probably found out >> yourself). We don't implement this outside of UHD, but UHD sends out >> discovery management packets into that network to see what's on the other >> side (e.g., a crossbar). You could forge one of those and send it in there >> via UHD, but you'd have to figure out the packet format from the RFNoC spec >> and the source code. >> >> --M >> >> On Tue, Mar 16, 2021 at 4:20 PM Ryan Marlow <[email protected]> wrote: >> >>> Hello All, >>> I have kinda an obscure/deep question about the functionality of the >>> internal ethernet interface on the N3xx. It is my understanding that this >>> interface (int0) connects the linux OS on the ARM to the CHDR/RFNoC network >>> on FPGA so you can run UHD on the N3xx ARM itself. To verify the >>> functionality of this interface, can I "ping" the IP address (defaults to >>> 192.168.10.2) of the FPGA side on that interface and expect a response? >>> Using tcpdump, I can see ARP request and replies. Just curious if anyone >>> has suggestions of sanity checks that are simpler than running >>> uhd_find_devices or uhd_usrp_probe to verify the integrity of that >>> interface connection. >>> Thanks, >>> Ryan Marlow >>> >>> -- >>> Ryan L. Marlow >>> R L Marlow Consulting LLC >>> rlmarlow.com >>> _______________________________________________ >>> USRP-users mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> >> > > -- > Ryan L. Marlow > R L Marlow Consulting LLC > rlmarlow.com > -- Ryan L. Marlow R L Marlow Consulting LLC rlmarlow.com
_______________________________________________ USRP-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
