Re: [casper] Question on Casperfpga python 3.8 version

[Marc]

Hi

The skarabs can be programmed using the progska utility directly, and it
accepts repeated -vvv flags to report more detail. so that partitions the
problem space to exclude python version issues.

progska uses bin file, if you don't have that handy, it can be extracted
from an fpg file by removing everthing up to and including the ?quit. "vim
-b" should work.

I suspect the mtu on your network card isn't set high enough. progska needs
jumbograms.

regards

marc







On Wed, Aug 30, 2023 at 9:03 PM 'Kobesky, Jeffrey CIV USN NRL (5533)
Washington DC (USA)' via casper@lists.berkeley.edu <
casper@lists.berkeley.edu> wrote:

> Hi, I think my questions are for Adam and Co., I can program a .fpg file
> into Red Pitaya but I cannot program one into SKARAB. Please see
> attachments, note errors in SKARAB programming screenshot and also note
> fpga.is_connected()=True. I’m using: Toolflow: Ubuntu 18.04LTS,
> Python ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌
>
> <https://za.report.cybergraph.mimecast.com/alert-details/?dep=mSxqzJffq5FCF70irnHanw%3D%3DCCXHc9ZWoPqIiT6DF%2BW73DxtiQuVrpsmupvv7hqGxBQcFIuPhv5X7hItK%2FToMGfXL4MZS3RmlLw6sz3v1XAIgyZ3aXKOFcTyUuKuy%2FMh%2BLkgcLugh%2F9VndZDe6RVQ6Hj3WJY6avgJagQ4WNSLXECfBtD3ocqPfUdnFhehg7rJIWOajC994G0e%2BFVpbIdoBWwvGTB4AZbxW9HY2s2Zfg3oCwahTC%2F1Eg2ATYxON8bR%2FUWnZGmwOYdwVvYGMBicK59GPG68M4DgYeTc6Co1RxQXM4Usqk2SGBse%2B4GUMiH1TeYDQvZsZF6tcO3K6GhiAslMA5oM%2BIcjhzZ6Y3YH7mUBQduI3pblXgfSpINon8ikNwLliKM%2BWtR7%2FoRUYqYBXKtLnInhvaEkI4nQinum7a7SLGcOygQkaoT4bLZEf9nC8cW9Y2GOB1d3Pe2E1c7W48LbZcdHTxOpHlltO3YAKyg4C64ZITaJywB%2BC1LM3NWEugIPjxoxMVo%2FQ%2F0IGWxw92CebO10qpTxoUeqoMaYWyTemna%2Fcbzd7bscQf6wjGR2lvCl4us0hUdz1WSmAlC8KTeg9r4bFiq5MTcz5BbDFLA1Bgh1tl0kcwGZIehF0CcnpJlQn%2FYiwVi%2BPHu9BTDcYmS1Ts787jKPM9l4%2BKY7GmH3EwYw%2FEXYkqE2TwGDvbMZ92p98XUN1rhvAX4EGCZm5j%2BPIxsfEOtjRouK1ZcCwECrw%3D%3D>
>
> Hi, I think my questions are for Adam and Co.,
>
>
>
> I can program a .fpg file into Red Pitaya but I cannot program one into
> SKARAB.  Please see attachments, note errors in SKARAB programming
> screenshot and also note fpga.is_connected()=True.
>
>
>
> I’m using:
>
> Toolflow: Ubuntu 18.04LTS, Python 3.6 (Virtual environment), Matlab
> R2018a, Vivado 2019.1.1.
>
> casperfpga: Ubuntu 18.04LTS, Python 2.7 (non-Virtual environment)
>
>
>
> Note I’m using non-virtual environment for casperfpga.  I’ve looked at
> older emails from Adam where he used non-virtual for casperfpga, but below
> specifies virtual.  Has something changed/been discovered with programming
> SKARAB?  Not sure why my non-virtual environment would work for Pitaya but
> not SKARAB.
>
>
>
> Things I’ve considered or tried include:
>
>
>
>- Able to ping SKARAB copper port and fiber ports.
>- Set mtu=9000 on my hos

Re: [casper] Roach2 progremote error & CASPER slack account

[Marc]

Hi

So that does look like an older version of tcpborphserver - if my history
is correct, that version doesn't even have a ?progremote command yet,
though it should have an ?upload command which does something similar.

I suppose you could run ?status or ?fpgastatus to confirm that the fpga
hasn't been programmed or try to run ?upload port filename (and a second
netcat connection to that port parameter, like ftp does it) to attempt an
upload by hand, but I suspect it would be easier to find a newer filesystem
image.

Hopefully the wiki's or somebody else can point you at the authoritative
new version of the romfs (or nfs image) - while there are several images in
one of the ska-sa repositories on github, it is probably best to pick the
one the community is using.

regards

marc






On Sat, Apr 1, 2023 at 6:15 PM Austin Dymont  wrote:

> Hi Marc,Thanks for the rapid response. Here's the log-lvl info. Trying
> 192.168.4.20...Connected to 192.168.4.20.Escape character is '^]'.#version
> memcpy-88-g38ad77a-dirty#build-state 2013-04-11T11:50:43?log-level
> debug!log-level ok debug#log info 1133318717282 raw
> new\_client\_co ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌
>
> <https://za.report.cybergraph.mimecast.com/alert-details/?dep=wyezVTpwtzojBu2qCXQK0g%3D%3DjTazUDg73xU3GUzq9DFKa8wUK5TzvWw855asR5hplkKt7tTxmCHgIcuQM%2BlEfdIgTMgdaE1Ee65xzN0J291tZBnDuUaRIu0Km19uXiqByD4Mq0bvLWYVM5abUXE377l5YJfDmh5Tm4w7VfPfDmibUZ51QQOpLnH0YyxMAyQ4azc%2FTdi6hgjel1wRCljQXTuy9B9n6VMgdYqEGR6uDh75SMLf7FpOf9vb1gapRwKZs2fM8Sopl%2Bh5BMeZlQehjlbmUBbBIlf0BFWt2ub350UIAqNVHajZI1L1HZg3QT8MW5wGXbTcBjxaGQl7gUpaa%2FZbczxqvlrDf09r6tqTeWMri2l6n2sganGy%2FMTHHOWHkIdgim5%2FDdf%2BJDbKNq312qkGPCEtKD8Wmu9umx0rFCkfTosQx%2B%2F%2FIizOe7bslkZLMed3Xqui7XSDNnooksqAfRMYqW8zdvPxRygKu7JIRR4k0qyhGQej1wHlZnQyNQWxzONmsLWErZxKogaLFX4ol13KDizwBM2obKv%2B1qz3Dx5cE62beAX%2B8Dp4WzOrZhgItdoXKtD1eYWmKVy29SF9QNI%2BnKWKluHumD197aGXLrVpNx16h92dNdbrf7hCib4JgCu%2BTWrzFdd7%2F0OgBsrn5XCDsX0Bts3pnhEpY0JAvOuDmYbKNrbuxbKTpaUOtaxmFro%3D>
> Hi Marc,
>
> Thanks for the rapid response. Here's the log-lvl info.
>
> Trying 192.168.4.20...
> Connected to 192.168.4.20.
> Escape character is '^]'.
> #version memcpy-88-g38ad77a-dirty
> #build-state 2013-04-11T11:50:43
> ?log-level debug
> !log-level ok debug
> #log info 1133318717282 raw new\_client\_connection\_192.168.4.1:38120
> #client-connected 192.168.4.1:38120
> #log info 1133318717284 raw received\_end\_of\_file\_from\_
> 192.168.4.1:38120
> #client-disconnected 192.168.4.1:38120
> #log info 1133318717286 raw new\_client\_connection\_192.168.4.1:38128
> #client-connected 192.168.4.1:38128
> #log debug 1133318717287 raw client\_message\_
> #log debug 1133318717289 raw client\_message\_
> #log error 1133318717289 raw fpga\_not\_programmed
> #log debug 1133318717291 raw clien

Re: [casper] Roach2 progremote error & CASPER slack account

[Marc]

On Fri, Mar 31, 2023 at 6:38 PM Austin Dymont  wrote:

> Hello,My name is Austin Dymont, a new graduate student at the University
> of Chicago. I'm in need some help regarding the setup of a ROACH2. I'm
> running into an issue with programming the roach with a new .fpg file. I
> followed through with some of the intro tutorial from the
> toolf ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ 
> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌
>
> <https://za.report.cybergraph.mimecast.com/alert-details/?dep=eoqFolyS2MxvE7m0loFNxQ%3D%3DJTcjHkgSA0QZMPY6whICPnrldIVnUa89NkzAq6DysXl63ilh1bP9MY0saTycOTw0zacVH483qzk6NTqPMP6oIrMEUejDMxJgHWaHGvfKZc6vDMVF1JFMfKCkbOrMSCYHAnxHu22wgsxVKGIihA8RHdIHGHXDtkPDtc0DrSOOEM0ObUfckY9YTnIymjdomksAWkMLOSOFQ0qXxvJe9s%2FBVgokPJflkjaSGemUNfafp3VuxNKrrvbisoVd9Myd4RMtV5TGzWnTWQGBACJ7bpJkbh97FPQ7Jq0aI7CuRlbtvXo0kEAPsLP%2BXUG6hqf2uUvPbGcnJ1L6FT3bntAujQoa0uVhM%2BsEIZxUoPUZihvn1pM9ty%2BLYsJ1NJu9aqAfh3OB%2F6S%2FmfaaghPeVcfyk1zjzMoSAIbG4fs6ODFOeOBkEtjWe1XswFdR2jfCull4wP51QQdiwbKfOf4bNT7h4YkIkEfC7xTiLRqzspx98i9RVvjtR%2Ff4UqqZTVuSfbVqv2T25z1bf4jSwG9atKeIPFzQNXuEbdhStcXevNU5nW0CI7w%3D>
> Hello,
>

Hi


> My name is Austin Dymont, a new graduate student at the University of
> Chicago. I'm in need some help regarding the setup of a ROACH2. I'm running
> into an issue with programming the roach with a new .fpg file. I followed
> through with some of the intro tutorial from the toolflow
> <https://casper-toolflow.readthedocs.io/projects/tutorials/en/latest/tutorials/roach/tut_intro.html>.
> The tutorial was able to connect to the ROACH2 and begin talking to it,
> checked by pinging and the is_connected() returned true. It errored when it
> tried to run progremote.
>
> INFO:192.168.X.XX:192.168.X.XX: uploading 
> tutorial/roach2/tut_intro/roach2_tut_intro.fpg, programming when done
> 
> ('progremote request(Request to client 192.168.X.XX failed.) on host 
> 192.168.X.XX failed',))
>
>

 If you telnet (or nc) to the roach on port 7147 while you do this, there
might be some messages telling us a bit more. And if you type

?log-level debug

on that connection, you might get more detailed feedback. Let us know what
you see and hopefully we can point you in the right direction.

On that connection you could also try to program fpg files by hand, though
that will involve a second netcat - it works in a similar way to ftp.

Regarding the uboot prompt: There are standalone tftp servers as well as
one part of dnsmasq, and if you do a printenv at the uboot prompt you can
see what those run macros expand to, so you could run the tftp get by hand
too...

I'd put off reflashing uboot until later, if that goes wrong then it
becomes quite a bit more tricky to recover

regards

marc

Disclaimer

The information contained in this communication from the sender is 
confidential. It is intended solely for use by the 

Re: [casper] Help with ROACH2 uboot issue

[Marc]

Hello

So first check if the kernel you are booting knows about nfs by doing
a "cat /proc/filesystems".

If so then try specifying the filesystem type explicity, using a "-t
nfs". If I recall correctly the mount executable is busybox, so might
not be as featureful as the mount we normally encounter.

regards

marc

On Wed, Aug 24, 2022 at 3:54 PM Gary, Dale E  wrote:
>
> Marc, I tried soloboot and it did let me log in, but I couldn't seem to 
> create a mount point.  The filesystem shows
>
> Filesystem   1K-blocks  Used Available Use% Mounted on
> /dev/root 6641  6641 0 100% /
> /dev/mtdblock2   49152  1352 47800   3% /usr
> tmpfs   387004 8386996   0% /var
>
> and I was able to make a directory /usr/local/ovsasrv, but when I tried to 
> mount into that I got
>
> ~ # mount 192.100.16.206/srv/roach2_boot/etch /usr/local/ovsasrv
> mount: mounting 192.100.16.206/srv/roach2_boot/etch on /usr/local/ovsasrv 
> failed: No such file or directory
>
>
> I also tried to mount into /tmp, /usr/tmp, and other places but got the same 
> result.  I created an empty file in /usr/local/ovsasrv thinking I would get a 
> different error like "directory not empty" but it still gave the above error. 
>  Can you suggest something else to test local mounting in soloboot?
>
> Regards,
> Dale
>
> On Wed, Aug 24, 2022 at 3:05 AM Marc  wrote:
>>
>> On Wed, Aug 24, 2022 at 12:57 AM Gary, Dale E  wrote:
>> >
>> > Hi Dave,
>> >
>> > There is only one interface on the server.  I am not actually sure how it 
>> > works with the private network, but it is not a dedicated NIC.  I was 
>> > using dnsmasq on the old server but when I changed to the new one I was 
>> > trying not to use it.  Since I can mount the share on another client on 
>> > the private network I don't understand why the ROACH can't do it.  I tried 
>> > the nolock option also, and specifying vers=3.  Nothing makes any 
>> > difference.
>>
>> Perhaps try soloboot the roach and try to mount the nfs share in some
>> random subdirectory - maybe the error messages are more informative
>> there ? I'd try to go with nolock and an earlier NFS version across
>> UDP, at least initially. That might give you an idea what
>> versions/options the roaches understand.
>>
>> regards
>>
>> marc
>>
>> --
>> https://katfs.kat.ac.za/~marc/
>>
>> --
>> 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/CAGrhWaTVAsJD-Tn1z3w_dLwtEdZant%2Bz2Sn5C%2BG1fQw0Rjk9Bw%40mail.gmail.com.
>
> --
> 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/CAKeNqUjvfnXQCLj%3DnHnJ%2B62v1KywYPzEobdwHqae2Vr5i18Juw%40mail.gmail.com.



-- 
https://katfs.kat.ac.za/~marc/

-- 
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/CAGrhWaT0k%3DExNRVD6gqKUKH%2Bv3R3AmQPGYkYM6BpXjAhOGXnVg%40mail.gmail.com.

Re: [casper] Help with ROACH2 uboot issue

[Marc]

On Wed, Aug 24, 2022 at 12:57 AM Gary, Dale E  wrote:
>
> Hi Dave,
>
> There is only one interface on the server.  I am not actually sure how it 
> works with the private network, but it is not a dedicated NIC.  I was using 
> dnsmasq on the old server but when I changed to the new one I was trying not 
> to use it.  Since I can mount the share on another client on the private 
> network I don't understand why the ROACH can't do it.  I tried the nolock 
> option also, and specifying vers=3.  Nothing makes any difference.

Perhaps try soloboot the roach and try to mount the nfs share in some
random subdirectory - maybe the error messages are more informative
there ? I'd try to go with nolock and an earlier NFS version across
UDP, at least initially. That might give you an idea what
versions/options the roaches understand.

regards

marc

-- 
https://katfs.kat.ac.za/~marc/

-- 
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/CAGrhWaTVAsJD-Tn1z3w_dLwtEdZant%2Bz2Sn5C%2BG1fQw0Rjk9Bw%40mail.gmail.com.

Re: [casper] Help with ROACH2 uboot issue

[Marc]

Hi

So it might be worth checking if your new server actually exports the
NFS filesystem - "showmount -e localhost" might be a first start, but
perhaps a better approach would be to try and mount the filesystem on
a normal PC ?

Other things to try might be the "nolock" option - I am hazy on the
detail, but I don't think the roaches are running a lock manager

The roaches get their command line via uboot, which can be
interrupted, and the commandline inspected by typing "printenv". I
remember the variables being nested - so the "bootargs" variable would
contain references other ${variables}. Be careful to escape them
propery, and only use saveenv once you are sure they do what you want.

All the best and regards

marc



On Tue, Aug 23, 2022 at 7:08 PM Gary, Dale E  wrote:
>
> Hi All,
>
> I upgraded my remote boot server to a new machine running ubuntu 20.04, and 
> although I tried to set everything up the same for remote booting the 
> ROACH2s, the process fails as shown in the attached file because the root 
> file system could not be mounted.  I found one suggestion on the web to edit 
> the Linux/PPC load configuration to add vers=4,tcp to the line, i.e. it might 
> look like this:
>
> root=/dev/nfs nfsroot=192.100.16.206:/srv/roach2_boot/etch,vers=4,tcp ip=dhcp
>
> but I cannot find any file where that configuration is set.  There is a file 
> in /srv/roach2_boot called pxelinux.cfg that looks promising, but it is an 
> empty file.  Am I on the right track?
>
> Any suggestions?
> Thanks,
> Dale
>
>
> --
> 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/CAKeNqUiMwt1RWdSmW6qACbPptY_Dfc1TYiddZa6CdTdUDkDGSA%40mail.gmail.com.



-- 
https://katfs.kat.ac.za/~marc/

-- 
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/CAGrhWaT4ZYUX5SKKkxC054rF_pZiTcGB12s3RiSS9wZ3Jd-DUQ%40mail.gmail.com.

Re: [casper] Hola Jack!

[Marc]

There is a version of the tcpborphserver binary at

https://github.com/ska-sa/roach2_nfs_uboot/tree/master/boot

(apologies for the github link)

I am not sure if it is exactly the version mentioned above, but it
looks newer, so should hopefully contain all the important bugfixes

If you are feeling adventureous you could get hold of a powerpc
toolchain (ftp.denx.de has one prebuilt, I think) and build it from
source too

regards

marc

On Thu, Jul 28, 2022 at 11:13 PM Rolando Paz  wrote:
>
> Thanks for the information.
> If anyone has a copy of this file, I'd appreciate it if you share a copy with 
> me...
>
> Regards
>
> Rolando
>
> El jue, 28 jul 2022 a las 12:30, David Harold Edward MacMahon 
> () escribió:
>>
>> It’s possible that the ROACH directories were not migrated to git.  I 
>> couldn’t find any evidence of a “roach” directory in the history of the 
>> casper-astro mlib_devel repo. :(
>>
>> Dave
>>
>> On Jul 28, 2022, at 11:09 AM, Jack Hickish  wrote:
>>
>>
>>
>> On Thu, 28 Jul 2022 at 18:59, Rolando Paz  wrote:
>>>
>>> Thanks Jack
>>>
>>> Do you know where I can find this file?
>>>
>>> https://casper.berkeley.edu/svn/trunk/roach/sw/binaries/tcpborphserver/tcpborphserver2-2010-04-02-tgtap
>>
>>
>> I actually don't. Does anyone know whether the svn server on the old 
>> casper.berkeley.edu server was migrated to casper.astro.berkeley.edu?
>>
>> J
>>
>>>
>>> Regards
>>>
>>> Rolando
>>>
>>> El mié, 27 jul 2022 a las 6:02, Jack Hickish () 
>>> escribió:
>>>>
>>>> Hi Rolando, list,
>>>>
>>>> Googling the issue, I think you want this solution -- 
>>>> https://unix.stackexchange.com/questions/340844/how-to-enable-diffie-hellman-group1-sha1-key-exchange-on-debian-8-0
>>>> The issue is that the ROACH version of openSSH is old, and only seems to 
>>>> support deprecated key exchange methods which your newer clients don't 
>>>> like. Probably a better solution is to update the openssh server, but I 
>>>> don't know how trivial a task this is.
>>>>
>>>> Cheers
>>>> Jack
>>>>
>>>> On Wed, 27 Jul 2022 at 03:19, Rolando Paz  wrote:
>>>>>
>>>>> :)
>>>>> I hope you are well Jack.
>>>>>
>>>>> I'm still trying to get permission to implement the roach and my 
>>>>> front-end in a 35m antenna here in Guatemala. It is an antenna that is no 
>>>>> longer used by a telecommunications company. Everything is difficult, but 
>>>>> I keep going :)
>>>>>
>>>>> Taking advantage of your knowledge on the topic: Do you know how I can 
>>>>> solve this SSH issue?
>>>>> I can't copy the bof file to the roach.
>>>>>
>>>>> Cheers
>>>>>
>>>>> Rolando
>>
>>
>> --
>> 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%3D1TugU0mrTu3Qxpq1WHZi7_RqpnjuaDHG%3D1cAAX%3D_Czg%40mail.gmail.com.
>>
>>
> --
> 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/CANP6g6DxX4F-YaPOcHxZ%2BjbBktu4Jbw3VgctPFhwfM1n4Nux6w%40mail.gmail.com.



-- 
https://katfs.kat.ac.za/~marc/

-- 
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/CAGrhWaS-jBsF2oeNZ7g8NWNLQExtwMjZb%3Dh1zrGKv1V0F6ztmQ%40mail.gmail.com.

Re: [casper] Re: tcpborphserver violates katcp specification

[Marc]

Hello

On Tue, Jul 19, 2022 at 10:01 PM Kiran Shila  wrote:
> > but there are use cases where multiple GBytes of data are moved through
> > katcp
> This is a crazy to me as clearly the protocol is not meant for this
> purpose.

So  quite a number of people have worked on the katcp protocol specification
over the last decade or so, and everybody has of course had a slightly different
view on it, so what it "meant" to do is fuzzy.

But I always intended it to be plain text where possible but able to handle
arbitrary data where necessary.

> > Could the problem have been solved without breaking the ascii
> > requirement - sure. Why was it not? I don't know.
>
> Again - why even have a formal specification if official implementations
> break it?

The BNF defines an argument as one or more characters, of which 7 have to be
escaped. It does not define what a character is, and now looking back
that is a deficiency, but to my mind a "control character" or "non
printable character"
are a subset of "character". Maybe "octet" would have been better...

Then there is also "Where message parameters are described
as `human-readable' the content of the parameters should be restricted to
plain ASCII text" (pg11) but that is for parameters which are documented
to be human readable - and I'd be surprised if all the parameters
"?write" and "!read" are described as such.

regards

marc






>
> > Changing the tcpborphserver behaviour of read/write in a way that is not
> > backwards compatible with casperfpga (and every other preexisting casper
> > katcp client) seems unlikely to me to be a goer. Obviously you could do
> > it to meet your needs/desires, but this code isn't going to ever get
> > merged into the main repos/branches (you might reasonable ask whether
> > this matters, given how many distinct, incompatible code branches are
> > already lying around). In any case, making new bulk transfer commands
> > which are compliant, and work with the client you're building seems like
> > a path which should keep everyone happy(?)
>
> For sure. I wasn't expecting anyone to actually update read and write, I
> was just providing an alternative should anyone want. Having a third
> option, (maybe `bulkread` and `bulkwrite`) that follows the spec sounds
> like it may be worth it.
>
> If we're actually worried about throughput, there are a number of
> solutions that pack binary data into plaintext relatively efficiently.
> Base64 is common in the web space, as well as compressing and then
> packing. Again, it seems like it would be better just to open another
> socket and not deal with the hassle.
>
> -Kiran
>
> --
> 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/af99003f-574f-4593-3a08-995a3dbdbff0%40kiranshila.com.



--
https://katfs.kat.ac.za/~marc/

-- 
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/CAGrhWaS9Si3LESq76eoEezmrU6geXYjkHV3CdzPeMr5j_Xzd4w%40mail.gmail.com.

Re: [casper] Re: tcpborphserver violates katcp specification

[Marc]

Hello

Right - so even more conext will be helpful: tcpborphserver was written for the
ROACH1 board - which is about a decade old. It memory maps the
FPGA into the processor's address space - so accesses were
actually rather quick. tcpboprhserver has since been ported to
number of other platforms too ...

I think Jack's advice is good - fixing the wordread/wordwrite functions
for your board would be a good first step, and might be sufficient
for what you need to achieve.

If I recall correctly, the functions implemented interesting byte
(and perhaps even bit-level) shifts, which weren't supported in hardware,
so maybe that complexity makes updating/porting them less of a
priority. I suppose if these
shifts aren't needed, they could be simplified/elided - and I suspect your
hardware does byte level accesses natively anyway.

regards

marc

On Tue, Jul 19, 2022 at 6:01 PM Kiran Shila  wrote:
>
> > ?wordread/?wordwrite was written with maximal human readability in
> > mind. Somebody who has a misbehaving roach deployed somewhere can just
> > telnet/netcat/socat/etc to port 7147 and issue a wordread
> > to see if enough bits are toggling, or if some counter is ticking
> > over, set a debug flag, etc.
>
> I would've just used `wordread/write` but as of the latest version of
> the Raspberry Pi image, that functionality is broken. I tried updating
> to the latest version of katcp_devel (75dde9d), but then nothing worked
> at all.
>
> > ?read/?write are intended to retrieve larger chunks of data,
> > and use a represenation which is reasonably efficient. The link
> > to the powerpc isn't particularly fast, and while there are things
> > that could be optimised further, the current backslash encoding isn't
> > computationally expensive and adds a bit over 3% overhead,
> > which I think is reasonably good.
>
> Why does it need to be efficient? Especially considering in other parts
> of the codebase we're bit-banging SPI through katcp messages (which is a
> single bit for a 28 byte message, a cool 0.45% efficiency)
>
> > When I was referring to escape (and cornered programmers) in the
> > previous mail I didn't only mean literal escape characters,
> > but also a means to escape some of the constaints or access
> > extended functionality. In the above case, binary(ish) data to
> > do more efficient bulk transfers.
>
> But again, was there an actual problem this was solving? Was there a
> throughput issue somewhere that required spec-breaking changes? For bulk
> transfer (like uploading the FPG file), this was solved with opening a
> separate TCP connection and streaming bytes that way.
>
> > Of course, there is also nothing stopping you from only
> > using ?wordread and ?wordwrite in your rust library if the ?read and ?write
> > requests strike you as suffiently awkward.
>
> Besides the commands being broken, it's not just awkward to use `read`
> and `write`, it's not valid katcp. It will not parse with the formal
> grammar given. Having messages that break the contract defeats the whole
> purpose of having a formal specification.
>
> --
> 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/63df8a5b-c1d8-6fd7-eed0-7d56ee2af203%40kiranshila.com.



-- 
https://katfs.kat.ac.za/~marc/

-- 
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/CAGrhWaQKmx4-Efb_RVw5uEqMG5D-%2BqP%2BhaJrJmHW5zL1J6r6vg%40mail.gmail.com.

Re: [casper] Re: tcpborphserver violates katcp specification

[Marc]

Hello

Maybe it is helpful to give the reason for having two different
read/write mechanisms in tcpborphserver:

?wordread/?wordwrite was written with maximal human readability in
mind. Somebody who has a misbehaving roach deployed somewhere can just
telnet/netcat/socat/etc to port 7147 and issue a wordread
to see if enough bits are toggling, or if some counter is ticking
over, set a debug flag, etc.

?read/?write are intended to retrieve larger chunks of data,
and use a represenation which is reasonably efficient. The link
to the powerpc isn't particularly fast, and while there are things
that could be optimised further, the current backslash encoding isn't
computationally expensive and adds a bit over 3% overhead,
which I think is reasonably good.

When I was referring to escape (and cornered programmers) in the
previous mail I didn't only mean literal escape characters,
but also a means to escape some of the constaints or access
extended functionality. In the above case, binary(ish) data to
do more efficient bulk transfers.

Of course, there is also nothing stopping you from only
using ?wordread and ?wordwrite in your rust library if the ?read and ?write
requests strike you as suffiently awkward.

regards

marc

On Tue, Jul 19, 2022 at 1:52 PM Kiran Shila  wrote:
>
> On 7/15/22 08:16, Marc wrote:
> > So re-reading my first reply it becomes clear that this was much too
> > terse - sorry.
> >
> > Here  then the longer explanation:
> >
> > At the lowest level katcp is a line-based protocol consisting out of lines
> > starting with either '#', '?', '!', followed by one or more words, each
> > word separated from the subsequent one by one or more spaces or tabs.
> >
> > Generally katcp is intended to be human readable, so where possible the 
> > words
> > should be plain (ascii) text, but where not[1] katcp offers the
> > following backslash
> > escapes '\\' '\n', '\r', '\t', '\0', '\e', '\@' and '\_'. The first five
> > of these escapes are the same as C. The other three require some
> > explanation:
> >
> > '\_' is interesting as it decodes to a *space*, so ' ', not an underscore. 
> > The
> > reason for that is that it means a naive parser unaware of escapes at least
> > still manages to extract the correct word.
> >
> >?hello paramter1 parameter\_two parameter3
> >
> > will yield 'parameter3' to the quick and dirty parser (say "cut -f4 -d
> > ' ')  which
> > simply splits on space, rather than 'two' if this were not the case.
> >
> > '\e' escapes the 27 (0x1b) as a curtesy, so that binary data displayed
> > to the terminal doesn't generate too many escape sequences.
> >
> > '\@' is the null parameter - so represents a word of zero length or
> > nothing. This means
> > it is possible to have optional parameters not just at the end of list, so
> > making it easier to refer to parameterN, even if nothing is given for
> > parameterN-1.
> >
> > It is possible to think about each word/parameter has having a type,
> > and while that might be
> > useful in a number of cases, say when binding it to a strongly typed
> > language, at this
> > level they are all just a sequence of octets...
> >
> > regards
> >
> > marc
> >
> > [1] - It is always good to offer an escape - not only to cornered wild
> > animals, but to other programmers too :) There is an ancient famous 
> > critique of
> > Pascal which takes it to task for not providing this.
> >
>
> Thanks Marc for your response,
>
> Yes - the escaping component of the plain text part of the protocol
> makes perfect sense and is currently handled by my parser
> (https://github.com/kiranshila/katcp/blob/2201557ea81d8c00dda3e72a02de0d81cdf6b3fb/src/protocol.rs#L213-L216)
>
> I'm mostly concerned with tcpborphserver's `read` and `write` messages
> as they send raw (non-ascii) bytes.
>
> For example, if I run:
>
> client.blindwrite("sys_scratchpad", b'\xde\xad\xbe\xef')
>
> The katcp payload sent over TCP is:
>
> 0x3F7772697465207379735F73637261746368706164203020DEADBEEF0A
>
> Or
>
> ?write sys_scratchpad 0 <4 bytes not representable in ASCII>
>
> ,clearly violating this plaintext contract. The fact that parser
> constants gets escaped in the middle of this payload honestly add to the
> confusion because then there is random plaintext in a binary payload.
>
> This is why I'm suggesting a revision of TCPBorphserver and casperfpga
> to use something plaintext to represent these payloads. Base64 wouldn't
> be a bad option.
>
> I've implemented TCP middleware
> (https://github.com/GReX-Telescope/katcp_canonicalizer) to transform the

Re: [casper] Re: tcpborphserver violates katcp specification

[Marc]

So re-reading my first reply it becomes clear that this was much too
terse - sorry.

Here  then the longer explanation:

At the lowest level katcp is a line-based protocol consisting out of lines
starting with either '#', '?', '!', followed by one or more words, each
word separated from the subsequent one by one or more spaces or tabs.

Generally katcp is intended to be human readable, so where possible the words
should be plain (ascii) text, but where not[1] katcp offers the
following backslash
escapes '\\' '\n', '\r', '\t', '\0', '\e', '\@' and '\_'. The first five
of these escapes are the same as C. The other three require some
explanation:

'\_' is interesting as it decodes to a *space*, so ' ', not an underscore. The
reason for that is that it means a naive parser unaware of escapes at least
still manages to extract the correct word.

  ?hello paramter1 parameter\_two parameter3

will yield 'parameter3' to the quick and dirty parser (say "cut -f4 -d
' ')  which
simply splits on space, rather than 'two' if this were not the case.

'\e' escapes the 27 (0x1b) as a curtesy, so that binary data displayed
to the terminal doesn't generate too many escape sequences.

'\@' is the null parameter - so represents a word of zero length or
nothing. This means
it is possible to have optional parameters not just at the end of list, so
making it easier to refer to parameterN, even if nothing is given for
parameterN-1.

It is possible to think about each word/parameter has having a type,
and while that might be
useful in a number of cases, say when binding it to a strongly typed
language, at this
level they are all just a sequence of octets...

regards

marc

[1] - It is always good to offer an escape - not only to cornered wild
animals, but to other programmers too :) There is an ancient famous critique of
Pascal which takes it to task for not providing this.

-- 
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/CAGrhWaS%3D-1kECGh2gs1a5JWF%2B8nHfNeJ%2B9_BTeuRh7wxngvQcw%40mail.gmail.com.

Re: [casper] Re: tcpborphserver violates katcp specification

[Marc]

Hello

On Fri, Jul 15, 2022 at 1:51 PM Kiran Shila  wrote:
> Actually, the more I think about this - I'm really unsure how this even
> works. What happens if the binary payload contains 0x20 or 0x10 (space
> or newline)? Wouldn't that just break the parser? Is there something
> somewhere that guarantees these bytes don't exist in the payload?

Those characters are backslash escaped (well, not 0x10, but certainly 0xa).

regards

marc

-- 
https://katfs.kat.ac.za/~marc/

-- 
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/CAGrhWaQe3NrAYHDa%3D4S81g39_5NosSKZ0oWZuBVr0RkPtUSSng%40mail.gmail.com.

Re: [casper] An error occurs when 'exportfs -a' is entered

[Marc]

Hello

> sandang@wz-sandang:/etc$ sudo exportfs -a
> exportfs: No options for to NFS: suggest NFS(sync) to avoid warning
> exportfs: /etc/exports [1]: Neither 'subtree_check' or 'no_subtree_check' 
> specified for
> export "NFS:to".
> Assuming default behaviour ('no_subtree_check').
> NOTE: this default has changed since nfs-utils version 1.0.x

What does

  $ sudo showmount -e

say ? If there is nothing exported there might be some syntax error in
the config file. I know some editors add usual unicode space
characters to the files they write, which might not be something that
config file parser knows about

regards

marc

-- 
https://katfs.kat.ac.za/~marc/

-- 
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/CAGrhWaQ91i7hKNNKbVu1DsydTaNXgpQuiO%2BZsvGkS8AibbmT1Q%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 
>>&

Re: [casper] ROACH2 jtag booting

[Marc]

So one way of recovering a roach with erased flash is to jtag a very
small program into the cpu cache/SRAM. That doesn't require the DRAM to
be initialised. From there one can then program the flash.

Such a program exists in

https://github.com/ska-sa/roach2_testing/roach2_production_test/support_files/program.mac

here formatted in a way that the macgraigor tools can understand.

It can speak xmodem, and writes whatever it receives (typically
uboot) to flash.

But these things can be fiddly, so best not to erase uboot if at all possible.

regards

marc

On Sun, Sep 13, 2020 at 7:40 PM Sebastian Antonio Jorquera Tapia
 wrote:
>
> Thanks for the responses!
> I think the Matt guessing is a good starting point, also in page 26 of the 
> schematics says that to debug the ppc you need the halt signal, my jtag 
> programmer has it but I am going to take a closer look there.
>
> I had seen the binging up doc, but I had the feeling that it suppose that you 
> have the uboot running, they even configure the eth so they have access to 
> the os.
> Like I erased the uboot, the USB doesn't have a loopback so I don't see any 
> response there :(   Anyway the ftdi should still work and I should be able to 
> run the scripts (crossed fingers)
>
> I also found some info about the xmd connection of the ppc in the edk 
> reference manual, and it says that for certain configurations the jtag doesnt 
> recognize the ppc as a xilinx device, so the user has to explicitly define it 
> to be recognized. So maybe I am in that case.
>
>
>
> El sáb., 12 sept. 2020 a las 19:43, Cesar Strauss () 
> escribió:
>>
>> Em 12/09/2020 18:08, Sebastian Antonio Jorquera Tapia escreveu:
>> > When I was playing trying to make a netbooting with the ROACH2 and I
>> > issue the command: "run tftpuboot" and making the story short I ended up
>> > with no uboot :(
>>
>> I was able to successfully update the U-Boot on a ROACH2 by following
>> these instructions:
>>
>> https://casper.ssl.berkeley.edu/wiki/ROACH-2_Revision_2#Testing.2FBringup_Status
>>
>> ... which point to this document:
>>
>> https://docs.google.com/a/ska.ac.za/document/d/1tqw4C6uZ6EULl1OykTFL_vQTnK52UBr0aYqTg44E5wg/edit
>>
>> ... which point to this repository:
>>
>> https://github.com/ska-sa/roach2_testing
>>
>> .. which has the following bring-up script:
>>
>> https://github.com/ska-sa/roach2_testing/blob/master/roach2_production_test/roach2_ats.py
>>
>> ... which has some low level commands:
>>
>> https://github.com/ska-sa/roach2_testing/blob/master/roach2_production_test/roach2_ats.py#L1034
>>
>> Interestingly, you only need a USB cable, since the FTDI chip is
>> connected to the JTAG chain internally.
>>
>> Having said that, the road was not smooth. And, in the end, updating
>> UBoot did not solve the root problem we had (DRAM check in U-Boot). We
>> ended up shipping the ROACH2 back to Digicom, where they restored it to
>> factory condition.
>>
>> Regards,
>>
>> Cesar
>>
>> --
>> 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/5bc6f2ae-7dc5-868f-591a-da7415dfafcf%40inpe.br.
>
> --
> 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/CAASoV%3DNXWk7v6OjSzrDFvxyx-9T6OEXvYymv5a2Nu_aAH2RsBA%40mail.gmail.com.



-- 
https://katfs.kat.ac.za/~marc/

-- 
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/CAGrhWaR64THAnV8p3DXW4LzJf%2BsxLdzavAxb_EU4x9OUiKsOdQ%40mail.gmail.com.

Re: [casper] Issue programming SNAP Microblaze golden image

[Marc]

I don't know enough about the system to make any authoritative
statement, but it seems that it is uploading via tftp ? tftp is a
really simple protocol, only one packet ever in flight - so it should
be easy to use tcpdump or similar to check the traffic - to see on
which side packets are being discarded/ignored.

regards

marc

On Sat, Jun 6, 2020 at 12:09 AM Danny Price  wrote:
>
> Hi all,
>
> I am trying to set up a SNAP board for microblaze, following the SNAP Bringup 
> guide https://casper.ssl.berkeley.edu/wiki/SNAP_Bringup
>
> I am programming the board using a raspberry pi with a microblaze-enabled fpg 
> file. It receives an IP address over 10 GbE, and I am able to connect to it 
> via tapcp:
>
> import casperfpga
> myfpga = casperfpga.CasperFpga(host='10.0.0.103', port=69, log_level='DEBUG', 
> transport=casperfpga.transport_tapcp.TapcpTransport)
>
> 2020-06-06 09:55:47.23 INFO 10.0.0.103 casperfpga.py:227 - Log level 
> successfully updated to: DEBUG
> INFO:10.0.0.103:Log level successfully updated to: DEBUG
> 2020-06-06 09:55:47.24 INFO 10.0.0.103 transport_tapcp.py:99 - *** NEW 
> CONNECTION MADE TO 10.0.0.103 ***
> INFO:10.0.0.103:*** NEW CONNECTION MADE TO 10.0.0.103 ***
> 2020-06-06 09:55:47.24 DEBUG 10.0.0.103 casperfpga.py:146 - 10.0.0.103: now a 
> CasperFpga
> DEBUG:10.0.0.103:10.0.0.103: now a CasperFpga
>
> However, when I try and program a golden image (same design as fpg file, but 
> using the myproj/impl_1/top.bin), it errors:
>
> In [7]: myfpga.transport._program_new_golden_image('/path/to/my/top.bin')
> Writing block 1 of 102
> Writing block 2 of 102
> ERROR:tftpy:hit max retries, giving up
>
> Has anyone experienced this before? Any pointers on how to debug?
>
> Thanks,
> Danny
>
> --
> 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/CAAtMgqnVKE5RhrBbgWNvyCXgYy%3DgHcpBNdRYMTcu2wJ%3DYEEC9w%40mail.gmail.com.



-- 
https://katfs.kat.ac.za/~marc/

-- 
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/CAGrhWaSFPD3t6Tnu9mE4GY9bF7XU-LS7G9FFtDtcAG%2BgboJBiQ%40mail.gmail.com.

Re: [casper] Red Pitaya access registers of snap blocks from PS

[Marc]

On Sun, May 31, 2020 at 6:54 PM Wesley New  wrote:


> You should have tcpborphserver installed on the PS. You can telnet into 
> tcpborphserver and issue register read and writes that way. ie you could 
> telnet into tcpborphserver on localhost form the RP using a python script and 
> run your tasks that way. If I remember correctly tcpboprhserver can address a 
> register by name so you shouldnt need to worry about memory maps,

There should be a ?listsdev command to give you the register mapping.
Not sure if the red pitaya has kcpcmd installed, if it does type

  kcpcmd listdev

or

  kcpcmd help

regards

marc

-- 
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/CAGrhWaQLihD1PQFv91A6J79JiLprcAVG_fqF6QFj%2BbNzK4_Zdg%40mail.gmail.com.

Re: [casper] Red Pitaya Tutorial 1 reg

[Marc]

On Sat, Apr 4, 2020 at 2:55 PM Adam Isaacson  wrote:

> Hi Aravind,
>
> Yes, you need casperfpga to configure the Red Pitaya. The tutorials
> explains how to use casperfpga. The Zynq processor on the Red Pitaya is
> running software called tcpborphserver. Casperfpga is a python comms
> package communicates with the tcpborphserver. You can also telnet to
> tcpborphserver directly on port 7147 and type "help?" It will give you a
> list of commands.
>

Small correction - the command would be "?help".

There are commands to read and write registers, and there is a utility
called kcpfg which should make it possible to program an fpg file remotely

regards

marc

-- 
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/CAGrhWaQMGrhJ0RHbMWZHf-V-vtC6fF%2BSze9fkJOjH1nuX%2BVZ%2Bw%40mail.gmail.com.

Re: [casper] (Red Pitaya 125-14) RuntimeError: no programming informs yet. Odd?

[Marc]

A fpg file is text (katcp commands describing the register layout) followed
by the bitstream - use less to view it. If you can generate the bitstream,
chances are you should be able to build the fpg file too.

regards

marc


On Thu, Feb 13, 2020 at 8:45 AM Lukas Karch  wrote:

> Thank you for all the help. Adding "127.0.0.1 localhost" to the host file
> worked. Afterwards I was able to program the fpga both with the tutorial
> .fpg file and a .fpg file I compiled myself.
> Just one more question. Do you happen to know if it is possible to compile
> .fpg files for the Red Pitaya using only Vivado WebPack.
> At the moment I'm using a 30 day evaluation license and I am wondering if
> compiling .fpg files will still work after it runs out.
>
> Adam Isaacson  hat am 11. Februar 2020 um 16:33
> geschrieben:
>
> Hi Lukas,
>
> Alexander Raymond from CfA remembers we may have had the same issue in
> Boston last year. Thanks, Alex! He suggests the following:
>
> "Adding 127.0.0.1 localhost to /etc/hosts worked for us in getting past
> the " *no programming informs yet. Odd?* “ error."
>
> Let us know how you progress.
>
> Kind regards,
>
> Adam Isaacson
> South African Radio Astronomy Observatory (SARAO)
> Hardware Manager
> Cell: (+27) 825639602
> Tel:  (+27) 215067300
> email: aisaac...@ska.ac.za
>
>
>
>
>
> On Tue, Feb 11, 2020 at 10:06 AM Adam Isaacson < aisaac...@ska.ac.za>
> wrote:
>
> Hi Lukas,
>
> 1) Did you install casperfpga using the following exactly (ReadMe.md
> "installation" section):  https://github.com/casper-astro/casperfpga?
>
> 2) What casperfpga version are you using? Type "casperfpga.__version__"
> after you import casperfpga.
>
> 3) You are sure tcpborphserver is running? if it is not running then
> casperfpga will not work. Refer to:
>  
> https://casper-toolflow.readthedocs.io/projects/tutorials/en/latest/tutorials/redpitaya/red_pitaya_setup.html
> <https://casper-toolflow.readthedocs.io/projects/tutorials/en/latest/tutorials/redpitaya/red_pitaya_setup.html>.
>
>
> Kind regards,
>
> Adam Isaacson
> South African Radio Astronomy Observatory (SARAO)
> Hardware Manager
> Cell: (+27) 825639602
> Tel:  (+27) 215067300
> email: aisaac...@ska.ac.za
>
>
>
>
>
> On Tue, Feb 11, 2020 at 9:48 AM Lukas Karch < lu...@karch.info> wrote:
>
> Thank you for the quick response. I tried specifiying the port number but
> the same error appeared. I tried using the .fpg and python script you
> suggested and a very similar error message appeared:
> *lukas@lukas-HP-Pavilion-x360-Convertible-15-br1xx:~/Downloads$ python
> tut_adc_dac.py 10.42.0.69 -p -b tut_adc_dac.fpg*
> *connecting to the Red Pitaya...*
> *done*
> *programming the Red Pitaya...*
> *2020-02-11 08:09:51.39 ERROR 10.42.0.69 transport_katcp.py:594 -
> 10.42.0.69 <http://10.42.0.69>: no programming informs yet. Odd?*
> *ERROR:10.42.0.69:10.42.0.69: no programming informs yet. Odd?*
> *Traceback (most recent call last):*
> *File "tut_adc_dac.py", line 38, in *
> *rp.upload_to_ram_and_program(opts.fpg)*
> *File
> "/usr/local/lib/python2.7/dist-packages/casperfpga-0.1.2-py2.7-linux-x86_64.egg/casperfpga/casperfpga.py",
> line 314, in upload_to_ram_and_program*
> *filename=filename, wait_complete=wait_complete)*
> *File
> "/usr/local/lib/python2.7/dist-packages/casperfpga-0.1.2-py2.7-linux-x86_64.egg/casperfpga/transport_katcp.py",
> line 596, in upload_to_ram_and_program*
> *'Odd?' % self.host)*
> *RuntimeError: 10.42.0.69 <http://10.42.0.69>: no programming informs yet.
> Odd?*
>
> Regarding the setup of the Red Pitaya, i mostly followed the instructions
> on this site:
> https://casper-toolflow.readthedocs.io/projects/tutorials/en/latest/tutorials/redpitaya/red_pitaya_setup.html.
> Only "git clone https://github.com/ska-sa/katcp.git; did not work ( *fatal:
> unable to access 'https://github.com/ska-sa/katcp.git/
> <https://github.com/ska-sa/katcp.git/>': Could not resolve host: github.com
> <http://github.com>*), so I downloaded the github on my pc and used "scp
> -r" to copy it to my Red Pitaya.
> Regarding the casperfpga version, I followed the installation instructions
> on this site: https://github.com/casper-astro/casperfpga. At first I
> installed casperfpga using "sudo pip install casperfpga". Later I also
> tried "sudo python setup.py install" but it made no difference.
>
> Adam Isaacson < aisaac...@ska.ac.za> hat am 7. Februar 2020 um 16:26
> geschrieben:
>
> Hi Lukas,
>
> This problem seems familiar to me, but I can't quite remember the
> solution. Thes

Re: [casper] (Red Pitaya 125-14) RuntimeError: no programming informs yet. Odd?

[Marc]

On Tue, Feb 11, 2020 at 7:48 AM Lukas Karch  wrote:

>
>
> Regarding the setup of the Red Pitaya, i mostly followed the instructions
> on this site:
> https://casper-toolflow.readthedocs.io/projects/tutorials/en/latest/tutorials/redpitaya/red_pitaya_setup.html.
> Only "git clone https://github.com/ska-sa/katcp.git; did not work ( *fatal:
> unable to access 'https://github.com/ska-sa/katcp.git/
> <https://github.com/ska-sa/katcp.git/>': Could not resolve host: github.com
> <http://github.com>*), so I downloaded the github on my pc and used "scp
> -r" to copy it to my Red Pitaya.
>


Can you confirm that a tcpborphserver process is running on the redpitaya ?
It should appear in the process listing (use ps)

regards

marc

-- 
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/CAGrhWaQovbte8y177F4%3DO1Y9D7eiKU7LkJAKqSb9A1khs5NRQQ%40mail.gmail.com.

Re: [casper] SNAP board writing and reading the registers issue.

[Marc]

Consider issuing the request by hand

telnet 192.168.41.159 7147

and then type

?read payload_length 0 4

if that fails, maybe try

?listdev to see if the device is even programmed

regards

marc


On Wed, Dec 18, 2019 at 2:49 AM Indrajit Barve  wrote:

> Dear all,
>
> I could able to program the .bof file on snap program using the old
> casperfpga package.
> I am able to see the register values at using the listdev. Where I am
> trying to write and read those registers I am getting errors.
>
> is that KATCP version issues ?
>
> fpga.listdev()
> Out[2]:
> ['adc16_controller',
> 'adc16_use_synth',
> 'adc16_wb_ram0',
> 'adc16_wb_ram1',
> 'adc16_wb_ram2',
> 'frame_cnt',
> 'lmx_ctrl',
> 'payload_length',
> 'reset_counts',
> 'sharaed_bram',
> 'sys_block',
> 'sys_board_id',
> 'sys_clkcounter',
> 'sys_rev',
> 'sys_rev_rcs',
> 'sys_scratchpad',
> 'xadc']
>
>
>
> In [1]: run snap_adc.py
> ---
> KatcpRequestFail  Traceback (most recent call last)
> /usr/lib/python2.7/dist-packages/IPython/utils/py3compat.pyc in
> execfile(fname, *where)
> 202 else:
> 203 filename = fname
> --> 204 __builtin__.execfile(filename, *where)
>
> /home/pulsar/Documents/python_workspace/snap_adc.py in ()
>   8 fpga.program()
>   9 time.sleep(3)
> ---> 10 fpga.write_int('payload_length', 1024)
>  11 fpga.write_int('reset_counts', 2)
>
> /usr/local/lib/python2.7/dist-packages/casperfpga/casperfpga.pyc in
> write_int(self, device_name, integer, blindwrite, word_offset)
> 285 self.blindwrite(device_name, data, word_offset*4)
> 286 else:
> --> 287 self.write(device_name, data, word_offset*4)
> 288 LOGGER.debug('%s: write_int %8x to register %s at word
> offset %d '
> 289  'okay%s.' % (self.host, integer, device_name,
>
> /usr/local/lib/python2.7/dist-packages/casperfpga/casperfpga.pyc in
> write(self, device_name, data, offset)
> 228 """
> 229 self.blindwrite(device_name, data, offset)
> --> 230 new_data = self.read(device_name, len(data), offset)
> 231 if new_data != data:
> 232 unpacked_wrdata = struct.unpack('>L', data[0:4])[0]
>
> /usr/local/lib/python2.7/dist-packages/casperfpga/katcp_fpga.pyc in
> read(self, device_name, size, offset)
> 252  require_ok=True,
> 253  request_args=(device_name,
> str(offset),
> --> 254str(size)))
> 255 return reply.arguments[1]
> 256
>
> /usr/local/lib/python2.7/dist-packages/casperfpga/katcp_fpga.pyc in
> katcprequest(self, name, request_timeout, require_ok, request_args)
> 161 'Request %s on host %s failed.\n\t'
> 162 'Request: %s\n\tReply: %s' %
> --> 163 (request.name, self.host, request, reply))
> 164 elif reply.arguments[0] == katcp.Message.INVALID:
> 165 raise KatcpRequestInvalid(
>
> KatcpRequestFail: Request read on host 192.168.41.159 failed.
> Request: ?read payload_length 0 4
> Reply: !read fail
>
>
>
> *Indrajit Barve*
> indra...@iiap.res.in
> Radio Astronomy Group
> <https://maps.google.com/?q=Radio%20Astronomy%20Group%20>
>
> --
> 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/4B705882-BF60-4871-87EA-A9118497B789%40getmailspring.com
> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/4B705882-BF60-4871-87EA-A9118497B789%40getmailspring.com?utm_medium=email_source=footer>
> .
>


-- 
https://katfs.kat.ac.za/~marc/

-- 
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/CAGrhWaR%2BGB8t5C_umzRtU6vJGkUc-DxZoMRH4xfDx8VLEBMhCg%40mail.gmail.com.

Re: [casper] Programming in the PPC

[Marc]

Hi there

If you remain keen to read raw values from within the ppc you could use
netcat (or your own socket) to localhost, port 7147 and issue ?read
requests directly. Note that there are differences between read and
wordread.

You could also pipe the text output of your ash script to gzip and compress
it - that might save you space too...

The reads from /proc//hw/ioreg were a thing on older software revisions
and probably not available on the roach2

regards

marc


On Wed, Nov 20, 2019 at 1:48 PM Sebastian Antonio Jorquera Tapia <
sebastian.jorqu...@ug.uchile.cl> wrote:

> Hello,
> In the last days I start to thinking in reading the BRAMs on the fpga via
> the PPC directly and not give the request via LAN reducing the reading
> latency (I suppose)
> Messing around inside the ppc, I found the command kcpcmd which enables me
> to send katcp requests so thats nice. I made a little ash script for
> continuously reading one register and saving it in the tmpfs mounted in
> /var.
>
> The main problem I found is that the kcpcmd gives me the reading in a
> human readable way (even when I set the -x option which gives the response
> in hexadecimal) so when I save it in a doc use much more space than binary
> data.. There is other way to read the brams of the fpga beside the kcpcmd?
> Searching I found that in the netfpga, which also use a borph os, reads
> the register from /proc/8033/hw/ioreg there is something similar to this in
> the ppc?
>
> Other way to fix my problem was to make a little script to translate the
> values form ascii(?) to binary after the reading with kcpcmd. My plan is
> using C and cross-compile for the powerpc in gcc.. Should this work in the
> borph environment?
>
>
>
> --
> 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/5f030be7-3ffa-4946-a3d7-b7f2b97d64b3%40lists.berkeley.edu
> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/5f030be7-3ffa-4946-a3d7-b7f2b97d64b3%40lists.berkeley.edu?utm_medium=email_source=footer>
> .
>


-- 
https://katfs.kat.ac.za/~marc/

-- 
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/CAGrhWaS6MLm%3DQBjoj%2BGU6VhoC4WmX%2BTww6k14wvYfv1KjC%3D13A%40mail.gmail.com.

Re: [casper] help with possible hardware problems in roach2

[Marc]

On 7/31/19, luis javier Ulloa  wrote:
> Hello everyone, again I, continuing with my problem, I share some
> screenshots about the USB FTDI, those errors are normal?
>
> Javier Ulloa.

So that doesn't look good.

You could try connecting with another PC, just in case it is some sort
of driver/kernel/hardware issue on the controlling Ubuntu system, but
I suspect there is something wrong on the roach. You might be able to
use another PSU to power the roach, in case it is a PSU problem, but
other problems might be harder to debug ...

regards

marc

-- 
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/CAGrhWaQ7xAGae6p7g0zGoUSiBoCczofS6ojUAGamc1ZHxG%2BvUQ%40mail.gmail.com.

Re: Re: Re: [casper] ROACH Network is unreachable

[Marc]

On 6/20/19, zhang laiyu  wrote:
> Hi，Marc, Jack
> I make some progress but it was not solved.
> I boot the ROACH by 'run mmcboot' and did not got an IP address. And
> then log in  RAOCH as root and try issuing the commands:
> dhclient -r
> dhclient
> ifconfig
> Then ROACH was assigned an ip address. And can use telnet to login
> ROACH.
> But when I reboot the ROACH, ROACH Network is still unreachable.I have
> to issuing the commands:dhclient again.
> I also open two ports (  tcp port 53 and udp port 67) in the server.But
> it still does not work.
> I think that the DHCP connection doesn't work during boot.But I do not
> the reason.

So if you boot into the broken system and connect via serial cable
what does the output of

/sbin/ifconfig eth0

say ? Is there no IP address configured, or is it set to the wrong one
? If it is set incorrectly there may be some startup script which has
some old/stale values set.
You could try to add a

set -x

to some of the startup scripts, so that they echo the commands they execute

regards

marc

-- 
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/CAGrhWaQPV8NBHcrvV8rQaUGdyQZJTFcW5aG1Vyujrn0HcBr7xg%40mail.gmail.com.

Re: [casper] ROACH Network is unreachable

[Marc]

On 6/18/19, zhang laiyu  wrote:
...
> Starting NTP server: ntpdstart-stop-daemon: open pidfile /var/run/ntpd.pid:
> Stale NFS file handle (Stale)
>  failed!
>
> tcpborphserver: starting
>
> SIOCADDRT: Network is unreachable
>

Could it be that something in /etc/network/interfaces isn't
configured, or that a route is being initialised that doesn't make
sense on the current network ?

regards

marc

-- 
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/CAGrhWaQ%3DF_%3DEzUSK8Ru%3Dfm%2Bx9PmV68wbQS0yyvjjK-K-v31WYA%40mail.gmail.com.

Re: [casper] Bof file issue

[Marc]

So the fpg file is in some ways just a set of commands issued to port
7147 of the roach, one of them includes uploading the bitstream. There
are two things to try, either perform these steps manually or use
another piece of software to perform the upload.

Manual upload involves isssuing an

?uploadbin 

on the 7147 port, and then (quickly, before it times out) on another
terminal using netcat to stream in the bitstream

$ nc -q 2 -w 2 IP.OF.ROA.CH  < your.bitstream

Note that what you are streaming in is *not* the fpg file, but the
bitstream, usually in system.bin (IIRC?). Once you have done that and
it succeeds, you can paste in the

?register sys_board_id 0x0 0x4

commands, followed by a

?finalise

at which point the roach should be programmed, and wordreads should succeed.

There is C utility which performs all these steps in one go, which is
called kcpfpg. it is part of katcp_devel to be found at
https://github.com/casper-astro/katcp_devel or
https://github.com/ska-sa/katcp_devel, use

$ make -k

to build it once you have cloned it, then

# make -C fpg install

to install it. It understands the -h option and can upload .fpg files

regards

marc



On Mon, Apr 29, 2019 at 8:47 AM 'Nikita Rathore' via
casper@lists.berkeley.edu  wrote:
>
> Still I am getting the same issue even I kept the connection open to port 
> 7147.
>
> Trying 192.168.100.196...
> Connected to 192.168.100.196.
> Escape character is '^]'.
> #version memcpy-88-g38ad77a-dirty
> #build-state 2013-04-11T11:50:43
> #log info 114991 raw new\_client\_connection\_192.168.100.1:46250
> #client-connected 192.168.100.1:46250
>
> In [1]: import casperfpga
>
> In [2]: fpga = casperfpga.CasperFpga('192.168.100.196')
> WARNING:casperfpga.transport_katcp:192.168.100.196: no ._stream instance 
> found.
>
> In [3]: fpga.upload_to_ram_and_program('pocov64_2019_Apr_04_1337.fpg')
> ---
> RuntimeError  Traceback (most recent call last)
>  in ()
> > 1 fpga.upload_to_ram_and_program('pocov64_2019_Apr_04_1337.fpg')
>
> /usr/local/lib/python2.7/dist-packages/casperfpga/casperfpga.pyc in 
> upload_to_ram_and_program(self, filename, port, timeout, wait_complete)
> 200 """
> 201 rv = self.transport.upload_to_ram_and_program(
> --> 202 filename, port, timeout, wait_complete)
> 203 if filename[-3:] == 'fpg':
> 204 self.get_system_information(filename)
>
> /usr/local/lib/python2.7/dist-packages/casperfpga/transport_katcp.pyc in 
> upload_to_ram_and_program(self, filename, port, timeout, wait_complete)
> 462 if request_result != '':
> 463 raise RuntimeError('progremote request(%s) on host %s 
> failed' %
> --> 464(request_result, self.host))
> 465 # start the upload thread and join
> 466 upload_queue = Queue.Queue()
>
> RuntimeError: progremote request(Request to client 192.168.100.196 failed.) 
> on host 192.168.100.196 failed
>
> On Mon, Apr 29, 2019 at 1:11 PM Marc  wrote:
>>
>> I suppose the next step would be to keep a telnet connection open to
>> port 7147 and attempt the upload again - there should be an error
>> message telling you why it failed. It might be a bit cryptic though.
>>
>> On earlier tcpborphserver revisions, the system didn't unmap the fpga,
>> and so ran out of address space after a dozen or so uploads, if there
>> was no reboot, but that has been fixed quite a while ago.
>>
>> regards
>>
>> marc
>>
>> On Mon, Apr 29, 2019 at 7:10 AM 'Nikita Rathore' via
>> casper@lists.berkeley.edu  wrote:
>> >
>> > Following fpg file I am using. Yes I can ping the IP of the roach board, 
>> > and port 7147 also works fine.
>> >
>> > Regards
>> > Nikita Rathore
>> >
>> > On Thu, Apr 25, 2019 at 4:25 PM Marc  wrote:
>> >>
>> >> Is the fpg file empty, if not do a less on the file - the first couple
>> >> of lines should be human readable register definitions, followed by
>> >> the bitstream to check that it looks reasonble. Also see if you can
>> >> ping the IP of the roach board, and see if telnet to its port 7147
>> >> works
>> >>
>> >> regards
>> >>
>> >> marc
>> >>
>> >> On Thu, Apr 25, 2019 at 9:27 AM 'Nikita Rathore' via
>> >> casper@lists.berkeley.edu  wrote:
>> >> >
>> >> > I am using MATLAB R2012b, Xilinx 14.7 and Roach2 board. Yes, I have 
>> >> > .fpg file and I am

Re: [casper] Bof file issue

[Marc]

I suppose the next step would be to keep a telnet connection open to
port 7147 and attempt the upload again - there should be an error
message telling you why it failed. It might be a bit cryptic though.

On earlier tcpborphserver revisions, the system didn't unmap the fpga,
and so ran out of address space after a dozen or so uploads, if there
was no reboot, but that has been fixed quite a while ago.

regards

marc

On Mon, Apr 29, 2019 at 7:10 AM 'Nikita Rathore' via
casper@lists.berkeley.edu  wrote:
>
> Following fpg file I am using. Yes I can ping the IP of the roach board, and 
> port 7147 also works fine.
>
> Regards
> Nikita Rathore
>
> On Thu, Apr 25, 2019 at 4:25 PM Marc  wrote:
>>
>> Is the fpg file empty, if not do a less on the file - the first couple
>> of lines should be human readable register definitions, followed by
>> the bitstream to check that it looks reasonble. Also see if you can
>> ping the IP of the roach board, and see if telnet to its port 7147
>> works
>>
>> regards
>>
>> marc
>>
>> On Thu, Apr 25, 2019 at 9:27 AM 'Nikita Rathore' via
>> casper@lists.berkeley.edu  wrote:
>> >
>> > I am using MATLAB R2012b, Xilinx 14.7 and Roach2 board. Yes, I have .fpg 
>> > file and I am trying to burn fpga with the generated .fpg file using 
>> > casperfpga but in that case I am getting following issue:
>> >
>> > import casperfpga
>> > > >>> fpga=casperfpga.katcp_fpga.KatcpFpga('192.168.100.192')
>> > > >>> fpga.upload_to_ram_and_program('pocov64_2017_Aug_17_1600.fpg')
>> > > Traceback (most recent call last):
>> > >   File "", line 1, in 
>> > >   File "/usr/local/lib/python2.7/site-packages/casperfpga/katcp_fpga.py",
>> > > line 358, in upload_to_ram_and_program
>> > > raise RuntimeError('progremote request(%s) on host %s failed' %
>> > > (request_result, self.host))
>> > > RuntimeError: progremote request(Request to client 192.168.100.192 
>> > > failed.) on
>> > > host 192.168.100.192 failed
>> >
>> > I also tried mkbof command to generate bof file from bit file but in that 
>> > case I had following error:
>> > mkbof: command not found
>> >
>> > I run it like this
>> > XPS_ROACH2_base# mkbof -o system.bof –s core_info.tab -t 3 
>> > pocov64_2017_Aug_17_1600.bit
>> >
>> >
>> >
>> > On Thu, Apr 25, 2019 at 1:09 PM Marc  wrote:
>> >>
>> >> Not sure what hardware you are working on, but your system might have
>> >> generated a newer .fpg file ? If this isn't the case, maybe the mkbof
>> >> executable isn't built for your build machine architecture (x86 vs
>> >> amd64) or c/linker revision ? See if you can run the mkbof executable
>> >> manually ?
>> >>
>> >> regards
>> >>
>> >> marc
>> >>
>> >> On Thu, Apr 25, 2019 at 5:59 AM 'Nikita Rathore' via
>> >> casper@lists.berkeley.edu  wrote:
>> >> >
>> >> > Hello,
>> >> >
>> >> > I started working on 2 element pocket correlator. Simulink design 
>> >> > compiled successfully but the bof file generated is completely blank (0 
>> >> > bytes).
>> >> > It would be grateful if someone could help me solve this issue.
>> >> >
>> >> > --
>> >> > Thanks & Regards
>> >> > Nikita Rathore
>> >> >
>> >> > --
>> >> > 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 post to this group, send email to casper@lists.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 post to this group, send email to casper@lists.berkeley.edu.
>> >
>> >
>> >
>> > --
>> > Thanks & Regards
>> > Nikita Rathore
>> >
>> > --
>> > You received this message because you are subscribed to the

Re: [casper] Bof file issue

[Marc]

Is the fpg file empty, if not do a less on the file - the first couple
of lines should be human readable register definitions, followed by
the bitstream to check that it looks reasonble. Also see if you can
ping the IP of the roach board, and see if telnet to its port 7147
works

regards

marc

On Thu, Apr 25, 2019 at 9:27 AM 'Nikita Rathore' via
casper@lists.berkeley.edu  wrote:
>
> I am using MATLAB R2012b, Xilinx 14.7 and Roach2 board. Yes, I have .fpg file 
> and I am trying to burn fpga with the generated .fpg file using casperfpga 
> but in that case I am getting following issue:
>
> import casperfpga
> > >>> fpga=casperfpga.katcp_fpga.KatcpFpga('192.168.100.192')
> > >>> fpga.upload_to_ram_and_program('pocov64_2017_Aug_17_1600.fpg')
> > Traceback (most recent call last):
> >   File "", line 1, in 
> >   File "/usr/local/lib/python2.7/site-packages/casperfpga/katcp_fpga.py",
> > line 358, in upload_to_ram_and_program
> > raise RuntimeError('progremote request(%s) on host %s failed' %
> > (request_result, self.host))
> > RuntimeError: progremote request(Request to client 192.168.100.192 failed.) 
> > on
> > host 192.168.100.192 failed
>
> I also tried mkbof command to generate bof file from bit file but in that 
> case I had following error:
> mkbof: command not found
>
> I run it like this
> XPS_ROACH2_base# mkbof -o system.bof –s core_info.tab -t 3 
> pocov64_2017_Aug_17_1600.bit
>
>
>
> On Thu, Apr 25, 2019 at 1:09 PM Marc  wrote:
>>
>> Not sure what hardware you are working on, but your system might have
>> generated a newer .fpg file ? If this isn't the case, maybe the mkbof
>> executable isn't built for your build machine architecture (x86 vs
>> amd64) or c/linker revision ? See if you can run the mkbof executable
>> manually ?
>>
>> regards
>>
>> marc
>>
>> On Thu, Apr 25, 2019 at 5:59 AM 'Nikita Rathore' via
>> casper@lists.berkeley.edu  wrote:
>> >
>> > Hello,
>> >
>> > I started working on 2 element pocket correlator. Simulink design compiled 
>> > successfully but the bof file generated is completely blank (0 bytes).
>> > It would be grateful if someone could help me solve this issue.
>> >
>> > --
>> > Thanks & Regards
>> > Nikita Rathore
>> >
>> > --
>> > 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 post to this group, send email to casper@lists.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 post to this group, send email to casper@lists.berkeley.edu.
>
>
>
> --
> Thanks & Regards
> Nikita Rathore
>
> --
> 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 post to this group, send email to casper@lists.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 post to this group, send email to casper@lists.berkeley.edu.

Re: [casper] Bof file issue

[Marc]

Not sure what hardware you are working on, but your system might have
generated a newer .fpg file ? If this isn't the case, maybe the mkbof
executable isn't built for your build machine architecture (x86 vs
amd64) or c/linker revision ? See if you can run the mkbof executable
manually ?

regards

marc

On Thu, Apr 25, 2019 at 5:59 AM 'Nikita Rathore' via
casper@lists.berkeley.edu  wrote:
>
> Hello,
>
> I started working on 2 element pocket correlator. Simulink design compiled 
> successfully but the bof file generated is completely blank (0 bytes).
> It would be grateful if someone could help me solve this issue.
>
> --
> Thanks & Regards
> Nikita Rathore
>
> --
> 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 post to this group, send email to casper@lists.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 post to this group, send email to casper@lists.berkeley.edu.

Re: [casper] Issues with setting up a ROACH2

[Marc]

This is strange advice so proceed with caution: Maybe take out the
dimm, rub its contacts (gently) with an eraser and reseat it ?

regards

marc

On Tue, Mar 19, 2019 at 1:59 PM Michael Peel  wrote:
>
> Hi Heystek,
>
> Thanks for the reply and the link. The memory error appears immediately after 
> the roach is turned on, before the option to stop the autoboot appears. 
> Sometimes it does continue a bit beyond that before stalling, so I’ll look at 
> trying to do a uboot update when it next does that.
>
> The links to the images on the webpage don’t work (the casper svn no longer 
> exists?), are the latest versions stored elsewhere now - perhaps they the 
> ones on the ska-sa git?
>
> Thanks,
> Mike
>
> On 17 Mar 2019, at 14:40, Heystek Grobler  wrote:
>
> Hey Michael
>
> Did you try this procedure?
>
> https://casper.ssl.berkeley.edu/wiki/ROACH_kernel_uboot_update
>
> Did you manage to solve it?
>
> Heystek
>
> On Fri, Mar 15, 2019 at 5:45 PM Michael Peel  wrote:
>>
>> Hi all,
>>
>> I’m currently trying to set up a ROACH2 (for the first time), and have run 
>> into a number of problems. The bottom line is that I’m currently getting 
>> this memory error message:
>>
>> U-Boot 2011.06-rc2-0-g2694c9d-dirty (Dec 04 2013 - 20:58:06)
>> CPU: AMCC PowerPC 440EPx Rev. A at 533.333 MHz (PLB=133 OPB=66 EBC=66)
>>  No Security/Kasumi support
>>  Bootstrap Option C - Boot ROM Location EBC (16 bits)
>>  32 kB I-Cache 32 kB D-Cache
>> Board: ROACH2
>> I2C: ready
>> DRAM: 512 MiB
>> Memory error at , wrote , read 273218ff !
>>
>> This follows from the casperfpga software being able to connect to the 
>> ROACH2, but unable to load the .fpg file onto it. That led to me attempting 
>> to update the romfs using ‘run tftproot’, but it could not get an IP address 
>> from the computer (DHCP/dnsmasq configuration issues on RHEL7 that I still 
>> need to figure out), so it did not run the update. However, after that I got 
>> a kernel panic on the onboard software, so the roach no longer got to the 
>> login stage.
>>
>> I then created a USB boot drive using:
>> https://github.com/ska-sa/roach2_nfs_uboot/blob/master/roach2-debian-fs-snapshot-24-10-2012.tar.gz
>> and tried to boot the roach from that, however it stalled during the boot 
>> process, and on reset I got the above error message.
>>
>> Any suggestions?
>>
>> Thanks,
>> Mike
>>
>> --
>> 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 post to this group, send email to casper@lists.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 post to this group, send email to casper@lists.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 post to this group, send email to casper@lists.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 post to this group, send email to casper@lists.berkeley.edu.

Re: [casper] Problem when programming ROACH2

[Marc Welz]

Excellent!

regards

marc




On Mon, Aug 13, 2018 at 10:19 AM, Concu, Raimondo
 wrote:
> Hi Mark,
>
> I replaced tcpborphserver3 with tcpborphserver3-unmap.
>
> I have programmed the roach2 100 + 400 times ... without problems
>
> We had an old version of tcpborphserver3
>
> Now we have a SARDARA reconfigurable many times ;-) and then permanently
> offered to the astronomers at SRT ...
>
> Problem solved
>
> Thanks again!
>
> 2018-08-13 11:24 GMT+02:00 Concu, Raimondo :
>>
>> I meant between versions,
>>
>>  but I read that: "New tcpborphserver3: fixes unmap issue when programming
>> boffiles" ,
>>
>> could be our case.
>>
>> It is being tested ...
>>
>> 2018-08-13 10:59 GMT+02:00 Marc Welz :
>>>
>>> The one is a symbolic link to the other
>>>
>>> regards
>>>
>>> marc
>>>
>>>
>>> On Mon, Aug 13, 2018 at 8:56 AM, Raimondo Concu 
>>> wrote:
>>> > Yes Mark!
>>> >
>>> > I had already seen this link.
>>> >
>>> > What is the difference between tcpborphserver3 and
>>> > tcpborphserver3-unmap?
>>> >
>>> > Thank You!
>>> > Raimondo
>>> >
>>> > Il Lun 13 Ago 2018, 10:00 Marc Welz  ha scritto:
>>> >>
>>> >> On Fri, Aug 10, 2018 at 5:51 PM, John Ford  wrote:
>>> >> > That depends where the image lives.  If it is on an NFS mounted disk
>>> >> > somewhere, you have to install the new kernel and file system there.
>>> >> > If
>>> >> > on
>>> >> > the flash, you have to install it on the flash.
>>> >> >
>>> >> > THe latest stuff ought to be here (Marc is it so?)
>>> >>
>>> >> Hmm... those look like they are roach1 related.
>>> >>
>>> >> Rather have a look in
>>> >>
>>> >> https://github.com/ska-sa/roach2_nfs_uboot/
>>> >>
>>> >> In particular the executable boot/tcpborphserver3
>>> >>
>>> >> regards
>>> >>
>>> >> marc
>>> >>
>>> >> --
>>> >> 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 post to this group, send email to casper@lists.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 post to this group, send email to casper@lists.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 post to this group, send email to casper@lists.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 post to this group, send email to casper@lists.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 post to this group, send email to casper@lists.berkeley.edu.

Re: [casper] Problem when programming ROACH2

[Marc Welz]

The one is a symbolic link to the other

regards

marc


On Mon, Aug 13, 2018 at 8:56 AM, Raimondo Concu  wrote:
> Yes Mark!
>
> I had already seen this link.
>
> What is the difference between tcpborphserver3 and tcpborphserver3-unmap?
>
> Thank You!
> Raimondo
>
> Il Lun 13 Ago 2018, 10:00 Marc Welz  ha scritto:
>>
>> On Fri, Aug 10, 2018 at 5:51 PM, John Ford  wrote:
>> > That depends where the image lives.  If it is on an NFS mounted disk
>> > somewhere, you have to install the new kernel and file system there.  If
>> > on
>> > the flash, you have to install it on the flash.
>> >
>> > THe latest stuff ought to be here (Marc is it so?)
>>
>> Hmm... those look like they are roach1 related.
>>
>> Rather have a look in
>>
>> https://github.com/ska-sa/roach2_nfs_uboot/
>>
>> In particular the executable boot/tcpborphserver3
>>
>> regards
>>
>> marc
>>
>> --
>> 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 post to this group, send email to casper@lists.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 post to this group, send email to casper@lists.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 post to this group, send email to casper@lists.berkeley.edu.

Re: [casper] Problem when programming ROACH2

[Marc Welz]

On Fri, Aug 10, 2018 at 5:51 PM, John Ford  wrote:
> That depends where the image lives.  If it is on an NFS mounted disk
> somewhere, you have to install the new kernel and file system there.  If on
> the flash, you have to install it on the flash.
>
> THe latest stuff ought to be here (Marc is it so?)

Hmm... those look like they are roach1 related.

Rather have a look in

https://github.com/ska-sa/roach2_nfs_uboot/

In particular the executable boot/tcpborphserver3

regards

marc

-- 
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 post to this group, send email to casper@lists.berkeley.edu.

Re: [casper] Problem when programming ROACH2

[Marc Welz]

As per previous email: Either start it again, or upgrade it

regards

marc


On Fri, Aug 10, 2018 at 12:45 PM, Concu, Raimondo
 wrote:
> Hi Mark,
>
> Hi everyone,
>
> maybe you're right
>
> when the problem happens
>
> and i restart tcpborphserver3, the problem disappears.
>
> and this is the output:
>
> root@192:~# ps -ALL | grep tcp
>   820   820 ?00:00:53 tcpborphserver3
> root@192:~# kill 820
> root@192:~#
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
> roach VMA close
> roach release mem called
>
>
>
> Any suggestions?
>
> Thanks in advance
> Raimondo
>
>
> 2018-08-10 13:46 GMT+02:00 Marc Welz :
>>
>> Hello
>>
>>
>> The "raw unable\_to\_map\_file\_/dev/roach/mem:\_Cannot\_allocate\_memory"
>> is the interesting line. I suspect you are running a slightly older
>> version of the filesystem or romfs which had a bug where it didn't
>> unmap the previous image, and so suffered address space exhaustion
>> after a dozen or so programs. The quick way to solve this is to reboot
>> occasionally, the long term solution is to program a newer version of
>> the romfs (in particular tcpborphserver)
>>
>> regards
>>
>> marc
>>
>>
>> On Fri, Aug 10, 2018 at 10:17 AM, Concu, Raimondo
>>  wrote:
>> > Hi Everyone,
>> >
>> > I have a problem when programming the board after a certain number of
>> > times
>> > (30 - 60),
>> >
>> > as you can see in the following log:
>> >
>> > DEBUG:katcp:Starting thread Thread-1
>> > 2018-08-10 11:04:15,203--client--DEBUG: Starting thread Thread-1
>> > DEBUG:katcp:#version alpha-6-g0b8dd54
>> > 2018-08-10 11:04:15,206--client--DEBUG: #version alpha-6-g0b8dd54
>> > DEBUG:katcp:#build-state 2012-10-24T10:04:56
>> > 2018-08-10 11:04:15,206--client--DEBUG: #build-state 2012-10-24T10:04:5

Re: [casper] Problem with ROACH2 netboot

[Marc Welz]

Well,  bootcmd is what gets run by default, and it differs quite a bit
on the working system - there it specifies the address of an nfs
server.

You could try to run these things manually in parts - first the dhcp,
then the setenv and then the bootm command. Make sure that the
bootargs contain the address and path for your nfs filesystem and your
root device isn't any of the mtblock devices.

These commands aren't particular to a roach, but to uboot in general
and should be documented online.

regards

marc


On Fri, May 11, 2018 at 10:02 AM, Bela Dixit <dixitb...@gmail.com> wrote:
> Thanks Devid and Marc.
> Working ROACH2 not giving "bad CRC" warning.
> I tried with printenv command to check environment variable there is
> difference between working and non-working board. Please find attached file
> of printenv output of working and non-working board.
>
>
> Thanks & Regards,
> Bela
>
> On Wed, May 9, 2018 at 2:41 PM, Marc Welz <m...@ska.ac.za> wrote:
>>
>> As uboot starts up, interrupt the boot to get the uboot prompt. Then
>> run a printenv command and compare it to the other working roach. If
>> the configuration is bad, you might not have a useful kernel command
>> line or mac address available - the latter is need for the network
>> interface to be initialised.
>>
>> regards
>>
>> marc
>>
>>
>> On Wed, May 9, 2018 at 5:50 AM, Bela Dixit <dixitb...@gmail.com> wrote:
>> > Hi CASPERites,
>> >
>> >  I get a problem when I try to boot ROACH2 via netboot. I tried
>> > anther
>> > ROACH2 board with same machine, it successfully booted. The complete log
>> > message dumped on minicom during the boot procedure is reported at the
>> > end
>> > of this email.
>> > Kindly help me to fix the problem.
>> >
>> > Thanks & Regards,
>> > Bela
>> >
>> >
>> > *
>> > Welcome to minicom 2.7
>> >
>> > OPTIONS: I18n
>> > Compiled on Jan  1 2014, 17:13:19.
>> > Port /dev/ttyUSB2, 11:07:44
>> >
>> > Press CTRL-A Z for help on special keys
>> >
>> >
>> >
>> > U-Boot 2011.06-rc2-0-gd422dc0-dirty (Nov 08 2012 - 16:04:14)
>> >
>> > CPU:   AMCC PowerPC 440EPx Rev. A at 533.333 MHz (PLB=133 OPB=66 EBC=66)
>> >No Security/Kasumi support
>> >Bootstrap Option C - Boot ROM Location EBC (16 bits)
>> >32 kB I-Cache 32 kB D-Cache
>> > Board: ROACH2
>> > I2C:   ready
>> > DRAM:  512 MiB
>> > Flash: 128 MiB
>> > *** Warning - bad CRC, using default environment
>> >
>> > In:serial
>> > Out:   serial
>> > Err:   serial
>> > CPLD:  2.1
>> > USB:   Host(int phy)
>> > SN:ROACH2.2 batch=D#6#33 software fixups match
>> > WARN:  MAC not set, deriving private MAC from serial number
>> > MAC:   02:44:01:02:06:21
>> > DTT:   1 is 39 C
>> > DTT:   2 is 39 C
>> > Net:   ppc_4xx_eth0
>> > Sensors Config
>> > type run netboot to boot via dhcp+tftp+nfs
>> > type run soloboot to run from flash independent of network
>> >
>> > Hit any key to stop autoboot:  0
>> > =>  run netboot
>> > Waiting for PHY auto negotiation to complete done
>> > ENET Speed is 1000 Mbps - FULL duplex connection (EMAC0)
>> > BOOTP broadcast 1
>> > *** Unhandled DHCP Option in OFFER/ACK: 28
>> > *** Unhandled DHCP Option in OFFER/ACK: 28
>> > DHCP client bound to address 192.168.100.196
>> > Using ppc_4xx_eth0 device
>> > TFTP from server 192.168.100.1; our IP address is 192.168.100.196
>> > Filename 'uImage'.
>> > Load address: 0x400
>> > Loading:
>> > #
>> >
>> > #
>> >
>> > #
>> >  
>> > done
>> > Bytes transferred = 3034268 (2e4c9c hex)
>> > ## Booting kernel from Legacy Image at 0400 ...
>> >Image Name:   Linux-3.16.0-saska-03675-g1c70ff
>> >Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>> >Data Size:3034204 Bytes = 2.9 MiB
>> >Load Address: 0070
>> >Entry Point:  007010c4
>> >Verifying Checksum ... OK
>> >Uncompressin

Re: [casper] Problem with ROACH2 netboot

[Marc Welz]

As uboot starts up, interrupt the boot to get the uboot prompt. Then
run a printenv command and compare it to the other working roach. If
the configuration is bad, you might not have a useful kernel command
line or mac address available - the latter is need for the network
interface to be initialised.

regards

marc


On Wed, May 9, 2018 at 5:50 AM, Bela Dixit <dixitb...@gmail.com> wrote:
> Hi CASPERites,
>
>  I get a problem when I try to boot ROACH2 via netboot. I tried anther
> ROACH2 board with same machine, it successfully booted. The complete log
> message dumped on minicom during the boot procedure is reported at the end
> of this email.
> Kindly help me to fix the problem.
>
> Thanks & Regards,
> Bela
>
> *
> Welcome to minicom 2.7
>
> OPTIONS: I18n
> Compiled on Jan  1 2014, 17:13:19.
> Port /dev/ttyUSB2, 11:07:44
>
> Press CTRL-A Z for help on special keys
>
>
>
> U-Boot 2011.06-rc2-0-gd422dc0-dirty (Nov 08 2012 - 16:04:14)
>
> CPU:   AMCC PowerPC 440EPx Rev. A at 533.333 MHz (PLB=133 OPB=66 EBC=66)
>No Security/Kasumi support
>Bootstrap Option C - Boot ROM Location EBC (16 bits)
>32 kB I-Cache 32 kB D-Cache
> Board: ROACH2
> I2C:   ready
> DRAM:  512 MiB
> Flash: 128 MiB
> *** Warning - bad CRC, using default environment
>
> In:serial
> Out:   serial
> Err:   serial
> CPLD:  2.1
> USB:   Host(int phy)
> SN:ROACH2.2 batch=D#6#33 software fixups match
> WARN:  MAC not set, deriving private MAC from serial number
> MAC:   02:44:01:02:06:21
> DTT:   1 is 39 C
> DTT:   2 is 39 C
> Net:   ppc_4xx_eth0
> Sensors Config
> type run netboot to boot via dhcp+tftp+nfs
> type run soloboot to run from flash independent of network
>
> Hit any key to stop autoboot:  0
> =>  run netboot
> Waiting for PHY auto negotiation to complete done
> ENET Speed is 1000 Mbps - FULL duplex connection (EMAC0)
> BOOTP broadcast 1
> *** Unhandled DHCP Option in OFFER/ACK: 28
> *** Unhandled DHCP Option in OFFER/ACK: 28
> DHCP client bound to address 192.168.100.196
> Using ppc_4xx_eth0 device
> TFTP from server 192.168.100.1; our IP address is 192.168.100.196
> Filename 'uImage'.
> Load address: 0x400
> Loading: #
>  #
>  #
>  
> done
> Bytes transferred = 3034268 (2e4c9c hex)
> ## Booting kernel from Legacy Image at 0400 ...
>Image Name:   Linux-3.16.0-saska-03675-g1c70ff
>Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>Data Size:3034204 Bytes = 2.9 MiB
>Load Address: 0070
>Entry Point:  007010c4
>Verifying Checksum ... OK
>Uncompressing Kernel Image ... OK
> CPU clock-frequency <- 0x1fca0550 (533MHz)
> CPU timebase-frequency <- 0x1fca0550 (533MHz)
> /plb: clock-frequency <- 7f28154 (133MHz)
> /plb/opb: clock-frequency <- 3f940aa (67MHz)
> /plb/opb/ebc: clock-frequency <- 3f940aa (67MHz)
> /plb/opb/serial@ef600300: clock-frequency <- 54c563 (6MHz)
> /plb/opb/serial@ef600400: clock-frequency <- 54c563 (6MHz)
> /plb/opb/serial@ef600500: clock-frequency <- 54c563 (6MHz)
> /plb/opb/serial@ef600600: clock-frequency <- 54c563 (6MHz)
> Memory <- <0x0 0x0 0x3000> (1023MB)
> ethernet0: local-mac-address <- 00:00:00:00:00:00
>
> zImage starting: loaded at 0x0070 (sp: 0x1fe22b40)
> Allocating 0x6db8a8 bytes for kernel ...
> gunzipping (0x <- 0x0070f000:0x00d5f1c8)...done 0x63fa80 bytes
>
> Linux/PowerPC load: console=ttyS0,115200 root=/dev/nfs
> rootpath=192.168.100.1:/srv/roach_boot/etch ip=dhcp
> Finalizing device tree... flat tree at 0xd6c160
> [0.00] roach2: claiming matching platform
> [0.00] Using PowerPC 44x Platform machine description
> [0.00] Linux version 3.16.0-saska-03675-g1c70ffc (rijandn@r2d2) (gcc
> version 4.6.1 20110627 (prerelease) (GCC) ) #3 Tue Aug 26 08:52:14 SAST 2014
> [0.00] bootconsole [udbg0] enabled
> setup_arch: bootmem
> arch: exit
> [0.00] Zone ranges:
> [0.00]   DMA  [mem 0x-0x3fffefff]
> [0.00]   Normal   empty
> [0.00] Movable zone start for each node
> [0.00] Early memory node ranges
> [0.00]   node   0: [mem 0x-0x3fffefff]
> [0.00] MMU: Allocated 1088 bytes of context maps for 255 contexts
> [0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total
> pages: 260095
&g

Re: [casper] casperfpga attribute error

[Marc Welz]

Another way of programming the roach is to go

(echo "?progdev filename" ; cat) | nc -q 1 roach-ip-or-name 7147

The protocol to speak to the roach is simple text, so you might not
need a supporting library to drive it, provided you are willing to
open a tcp socket and write/read text from it.

regards

marc


On Fri, Jul 7, 2017 at 8:58 AM, James Smith <jsm...@ska.ac.za> wrote:
> Hello Anshu,
>
> Looping back into the mailing list so this is a reference for anyone else
> who encounters this.
>
> In order to use the casperfpga package with a ROACH 1 you need the
> following:
>
> bof file on the ROACH's filesystem, in the /boffiles directory. Either this
> must be on an SD card if you've booted from the SD card, or it must be in
> the appropriate place on the NFS share if you've booted from network. If
> your bof file is in whatever your current directory is, it will still not
> work.
> fpg file in the current directory, this must correspond to the bof file.
> They're generated together by the casper_xps tool.
>
>
> Steps are as follows:
>
> import casperfpga
> fpga = casperfpga.katcp_fpga.KatcpFpga(roachname) # port and timeout
> optional
> fpga.system_info["program_filename"] = boffile
> fpga.program()
> fpga.get_system_information(fpgfile)
>
> And Bob's your uncle. There you go. It's likely that your problem was the
> bof file not being accessible to the ROACH.
>
> Just a note, that if you try to program a ROACH and it fails, the tcpborph
> server often falls over. You may need to reboot the ROACH. To test this:
>
> ssh root@
> ps aux | grep tcpborphserver
>
> Check if the output of that command has  anywhere in it. If so,
> reboot your ROACH:
> shutdown -r now
>
> before trying to program it again.
>
> Hope this helps,
> James
>
>
> On Fri, Jul 7, 2017 at 10:48 AM, Anshu Singh <anshusingh...@gmail.com>
> wrote:
>>
>> Hi James,
>>
>> katchcp version: 0.3.5
>> I upgraded to the latest version (0.6). It is working now.
>> Now the fpga is connected, but I am not able to program it.
>>
>>
>> The bof file is generated using MATLAB 2013a simulink version. ISE version
>> is 14.7.
>>
>>
>> The error is:
>> KatcpRequestFail
>>
>> Details:
>>
>> In [1]: import casperfpga
>>
>> In [2]: boffile='lfpolv1_2048ch_2017_Jul_06_1811.bof'
>>
>> In [3]: fpga = casperfpga.katcp_fpga.KatcpFpga('100.100.100.1',7147,10)
>>
>> In [4]: fpga.is_connected()
>> Out[4]: True
>>
>> In [5]: fpga.system_info['program_filename'] = boffile
>>
>> In [6]: fpga.program()
>>
>> ---
>> KatcpRequestFail  Traceback (most recent call
>> last)
>>  in ()
>> > 1 fpga.program()
>>
>> /usr/local/lib/python2.7/dist-packages/casperfpga/katcp_fpga.pyc in
>> program(self, filename)
>> 326 complete_okay = True
>> 327 if not complete_okay: # Modify to do an extra check
>> --> 328 reply, _ = self.katcprequest(name='status',
>> request_timeout=1)
>> 329 # Not sure whether 1 second is a good timeout here
>> 330 if reply.arguments[0] == 'ok':
>>
>> /usr/local/lib/python2.7/dist-packages/casperfpga/katcp_fpga.pyc in
>> katcprequest(self, name, request_timeout, require_ok, request_args)
>> 161 'Request %s on host %s failed.\n\t'
>> 162 'Request: %s\n\tReply: %s' %
>> --> 163 (request.name, self.host, request, reply))
>> 164 elif reply.arguments[0] == katcp.Message.INVALID:
>> 165 raise KatcpRequestInvalid(
>>
>> KatcpRequestFail: Request status on host 100.100.100.1 failed.
>> Request: ?status
>> Reply: !status fail program
>>
>>
>>
>> What could be the issue?
>>
>>
>> On Fri, Jul 7, 2017 at 12:37 PM, James Smith <jsm...@ska.ac.za> wrote:
>>>
>>> Hello Anshu,
>>>
>>> What version of katcp do you have installed? I have seen this issue when
>>> the katcp library isn't up-to-date.
>>>
>>> I think you can get this either from pip or directly from github.
>>>
>>> Regards,
>>> James
>>>
>>>
>>> On Fri, Jul 7, 2017 at 7:39 AM, Anshu Singh <anshusingh...@gmail.com>
>>> wrote:
>>>>
>>>> Hello,
>>>>
>>>> While trying to link the CASPER 

Re: [casper] Options for reading slow data throughput from ROACH2

[Marc Welz]

On Wed, Jun 28, 2017 at 7:56 PM, Jack Hickish <jackhick...@gmail.com> wrote:

> Here's a preview, which maybe someone more knowledgable with augment /
> correct --
>
> ..
>
> What tgtap does is start a process on the CPU which will read and respond to
> packets from the interface which aren't addressed to the port the FPGA-side
> of the interface is bound to. This is handy, because it means the CPU will
> handle arp traffic, and will automatically discover the MAC addresses of
> devices on the network so you don't have to handle the arp table yourself.

Expanding on this: The tgtap functionality has moved into the tcpborphsever
process itself on more recent roach2 builds.

It uses the tap/tun driver of the linux kernel to make the fpga network devices
available to the CPU.

In addition to handling arp (noisily), it also becomes possible to
handle multicast
subscriptions and dhcp requests. And it it is even possible to ssh
into the roach via
the interfaces. None of that is particularly fast, as the interface is
being polled.

> I
> actually don't know whether tgtap works with a 1GbE interface (I've never
> tried), but if it doesn't manually configuring the core parameters is fairly
> straightforward.

Nor have I ... if the layout of the registers is the same (particularly the word
sizes used to tell the core how to transmit data), then it should
work. Otherwise
there is some hacking required: See
github.com/ska-sa/katcp_devel/tcpborphserver,
in particular tg.c. From line 1700 onward, functions ending in _cmd are the ones
which can be used from the network to drive the devices.

regards

marc

-- 
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 post to this group, send email to casper@lists.berkeley.edu.

Re: [casper] [ROACH2] tap-start invalid

[Marc Welz]

Unrelated to the age of tcpborphserver. If you can't find
/proct/net/igmp then you would be running a kernel build quite a bit
older that what is available ...

regards

marc


On Thu, Jun 8, 2017 at 2:06 PM, Amit Bansod <aban...@mpifr-bonn.mpg.de> wrote:
> Hi Marc,
>
> On "netstat -ng", it says "netstat: no support for 'AF INET (igmp)' on
> this system. Can this be due to old version of tcpborphserver ?
>
> Regards,
> Amit
>
> On 08-Jun-17 3:54 PM, Marc Welz wrote:
>> You might be looking in /proc/sys/net, you want to be in /proc/net
>>
>> regards
>>
>> marc
>>
>>
>> On Thu, Jun 8, 2017 at 1:51 PM, Amit Bansod <aban...@mpifr-bonn.mpg.de> 
>> wrote:
>>> Hi Marc,
>>>
>>> Thanks, I changed the force_igmp_version to 2 however I do not see any
>>> "igmp" entry in /proc/net directory.
>>>
>>> Regards,
>>> Amit
>>>
>>> On 08-Jun-17 3:38 PM, Marc Welz wrote:
>>>> Not 100% sure, but I think you might have to downgrade the linux igmp
>>>> messages to version 2 to work with mellanox ? There is a
>>>> force_igmp_version entry in /proc/sys/net ...
>>>>
>>>> regards
>>>>
>>>> marc
>>>>
>>>>
>>>> On Thu, Jun 8, 2017 at 12:15 PM, Amit Bansod <aban...@mpifr-bonn.mpg.de> 
>>>> wrote:
>>>>> Hi Marc,
>>>>>
>>>>> I gave this a try:
>>>>>
>>>>> fpga.tap_start('tap0',gbe_core_name,mac_id,unicast_source_ip,fabric_port)
>>>>> fpga.tap_multicast_add_recv('tap0',multicast_ip)
>>>>>
>>>>> I do see the log shows "multicast add" successful but we do not see any
>>>>> membership reports from ROACH2. Is there a way to monitor IGMP requests
>>>>> ? I am not sure if the IGMP version has to be same as the switch. We are
>>>>> using the Mellanox SX1012.
>>>>>
>>>>> Thanks,
>>>>> Amit
>>>>>
>>>>>
>>>>> On 02-Jun-17 4:28 PM, Marc Welz wrote:
>>>>>> On Fri, Jun 2, 2017 at 2:10 PM, Amit Bansod <aban...@mpifr-bonn.mpg.de> 
>>>>>> wrote:
>>>>>>> Hi Marc,
>>>>>>>
>>>>>>> I am trying to subscribe to a multicast group (receive data). How then
>>>>>>> can I configure the core to send an IGMP request ?
>>>>>> You are probably looking for ?tap-multicast-add. Note that you can
>>>>>> only invoke that once
>>>>>> you have brought up the tap interface with ?tap-start and related.
>>>>>> There should be
>>>>>> a ?help command which provides an overview.
>>>>>>
>>>>>> regards
>>>>>>
>>>>>> marc
>>>>>>
>

-- 
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 post to this group, send email to casper@lists.berkeley.edu.

Re: [casper] [ROACH2] tap-start invalid

[Marc Welz]

You might be looking in /proc/sys/net, you want to be in /proc/net

regards

marc


On Thu, Jun 8, 2017 at 1:51 PM, Amit Bansod <aban...@mpifr-bonn.mpg.de> wrote:
> Hi Marc,
>
> Thanks, I changed the force_igmp_version to 2 however I do not see any
> "igmp" entry in /proc/net directory.
>
> Regards,
> Amit
>
> On 08-Jun-17 3:38 PM, Marc Welz wrote:
>> Not 100% sure, but I think you might have to downgrade the linux igmp
>> messages to version 2 to work with mellanox ? There is a
>> force_igmp_version entry in /proc/sys/net ...
>>
>> regards
>>
>> marc
>>
>>
>> On Thu, Jun 8, 2017 at 12:15 PM, Amit Bansod <aban...@mpifr-bonn.mpg.de> 
>> wrote:
>>> Hi Marc,
>>>
>>> I gave this a try:
>>>
>>> fpga.tap_start('tap0',gbe_core_name,mac_id,unicast_source_ip,fabric_port)
>>> fpga.tap_multicast_add_recv('tap0',multicast_ip)
>>>
>>> I do see the log shows "multicast add" successful but we do not see any
>>> membership reports from ROACH2. Is there a way to monitor IGMP requests
>>> ? I am not sure if the IGMP version has to be same as the switch. We are
>>> using the Mellanox SX1012.
>>>
>>> Thanks,
>>> Amit
>>>
>>>
>>> On 02-Jun-17 4:28 PM, Marc Welz wrote:
>>>> On Fri, Jun 2, 2017 at 2:10 PM, Amit Bansod <aban...@mpifr-bonn.mpg.de> 
>>>> wrote:
>>>>> Hi Marc,
>>>>>
>>>>> I am trying to subscribe to a multicast group (receive data). How then
>>>>> can I configure the core to send an IGMP request ?
>>>> You are probably looking for ?tap-multicast-add. Note that you can
>>>> only invoke that once
>>>> you have brought up the tap interface with ?tap-start and related.
>>>> There should be
>>>> a ?help command which provides an overview.
>>>>
>>>> regards
>>>>
>>>> marc
>>>>
>

-- 
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 post to this group, send email to casper@lists.berkeley.edu.

Re: [casper] [ROACH2] tap-start invalid

[Marc Welz]

Also:

cat /proc/net/igmp on the roach will tell you what groups the kernel
thinks it should be subscribed to ...

regards

marc


On Thu, Jun 8, 2017 at 12:15 PM, Amit Bansod <aban...@mpifr-bonn.mpg.de> wrote:
> Hi Marc,
>
> I gave this a try:
>
> fpga.tap_start('tap0',gbe_core_name,mac_id,unicast_source_ip,fabric_port)
> fpga.tap_multicast_add_recv('tap0',multicast_ip)
>
> I do see the log shows "multicast add" successful but we do not see any
> membership reports from ROACH2. Is there a way to monitor IGMP requests
> ? I am not sure if the IGMP version has to be same as the switch. We are
> using the Mellanox SX1012.
>
> Thanks,
> Amit
>
>
> On 02-Jun-17 4:28 PM, Marc Welz wrote:
>> On Fri, Jun 2, 2017 at 2:10 PM, Amit Bansod <aban...@mpifr-bonn.mpg.de> 
>> wrote:
>>> Hi Marc,
>>>
>>> I am trying to subscribe to a multicast group (receive data). How then
>>> can I configure the core to send an IGMP request ?
>> You are probably looking for ?tap-multicast-add. Note that you can
>> only invoke that once
>> you have brought up the tap interface with ?tap-start and related.
>> There should be
>> a ?help command which provides an overview.
>>
>> regards
>>
>> marc
>>
>

-- 
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 post to this group, send email to casper@lists.berkeley.edu.

Re: [casper] [ROACH2] tap-start invalid

[Marc Welz]

Not 100% sure, but I think you might have to downgrade the linux igmp
messages to version 2 to work with mellanox ? There is a
force_igmp_version entry in /proc/sys/net ...

regards

marc


On Thu, Jun 8, 2017 at 12:15 PM, Amit Bansod <aban...@mpifr-bonn.mpg.de> wrote:
> Hi Marc,
>
> I gave this a try:
>
> fpga.tap_start('tap0',gbe_core_name,mac_id,unicast_source_ip,fabric_port)
> fpga.tap_multicast_add_recv('tap0',multicast_ip)
>
> I do see the log shows "multicast add" successful but we do not see any
> membership reports from ROACH2. Is there a way to monitor IGMP requests
> ? I am not sure if the IGMP version has to be same as the switch. We are
> using the Mellanox SX1012.
>
> Thanks,
> Amit
>
>
> On 02-Jun-17 4:28 PM, Marc Welz wrote:
>> On Fri, Jun 2, 2017 at 2:10 PM, Amit Bansod <aban...@mpifr-bonn.mpg.de> 
>> wrote:
>>> Hi Marc,
>>>
>>> I am trying to subscribe to a multicast group (receive data). How then
>>> can I configure the core to send an IGMP request ?
>> You are probably looking for ?tap-multicast-add. Note that you can
>> only invoke that once
>> you have brought up the tap interface with ?tap-start and related.
>> There should be
>> a ?help command which provides an overview.
>>
>> regards
>>
>> marc
>>
>

-- 
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 post to this group, send email to casper@lists.berkeley.edu.

Re: [casper] [ROACH2] tap-start invalid

[Marc Welz]

On Fri, Jun 2, 2017 at 2:10 PM, Amit Bansod <aban...@mpifr-bonn.mpg.de> wrote:
> Hi Marc,
>
> I am trying to subscribe to a multicast group (receive data). How then
> can I configure the core to send an IGMP request ?

You are probably looking for ?tap-multicast-add. Note that you can
only invoke that once
you have brought up the tap interface with ?tap-start and related.
There should be
a ?help command which provides an overview.

regards

marc

-- 
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 post to this group, send email to casper@lists.berkeley.edu.

Re: [casper] [ROACH2] tap-start invalid

[Marc Welz]

On Fri, Jun 2, 2017 at 9:53 AM, Amit Bansod <aban...@mpifr-bonn.mpg.de> wrote:
> Dear All,
>
> I am getting this message on giving tap-start on ROACH2:
>
> ?tap-start tap0 gbe0 239.10.1.64 7148 01:00:5E:0A:01:40

Hang on - you are configuring your local interface to be a multicast address.

That doesn't work - an interface needs to have a *unicast* address, it
then *sends*
to a multicast address.

regards

marc

-- 
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 post to this group, send email to casper@lists.berkeley.edu.

Re: [casper] Problem uploading .bof file to Roach1

[Marc Welz]

Long shot - could you have run out of space on the roach ?

On Mon, May 15, 2017 at 7:39 AM, Heystek Grobler
 wrote:
> Good day everyone
>
> I have encountered a weird problem. Everything was working fine until today.
> I cant upload a .bof file to my roach1. I keep getting this error:
>
> #log error 2947729786047 poco ulpoad\_process\_exitet\_with\_code\_69
>
> I have tried uploading the file through kapcp and telnet but poco errors
> keeps popping up.
>
> Does anyone have an idee whats going on?
>
> Thanks for the help
>
> Heystek
>
> --
> 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 post to this group, send email to casper@lists.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 post to this group, send email to casper@lists.berkeley.edu.

Re: [casper] Help to program roach1

[Marc Welz]

It has been a while, but I am not sure if/how the remote upload was
implemented in the roach1 and what its syntax was - it might have been
different. Telnet to port 7147 on the roach and type ?help - if there
is no progremote, see if you can find something similar ...

On Sat, Apr 22, 2017 at 11:26 AM, Heystek Grobler
 wrote:
> Good day
>
> I have an interesting problem. I'm used to working on a ROACH2 and now I
> must do a project on a ROACH1 board.
>
> When Running the casperfpga package I received this error:
>
> In [1]: import casperfpga
>
> In [2]: fpga=casperfpga.katcp_fpga.KatcpFpga('192.168.33.3')
> In [3]:
> fpga.upload_to_ram_and_program('heystek_tut3_2017_Apr_19_1133.bof')---
> RuntimeError  Traceback (most recent call last)
>  in ()
> > 1 fpga.upload_to_ram_and_program('heystek_tut3_2017_Apr_19_1133.bof')
>
> /usr/local/lib/python2.7/dist-packages/casperfpga/katcp_fpga.pyc in
> upload_to_ram_and_program(self, filename, port, timeout, wait_complete)
> 442 if request_result != '':
> 443 raise RuntimeError('progremote request(%s) on host %s
> failed' %
> --> 444(request_result, self.host))
> 445
> 446 # start the upload thread and join
>
> RuntimeError: progremote request(Request to client 192.168.33.3 failed.) on
> host 192.168.33.3 failed
>
> I then tried running the corr package and I got this error:
>
> In [7]: fpga=corr.katcp_wrapper.FpgaClient('192.168.33.3',7147)
> ---
> TypeError Traceback (most recent call last)
>  in ()
> > 1 fpga=corr.katcp_wrapper.FpgaClient('192.168.33.3',7147)
>
> /usr/local/lib/python2.7/dist-packages/corr/katcp_wrapper.pyc in
> __init__(self, host, port, tb_limit, timeout, logger)
>  86 self.host = host
>  87 self._timeout = timeout
> ---> 88 self.start(daemon = True)
>  89
>  90 # async stuff
>
> TypeError: start() got an unexpected keyword argument 'daemon'
>
> With my ROACH2 I had to update the kernel and file system with this
> instructions to solve the problem:
> https://www.mail-archive.com/casper@lists.berkeley.edu/msg06452.html
>
> but this does not work on the ROACH1 so I reverted back to this kernel and
> file system
> https://casper.berkeley.edu/wiki/Setting_Up_BORPH_on_ROACH
>
> What am I doing wrong?
>
> Thanks for the help
>
> Heystek
>
> --
> 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 post to this group, send email to casper@lists.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 post to this group, send email to casper@lists.berkeley.edu.

Re: [casper] ROACH1 serial to USB connection

[Marc Welz]

This is a bit hazy, but I think that might be because the processor
hasn't stopped properly - some permutation of rebooting, unplugging
and pressing the halt button on the GUI repeatedly sometimes helps.
Also check if the processor isn't running in an overclocked
configuration

regards

marc

On Mon, Apr 3, 2017 at 1:07 PM, Heystek Grobler
<heystekgrob...@gmail.com> wrote:
> Hi Jason
>
> Its really no problem.
>
> I used the steps that you have send me with a ST-link V2 J-TAG (It is almost
> like the USB wiggler). I can open up a serail connection with Hyperterminal
> and open up an connection with the OCD Commander. Once i run the Macro I get
> the following error:
>
> Write large: processor running (40:0C)
>
> and
>
> An error occured during the execution of your Marco file. Exit Marco
> execution now?
>
> and then nothing happens.
>
> Thanks for your help!!
>
> Heystek
>
> On Fri, Mar 31, 2017 at 9:27 PM, Jason Ray <j...@nrao.edu> wrote:
>>
>> Heystek,
>>
>> Sorry for the delay in replying.
>>
>> I'm not sure about the converter script.  Every time I've debricked a
>> roach, I used our USB wiggler, and followed these steps:
>>
>> http://www2.asiaa.sinica.edu.tw/~homin/wiki/pmwiki-2.1.27/uploads/HiSpeedDigital/fileHow_to_update_uboot_file_if_ROACH_cannot_bootup.pdf
>>
>> And, this procedure as well...
>> https://casper.berkeley.edu/wiki/ROACH_kernel_uboot_update
>>
>> Hope this helps,
>> Jason
>>
>>
>>
>> On 3/29/2017 8:45 AM, Heystek Grobler wrote:
>>
>> Hi Jason
>>
>> I got my hands on a JTAG. I went through the CASPER debricking tutorial
>> page but I dont understand how to use the converter script? Do you perhaps
>> know how to use it?
>>
>> Thanks for all of your help
>>
>> Heystek
>>
>> On Mon, Mar 27, 2017 at 11:54 AM, Heystek Grobler
>> <heystekgrob...@gmail.com> wrote:
>>>
>>> Hi Jason
>>>
>>> Yes, all flow control is off. both the (Xon/Xoff or DC1/DC3) is off.
>>>
>>> On Mon, Mar 27, 2017 at 11:32 AM, Jason Manley <jman...@ska.ac.za> wrote:
>>>>
>>>> You've checked that hardware flow control is turned off on your serial
>>>> port?
>>>>
>>>> Jason
>>>>
>>>>
>>>> On 27 Mar 2017, at 11:29, Heystek Grobler <heystekgrob...@gmail.com>
>>>> wrote:
>>>>
>>>> > Hi Jason
>>>> >
>>>> > The ROACH1 is a brand new board that we just unboxed. I tried
>>>> > connecing to it using two diffirent serial to usb cables and both gave 
>>>> > the
>>>> > same result, a connection to the board, but the terminal only displays a
>>>> > black screen. No Uboot sequence or any kind of output.
>>>> >
>>>> > I will double check by shorting pins 2 & 3 and see if I get anyyhing
>>>> > on the terminal.
>>>> >
>>>> > If I am right if I say I think that the roach might be bricked?
>>>> >
>>>> > Thanks for all the help
>>>> >
>>>> > Heystek
>>>> >
>>>> > On Wed, Mar 22, 2017 at 9:23 PM, Jason Ray <j...@nrao.edu> wrote:
>>>> > Heystek,
>>>> >
>>>> > Is this a known good roach1 board?  Could it have been bricked by
>>>> > chance?  If so it will behave like you describe and you may need to do 
>>>> > this:
>>>> >
>>>> > https://casper.berkeley.edu/wiki/ROACH_Debricking
>>>> >
>>>> > Another thing you can try if you haven't already is to swap pins 2 &
>>>> > 3.  Even if you have a null modem cable, something else could be going on
>>>> > (with the adapter perhaps.?) and it never hurts to just swap 2 & 3 and 
>>>> > give
>>>> > it another try.
>>>> >
>>>> > Also, a simple thing you can do to verify your serial adapter is
>>>> > working is to do a loopback, short pins 2 & 3 together, then type 
>>>> > something
>>>> > in the terminal and see if it displays on the screen.
>>>> >
>>>> > Good luck,
>>>> > Jason
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > On 3/22/2017 3:08 PM, Heystek Grobler wrote:
>>>> >> Hi
>>>> >>
>>>> >> When I use dev/tty* I can se

Re: [casper] progdev fail

[Marc Welz]

The fpga<->ppc interface is limited in size - if you want to see huge
memory areas, you will need some sort of windowing/offset scheme

regards

marc


On Wed, Dec 14, 2016 at 1:43 PM, Franco <francocuro...@gmail.com> wrote:
> Doing some more testing, I realize the progdev works when I remove the DRAM
> block from the model. What could this mean??
>
> Franco
>
>
>
> On 14/12/16 10:13, Franco wrote:
>>
>> Dear Casperites,
>>
>> I'm trying to progdev a model to ROACH2 and I get the following error:
>>
>> ?progdev cntr_dram2_2016_Dec_13_1558.bof
>> #log info 1019840342915 raw
>> attempting\_to\_program\_cntr_dram2_2016_Dec_13_1558.bof
>> #log info 1019840343002 raw
>> attempting\_to\_program\_bitstream\_of\_19586188\_bytes\_to\_device\_/dev/roach/config
>> #fpga loaded
>> #log warn 1019840343887 raw
>> requesting\_to\_map\_a\_rather\_large\_area\_of\_0x8000
>> #log error 1019840343887 raw
>> unable\_to\_map\_file\_/dev/roach/mem:\_Cannot\_allocate\_memory
>> #log error 1019840343890 raw
>> unable\_to\_program\_bit\_stream\_from\_cntr_dram2_2016_Dec_13_1558.bof
>> !progdev fail
>>
>> Anyone has any idea what's the problem? I can program other models fine,
>> but this is the first model I compiled using the SKA fork library.
>>
>> Thanks,
>>
>> Franco
>>
>
>

Re: [casper] Problem reading DRAM in ROACH2

[Marc Welz]

Then there is no bitstream programmed or the particular bitstream
doesn't contain that register. Type

?listdev

on that connection to find out

regards

marc


On Fri, Dec 2, 2016 at 12:52 PM, Franco <francocuro...@gmail.com> wrote:
> It says: #log error 1018802834854 raw
> register\_dram_controller\_not\_defined
>
>
> Franco
>
>
>
> On 02/12/16 04:32, Marc Welz wrote:
>>
>> telnet to the roach on port 7147 while repeating the operation - what
>> do the #log messages say ?
>>
>> On Thu, Dec 1, 2016 at 3:43 PM, Franco <francocuro...@gmail.com> wrote:
>>>
>>> Hi!
>>>
>>> I tried to test the dram of ROACH2 by porting an example model I had for
>>> ROACH1.
>>>
>>> However when I tried to read the dram I got the following error:
>>>
>>> RuntimeError: Request write failed.
>>>Request: ?write dram_controller 0 \0\0\0\0
>>>Reply: !write fail.
>>>
>>> Someone knows what's the problem?
>>>
>>>
>>> thanks,
>>>
>>> Franco Curotto
>>>
>>>
>

Re: [casper] Problem reading DRAM in ROACH2

[Marc Welz]

telnet to the roach on port 7147 while repeating the operation - what
do the #log messages say ?

On Thu, Dec 1, 2016 at 3:43 PM, Franco  wrote:
> Hi!
>
> I tried to test the dram of ROACH2 by porting an example model I had for
> ROACH1.
>
> However when I tried to read the dram I got the following error:
>
> RuntimeError: Request write failed.
>   Request: ?write dram_controller 0 \0\0\0\0
>   Reply: !write fail.
>
> Someone knows what's the problem?
>
>
> thanks,
>
> Franco Curotto
>
>

Re: [casper] Programming a ROACH2

[Marc Welz]

I can't answer the question directly, there is a C utility which will
program fpg files into roach2s, called kcpfpg - it lives on github in
ska-ska/katcp_devel - run the toplevel makefile then cd into fpg and
there should be the utility

regards

marc


On Tue, Oct 11, 2016 at 12:56 PM, Heystek Grobler
<heystekgrob...@gmail.com> wrote:
> Hi
>
> I am now trying to do this manually line by line through ipython.
>
> Do anyone perhaps know what is the equivalent for the roach2 of the
> following function?
> fpga.progdev()
>
> a_0=struct.unpack('>1024l',fpga.read('even',1024*4,0))
> a_1=struct.unpack('>1024l',fpga.read('odd',1024*4,0))
>
>
>
> On Tue, Oct 11, 2016 at 1:43 PM, James Smith <jsm...@ska.ac.za> wrote:
>>
>> Hello Heystek,
>>
>> Having looked at the tut3 which is on the website, it is using the older
>> corr library, not casperfpga. It also looks as though it's intended for
>> ROACH and not ROACH2, I'm not sure whether that's an issue. I've never used
>> a ROACH2.
>>
>> I was under the impression that it should have been updated for the recent
>> CASPER workshop. Can someone comment on this?
>>
>> It might be an interesting exercise to try and use the model files to
>> compile for ROACH2 then to write your own script, using this one as a guide.
>> You'd learn a lot about how things work in the process. Not a quick fix to
>> your problem, I'll admit, but it'll be an education.
>>
>> Regards,
>> James
>>
>>
>> On Tue, Oct 11, 2016 at 1:33 PM, Heystek Grobler
>> <heystekgrob...@gmail.com> wrote:
>>>
>>> Hi James
>>>
>>> Through ipython I can connect to the Roach and upload the .fga file. I
>>> can also ping the roach.The problem comes in using the script with the .bof
>>> file. I am very new to python but have training in C, C#, Java and Assembly.
>>>
>>> I run the script as follows:
>>> python tut3.py 192.168.33.7
>>>
>>>
>>> On Tue, Oct 11, 2016 at 1:06 PM, James Smith <jsm...@ska.ac.za> wrote:
>>>>
>>>> Hello Heystek,
>>>>
>>>> How cognisant are you with Python? Try opening an ipython session and
>>>> connecting to your ROACH manually, I think you have been able to do that in
>>>> the past.
>>>>
>>>> This error message means that your network can't reach the ROACH for
>>>> some reason.
>>>>
>>>> Regards,
>>>> James
>>>>
>>>>
>>>> On Tue, Oct 11, 2016 at 12:46 PM, Heystek Grobler
>>>> <heystekgrob...@gmail.com> wrote:
>>>>>
>>>>> Hi Everyone
>>>>>
>>>>> After trying all of your suggestions and install a few more packages is
>>>>> works. I get the following error now when I run the tut3.py script for 
>>>>> tut3.
>>>>>
>>>>>
>>>>> heystek@heystek-HP-G62-Notebook-PC:~/simulink/heystek_tutorial_3/heystek_tut3$
>>>>> ./tut3.py 192.168.33.7 tut3.bofConnecting to server 192.168.33.7 on port
>>>>> 7147...  FAILURE DETECTED. Log entries:
>>>>> None
>>>>> Traceback (most recent call last):
>>>>>   File "./tut3.py", line 141, in 
>>>>> exit_fail()
>>>>>   File "./tut3.py", line 21, in exit_fail
>>>>> fpga.stop()
>>>>> NameError: global name 'fpga' is not defined
>>>>>
>>>>>
>>>>> Any ideas on how to solve this?
>>>>>
>>>>> Thank you
>>>>>
>>>>> Heystek
>>>>>
>>>>> On Fri, Oct 7, 2016 at 9:05 PM, Ryan Monroe <ryan.m.mon...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> I would suggest using "pip uninstall spead" instead -- I don't recall
>>>>>> ever using it myself, but it appears to be the pip-sanctioned way of
>>>>>> removing something.
>>>>>>
>>>>>>
>>>>>> On 10/07/2016 02:24 AM, James Smith wrote:
>>>>>>
>>>>>> Hello Heystek,
>>>>>>
>>>>>> Pip is seeing that you've already got a version of Spead installed,
>>>>>> which might not have worked. You can delete the directory to 'uninstall' 
>>>>>> it
>>>>>> (Request for comment: is this a safe approach? It's what I've always done
>>>>>> with 

Re: [casper] ROACH status queries

[Marc Welz]

So: if you have multiple bof files, then I am not sure if between
reprograms things should remain set up or initialised. In addition to
whatever resets happen on the fpga, the register layout (the memory
locations) can also change ?

regards

marc


On Thu, Jul 14, 2016 at 7:59 PM, Miller, Eric H. <eric.mil...@sdsmt.edu> wrote:
> Thanks all for the replies and suggestions.
>
> "?listdev" does indeed show a number of register names, so it looks like the 
> ROACH was programmed successfully, and that "program" was an indication of 
> success rather than an error.
>
> Currently I am unable to take data (attempts return only zeros).  Perhaps 
> more significantly, the clock returns \x00\x00\x00\x00.
>
> Some additional information:
> I am using roach1.
> tcpborphserver2 is running on the ROACH.
> I have been controlling the ROACH through the Casper python interface on the 
> control computer.
> I have input a clock signal at 746 MHz through the digitization card.
> I can successfully read and write to any registers on the ROACH after it is 
> programmed.
> My first step is to load and run a .bof file called init_clock.  After 
> loading this, clock values increment reasonably.
> My second step is to load and run a .bof file to take data.  This appears to 
> load correctly, but bram registers are all zeros after forcing a trigger, and 
> the clock value sits at zero always.
>
> This system had been run previously with success using the same python 
> operations and .bof files.  It's possible that there are required packages 
> that are not installed on the ROACH, because the USB drive had been loaded as 
> read-only (so packages installed previously may now be absent).
>
> Best,
> Eric Miller
>
>
> 
> From: Marc Welz <m...@ska.ac.za>
> Sent: Tuesday, June 28, 2016 1:52 AM
> To: Miller, Eric H.
> Cc: To: casper@lists.berkeley.edu
> Subject: Re: [casper] ROACH status queries
>
> What does
>
> "?listdev" (issued via telnet roach-ip 7147, discard the quotes) have
> to say after a program ? If there are lots of register names, then it
> probably programmed successfully.
>
> You don't specify if you are using a roach1 or roach2...  Generally
> you can telnet to the roach on port 7147 via a separate connection
> which you can keep open indefinitely, and it should give you some
> feedback on what it is attempting to do. If you issue a "?log-level
> debug" or even "?log-level trace" you should get even more detailed
> feedback. Programming on a roach1 happens in a subprocess, so that is
> one of the cases where there is a bit less detail... common problems
> include that the executable in the bof file doesn't match the
> libraries installed on the roach.
>
> regards
>
> marc
>
>
> On Mon, Jun 27, 2016 at 3:45 PM, Miller, Eric H. <eric.mil...@sdsmt.edu> 
> wrote:
>> Hello ROACHers,
>>
>>
>> I'm having some trouble operating a ROACH I've inherited, which used to
>> work.  Currently, after loading a .bof file via progdev, a status query
>> returns "program."  I understand this to be an error message of some sort,
>> but cannot find any documentation explaining what the various status errors
>> mean.  Can anyone shed some light on this, or point me to where these error
>> messages are detailed?
>>
>>
>> Thanks,
>>
>> Eric

Re: [casper] packet capture

[Marc Welz]

There are a number of things to look at:

  - the content of /proc/sys/net/*/*rmem*
  - various sheduling priorities
  - the network driver (and card) - some are better than others, and
many have options to tweak things
  - how bursty your traffic from the roach is
  - the locking strategy of your code (you might be waiting
unproductively for a lock)
  - and maybe CPU affinities ?

And if you can, measure and profile your execution path

regards

marc






On Thu, Jun 30, 2016 at 4:58 AM, Louis P. Dartez <louisdar...@gmail.com> wrote:
> Hi all,
> Can anyone guide me on what tools are being used for packet capture purposes
> right now? I’ve been working on a baseband recorder using a ROACH1 using the
> 10GbE lines but I can’t seem to avoid losing packets when writing data to
> memory or disk. I wrote a threaded packet sniffer in C with a pretty tight
> loop that write directly to memory in Ubuntu Linux. I’m wondering if there
> are any optimizations that I could be missing out.
>
>
> Any advice would be greatly appreciated, Thanks in advance!
> LD
>
> Louis P. Dartez
>
> Ph.D. Candidate
>
> STARGATE
>
> Center for Advanced Radio Astronomy
>
> University of Texas Rio Grande Valley
>
> (956) 372-5812
>
>

Re: [casper] ROACH status queries

[Marc Welz]

What does

"?listdev" (issued via telnet roach-ip 7147, discard the quotes) have
to say after a program ? If there are lots of register names, then it
probably programmed successfully.

You don't specify if you are using a roach1 or roach2...  Generally
you can telnet to the roach on port 7147 via a separate connection
which you can keep open indefinitely, and it should give you some
feedback on what it is attempting to do. If you issue a "?log-level
debug" or even "?log-level trace" you should get even more detailed
feedback. Programming on a roach1 happens in a subprocess, so that is
one of the cases where there is a bit less detail... common problems
include that the executable in the bof file doesn't match the
libraries installed on the roach.

regards

marc


On Mon, Jun 27, 2016 at 3:45 PM, Miller, Eric H. <eric.mil...@sdsmt.edu> wrote:
> Hello ROACHers,
>
>
> I'm having some trouble operating a ROACH I've inherited, which used to
> work.  Currently, after loading a .bof file via progdev, a status query
> returns "program."  I understand this to be an error message of some sort,
> but cannot find any documentation explaining what the various status errors
> mean.  Can anyone shed some light on this, or point me to where these error
> messages are detailed?
>
>
> Thanks,
>
> Eric

Re: [casper] ROACH2 romfs upgrade

[Marc Welz]

On Thu, May 19, 2016 at 1:42 PM, Amit Bansod <aban...@mpifr-bonn.mpg.de> wrote:
> Hello,
>
> I am trying to upgrade romfs on ROACH2 via "run tftproot".
>
> https://github.com/ska-sa/roach2_nfs_uboot/blob/master/boot/roach2-root-phyprog-release-2015-04-01.romfs
>
> The process seems to work but it stops after
>
> "Copy to Flash...done" with a prompt.
>
> After entering => boot, the romfs doesn't seem to be upgraded.

Maybe do an rm /usr/.keep and then reboot again, if you would like to
destroy local customisations and reset things to the new defaults ?

regards

marc

Re: [casper] upload_program_bof error

[Marc Welz]

Hello

Just use a port over 1024 in the upload command

On Thu, May 12, 2016 at 7:37 AM, Amit Bansod <aban...@mpifr-bonn.mpg.de> wrote:
> Hi Marc,
>
> I tried as root as well but I get the same error.
>
> Cheers,
> Amit
>
> On 28-Apr-16 10:57 AM, Marc Welz wrote:
>> unix systems do not let unpriviledged users bind ports under 1024
>>
>> On Wed, Apr 27, 2016 at 6:08 PM, Amit Bansod <aban...@mpifr-bonn.mpg.de> 
>> wrote:
>>> Hello,
>>>
>>> I am using upload_program_bof to upload the bof file and I get following
>>> errors:
>>>
>>> Programming FPGA... 
>>> ('Error: request(Request to client failed.), upload(Could not connect to
>>> upload port.)',)
>>> Error: request(Request to client failed.), upload(Could not connect to
>>> upload port.)
>>> FAILURE DETECTED. Log entries:
>>> 192.168.2.102: Starting thread Thread-1
>>> 192.168.2.102: #version 62baddd-dirty
>>> 192.168.2.102: #build-state 2015-03-25T11:27:47
>>> 192.168.2.102: ?upload 30 3000
>>>
>>> 192.168.2.102: #log error 1015543619345 raw
>>> unwilling\_to\_bind\_reserved\_port\_30
>>> 192.168.2.102: !upload invalid
>>> 192.168.2.102: Request upload failed.
>>>   Request: ?upload 30 3000
>>>   Reply: !upload invalid.
>>> None
>>>
>>> Do I need to update the corr/katcp library or this has to do with the
>>> reserved port particular to this system as I did not observe this before
>>> with other systems ?
>>>
>>> Cheers,
>>> Amit
>>>

Re: [casper] Tap-Start Error message 1GbE block

[Marc Welz]

On Tue, May 10, 2016 at 3:56 PM, Sam Gordon <sbg2...@gmail.com> wrote:
> Hi Marc,
>
> Thanks for the lead. I see the line you're referring to (735), but am not
> sure how to go about clearing that register. I tried toggling the transfer
> and receive registers on the GbE block to no avail (thinking it might be one
> of those).

So here I am of little use, as I haven't ever looked at the gateware
backing that register - I just know that the control software checks
that register to see if there is space to send. Maybe somebody else
knows the insides of the 10Gbe core ?

regards

marc

Re: [casper] Tap-Start Error message 1GbE block

[Marc Welz]

> After sending, telnet returns the 'tap-start is OK' message, then enters
> into an endless stream of:
>
> #log warn 183324 raw tx\_queue\_still\_busy\_(8\_words\_to\_send)
>
> Meanwhile, the network configuration in the PPC shows that tap0 has been
> created, and the UDP frame contains the settings that I chose:

In such cases, checking the source for the log message
(github.com/ska-sa/katcp_devel/ - tcpborphserver/tg.c), suggests that
the register at offset 0x18 in gbeX never seems to clear, indicating
to software that there is no space to send ?

regards

marc

Re: [casper] upload_program_bof error

[Marc Welz]

unix systems do not let unpriviledged users bind ports under 1024

On Wed, Apr 27, 2016 at 6:08 PM, Amit Bansod  wrote:
> Hello,
>
> I am using upload_program_bof to upload the bof file and I get following
> errors:
>
> Programming FPGA... 
> ('Error: request(Request to client failed.), upload(Could not connect to
> upload port.)',)
> Error: request(Request to client failed.), upload(Could not connect to
> upload port.)
> FAILURE DETECTED. Log entries:
> 192.168.2.102: Starting thread Thread-1
> 192.168.2.102: #version 62baddd-dirty
> 192.168.2.102: #build-state 2015-03-25T11:27:47
> 192.168.2.102: ?upload 30 3000
>
> 192.168.2.102: #log error 1015543619345 raw
> unwilling\_to\_bind\_reserved\_port\_30
> 192.168.2.102: !upload invalid
> 192.168.2.102: Request upload failed.
>   Request: ?upload 30 3000
>   Reply: !upload invalid.
> None
>
> Do I need to update the corr/katcp library or this has to do with the
> reserved port particular to this system as I did not observe this before
> with other systems ?
>
> Cheers,
> Amit
>

Re: [casper] arp: unknown or malformed arp packet

[Marc Welz]

On Fri, Apr 1, 2016 at 10:05 AM, Amit Bansod <aban...@mpifr-bonn.mpg.de> wrote:
> Hi Marc,
>
> Unfortunately ?tap-info does not show any information like "announce" or
> "query".

That probably means you are running an earlier version of tcpborphserver

> I do see lot of messages like
>
> #log warn raw discarding frame of unknown type 0x808 and length 72
> #log warn raw discarding frame of unknown type 0x808 and length 600
> #log warn raw write to tap device tap3 failed: Invalid argument


Type 0x800 is IP, 0x806 is arp. But 0x808 it seems to be frame relay
arp !? That seems a bit weird.

Maybe you have trunking vlan enabled on those ports ? I would have
guessed IPv6 (which the roaches don't do) but that seems to be 86dd.
Maybe check your switch configuration ?

regards

marc

Re: [casper] arp: unknown or malformed arp packet

[Marc Welz]

Assuming you are running a recent version of tcpborphserver, the error
message is generated at line 2601 or so in tg.c, where the beginning
of a packet is compared to the arp header which we can process
(arp_const). It maybe be that your network has:

* unusual arp traffic
* maybe vlan traffic
* or some sort of other corruption.

Check with tcpdump on a PC to see if you can spot anything usual, it
might not be anything serious but simply something that isn't
supported

regards

marc


On Thu, Mar 31, 2016 at 2:23 PM, Amit Bansod <aban...@mpifr-bonn.mpg.de> wrote:
> Hi All,
>
> We are seeing, "arp: unknown or malformed arp packet" messages on ROACH2
> board, quite frequently.
>
> In our setup, we have ROACH2 board sending data out via a  40G switch.
> Sometimes the data is broadcast from ROACH2 boards instead of sending to
> a particular ip address.
>
> The 10GbE core details show ARP table having unknown MAC addresses tied
> to unused IP addresses. Is this usual ? We do not have anything else
> connected in this closed network.
>
> We are trying to figure out if the above message is related to this issue.
>
> How can we debug the root of this message ?
>
> Thanks,
> Amit
>

Re: [casper] 10 gbe on ROACH-2

[Marc Welz]

So it depends on exactly what you want - if you are going though one
(eg default) gateway to both subnets, then this might be feasible, but
you will need a very new tcpborphserver. Having multiple routes on a
single interface will require custom fpga work, however.

It isn't clear how smart a switch you have - in some cases multicast
may also be an option

regards

marc


On Tue, Dec 1, 2015 at 3:46 PM, John Ford <jf...@nrao.edu> wrote:
> Hi all.  I have another question on ROACH-2 ten gbe interfaces.
>
> We really need to be able to set up 2 10.0.{17,18}.X subnets on our system
> with the roaches able to send to  either subnet.  I understand this is
> currently not possible.
>
> Is it something that could be undertaken?  Hints as to where to start
> would be welcome...
>
> John
>
>
>
>

Re: [casper] Multicast on 10 gbe on ROACH-2?

[Marc Welz]

David MacMhaon wrote:

>> I think multicast transmit is easy (just populate the ARP table
>> appropriately).  I think multicast receive is also supported with recent
>> versions of the 10GbE yellow block.  You could probably check the
>> mlib_devel git commit logs for the yellow block code to find clues.

Not sure if the arp table is involved in this - the destination mac is
(should be)
generated algorithmically from the destination multicast IP address, though
the above might be a unusual workaround.

Sending is reasonably straighforward, as there is no control traffic involved.
Reception does require a newer romfs/tcpborphserver where we get the kernel
to issue IGMP requests on the 10Gbe interfaces, so that the traffic arrives
at the particular port.

regards

marc

Re: [casper] ROACH1 10GbE routing

[Marc Welz]

>
> I use an ancient version of the core package, and here is the help on on 
> tg_tap - no mention of a gateway here...
>
> tap_start(self, tap_dev, device, mac, ip, port) method of 
> corr.katcp_wrapper.FpgaClient instance
> Program a 10GbE device and start the TAP driver.
>
> @param self  This object.
> @param device  String: name of the device (as in simulink name).
> @param tap_dev  String: name of the tap device (a Linux identifier). If 
> you want to destroy a device later, you need to use this name.
> @param mac   integer: MAC address, 48 bits.
> @param ipinteger: IP address, 32 bits.
> @param port  integer: port of fabric interface (16 bits).
>
> Please note that the function definition changed from corr-0.4.0 to 
> corr-0.4.1 to include the tap_dev identifier.

Hmmm ... there are three options:

* Try to set the gateway manually - do serveral wordreads of the gbe0
register, and then write the gateway into the 0xc offset. This is
probably the quickest way of getting it going, but will only route
gateware traffic

* try and extend tcpborphserver to add routing functionality, using
the code from the new tcpborphserver3 as a guide. That is some effort
and involves cross-compiling - and might also need a matching update
to the corr package

* backport the mmap driver from roach2 to roach1 - that is the biggest
chunk of work and involves  a bit of kernel hacking, and you
personally might not be up for it - but if anybody else on the list
has the energy it it would mean that the roach2 and roach1 userland
could be pretty much merged, and things like multicast support would
be available on roach1, in addition to the other fixes and features
(.fpg files, etc)

regards

marc


>
> Cheers,
> Ramesh
>
>
>
>
>

Re: [casper] ROACH1 10GbE routing

[Marc Welz]

On Tue, Oct 27, 2015 at 2:46 PM, Ramesh Karuppusamy
<ram...@mpifr-bonn.mpg.de> wrote:
>
> Hello List,
>
> For a set up here, we have a ROACH1 with it 10GbE (assigned to 10.0.0.30) 
> ports connected to a HP 5412l switch’s VLAN (subnet 10.0.0.0/24). Is there a 
> way to get the ROACH1’s 10GbE packets on a second VLAN (subnet 10.0.2.0/24) 
> on the same switch?
>
> On starting tgtap, the following routing table looks as follows on the ROACH1:
>
> root@dhcpeff64253:~# route -n
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric RefUse Iface
> 10.0.0.00.0.0.0 255.255.255.0   U 0  00 tap0
> 134.104.64.00.0.0.0 255.255.240.0   U 0  00 eth0
> 0.0.0.0 134.104.64.16   0.0.0.0 UG0  00 eth0
>
>
> I did manually add a static route on the ROACH1 as soon as the gateway was 
> loaded: route add -net 10.0.2.0 netmask 255.255.255.0 gw 10.0.0.200 dev tap0

Shouldn't you then have a route involving the tap0 interace with a G
flag in it ?

> I have enabled routing on the switch, and I can ping 10.0.2.20 from 10.0.0.11 
> on adding relevant static routes on both machines. However this doesn’t work 
> for the ROACH1. What is going wrong here?

The tgtap logic handles arp and thus also needs to substitute the
ethernet mac of the gateway - I don't remember when support was added
for that - github/ska-sa/katcp_devel has the code in
transmit_ip_fpga(), there is a chance you might have to backport it.
However, this is for control traffic (packets that the kernel sends)
only.

In the case of the packets being generated by gateware on the fpga,
this substitution is made differently - I think the gateway register
needs to be loaded up (at offset 0xc). Doesn't the tap-start call have
an option for that ?

regards

marc


>
> Cheers,
> Ramesh

Re: [casper] network settings.

[Marc Welz]

You don't specify if you boot off the onboard flash, via nfs or something else.

If you boot via nfs, the kernel does the initial dhcp request to get
the root filesystem,
so it won't write anything into resolv.conf - that you would have to
do with another
dhcp request, taking care not to deconfigure the interface, otherwise
you use your
filesystem (as it is set up via nfs) - best is to keep the resolv.conf
set up remotely.

Generally, strace is helpful, it will tell you what configuration
files an application opens

regards

marc


On Fri, Oct 16, 2015 at 2:56 AM, Simon Dicker <simon.dic...@gmail.com> wrote:
> This should be a simple one - where/how does a roach1 store its network
> settings?  I need to change a static IP address.  Editing
> /etc/network/interfaces and rebooting does not seem to do the trick, instead
> I had to use:
> ifconfig eth0 xxx.xx.xx.xx netmask 255.255.248.0
>
> A bigger problem is getting a working DNS nameserver.  I have one roach that
> has no problem resolving any name I give it while another can only access
> other machines using numerical IPs (or if you add them to the /etc/hosts
> file).  Editing /etc/resolv.conf makes no difference and in any case that
> file is the same in both roaches.
>
> Thanks
>
> Simon Dicker

[casper] Fwd: ROACH-1 Boot issue

[Marc Welz]

From: Marc Welz <m...@ska.ac.za>
Date: Wed, Oct 14, 2015 at 7:24 AM
Subject: Re: [casper] ROACH-1 Boot issue
To: indrajit <indra...@iiap.res.in>


What is autoboot configured as ? It looks like boot from mmc - mmc
(depending on card and controller) can corrupt horribly on power
failures. Have you tried regenerating the images, or swapping the
cards out ?

regards

marc


On Wed, Oct 14, 2015 at 4:26 AM, indrajit <indra...@iiap.res.in> wrote:
> Hi all,
>
> A new ROACH-1 board was working fine till yesterday night. In the morning I
> am trying to boot the board using autoboot mode following error has
> occurred. Where I could able to login into the solo boot sequence and trying
> to edit the
> /etc/network/interfaces file . But no such file is there . Should I create
> manually then I have to connect ?
>
> The Board is new one came to replace old one which is not at all booting.
>
>
> Experts please suggest how to go about this..
>
> Bellow is the sequence of both auto boot mode and solo boot mode 
>
>
> ++ auto boot sequence +
>
> U-Boot 2008.10-svn3231 (Jul 15 2010 - 14:58:38)
>
> CPU:   AMCC PowerPC 440EPx Rev. A at 533.333 MHz (PLB=133, OPB=66, EBC=66
> MHz)
>No Security/Kasumi support
>Bootstrap Option C - Boot ROM Location EBC (16 bits)
>32 kB I-Cache 32 kB D-Cache
> Board: Roach
> I2C:   ready
> DTT:   1 is 24 C
> DRAM:  (spd v1.3) dram: notice: ecc ignored
>  1 GB
> FLASH: 64 MB
> USB:   Host(int phy) Device(ext phy)
> Net:   ppc_4xx_eth0
>
> Roach Information
> Serial Number:040524
> Monitor Revision: 10.1.1843
> CPLD Revision:8.0.1588
>
> type run netboot to boot via dhcp+tftp+nfs
> type run soloboot to run from flash without network
> type run mmcboot to boot using filesystem on mmc/sdcard
> type run usbboot to boot using filesystem on usb
> type run bit to run tests
>
> Hit any key to stop autoboot:  0
> WARNING: adjusting available memory to 3000
> ## Booting kernel from Legacy Image at fc00 ...
>Image Name:   Linux-2.6.25-svn2382-dirty3
>Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>Data Size:1399105 Bytes =  1.3 MB
>Load Address: 
>Entry Point:  
>Verifying Checksum ... OK
>Uncompressing Kernel Image ... OK
> id mach(): done
> MMU:enter
> MMU:hw init
> MMU:mapin
> MMU:setio
> MMU:exit
> setup_arch: enter
> setup_arch: bootmem
> ocp: exit
> arch: exit
> Linux version 2.6.25-svn2382-dirty3 (marc@seif) (gcc version 4.0.0 (DENX
> ELDK 4.0 4.0.0)) #23 Tue Nov 10 15:30:48 SAST 2009
> AMCC PowerPC 440EPx Roach Platform
> Zone PFN ranges:
>   DMA 0 ->   262143
>   Normal 262143 ->   262143
> Movable zone start PFN for each node
> early_node_map[1] active PFN ranges
> 0:0 ->   262143
> Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260096
> Kernel command line: console=ttyS0,115200
> mtdparts=physmap-flash.0:1792k(linux),256k@0x1c(fdt),8192k@0x20(root),54656k@0xa0(usr),256k@0x3f6(env),384k@0x3fa(uboot)fdt_addr=0xfc1c
> root=b301 rw rootdelay=1
> PID hash table entries: 4096 (order: 12, 16384 bytes)
> console [ttyS0] enabled
> Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
> Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
> Memory: 1036416k available (2092k kernel code, 728k data, 132k init, 0k
> highmem)
> Mount-cache hash table entries: 512
> BORPH version CVS-$Revision: 1.10 $ Initialized
> net_namespace: 152 bytes
> NET: Registered protocol family 16
>
> PCI: Probing PCI hardware
> SCSI subsystem initialized
> usbcore: registered new interface driver usbfs
> usbcore: registered new interface driver hub
> usbcore: registered new device driver usb
> NET: Registered protocol family 2
> IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
> TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
> TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
> TCP: Hash tables configured (established 131072 bind 65536)
> TCP reno registered
> hwrtype_roach version CVS-$Revision: 1.1 $ registered
> JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
> io scheduler noop registered (default)
> Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
> serial8250: ttyS0 at MMIO 0x0 (irq = 0) is a 16550A
> serial8250: ttyS1 at MMIO 0x0 (irq = 1) is a 16550A
> serial8250: ttyS2 at MMIO 0x0 (irq = 35) is a 16550A
> serial8250: ttyS3 at MMIO 0x0 (irq = 36) is a 16550A
> brd: module loaded
> PPC 4xx OCP EMAC driver, version 3.54
> mal0: initialized

Re: [casper] Error Booting ROACH2 "wrong image format for bootm commmand"

[Marc Welz]

You need both a valid root file system and kernel on your roach for
the "soloboot" macro to bring up your system. The "run tftproot"
programs a new file system, but it seems that the kernel image isn't
correct, so that must have been managled somehow (possibly with a "run
tftpkernel"). So try to update your kernel. Also: don't try updating
uboot until you are a lot more comfortable with the entire thing,
recovering from a failed uboot update is a lot harder. But you may
have an imls command, it might tell you if it can find a valid kernel
on flash.

regards

marc




On Fri, Sep 25, 2015 at 2:53 PM, Brad Dober <do...@sas.upenn.edu> wrote:
> Hi Casperites,
>
> I'm booting up a new ROACH2 and it was booting fine on soloboot last night.
> I came in this morning to see this on bootup:
>
> type run netboot to boot via dhcp+tftp+nfs
>
> type run soloboot to run from flash independent of network
>
>
> Hit any key to stop autoboot: 2 \0x08\0x08\0x08 1 \0x08\0x08\0x08 0
>
> Wrong Image Format for bootm command
>
> ERROR: can't get kernel image!
>
>
> I just tried running tftproot from the latest github version, and it loads
> without throwing an error, but when I run 'reset', the same error:
>
>
> Wrong Image Format for bootm command
>
> ERROR: can't get kernel image!
>
>
> comes up when trying to boot into soloboot.
>
>
> Any idea what could be the culprit?
>
>
> Brad Dober
> Ph.D. Candidate
> Department of Physics and Astronomy
> University of Pennsylvania
> Cell: 262-949-4668

Re: [casper] Connecting to ROACH2 via USB and Ethernet

[Marc Welz]

On Wed, Sep 9, 2015 at 4:21 PM, Christopher Barnes <barnc...@umich.edu>
wrote:

> Hey Marc,
>
> I plugged the ROACH into a PC, and the USB connection is visible within my
> /dev/ folder.  However, when I updated minicom to recognize the correct USB
> connection and then turned on the ROACH (same as power cycling it?), the
> ROACH did not boot up in the terminal window.  Do you think that using
> another program, like cutecom or picocom, might make a difference?
>

Not sure if another terminal emulator helps, but do note that there are 4
serial ports
which connect to the roach (some used for jtag) and only one runs the
console, so try all the permutations, especially with the new systemd/udev
nonsense - it might rename the ports. Also port speed and flow control
might need to be set correctly

regards

marc

Re: [casper] Connecting to ROACH2 via USB and Ethernet

[Marc Welz]

If you erase the last couple of sectors of onboard flash, then the uboot
bootloader is gone, at which point the board is unresponsive. There are
ways to recover it via jtag over usb. But you will have to do some work.

Things to try: plug in the roach into a PC: does dmesg show any fdti
devices being registered ? If so, there is at least something of the roach
hardware is up. Then power cycle the roach while the correct USB port is
used by minicom: Do you see any messages going past ? If so uboot is
probably ok.

regards

marc


On Tue, Sep 8, 2015 at 6:47 PM, Christopher Barnes <barnc...@umich.edu>
wrote:

> Hello,
>
> My name is Christopher Barnes, and I am a new graduate student at the
> University of Michigan.  My current project is programming a ROACH 2, and
> I've been having a fundamental problem in getting started.
>
> As recently as two weeks ago, I was able to connect to my ROACH over the
> serial connection program 'minicom' and use the 'telnet' command over an
> ethernet cord.  Last week, both of these functionalities did not work.  Is
> there anything basic that I could have broken with the software that could
> have caused this problem?  Establishing one of these two connections is
> essential to moving files to the ROACH 2 in order to program it.
>
> Any help given on this subject would be greatly appreciated.
>
> Thanks,
>
> Chris
>

Re: [casper] ROCH 2 communication through Python

[Marc Welz]

On Wed, Sep 2, 2015 at 6:52 AM, Craig Tong <ct...@ska.ac.za> wrote:

> Hi Aniket.
>
> As James has said, if you have been making various telnet connections to
> your Roach2 before running the script it might be worth just rebooting
> the board before trying the casperFPGA scripts. The tcpborphserver may
> have crashed due to receiving some commands it didn't like.
>
>
if tcpborphserver crashes, it gets restarted automatically (there is a loop
in the startup script, and also something which saves the core file). I
suppose
if it hangs it may be unresponsive.

But really the best way to test if the system is up is to telnet to port
7147.
If something like ?help or ?wordread gives a reply the roach is almost
certainly
working (exception: there was an older mmap bug which prevented ?progdev
working after a dozen attempts or so, it did require a reboot).

If the roach is responsive, then consider looking on the control PC side if
something
has gone wrong. Maybe version differences/mismatches in python or katcp
libraries ?
Unexpected container/control group nonsense courtesy of systemd ?

regards

marc

Re: [casper] ROACH2 SDRAM Check on startup?

[Marc Welz]

The first point looks like you (maybe ?) installed a version of u-boot with
the memory
check and are running it. Updating uboot should be done with care, as
recovering from
a garbled upload is tricky. In other words, if you can tolerate the delay,
and the system is working for you, don't worry too much.

The second means that you are running a kernel which was built without
hardware monitoring
support. If you are not interested in board temperatures, then you can
ignore that. Otherwise there are newer kernels and romfs images on github
in the ska-sa repositories

regards

marc



On Fri, Aug 28, 2015 at 7:27 PM, Brad Dober <do...@sas.upenn.edu> wrote:

> Hi Casperites,
>
> Recently, when soloboot my ROACH2, it begins an SDRAM that slowly (~2-4
> mins) checks the 512 Mb of SDRAM 1 Mb at a time. It previously didn't do
> that.
> Is this a feature that can be turned off? Any idea why it started doing
> this in the first place? My thoughts was maybe a hard reset caused it to
> start up.
>
> While I have your attention, it's also spitting out a bunch of these with
> various sensor names:
> hwmon: create hwsensor could not open
> /sys/bus/i2c/devices/0-0018/temp1_input (No such file or directory)
>
> Is that normal? I don't recall seeing this before...
>
> Thanks for the help!
>
> Brad Dober
> Ph.D. Candidate
> Department of Physics and Astronomy
> University of Pennsylvania
> Cell: 262-949-4668
>

Re: [casper] Roach-2 crashing fix

[Marc Welz]

So I confess to relying on third parties for this information, but isn't
the board populated with 1Gb RAM after all ? Would the crash be trigged by
a kernel memory layout of 3Gb+1Gb rather than  2Gb+2Gb ?

Have you tried the kernel from 9 months ago at github
ska-sa/roach2_nfs_uboot ?

regards

marc


On Wed, Jun 24, 2015 at 11:49 PM, John Ford jf...@nrao.edu wrote:

 Hi all.

 We were having problems with multiple sequentail progdev calls failing on
 our ROACH-2 systems.  We were testing multiple bof files in a loop, and
 the roach would fall over and crash completely, and after the kernel
 panic, it would reboot itself.

 After a great deal of concentrated debugging effort this afternoon by
 Jack, David, Justin, Ryan, Arindam, Randy, and me, the cause of the
 crashing upon multiple progdev calls was found.  It turned out to have
 nothing to do with programming the chip, rather it was a problem with
 memory allocation by the operating system.  Jack found that problem could
 also be caused by allocating a huge array in Python, using lots of memory.

 The problem was caused by the kernel thinking that the ROACH has 768 MB of
 memory on board, when in fact it has only 512 MB.  The fix is to pass the
 real amount of memory to the kernel in the bootargs.  the systems have
 been mostly working for a long time (Years!), so you may want to check
 that your systems know in fact how much memory they have.  If you start up
 top you can see what it thinks, or look in /proc/meminfo.

 John

Re: [casper] Roach1 not working

[Marc Welz]

Well, then you are almost there: Note that the NFS server somehow isn't
happy:

 Root-NFS: Server returned error -13 while mounting
/home/nfs/roach1/current

regards

marc

Re: [casper] Roach1 not working

[Marc Welz]

On Wed, Apr 29, 2015 at 10:49 PM, Nishanth Shivashankaran nshiv...@asu.edu
wrote:

 Hi All,

 We bought a new desktop and I tried installing nfs boot on to the new
 computer to boot the roach1 and  was trying to bring the roach1 up. But I
 think I messed up installing something somewhere and the roach 1 is not
 returning anything to the minicom terminal at all.

 I am sure it is connected to the right port because I can see it on the
 terminal using dmesg command.


If you can see serial text output, then chances are very good that your
bootloader
is still working. Have you tried pressing any key during bootup, to see if
you can reach the
bootloader prompt - if you can type printenv then uboot is still
functional, and there is
no need to resort to jtag

regards

marc

Re: [casper] Roach 2 telnetd

[Marc Welz]

On Fri, Mar 27, 2015 at 4:44 PM, Madden, Timothy J. tmad...@aps.anl.gov
wrote:

  I am trying to start telnetd on a roach2 booting from the local flash.

 I added
 telnetd

 to /etc/rc.local

 When I do a ps -a, no telnet is listed...
 Also I cannot telnet to it.


What happens if you run telnetd from the commandline (via the serial
connection ?)

regards

marc

Re: [casper] Suggested convention for writing registers

[Marc Welz]

On Fri, Mar 20, 2015 at 7:08 AM, James Smith jsm...@ska.ac.za wrote:

 Hello all,

 I've given some thought to the topic of writing (and reading) registers on
 the ROACH using the python corr module. Often in a design a single register
 may be sliced into many bits to control various things. The way I've
 normally seen such a register written in python looks something like this:

 fpga.write_int('control',19|110|025|12|13)

 My feeling is that this approach is difficult to maintain - inheriting
 code from someone else (or even from one's self 6 months down the line) is
 likely to bring about some confusion in this case, and lead to a fair
 amount of spelunking through the Simulink model in order to figure out what
 bit 9 and bit 10 etc. do. On top of this, it places limitations on changing
 one of the bits later without modifying the other ones - bitwise or
 functions work well enough when you're over-writing zeros, but if there's
 something there already it might not work so well.


So it turns out that it is possible to define registers which aren't full
word sizes long in tcpborphserver itself - and then the powerpc will do the
shifts for you - this is particularly useful,
for writes as that then cuts out a network operation (which would be needed
to fetch the adjacent bits so that they aren't clobbered by the write).

In the fpg file (or on the telnet connection), use optional [:bits] after
an offset or a length to define the register - it is fine if such a
register overlaps with something else, as long as the name is unique.

The downside of all this: It isn't tested at all, as nobody is using it
yet. And the code to make it work is a bit tricky - search for the
read/write functions in
https://github.com/ska-sa/katcp_devel/blob/master/tcpborphserver3/raw.c,
for example write_cmd

regards

marc

Re: [casper] Error programming .fpg file

[Marc Welz]

On Wed, Mar 18, 2015 at 1:40 PM, Brad Dober do...@sas.upenn.edu wrote:

 Hi Marc,

 /dev/roach/mem exists but I'm not sure what the correct numbers are.


So if you go cat /proc/devices there should be an entry for the roach
driver which should tell you the major number, if there isn't such a line
then your kernel doesn't ship with support for the mmap driver

regards

marc

Re: [casper] Error programming .fpg file

[Marc Welz]

On Wed, Mar 18, 2015 at 2:10 PM, Brad Dober do...@sas.upenn.edu wrote:

 This is what comes up.


 Character devices:

   ...

252 roach2_fpga

 


Ok, so then /dev/roach/config should be c 252 0 and mem c 252 1. When the
programming
fails, does dmesg tell you anything interesting ?

regards

marc

Re: [casper] Error programming .fpg file

[Marc Welz]

On Wed, Mar 18, 2015 at 2:29 PM, Brad Dober do...@sas.upenn.edu wrote:

 Hi Marc. Thanks for the help.
 I'm not exactly sure what I'm supposed to be looking for, but here's the
 dmesg dump:

 roach2: claiming matching platform

 Using PowerPC 44x Platform machine description

 Linux version 3.9.0-rc1+ (shanly@shanly-HP8710w) (gcc version 4.6.1
 20110627 (prerelease) (GCC) ) #8 Wed Mar 6 12:54:28 SAST 2013


Hmm... maybe try a more recent kernel - there are prebuilt ones at

https://github.com/ska-sa/roach2_nfs_uboot/tree/master/boot as uImage

regards

marc

Re: [casper] Error programming .fpg file

[Marc Welz]

On Wed, Mar 18, 2015 at 2:53 PM, Brad Dober do...@sas.upenn.edu wrote:

 I do that by running tftpkernel at the R2 bootup instead of tftproot,
 correct?


yep - printenv will show you what these macros do in case you want to know
more


 Is there any cleanup I need to do after the reset like when updating
 tcpborphserver3?


No, I think a reboot should be sufficient

regards

marc

Re: [casper] Error programming .fpg file

[Marc Welz]

On Wed, Mar 18, 2015 at 3:11 PM, Brad Dober do...@sas.upenn.edu wrote:


 I tried again with progdev and it failed, but I tried
 fpga.upload_to_ram_and_program('qdr_err_check_2015_Mar_16_1247.fpg') and it
 succeeded.

 Could fpga.upload_to_flash('qdr_err_check_2015_Mar_16_1247.fpg') be
 exhibiting errors?
 I'm using casperfpga.katcp_fpga.KatcpFpga instead of
 corr.katcp_wrapper.FpgaClient


So I don't know about the status of these things ... maybe somebody else
will know

regards

marc

Re: [casper] Error programming .fpg file

[Marc Welz]

On Tue, Mar 17, 2015 at 8:54 PM, Brad Dober do...@sas.upenn.edu wrote:


 #log error 957577359468 raw
 unable\_to\_map\_file\_/dev/roach/mem:\_Invalid\_argument
 #log error 957577359471 raw Unable\_to\_map\_/dev/roach/mem


That looks like you have a kernel which doesn't have the roach2 mmap driver
built for it ?
Maybe you need to upgrade your kernel too ? Do the files /dev/roach/mem
exist and have the
correct major/minor numbers ?

regards

marc

Re: [casper] unable to run tcpborphserver2 from the command line

[Marc Welz]

If you telnet to port 7147 and then type

?log-level trace
followed by
?progdev something

where something is the file you want to have programmed, what happens ?


On Tue, Feb 24, 2015 at 2:28 PM, Paul Marganian pmarg...@nrao.edu wrote:

  Thanks Marc,
 I tracked down where it is being called from linux startup, and it didn't
 look like any options were being passed, so I ignored this issue for a
 while.  I then tried it once with the -b set to /boffiles, and that made no
 difference.  I wasn't sure what the other option values should be other
 then the defaults.
 Paul

 On 02/24/2015 09:25 AM, Marc Welz wrote:



 On Tue, Feb 24, 2015 at 12:22 PM, Paul Marganian pmarg...@nrao.edu
 wrote:

 Hi everyone,
 I've recently run in to a problem with tcpborphserver2 running on Roach
 1.  In the past, I've been able to debug and develop simply by running this
 program interactively, getting feedback from print statements.
 Recently, I've seen that when I run this program from the command line,
 the 'progdev' command fails.  Has anyone else seen this behavior?
 thanks
 Paul Marganian


  Are you running it with the correct options, in particular the one which
 points it at the correct bof file directory  ?

  regards

  marc

Re: [casper] unable to run tcpborphserver2 from the command line

[Marc Welz]

On Tue, Feb 24, 2015 at 12:22 PM, Paul Marganian pmarg...@nrao.edu wrote:

 Hi everyone,
 I've recently run in to a problem with tcpborphserver2 running on Roach
 1.  In the past, I've been able to debug and develop simply by running this
 program interactively, getting feedback from print statements.
 Recently, I've seen that when I run this program from the command line,
 the 'progdev' command fails.  Has anyone else seen this behavior?
 thanks
 Paul Marganian


Are you running it with the correct options, in particular the one which
points it at the correct bof file directory  ?

regards

marc

Re: [casper] unable to run tcpborphserver2 from the command line

[Marc Welz]

Hello

 Thanks Marc,
 Good suggestion.  I'd hat the log level set to debug, but hadn't thought 
 of lowering it.  I get a lot of output, most of which I don't quite 
 understand (see below).  At this point, I probably should add that we 
 are running a tcpborphserver with a mode we created for our own system, 
 'mba':

So 

 ?progdev mba15_obs2d_2014_Jan_31_1052.bof
...
 !progdev ok 537

the !progdev ok suggests that it managed to program the FPGA 
successfully - there should be a borph process with pid 537 
running - you should now be able to read/write the registers ? 

 #log error 151615780430 roach.mba 
 timed\_out\_while\_waiting\_for\_fpga\_status\_to\_change:\_No\_such\_file\_or\_directory
  

This I think relates to a particular status register which 
certain revisions of the gateware supplied to show if the programming
completed - it is unclear if this is even a problem in your case, but I
probably don't the details completely. What matters is if you can see the 
registers then the programming should have worked out - if you type
?listdev you can check your register set, if that disappears after
a short while then you might have problems with the elf executable
embedded in your .bof file 

regards

marc

Re: [casper] unable to run tcpborphserver2 from the command line

[Marc Welz]

 ?progdev mba15_obs2d_2014_Jan_31_1052.bof



So this is the same bof file which sometimes works and sometimes does not ?
Or is this subsequent to some upgrade of the roach ? If it is a sometimes
work/not work issue maybe
you are not marking it executable (chmod +x) on transfer or the transfer is
garbled.

If it is subsequent to an upgrade: Note that at some point we moved to a
different kernel+driver+tcpborphserver  combination, which uses a mmap
interface - if you change to that you will have to update both kernel and
tcpborphserver, but for roach1 this is a backport, so probably something
for experts ...

regards

marc

Re: [casper] Fwd: casperfpga and fpg's

[Marc Welz]

On Wed, Feb 18, 2015 at 5:05 PM, Matt Strader mstra...@physics.ucsb.edu
wrote:

 Hi Alec and Paul,

 I should have said, I'm booting from NFS.  I see that on
 https://github.com/ska-sa/roach2_nfs_uboot, the romfs and uImage is much
 newer than boot/tcpborphserver3, which is what I copied into
 $NFS_PATH/usr/local/sbin/.  So, an updated tcpborphserver3 that works for
 netboot would be helpful.


So yep - we don't use the NFS image anymore, so it isn't that well
maintained - I believe other casper people have more up-to-date NFS file
systems.

To get the new tcpborphserver3 - mount the romfs image via loopback and get
it from
there

  # mkdir -p /mnt/tmp  mount -o loop romfs /mnt/tmp

regards

marc

Re: [casper] KATCP maximum segment size for transmition and struct.pack/unpack format

[Marc Welz]

So as already mentioned, the trick would be to stick to the object files
that implement
only the _katcl functions - that shouldn't require some basics (malloc,
strcmp, etc) but
not the full unix io API. That might mean building individual object files
(parse.c, line.c etc)
rather than the full library.

regards

marc


On Mon, Feb 2, 2015 at 6:22 AM, Jason Manley jman...@ska.ac.za wrote:

 Hi Pablo

 I'm hoping Marc will chime-in here, as the author of the package. My
 suspicion is that these are expected standard libraries that should be
 supplied with your dev environment. If PIC don't supply them, then perhaps
 you can compile without those features, or rewrite those few functions
 yourself?

 Jason Manley
 CBF Manager
 SKA-SA

 Cell: +27 82 662 7726
 Work: +27 21 506 7300

 On 30 Jan 2015, at 16:34, Pablo Vasquez pvasq...@das.uchile.cl wrote:

  Hi Jason,
 
  Thanks for the reply. The problem that I have when trying to implement
 this library on the PIC32 is that on the compiler that I use there is no
 sys/select.h file. Also there are some functions defined inside this .h
 files that are missing.
 
  Do you know where can I get these special .h files that were used with
 this lightweight processors?
 
  Best regards.
 
 
  On Mon, Jan 26, 2015 at 11:35 AM, Jason Manley jman...@ska.ac.za
 wrote:
  There is a C-based KATCP library that has been used successfully on
 lightweight (8-bit) processors in the past. It might make your life a
 little easier, as the parsing and everything's already taken care of. Try
 this: https://github.com/ska-sa/katcp_devel
 
  Jason Manley
  CBF Manager
  SKA-SA
 
  Cell: +27 82 662 7726
  Work: +27 21 506 7300
 
  On 26 Jan 2015, at 15:50, Pablo Vasquez pvasq...@das.uchile.cl wrote:
 
   Hi,
  
   I'm trying to get  a 32 bits PIC controller to work with a ROACH. I'm
 establishing communication through a standard TCP connection and getting
 data from a socket opened between the PIC and the ROACH. About this I have
 two questions:
  
   1.- What is the package size, also know as maximum segment size, that
 the ROACH/KATCP uses for transmission over the LAN port?
   I need to know this so I can work with the same segment size on both
 platforms and get proper data flow synchronization.
  
  
   2.- Do you know where can I find more info about the way struct.pack
 works?
   I need to unpack the data coming in the string from the ROACH, but
 since I have no python libraries on the PIC I need to handle the unpacking
 myself. Looking directly at the data I seem to recognize some patterns
 (i.e. /0 at the end of each integer per channel) but this patterns are
 not behaving the same through the whole string.
  
   Any hints will help.
  
   Best regards.
  
   --
   Pablo Vasquez
   Ingeniero Eléctrico
   DAS Universidad de Chile
   (+562)29771119
 
 
 
 
  --
  Pablo Vasquez
  Ingeniero Eléctrico
  DAS Universidad de Chile
  (+562)29771119

Re: [casper] KATCP maximum segment size for transmition and struct.pack/unpack format

[Marc Welz]

On Mon, Jan 26, 2015 at 1:50 PM, Pablo Vasquez pvasq...@das.uchile.cl
wrote:

 Hi,

 I'm trying to get  a 32 bits PIC controller to work with a ROACH. I'm
 establishing communication through a standard TCP connection and getting
 data from a socket opened between the PIC and the ROACH. About this I have
 two questions:

 1.- What is the package size, also know as maximum segment size, that the
 ROACH/KATCP uses for transmission over the LAN port?
 I need to know this so I can work with the same segment size on both
 platforms and get proper data flow synchronization.


The control port of the roach is running a linux ip stack. I believe the
MTU can be
set using ifconfig, so this is configurable. If you are using the
high-speed interfaces, then
this is all going via the fpga

2.- Do you know where can I find more info about the way struct.pack works?
 I need to unpack the data coming in the string from the ROACH, but since
 I have no python libraries on the PIC I need to handle the unpacking
 myself. Looking directly at the data I seem to recognize some patterns
 (i.e. /0 at the end of each integer per channel) but this patterns are
 not behaving the same through the whole string.


Certain bytes are escaped, the escape sequences are \e \n \r \t \0 and \_
- the last one is unusual, it escapes space. There is also a sequence \@
which means no argument, but you may not encounter that. As Jason mentioned
there is a C library on github which parses that for you - you may want to
restrict yourself to the *_katcl functions if you are resource limited

regards

marc




 Any hints will help.

 Best regards.

 --
 Pablo Vasquez
 Ingeniero Eléctrico
 DAS Universidad de Chile
 (+562)29771119

Re: [casper] ROACH serial connection issues

[Marc Welz]

On Mon, Dec 1, 2014 at 2:47 PM, Norbert Bonnici 
norbert.bonnici...@um.edu.mt wrote:

 Dear Marc,

 I've have tried all the possible CR+LF combinations.



 Any ideas?


Then I am not sure - I know that some USB dongles attempt to autodetect the
serial
speed - maybe something is going wrong there ? Also, maybe enable line
wrapping (Control-A W) might help.

BTW:  CC'ing the mailing list is good form - it helps others who might have
the same problem, and you might also get suggestions from other people

regards

marc

Re: [casper] Problem about the adc frequency in PAPER model.

[Marc Welz]

On Wed, Nov 19, 2014 at 6:50 AM, Peter Niu peterniu...@163.com wrote:

 Hi,Dave,
 Sorry reply you late.
 The little trouble I encountered in netboot turned out to be that the
 uImage I am using have changed.Well ,As for a test ,I download the latest
 uImage from
 https://github.com/ska-sa/roach2_nfs_uboot/tree/master/boot, the
 uImage-roach2-3.16-hwmon
 https://github.com/ska-sa/roach2_nfs_uboot/blob/master/boot/uImage-roach2-3.16-hwmon
  as
 the uImage in netboot.
 The file like this:
 [peter@roachserver ~]$ file -L /srv/roach_boot/boot/uImage
 /srv/roach_boot/boot/uImage: u-boot legacy uImage,
 Linux-3.16.0-saska-03675-g1c70f, Linux/PowerPC, OS Kernel Image (gzip),
 3034204 bytes, Tue Aug 26 14:54:14 2014, Load Address: 0x0070, Entry
 Point: 0x007010C4, Header CRC: 0x66EDCF88, Data CRC: 0x42A230BA
 I changed the uImage to uImage-r2borph3
 https://github.com/ska-sa/roach2_nfs_uboot/blob/master/boot/uImage-r2borph3
 ,


 There should be an even newer uImage (ie linux kernel) and romfs (ie flash
filesystem, containing tcpborphserver3) at that location.

I think the most notable change is that we have changed the kernel memory
model, so
that the full 128Mb fpga address space is visible in one go. There are a
probably some other
fixes and change too - the commit logs in katcp_devel should have some
information.

Things are rather busy here, so apologies for not updating the NFS
filesystem - we currently don't use it, so it is likely to remain out of
date, though Dave (I think ?) maintains a more
recent version.

regards

marc

Re: [casper] Problem about the adc frequency in PAPER model.

[Marc Welz]

On Wed, Nov 19, 2014 at 8:37 AM, Marc Welz m...@ska.ac.za wrote:

 There should be an even newer uImage (ie linux kernel) and romfs (ie flash
 filesystem, containing tcpborphserver3) at that location.

 I think the most notable change is that we have changed the kernel memory
 model, so
 that the full 128Mb fpga address space is visible in one go.


... meaning that you would need to update both the kernel and
tcpborphserver3 to the revisions checked in a week ago or so, to map the
full address space - just updating one will not be sufficient.

regards

marc

Re: [casper] Problem about the adc frequency in PAPER model.

[Marc Welz]

Hello



  I find a updated roach2-root-fullmap-2014-08-12.romfs.Could you please
 tell me what should I do to make it work?
  Should I put this file in the same place as tcpborphserver3 in Roach2
 file system (/usr/local/sbin)?
 Thanks for your answer ,I am totally a fresh man. :)
 Peter



If you are not solobooting, then on a linux pc somewhere

# mkdir -p /mnt/tmp  mount -o loop roach2-root-fullmap-2014-08-12.romfs
/mnt/tmp

... now copy out /mnt/tmp/sbin/tcpborphserver3 to where you need it

regards

marc

Re: [casper] Problem about the adc frequency in PAPER model.

[Marc Welz]

On Thu, Nov 13, 2014 at 5:49 AM, Richard Black aeldstes...@gmail.com
wrote:

 Wow. Well that seemed to be the magic bullet. Thanks!

 Any ideas why this works? Is it because of an NFS lock-out or a 10-GbE
 driver issue in the NFS kernel image?


So I don't know. It could also be a version difference ? The things to look
at are
the kernel and tcpborphserver  (the former is a file in its own right, the
latter can
be gotten by mounting a romfs image via loopback and copying out
/sbin/tcpborphserver3).

We also have had interesting cases where the fpga doesn't quite do what the
bus controller
on the power pc expects to happen - in those cases random perturbations
change the behaviour,
although pathological cases can have the fpga contend with flash accesses
which then corrupts things.

Also look in https://github.com/ska-sa/roach2_nfs_uboot, particularly the
boot directory - occasionally prebuilt images get uploaded there, though
for the change information you will
have to read the ska-sa/katcp_devel commits.

Final, unrelated, tip: It is fine to have another (interactive) telnet
connection to port 7147
on the roach while your scripts are doing things - this connection can be
used to see failures or problems, and for detailed debugging messages, try
typing ?log-level trace - just be mindful
of the performance impact. There is a tool (kcplog) which can be built for
a remote machine
to automate this.

regards

marc

Re: [casper] Problem about the adc frequency in PAPER model.

[Marc Welz]

On Thu, Nov 13, 2014 at 8:32 AM, David MacMahon dav...@astro.berkeley.edu
wrote:


 Are the drivers that provide the /dev/roach/mem and /dev/roach/config
 nodes compiled into the kernel image?


Yes, the roach kernels have never used modules

regards

marc

Re: [casper] question about upload bof in soloboot

[Marc Welz]

On Fri, Nov 7, 2014 at 6:11 PM, 牛晨辉 peterniu...@163.com wrote:


 hi, all,
 I try a soloboot to install a roavh2.What should I do to transfer bof file
 from PC to Roach board?the upload command in telnet may a little slowly, it
 seems never  completed,so i close it first.the second time i upload through
 telnet,it shows the port is used.


Have you actually sent the bof file to the other port (using netcat or
something similar ?). You
need to close that port once you have finished sending the file

regards

marc

Re: [casper] about nfs boot configuration on roach2

[Marc Welz]

Hello

Then I reboot in the minicom window,command dhcp and nfs seperately,the
 ouput information is below.It seems that the roach has found the uImage and
 transferred the kernel file.But next it doesn't boot up automaticly.

Yes, that is expected.

 In my thought, once the roach have loaded the uImage file, the linux
 system should boot up automaticly. But now it stop on the line.


No, transferring the image and booting are two separate steps, while
booting itself has a number of options/settings. Type printenv, it should
show you a sequence of commands used to boot via nfs

regards

marc

Re: [casper] about boffile download using tut3.py

[Marc Welz]

On Sat, Oct 25, 2014 at 2:33 PM, Wang Jinqing jqw...@shao.ac.cn wrote:

 For tut1 I can use telnet to roach2,the using the command like

 nc -w 2 -q 2 192.168.111.10   name.bof

 to download the bof file.But tut3.py looks not in that way. What should I
 do  ?


I think try using the same approach as for tut 1


  By the way,is there a linux system in roach2?


Yes, there are flash chips soldered onto the roach. They contain several
partitions, and one of them is a writable filesystem


 For I even can't find a SD card on the board.

 error information:

 192.168.40.60: ?progdev tut3_2014_Oct_24_0848.bof



 192.168.40.60: #log info 992952462866 raw attempting\_to\_empty\_fpga

 192.168.40.60: #log info 992952462866 raw
 attempting\_to\_program\_tut3_2014_Oct_24_0848.bof

 192.168.40.60: #log error 992952462867 raw
 unable\_to\_open\_boffile\_./tut3_2014_Oct_24_0848.bof:\_No\_such\_file\_or\_directory


Progdev requires a file on the local filesystem - if it hasn't been
transferred/uploaded to it previously, then this won't be found. Use the
upload* requests to transfer the bof file on to the roach

regards

marc

Re: [casper] Problem uploading bofs to ROACH 2

[Marc Welz]

On Mon, Aug 4, 2014 at 6:10 PM, Raul Sapunar Opazo rasapu...@gmail.com wrote:

 #log error 963267824776 upload
 saving\_of\_bof\_file\_failed:\_No\_such\_file\_or\_directory
 #log info 963267824780 raw job\_483\_completed\_with\_code\_1
 #log error 963267824781 raw encountered\_fail\_on\_upload
 !uploadbof fail

Either you have run out of space (use listbof to see
if you have lots of other bof files around, then delbof), or
the writable  section of flash has been corrupted.

In the latter case you
might want to connect a serial cable and see if dmesg
reports any filesystem errors - given that flash is connected
to the same bus as the fpga, a misbehaving fpga can interfere
with flash io. Now, /usr is writable, but it can be erased and will
be recreated at boot time. / is readonly and shoudn't be modified

regards

marc