[casper] Re: Roach 2

[Matt Dexter]

Hi My,

the first couple of tests look pretty interesting:
11 and 3 devices are detected.
I can't remember such details so I'd have to check versus
a working board and look for differences in the messages.

Perhaps the latter tests are being performed correctly.
See "TDO seems to be stuck at 1".
Was the corresponding zero ohm resistor R467 removed as well as the
new jumper wires added ?

Matt


On Tue, 20 Oct 2020, My Nguyen wrote:


Date: Tue, 20 Oct 2020 14:23:10 -0700
From: My Nguyen 
To: Matt Dexter 
Cc: casper@lists.berkeley.edu
Subject: Re: Roach 2

Hi Matt,
I followed your instructions and here is the result (see attached document). 
I saw the message repeatedly c:117 and assumed it was C117 under the power PPC chip (U2)

so I replaced it with another one but it still failed. At this point I do not 
know what
caused it to fail because when I ran the JTAG boundary scan test with Provision 
app a
couple times (for each board) and it passed everything. Please advise.

MY NGUYEN
Digicom Electronics Inc.
7799 Pardee Lane, Oakland, CA 94621.Website: www.Digicom.org.
Direct Line : (510) 668-8443
Main line : (510) 639-7003
Email: myngu...@digicom.org


On Fri, Oct 16, 2020 at 8:36 AM My Nguyen  wrote:
  Good morning Matt,
Thanks for the info. I'll try and see what happens.
Have a good weekend and stay healthy.

MY NGUYEN
Digicom Electronics Inc.
7799 Pardee Lane, Oakland, CA 94621.Website: www.Digicom.org.
Direct Line : (510) 668-8443
Main line : (510) 639-7003
Email: myngu...@digicom.org


[icon-envelope-tick-green-avg-v1.png]
Virus-free. www.avg.com

On Thu, Oct 15, 2020 at 4:22 PM Matt Dexter  wrote:
  Hi My,

  I don't know what is going on.

  As usual Jack has wise comments.
  Alec really understood the JTAG scheme and worked on
  the low level diagnostics. He really knew that stuff but
  time is rough on all of our memories especially without
  frequent refresh cycles.

  You were smart to replace the FTDI chip (U33) as
  that part caused all sorts of such problems.  JTAG's
  TDO stuck high due to U33 nonsense comes to mind.

  You mention you wisely checked the JTAG Provision itself.
  There were all sorts of ?Windows OS? issues with getting
  that detected and running.  lots of memories of rebooting the PC
  un-mating the JTAG gizmo from the PC and
  then re-mating it, etc.  Silly stuff but cost lots of lost
  time.

  I scanned old notes and found during some debug sessions
  we changed(shortened) the JTAG chain by the use of the
  0 ohm resistors on the right hand side of page 26 of the
  schematics.  See R477, R478, ... R481, and so on.
  By removing some particular 0 ohm resistor and adding a
  jumper wire then JTAG chain can be (dramatically) shortened.
  Instead of the full 11 device chain does it work if
  there are only 6 or 3 or ... devices.

  For example (I think)
     remove 0ohm part from R467 (near U33)
     add wire from R478 (either pin; between J7,J7 Mezz) to R467 pad 2.
     verify: R478 is 0 ohms to U33-18.
     does JTAG chain see something like 3 devices ?
     say it does then ...
        move wire from R478 to R483 (either pin; near lower left of QDR
  2).
        does JTAG chain see something like 6 devices ?
        and so on.


  Other ancient notes also mention the rather un-exciting debug style of
  checking all the 0 ohm resistors in the JTAG chain such
  as R462, R464, ...
  At least 1 such resistor was not zero ohms (due to physical cracking).
  U77, U79, and U82 are critical and I think easy enough to
  ohm out and probe for toggling JTAG clock or whatever.
  U52 and U53 are critical too.
  I think a solder blob at U52 caused grief on at least 1 board.

  Good luck,

  Matt



  On Thu, 15 Oct 2020, My Nguyen wrote:

  > Date: Thu, 15 Oct 2020 12:07:20 -0700
  > From: My Nguyen 
  > To: Jack Hickish 
  > Cc: Matt Dexter 
  > Subject: Re: Roach 2
  >
  > Hi Jack,
  > No problem, I understand.
  > Have a great day and stay healthy.
  >
  > MY NGUYEN
  > Digicom Electronics Inc.
  > 7799 Pardee Lane, Oakland, CA 94621.Website: www.Digicom.org.
  > Direct Line : (510) 668-8443
  > Main line : (510) 639-7003
  > Email: myngu...@digicom.org
  >
  >
  > On Thu, Oct 15, 2020 at 12:05 PM Jack Hickish 
  wrote:
  >       Hi My,
  >
  > Good to hear from you. Things are going OK with me, all things
  considered. I hope
  > you're doing alright too.
  > I think this is a bit above my pay grade. Hopefully Matt can help,
  and if you're
  > lucky Alec Rust from South Africa will see your message and might
  have some words
  > of wisdom. But I fear very few people have any ROACH2 wisdom still in
  their
  > memories.
  >
  > Sorry to not be more help.
  > Jack
 

Re: [casper] Jasper error while compiling

[Guillermo Gancio]

Hi Jonathon,

Thanks for the ideas, I installed the KDE desktop, and I has available
to compile the tut_intro and tut_spec doing a
update_casper_blocks(bdroot), but they run only once, the second time
as before they seems to never end

I guess I have some bad environment config.I'll keep trying to
find the issue

Thanks again!



El lun., 19 oct. 2020 a las 20:52, Jonathon Kocz () escribió:
>
>
>> I'm working on Ubuntu 18, matlab 2019a and vivado 2019.1.3
>>
> So I hadn't tried these tutorials in 2019a, only 2018a. (See recommended 
> versions here: 
> https://casper-toolflow.readthedocs.io/en/latest/src/Installing-the-Toolflow.html
>  Vivado/Matlab are extraordinarily picky about which combinations will work)
>
> Just quickly testing:
>
> tut_intro ran, and took about 10 minutes.
>
> spec/corr would not compile without updating the blocks in 2019a. Did you run 
> update_casper_blocks / regen the fft with a new one from the library before 
> running jasper?
>
> So these ones not working *might* be a matlab version issue, but they should 
> work once you update the blocks.
>
>> I also tried tut_intro and I didnt get any error but it reaches
>> Skipping diagram update
>> Running system generator ...
>> and never finishes.
>
>
> This seems like something else.
>
> I'm wondering if this is an Ubuntu 18 issue - do you have kde installed? (See 
> this post by Jack in the mail archive: 
> https://www.mail-archive.com/casper@lists.berkeley.edu/msg07886.html). Even 
> though it's not quite the same, the timeout makes me wonder.
>
> Cheers,
> Jonathon
>
> --
> You received this message because you are subscribed to the Google Groups 
> "casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to casper+unsubscr...@lists.berkeley.edu.
> To view this discussion on the web visit 
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAPU71P_OcNnwtyZMWpUWaAqca5sAS%2B-9u28ZRDyQaaO7GPx-qw%40mail.gmail.com.



-- 
Instituto Argentino de Radioastronomia
[Argentine Institute of Radioastronomy]

Guillermo M. Gancio
Responsable Área Observatorio
[Head of Observatory]

Tel: (0054-0221) 482-4903 Int: 106
Mail laboralggan...@iar.unlp.edu.ar

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CA%2BEePfTfyUJFYbJCWfUQXxyPfHbr4AJJ6wYkJsv1bzhHjTKv0g%40mail.gmail.com.

Re: [casper] ROACH 2 10 GbE Troubleshooting

[Marc]

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
casper@lists.berkeley.edu  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  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 
>> casper@lists.berkeley.edu,  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 = 6
>>> 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 

Re: [casper] ROACH 2 10 GbE Troubleshooting

[Jack Hickish]

On Tue, 20 Oct 2020, 9:42 am 'Benjamin Godfrey' via
casper@lists.berkeley.edu,  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
>

As in, EOF pulses high for one clock, then goes low with valid? That sounds
fine.

- 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.
>

Yeah, that seems strange. It's always worth checking there isn't something
really wrong happening, like the core being locked in reset, or being
disabled from software. I believe there is a "print_core_details" of some
such, which will show you various internal core parameters.


> 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?
>

Ping definitely won't work without the tap interface. But if it doesn't
even work with that, I'm not sure I have any suggestions. I generally never
used the tap interface and just micromanaged the core configurations as you
are now doing.

Cheers
Jack

>
> I definitely have some paths to explore.
>
> Thanks,
> Ben G.
>
> On Tue, Oct 20, 2020 at 12:56 AM Jack Hickish 
> 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
>> casper@lists.berkeley.edu,  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 = 6*
>>> *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 

Re: [casper] ROACH 2 10 GbE Troubleshooting

['Benjamin Godfrey' via casper@lists.berkeley.edu]

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  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
> casper@lists.berkeley.edu,  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 = 6*
>> *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
>> "casper@lists.berkeley.edu" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> 

Re: [casper] ROACH 2 10 GbE Troubleshooting

[Jack Hickish]

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
casper@lists.berkeley.edu,  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 = 6*
> *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 "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> 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 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
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.