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 <martin.br...@ettus.com> 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 <r...@lmarlow.com> 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 -- usrp-users@lists.ettus.com >> To unsubscribe send an email to usrp-users-le...@lists.ettus.com >> > -- Ryan L. Marlow R L Marlow Consulting LLC rlmarlow.com
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
