Hi Marc and Jack, Thank you again for all the suggestions. After fiddling for a while, the answer ended up being sillier than I expected: I had selected the wrong slot number on the ten gbe yellow block, and I was also using the wrong SFP+ port on the PC side of things. No doubt there will be other issues that come up, but I can at least digitize mock data using the ROACH2 and read it using a Python script now.
- Ben G. On Tue, Oct 20, 2020 at 3:02 AM Marc <[email protected]> wrote: > Hi > > Hmm... if you are capable of pinging things in one direction, then > tcpborphserver is at least partially up - amongst other things, it is > responsible for picking up frames from the fpga and handing them > off to the kernel, which then does the IP logic and vice versa. > > You seem to have problems with arp, and say that you have > prepopulated the arp tables on the roach with set arp - maybe > you will have to do the same on the PC side. Linux at least > as an "arp -s" command to hardcode them into the PC arp > cache (cat /proc/net/arp). > > Note that the roaches do arp in an usual way - they iterate over > the subnet (fixed size) and query the hardware addresses > periodically and pre-emptively, unlike normal arp which only does > that on demand. This is needed as the ppc/tcpborphserver > might have no idea which stations the fpga is trying > to reach. So if you run tcpdump on a PC, you should > see these queries all the time, if the tap device is up. > > There are commands like ?tap-info and ?tap-arp-reload > which might give you more detail, either on the roach > type "kcpcmd tap-info", or remotely > > echo "?tap-info" | nc -q 2 -w 2 ip-of-roach 7147 > > Note that you will have to use those commands, rather > then looking in /proc/net/arp on the roach, as arp > isn't handled by the ppc linux kernel - those tables > have to be shared with the fpga. > > regards > > marc > > On Tue, Oct 20, 2020 at 8:42 AM 'Benjamin Godfrey' via > [email protected] <[email protected]> wrote: > > > > Hi Jack, > > Thank you for all your suggestions. Really appreciate all the > troubleshooting help. Going through your suggestions in order: > > > > - EOF is going low with the final valid signal in simulation > > - But valid is always high when I read the snapshot block, which is > unexpected (need to dig further to figure out why this is happening). EOF, > though, is still going high for one clock cycle at the expected time. > > - Reading from the transmit full output reports false, but I don't > really understand this since the valid signal is always high. > > > > I was having issues with the tap interface populating the ARP table with > correct addresses so I've now taken to populating it manually (using > set_arp_table, which I found in the docs). Furthermore, I've had problems > being able to ping the ROACH from the PC. I am now able to ping the PC > logged into the ROACH, but I am unable to ping the ROACH from the PC side. > Do you know why this may be the case? > > > > I definitely have some paths to explore. > > > > Thanks, > > Ben G. > > > > On Tue, Oct 20, 2020 at 12:56 AM Jack Hickish <[email protected]> > wrote: > >> > >> Hi Ben, > >> > >> Before getting too far into the power PC software side, some basic > checks in firmware which are probably worth doing - > >> > >> - does EOF go high with (not after) the last valid sample? > >> - can you (using a snapshot block) verify that what is happening in > firmware with the vld / EOF signals matches your simulation? > >> - do you have the ability to read the Tge overflow outputs, which are a > good indicator of something going awry? > >> > >> If you compile with the "enable core on startup" option on the The > block checked, you should be able to transmit regardless of the software > "tap" interface. The tap interface is needed to handle things like ARP, but > even without it you should see packets coming out of your board on tcpdump, > even if they all have the wrong destination MAC addresses. > >> > >> Good luck! > >> > >> Jack > >> > >> > >> On Mon, 19 Oct 2020, 6:48 pm 'Benjamin Godfrey' via > [email protected], <[email protected]> wrote: > >>> > >>> Hi everyone, > >>> I've been getting my feet wet the last little while introducing > myself to using the ROACH 2 toolset. After being unable to get Tutorial 2 > to work out of the box, I took a step back and am trying to just transmit > packets using the SFP+ port to my PC and read them out. My design is > heavily based on the one in the Roach 2 tutorial except that I am using the > katadc to generate data. What I've tried so far is detailed below: > >>> > >>> Right now, I am trying to send 64, 64-bit samples at ~390 kHz (feeding > in an 800 MHz clock) so I shouldn't be overfilling buffers. In simulation, > it looks like tx_valid and tx_end_of_frame are both being set as I would > expect, namely tx_valid goes high whenever I am sending data and > tx_end_of_frame goes high for one clock cycle at the end of when I expect > to send data. > >>> > >>> On the PC side of things, I also wasn't able to get the Python script > to work out of the box, so I modified it a little bit using suggestions > from the mail archives. The important details are below: > >>> > >>> ip_base = 192*(2**24) + 168*(2**16) + 41*(2**8) > >>> mac_base = (2<<40) + (2<<32) > >>> fabric_port = 60000 > >>> gbe_tx = casperfpga.tengbe.TenGbe(fpga, 'gbe0', ip_base+20, 512) > >>> gbe_tx.setup(mac_base+20, ip_base+20, fabric_port) > >>> gbe_tx.tap_start() > >>> > >>> I am trying to write data to 192.168.41.1 (same subnet as the ROACH2), > on my PC, connected to the ROACH2 using an SFP+ cable. To do this, I've > used the socket library in Python configured to listen for UDP packets at > the required IP/port. However, I am unable to get any data from the ROACH2 > whatsoever. I've looked to see if I have any packets coming over the port > using Wireshark and I see nothing. > >>> > >>> Something that I've noticed, is that I am unable to ping the gbe port > (after writing the design to the board). When I look at ifconfig after > ssh-ing into the ROACH, I see the following: > >>> > >>> gbe 0 Link encap: UNSPEC HWaddr > 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 > >>> inet addr:192.168.41.20 P-t-P:192.168.41.20 > Mask:255.255.255.0 > >>> UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 > >>> RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > >>> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > >>> collisions:0 txqueuelen: 500 > >>> RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) > >>> > >>> I think this looks reasonable other than the lack of packets being > sent. I'm now off playing with routing tables thinking that this may be my > issue, but I am honestly pretty in the weeds at this point. Do you guys > have some suggestions? I'm sure there are a few things I've fouled up along > the way. > >>> > >>> Thanks for the help, > >>> Ben G. > >>> > >>> -- > >>> You received this message because you are subscribed to the Google > Groups "[email protected]" group. > >>> To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected]. > >>> To view this discussion on the web visit > https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/4634df92-fb67-4bf5-bcab-22478a4c952cn%40lists.berkeley.edu > . > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups "[email protected]" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected]. > >> To view this discussion on the web visit > https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAG1GKS%3D2h_S-rwBOJKSc%3D7-EXt8zDDeCeBC%2BYnKREuevOZJN9w%40mail.gmail.com > . > > > > -- > > You received this message because you are subscribed to the Google > Groups "[email protected]" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected]. > > To view this discussion on the web visit > https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAERfaAhVn0MBUMApKy%2BECvhp%2B-vbo_%2BxWTUh2VYSSvwZAbNPzQ%40mail.gmail.com > . > > > > -- > https://katfs.kat.ac.za/~marc/ > > -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAGrhWaRPp_eyZ1aez%3DemSnONwzPPwNncbmRe0n1iU_oTUP-%3DhQ%40mail.gmail.com > . > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAERfaAh_ojtRhpSkJfVcab1oqXT9NSB%3D1XvTgjtXy9apnAZBiA%40mail.gmail.com.
