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  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
> [0.00] Kernel command line: console=ttyS0,115200 root=/dev/nfs
> rootpath=192.168.100.1:/srv/roach_boot/etch ip=dhcp
> [0.00] PID hash table entries: 4096 (order: 2, 16384 bytes)
> [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288
> bytes)
> [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144
> bytes)
> [0.00] Sorting 

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  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 
> 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  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 
>>> wrote:

 Hello,

 While trying to link the CASPER ROACH1 board to PC, I am getting this
 error:

 AttributeError: 'KatcpFpga' object has no attribute 'callback_request'


 The steps followed are as such:


 In [1]: import casperfpga

 In [2]: fpga=casperfpga.katcp_fpga.KatcpFpga('100.100.100.1',7147,10)

 ---
 AttributeErrorTraceback (most recent call
 last)
  in ()
 > 1 fpga=casperfpga.katcp_fpga.KatcpFpga('100.100.100.1',7147,10)

 /usr/local/lib/python2.7/dist-packages/casperfpga/katcp_fpga.pyc in
 __init__(self, host, port, timeout, connect)
  70 def __init__(self, host, port=7147, 

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

[Marc Welz]

On Wed, Jun 28, 2017 at 7:56 PM, Jack Hickish  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  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  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
 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  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
>>  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  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 
 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  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 see the adapter. This is the adapter Im
 >> using
 >>
 >> https://www.unitek-products.com/en/product_detail.php?id=12
 >>
 >>
 >> On Wed, 22 Mar 2017 at 9:05 PM Jack Hickish 
 >> wrote:
 >> H. And the adapter definitely works?
 >>
 >> Sorry, I think you're going to need someone smarter than me.
 >>
 >> On Wed, 22 Mar 2017 at 11:06 Heystek Grobler
 >>  wrote:
 >> Hi Jack
 >>
 >> Jip it is the null-modem type with the 9 pins. If I open up an
 >> terminal connection through putty or minicom I can open up an connection
 >> with the 115200 8N1 settings, but I cant see Uboot. I can only see 'n 
 >> blank
 >> terminal window.
 >>
 >>
 >> On Wed, 22 Mar 2017 at 7:24 PM Jack Hickish 
 >> wrote:
 >> Hi Heystek,
 >>
 >> Just to be clear, you're connecting to the 9 pin serial connector on
 >> the ROACH (not the USB port)?
 >> If you're using a serial cable between the ROACH and your USB
 >> adapter, is it the correct null-modem type?
 >> Do you have the correct comms settings? -- roach1 is 115200 8N1
 >>
 >> 

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  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
 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  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
>>  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  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
  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 
> 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 no problems.)
>>
>> Before you try that though, perhaps just try importing spead in
>> ipython as Ryan did. What are the error messages?
>>
>> Regards,
>> James
>>
>>
>> On Fri, Oct 7, 2016 at 11:23 AM, Heystek Grobler
>>  wrote:
>>>
>>> Hi James and Ryan
>>>
>>> I tried sudo pip install spead and I get the following
>>>
>>> Requirment already satisfied (use --upgrade): spead in
>>> usr/local/lib/python2.7/dist-packages
>>> cleaning up
>>>
>>> Any ideas?
>>>
>>> I am a bit lost to be honest.
>>>
>>> On Fri, Oct 7, 2016 at 11:09 AM, James Smith 
>>> wrote:

 Hello Heystek,

 I vaguely recall installing spead from pip as well, as Ryan has done
 here. Give that a whirl.

 Regards,
 James


 On Fri, Oct 7, 2016 at 11:06 AM, Ryan Monroe
  wrote:
>
> rmonroe@rmonroe-ThinkPad-P50:~$ sudo pip install spead
> [sudo] password for rmonroe:
> The directory '/home/rmonroe/.cache/pip/http' or its parent
> directory is not owned by the 

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

Re: [casper] Fwd: ROACH 2 First Use

[Marc Welz]

On Tue, Jun 3, 2014 at 1:23 PM, Roelof Burger roe...@eflex.co.za wrote:
 Hi John,

 Thanx for the quick response.

 I can ping the ROACH from my windows and UBUNTU machines. They are on the
 same domains

 I left a TELNET session open just now, and when i run the command:  ssh -p
 7147 root@ip_address command from UBUNTU

 i see the following on the TELNET session: #log info 946781856113 raw
 new\_client\_connection\_ip_address:57673

 #client-connected ip_address:57673

 Does this mean the connection was good? How do I transfer the.bof file now?

There are a number of commands to upload a file on that control connection
(use ?help to see them)

These commands will open another port (I think by default 7146) which
can then receive the bof file. Either you send it across using your own code,
or you can use something like netcat or socat.

From memory

nc -w 2 -q 2 roachip 7146  yourboffile.bof

(aside: this isn't that different how ftp works, internally - the ftp
client just hides it from you)

If you have kcpcmd installed that can do all that in one go, and set
up an alias for it

regards

marc

Re: [casper] PIC32 controlling ROACH in a radio telescope.

[Marc Welz]

On Thu, May 15, 2014 at 10:09 PM, Pablo Vasquez pvasq...@das.uchile.cl wrote:
 Hi,

 I want to implement KATCP protocol on a PIC32 micro controller. I'm trying
 to compile the KATCP C library over a TCP/IP stack freeware provided by
 Microchip (the manufacturer of the starter kit I'm working with).

 I included all the .h files listed in the KATCP wiki but the compiler asks
 for a unistd.h header. I found many unistd.h files in my system (ubuntu
 12.04 lts), which one should I use?

As John mentioned, you can not just copy the unistd.h file
across platforms. unistd.h just declares, but doesn't implement
the core unix system api (read, write, etc). The implementation
happens in the operating system/runtime. If your development platform
has support for a unix/posix/xopen API you should be able to port
it across, but with some changes - I have had reports that katcp has
been ported to smaller platforms, so this is possible.

Further notes:

  - I tried not to use too many exotic system calls, but
there are some things which might have to be adapted:

* send() system calls takes some special flags

* signal handling via sigaction, might not be needed on
  small systems

* you may want to inhibit the fork related stuff in job.c,
  if you don't have processes

  - For very small systems, you might be able to just use
the _katcl api, not the full _katcp one (the former just
handles the formatting of messages, the latter provides
a full mainloop with callbacks)

  - katcp was also intended to run across serial connections,
so instead of using a network stack on a small system, you
could run it over a serial port and save the resources for
something else

All the best

marc

Re: [casper] ISE 14.7 in ubuntu 12.04

[Marc Welz]

On Tue, May 13, 2014 at 12:54 PM, Rolando Paz flx...@gmail.com wrote:
 Hi Wesley

 I did this:

 rolando@rolando-MS-7815:/media/TERA/roach/Xilinx_ISE_DS_Lin_14.7_1015_1$
 chmod +x xsetup
 rolando@rolando-MS-7815:/media/TERA/roach/Xilinx_ISE_DS_Lin_14.7_1015_1$
 sudo ./xsetup
 ./xsetup: 18: ./xsetup: ./bin/lin64/xsetup: Permission denied
 rolando@rolando-MS-7815:/media/TERA/roach/Xilinx_ISE_DS_Lin_14.7_1015_1$


So now another file seems not marked executable - you probably mounted
the disc/dvd/stick
in such a way as to inhibit execution ...

regards

marc

Re: [casper] Executing .bof on ROACH-2

[Marc Welz]

On Thu, Mar 20, 2014 at 10:22 AM, David Bonnici
dav...@ascentsoftware.eu wrote:
 Hello Mark.  Are there any replacements for the BORPH ioreg interfaces?  How 
 do I access the FPGA registersor am I now kinda restricted to use the 
 katcp interface?

The ioreg interface is gone.

To access FPGA registers over the network, the katcp interface and the
libraries around
it are the way to go.

On the local machine you can do kcpcmd listdev or kcpcmd wordread
sys_scratchpad etc
to get simple commandline access.

If you really, really have a high performance application where code
needs to run on the
local powerpc, you may wish to look into adding extra commands to tcpborphserver
(github.com/ska-sa/katcp_devel) - look at the bottom of
tcpborphserver/raw.c to see how to
register extra commands.

regards

marc

Re: [casper] ROACH 1 DRAM

[Marc Welz]

On Tue, Feb 25, 2014 at 7:43 AM, G Jones glenn.calt...@gmail.com wrote:
 Hi Marc,
 Thanks for the reply. I would have expected that selecting the 64 MB chunk
 with the dram_controller register as described in the DRAM block
 documentation on the wiki would get around any such PPC address space
 limitation. Is that not the case?

I think that should indeed be the case - I had forgotten that the base+offset
scheme had already been implemented quite some time ago.

A note though: On the other side of the FPGA, there isn't that much
memory to go around either - so where possibly try and send it out (or
process it)
in smaller pieces

regards

marc

Re: [casper] ROACH 1 DRAM

[Marc Welz]

On Mon, Feb 24, 2014 at 7:57 PM, G Jones glenn.calt...@gmail.com wrote:
 Hi,
 Sorry to repost this. Just curious if anyone has experience using more than
 256 MB of FPGA DRAM on the ROACH, in particular through the PPC interface.

The PowerPC's virtual memory subsystem maps things in 256Mb regions/segments,
and only one is used to access the FPGA(*) - so you will probably have
to implement
some sort of windowing/base+offset scheme.

(The address space of the PowerPC is pretty constrained)

regards

marc

Re: [casper] determining running bof file from tcpborphserver?

[Marc Welz]

On Fri, Feb 21, 2014 at 3:15 PM, Paul Marganian pmarg...@nrao.edu wrote:
 Thanks marc!
 Embarrassingly enough, I've noticed these registers before, but never
 investigated them:
 sys_scratchpad

So scratchpad is just a test register to see if accesses across the bus are
ok (timing issues, etc can make this a problem), but

 sys_rev
 sys_rev_rcs

are things which can be set at build time. However, I am not familiar with
the toolflow, so somebody else will have to answer that

regards

marc

Re: [casper] question about roach2 netboot

[Marc Welz]

Hello

 Then, the error msgs start to show up:

 modprobe: FATAL: Could not load /lib/modules/3.7.0-rc2+/modules.dep: No such
 file or directory

 modprobe: FATAL: Could not load /lib/modules/3.7.0-rc2+/modules.dep: No such
 file or directory

 modprobe: FATAL: Could not load /lib/modules/3.7.0-rc2+/modules.dep: No such
 file or directory

This isn't really a problem, despite what modprobe says. We have built
the roach2
kernel without modules, but have left modprobe in - creating an empty file

  # touch /lib/modules/3.7.0-rc2+/modules.dep

makes the message go away.

 warning: can't open /etc/mtab: No such file or directory

There are two ways of handling mtab, either using a normal file, or a
symlink to /proc/mounts. In the former case, this file has to exist
and be writeable,
in the latter mount has to be told not to update the file, since the
kernel does it
automatically. Even if you don't fix that, your mount/df output might look a bit
strange, but you should be fine otherwise.

 mount: mount point /proc/bus/usb does not exist

Either /proc hasn't been mounted, or the kernel has been built without usb
support, but the startup scripts are still trying to mount usbfs. We
have had some usb
problems with the PPC, so on a number of builds usb is disabled. Maybe remove
the usbfs entry from fstab or the mount scripts ?

  1 Jan 00:00:15 ntpdate[452]: no server suitable for synchronization found

If you wish to have time synchronised, point the roach at an ntp server. I think
the easiest would be to install the ntpd package on your NFS server

TLDR: none of the problems are critical. You should be able to telnet
to port 7147 of the roach and issue commands to program and access the fpga.

regards

marc

Re: [casper] bram and katcp

[Marc Welz]

Hello

 I'm also going to look at another option which is with the mmap kernel I
 have access to the FPGA memory in /dev/roach/mem.  I think it should
 be fairly easy to write a custom server that runs on the roach that
 collects the bram data from the mem and then buffers if for sending
 over ethernet via udp. This is probably very similar to what the UDP
 option in tcpborphserver does but I'll be able to control the amount
 of buffering

So tcpborphserver3 provides a function

  register_every_ms_katcp(d, period, callback, localstate);

which will arrange to call callback every period ms with
a pointer localstate. In that callback function you should be
able to read from the fpga and buffer/send out udp data at the rate
you wish (fpga can be found at raw_mode-r_map)

I'd recommend that you have a setup function (the one which
sets up localstate and calls register_every_ms_katcp). This
function should have the prototype

  int your_cmd(struct katcp_dispatch *d, int argc)

if that is the case, you can add a call

  register_flag_mode(d, ?your-cmd, helpmessage, your_cmd, 0, TBS_MODE_RAW);

and then you'll have an extra command which will launch
your data dumping logic to run periodically. The tgtap routines
use this approach - the end of tg.c shows this.

regards

marc

Re: [casper] bram and katcp

[Marc Welz]

Hello

The path FGA-PPC-ethernet-python hasn't been
optimised for speed. So if you can get hold of a
PCI(e) CX4 ethernet card for your capture machine
then you will save yourself a considerable amount
of effort and get way better max transfer rates

However: If this isn't an option, there are a
couple of things you can attempt. The warning
is that you will have to be(come) reasonably
handy with C. As Jason mentioned, you could
try larger read sizes and maybe have multiple
concurrent reads from different connections in an
effort to amortise the round trip time.

If that doesn't work: tcpborphserver(2,3)
has an extension mechanism... you can run
callbacks which do things - and one option
is to run something which sends out your
data in UDP packets - that saves on encoding
time (no katcp escaping) and also doesn't
halve throughput on packet loss. It turns
out that in tcpborphserver2 there is an
optional mode which can be built which
is specific for a pocket correlator - this does
provide an example on how to implement udp
data dumping. The downside is that the
interface is not documented and there are
some differences between v2 and v3

Another option is to look at the linux
kernel driver for the network interface,
there was some weirdness with the EMAC
and also the PHY - so there may be
the option of tweaking and fixing things
to get better throughput

regards

marc

Re: [casper] ROACH TGE Multicast

[Marc Welz]

Hi there

 I think building a multicast receiver is non-trivial.  Doing multicast the 
 right way requires that hosts implement IGMP (Internet Group Management 
 Protocol).

If you are running sshd or telnetd on the roach you can connect to
those over the 10GbE
interface attached to the FPGA. It is neither efficient nor pretty,
but it does work.

regards

marc

Re: [casper] How do you program a ROACH-2 that is soloboot mode?

[Marc Welz]

Hi there

Regarding the chdir issue:

The way to fix it properly is to install a more recent
tcpborphserver which always programs an absolute path.
(See progdev_cmd() in tcpborphserver3/raw.c on github). I think
that was changed at the beginning of the year.

However, this probably isn't necessary - I haven't gone
through the old revisions to check, but it may be that
the chdir to /var/tmp might be triggered the older
?upload or ?uploadbof logic - if this is the case: if you
don't use them you shouldn't see your directory changing.

Alternatively: tcpborphserver understands an initialisation
file where you can put commands, including changing directories
and programming bof files, to be run at startup. But again I think you
might need a newer image ... come to think of it, the
new tcpborphserver3 revisions also fix a more irritating bug which
prevents one reprogramming bof files after a dozen or so times
without rebooting - so might be worth an upgrade ... but that
requires one to be comfortable with uboot and ymodem, so maybe
defer all this until you run into the above problem ?

regards

marc

Re: [casper] Error when execute .bof files

[Marc Welz]

Hello

 -bash: ./tur.bof: cannot execute binary file

 - I execute a lot of bof files, but the ROACH show the same error.

Assuming you are running on a roach and not a roach2, the most likely
reason would be that ./tur.bof isn't marked executable, so use chmod +x
to change that.

regards

marc

Re: [casper] progdev fails on roach2

[Marc Welz]

Hello

On Wed, Aug 14, 2013 at 12:17 PM, Jason Ray j...@nrao.edu wrote:
 All,

 Occasionally I've noticed (maybe a handful of times over the past few
 months) that progdev will fail with our roach2 boards.  After working fine
 for long periods, it will fail to program out of nowhere and the only fix is
 to reboot the roach2.

 -- 115 raise KatcpClientError(Client not connected)

So one of the reasons why you are disconnected may be that
tcpborphserver3 is no longer running. This can be caused by a software
error internal to tcpborhpserver (the kernel will report a sigsegv, 11 typically
and somtimes sigabort, 6 in cases where I detect major internal
consistency failures)
or by a bus timeout when doing io to the fpga, when the gateware isn't
quite doing
the right thing - the latter generally shows up as a sigbus signal, 7.

To distinguish between the two options, get a shell prompt on the roach2
and type dmesg

Also: If you check the mailing list archive you should see some
activity relating to bus timeouts in April

regards

marc

Re: [casper] Creating boffiles directory

[Marc Welz]

Hello

 cockroach3 / $ ls
 bin   dev   etc   lib   mnt   proc  root  sbin  sys   tmp usr   var

On the solobooted filesystem, bof files live in /usr/bof

 When I try to create a boffiles directory, I find that the system does not
 allow it (soloboot):

Yes, / is readonly, /usr is writable. We have had cases where gateware
bus timing
bugs have done antisocial things on the EPB bus of the powerpc - we
believe that this
can corrupt flash IO, making it essential for a part of the system to
be readonly to recover
from corruption.

regards

marc

Re: [casper] Creating boffiles directory

[Marc Welz]

Hello

 Second, I have tried
 ?listbof -b /usr/bof

 and

 ?listbof -b/usr/bof  (no space)

Oh, I didn't explain that properly - it is the tcpborphserver process
that accepts commandline parameters (eg tcpborphserver3 -b /usr/bof)

But the unusual part is that it seems to be running already, and generally
should be configured to fetch files out of /usr/bof anyway ... unless
you somehow have a really old and somehow broken
root filesystem ?

 The only mention of jff in the response is:

 jffs2: version 2.2. (NAND) .. 2001-2006 Red Hat, Inc.

Good, no corruption in /usr.

 Also, in response to Adam's last email, I don't seem to have an init.d
 directory  under /etc

That is fine, setup gets done from a few rc.* files

 -rwxr-xr-x1 root root   374 Jan  1  1970 rc.tcpborphserver3

That file is quite a lot bigger on newer filesystem images ... so you have a
somewhat older version of the software... possibly upgrading the root
filesystem/romfs might be an option to try ... the casper wiki has
instructions on this, but the process requires some care. Or maybe you
have attempted an upgrade already, but haven't reset the configuration
and startup files by removing /usr/.keep and then rebooting ?

regards

marc

Re: [casper] Creating boffiles directory

[Marc Welz]

AFIK you can use the -b flag of tcpborphserver to set the bof dir u'll need
 to edit /etc/init.d/tcpborphserver startup script to change that.


Confirmed -b will work, but for solobooted roaches the startup file is
/etc/rc.tcpborphserver3

regards

marc

Re: [casper] Using Memory Mapped Kernel for Roach2

[Marc Welz]

Bad magic in file bof header ? That looks like a corrupt bof file ...
Is it really a bof file and not a bin or bit file ?

On Mon, Jun 24, 2013 at 1:21 PM, Sarfraz Qureshi
sarfrazqureshi...@gmail.com wrote:
 Hi Shanly,
 Thanks for the reply. We have tried doing this and seem to be getting the
 following error:

 #log info 187063 raw
 attempting\_to_\_program\_flash_comic_2013_Jun_21_0733.bof
 #log error 187069 raw bad\_magic\_in\_file\_bof\_header
 !progdev fail

 Also from within roach, on trying ./boffile: we get: cannot execute binary
 file
 (please refer to
 http://www.mail-archive.com/casper@lists.berkeley.edu/msg04193.html).



 On Mon, Jun 24, 2013 at 6:05 PM, Shanly Rajan sha...@ska.ac.za wrote:

 Sarfraz

 You need to have tcpborphserver3 which is a server designed to control
 ROACH2's. tcpborphserver3 requires a kernel with memory mapped device driver
 inorder to handle FPGA transactions.

 If you have successfully managed to netboot ROACH2, you should be able to
 now use katcp interface to talk to the FPGA. The supported list of KATCP
 commands can be viewed here:
 tcpborphserver3/README

 Bof files should be programmed by connecting to the roach2 using telnet
 and running progdev:

 telnet roach-ip 7147
 ?progdev boffile

 I am in the process of completing a wikipage on getting started with
 ROACH2. You can check it out as soon as its finished.

 Regards
 Shanly Rajan


 On Mon, Jun 24, 2013 at 11:38 AM, Sarfraz Qureshi
 sarfrazqureshi...@gmail.com wrote:

 Hi Everyone,
 We are trying to move on to using memory maped kernel for our roach2,
 following the discussion on this
 thread:http://www.mail-archive.com/casper@lists.berkeley.edu/msg04167.html
 (since we are also facing the same problem when executing bof files)
 We have downloaded the source files from:
 https://github.com/shanlyrajan/mmap_driver_devel

 Can someone please help us with the next step? Currently, we are
 netbooting the roach2 using the NFS filesystem.

 Regards,
 Sarfraz Qureshi




 --
 Shanly Rajan

 SKA-SA
 DBE Team
 021 506 7362 (O)
 072 783 2022 (M)

Re: [casper] Problem receiving ROACH2 packets

[Marc Welz]

 I am having a problem receiving 10gbe packets from one of the interfaces on
 a dual-port Myricom NIC.  I believe the packets are properly addressed, and
 wireshark sees them fine, but programmatically we cannot receive them on
 10.0.0.102 via C or Python (recvfrom() just hangs), while on 10.0.0.101
 everything is working fine.

Having two IPs on the same subnet can yield interesting results under linux,
In particular the kernel may answer arp requests for one interface on the
other interface ...

regards

marc

Re: [casper] Setting up 10gbe core for ROACH2

[Marc Welz]

On Fri, Jun 7, 2013 at 1:14 PM, Gary, Dale E. dale.e.g...@njit.edu wrote:
 Hi All,

Hello

 We previously were successful in setting up the 10gbe core for ROACH1 using
 tap_start, which I believe resulted in a process tgtap appearing in the
 ROACH.

 I am using the same method for ROACH2 (using the latest ROACH2 rev 2 file
 system loaded via netboot), and there is no reported error, but the ARP
 table does not contain the MAC address for the destination IP address, and
 when I check the processes running on the ROACH2 I do not see tgtap.

As mentioned by others: The tgtap logic on roach2 runs
internal to tcpborphserver3.

There should be a ?tap-info command you could run
to look at the arp table as seen by the roach2 - it will
show timeout information not visible using the current python
interface.

A while ago I tried improving the logic which generates arp traffic,
the code is at github.com/ska-sa/katcp_devel/blob/master/tcpborphserver3/tg.c,
in particular in function run_timer_tap - the code path which might still be
problematic is on line 821 (if(burst  1)). You could increase 1 to some larger
number, or remove the test entirely.

During the week I may add some logic to check for starvation problems.

However, there are fundamental limits at play: The interface between the PPC
and FPGA is pretty slow/inefficient when compared to what can come in on
10GbE, so it is important to make sure that the PPC doesn't get swamped - and
the greatest sources of traffic in this regard are other roaches
sending arp requests
(an N^2 problem) - so on roach2 I have tried to send out arp traffic reasonably
conservatively - maybe even too conservatively ...

regards

marc

Re: [casper] KATCP library thread-safe?

[Marc Welz]

 Hi,

Hello

 I was wondering if anyone knew the answer to two questions:
 
 1) Can I use more than one KATCP connection within one process?

Yes. See kcppar for an example which issues commands to 
multiple katcp servers in parallel. 

 2) If so, do they need to be protected from each other via mutex?

That depends. 

Each katcp client connection keeps it state a handle/state 
structure (katcl_line) - so there shouldn't be global variables 
to be overwritten.

This means where you use select() on multiple connections
or only use a connection per thread you should be fine. However,
access to individual data structures isn't locked - thus if you
access the same data structure from multiple threads you will
need to provide your own mutexes.

[Personally I find that threads make reasoning about code
quite a bit harder, and thus prefer to use select() or poll()
for doing concurrent IO, even if the initial effort is a bit more]

regards

marc

Re: [casper] Thermal testing

[Marc Welz]

On Thu, May 16, 2013 at 12:56 PM, Rich Lacasse rlaca...@nrao.edu wrote:

 Hi Casperites,

 Is there a easy way to monitor the temperature of the FPGA and PPC on the
 ROACH2?  Perhaps using the sensors command on katcp?

 Thanks,
 Rich


Try

?sensor-sampling raw.temp.ppc period 2000

regards

marc

Re: [casper] Building a new romfs

[Marc Welz]

On Wed, Apr 3, 2013 at 1:30 PM, John Ford jf...@nrao.edu wrote:
 Hi all.  We are going to attempt to update the standard romfs file system
 to support some additional stuff, like ssh and ???.  Can someone give me a
 hint where to start?

Well, the current romfs is mainly busybox (unmodified) and the katcp
tools (tcpborphserver3)
and then some libraries and extra utilities.

There are several ways of adding more things:

- build them yourself... probably the most space efficient way of
going about it.
  You probably want to look at dropbear rather than the conventional opensshd

- Just copy sshd and its needed libraries from the NFS filesystem (a
debian image).
  Typically one ends up using ldd to figure out what libraries are
needed and then strace
  to find the other missing pieces.

- Look at some other small distribution as a starting point ...
openwrt comes to mind

 Or is there a better way?

For quick sharing of files or misc development, just mount an nfs
server export on the roach, say in /mnt
That should be more convenient than scp, though not encrypted. Often
-o nolock can be useful.

Our plan is to treat a roach as an appliance (eg printer) where one
uses katcp (instead of say ippl)
to operate the system remotely. I suspect we'll gradually add features
to optimise some of that, eg
eliminate certain polling operations.

regards

marc

Re: [casper] r2case_event() in dmesg

[Marc Welz]

On Wed, Mar 27, 2013 at 3:52 PM, G Jones glenn.calt...@gmail.com wrote:
 Hi,

Hello

 Anyone know why there are a bunch of messages like this in dmesg on a ROACH 
 II:

 r2case_event(): Got type 11, code 8, value 1
 attempting led toggle
 About to toggle cpu_rdy pin7r2case_event(): Got type 11, code 8, value 0
 attempting led toggle
 About to toggle cpu_rdy pin7r2case_event(): Got type 11, code 8, value 1
 attempting led toggle
 About to toggle cpu_rdy pin7r2case_event(): Got type 11, code 8, value 0
 attempting led toggle

tcpborphserver3 turns off the one LED while processing a katcp command (and
when done turns it on again) - this is an attempt at an activity LED -
this LED is routed
to the front panel in our cases.

This logic is implemented using the linux input event framework, and
what you are seeing
is the debug output in the event driver
(drivers/input/misc/r2chassis.c). If you wish to remove
a couple of system calls in overhead you can remove the driver and
tcpborphserver3 then
won't do this.

TLDR: Nothing to worry about

regards

marc

Re: [casper] tcpborphserver3 logging with network mounted ROACH II

[Marc Welz]

On Wed, Mar 27, 2013 at 3:29 PM, G Jones glenn.calt...@gmail.com wrote:
 Hi,

Hello

 We're experiencing some intermittent failures where it appears the
 FPGA is spontaneously deprogramming on the ROACH II. We'd like to try
 to track this down by turning on logging in tcpborphserver3. Has
 anyone done this for a network mounted ROACH II? Should we mount an
 extra directory as r+w to store the logs? Looking for advice on best
 practices or at least something that works.

As per other mails: Remote syslog for kernel level messages.

To log katcp messages:

- Check out github.com/ska-sa/katcp_devel/
- Remove/comment out KATCP_STRICT_CONFORMANCE in Makefile.inc
- Compile on your logging server, not the roach.
- use the utility log/kcplog to connect to a remote roach and save
  katcp log messages to local file. kcplog understands SIGHUP and
  thus can be used under logrotate, while SIGUSR? can be used to
  de/increase the log verbosity. use ./kcplog -h for more information.

You can also monitor individual hardware sensors with commands like this

  (echo ?sensor-sampling raw.voltage.3v3 event ; cat ) | nc roach_host 7147

regards

marc

Re: [casper] unable to load my boffiles and to configure my roach2

[Marc Welz]

On Fri, Mar 8, 2013 at 3:42 PM, Guy kenfack guy.kenf...@gmail.com wrote:

 and we get:

 ?progdev roach2_tut1_2013_Mar_06_1343.bof
 #log info 152278 raw
 attempting\_to\_program\_roach2_tut1_2013_Mar_06_1343.bof
 #log info 152365 raw
 attempting\_to\_program\_bitstream\_of\_19586188\_bytes\_to\_device\_/dev/roach/config
 #fpga loaded
 #log warn 153163 raw unsupported\_access\_mode\_0\_for\_register\_
 #log error 153163 raw register\_called\_\_already\_defined
 #log error 153163 raw unable\_to\_load\_register\_mapping
 #log error 153163 raw
 unable\_to\_program\_bit\_stream\_from\_roach2_tut1_2013_Mar_06_1343.bof
 !progdev fail

This problem could also be part of a too old toolchain - older versions
of mkbof parsed empty lines into register definitions ... maybe
update mkbof (or remove empty lines from coreinfo.tab - sp?)

regards

marc

Re: [casper] Error reading registers with ROACH2

[Marc Welz]

Hello

On Tue, Mar 5, 2013 at 7:25 PM, Jason Castro jcas...@nrao.edu wrote:
 I just loaded the latest version of tcpborphserver dated 2013-02-12T17:00:21
 for my ROACH2.  I've recompiled tutorial1 for a ROACH2 and I'm able to load
 the bof file to the FPGA, however when I try to read a register I get a
 communications error from the Roach and the personality of the FPGA is
 dumped.  The roach is still on the network and KATCP is still there, but I
 have to reload the BOF file.  It appears I can write to registers correctly.
 If I request say 5 bytes from the sys_stratchpad KATCP recovers gracefully
 with an error, but if I request 4 bytes I get the following error dump from
 the ROACH2, as read from the USB serial interface:

Just to check and help us debug things: Are you using ?wordread or
?read to access the data ?

?read sys_scratchpad 0 4
?wordread sys_scratchpad 0 1

(reads operate on byte quantities, wordreads on multiples of 32bits).

sys_scratchpad is only 1 word (4 bytes) long, so the 5 byte read will
be trapped by sanity checks before even a bus transaction occurs.


 Machine check in kernel mode.
 Data Read PLB Error
 Oops: Machine check, sig: 7 [#6]

Sig 7 is a bus error, so a transaction across the EPB timed out or failed.
A userspace application has difficulties recovering from this - for
most purposes it is handled similarly to a segmentation fault.

We are keen to understand what fails... let us know how things progress ...
Did the problem only appear after the new tcpborphserver install ? Did
it happen on other gateware images ?

regards

marc

Re: [casper] Roach2 configuration and setup

[Marc Welz]

Hello

 1/
 a- how can I find the version of my romfs and also how can I find the
 version of my Tcpborphserver3

if you telnet to port 7147, there should be a version string
for tcpborphserver3. The romfs contains a timestamp in its filesystem
label, but since it such a small system, you can pretty much use the
tcpborphserver3 version string as a proxy for it

 b- which version for the uboot and the tcborphserver3 should I use, should I
 keep the current version above ?
 where is it located?

The source is in git at github.com/ska-sa

 2/ I heard that the configuration with the SD card is not yet working  ? is
 it still the case ?

Yes. A roach2 has sufficient onboard flash to keep a number of
(optionally compressed)  bof files there
without having to use external storage, so we not allocated anybody to
work on the MMC logic. Also note that MMC cards can be interesting, see
http://www.bunniestudios.com/blog/?p=2297

So we recommend you soloboot, ie boot off the onboard flash.

 3/I want to load my boffiles, can I use ssh  ? or should Iuse the telnet to
 tranfer my files ?
 How should I do If I want to keep my boffiles alive? I used to store them on
 the SD card, even when shutting down my roach board. Do I need to re-load or
 to copy my boffiles after switching on my roach2 boards?

The content of /usr on the onboard flash is preserved, so the bof files in
/usr/bof are retained.

 I read somewhere that it could be possible to upload from the python ?(I've
 never done it)
 How long does it take to the boffile to be copied ? before launching the
 fpgaprogdev() ?

I think Paul answered that (but note that you will need a pretty recent version
of tcpborphserver3 to use the uploadbof request).

If you are concerned about speed, you can transfer a bof file
beforehand (say using wget or ftpget or an nfs mountpoint) - then
the progdev is pretty quick, and you can then even arrange that the
file is programmed at startup (by adding a progdev command to
etc/tcpborphserver3.init)

regards

marc

Re: [casper] tcpborphserver3 failure in tg.c

[Marc Welz]

Hello

On Tue, Jan 29, 2013 at 8:42 PM, G Jones glenn.calt...@gmail.com wrote:
 Hi,
 As mentioned previously, we've been noticing failures of
 tcpborphserver3 at a rate that has become annoying enough to finally
 track down. We compiled from the github source on the ROACH2 itself
 with debugging enabled and ran through gdb. The failure results are
 described below. The problem seems to occur during the starttap
 command. We'll forward along the raw katcp command we're using, but
 the curious thing is why base which comes from:

 base = gs-s_raw_mode-r_map + gs-s_register-e_pos_base;

 is pointing to invalid memory sometimes.

So I am the author of this.

gs-s_raw_mode-r_map is the pointer into the FPGA which is mapped
into the address space of the process.

gs-s_register-e_pos_base is offset of the register in this memory area.

These pointers can become invalid when the fpga is reprogrammed - but
there is a test to exit when the fpga is reprogrammed - which (going by your
report) may not be sufficient.

Does the crash occur while the fpga is being (re)programmed ? If so, while
I try to understand the failure, you could do an explicit tap stop
before reprogramming the fpga (as a temp workaround).

If it occurs on other occasions, then this problem becomes more interesting.

regards

marc

 -- Forwarded message --
 From: Ramon E. Creager rcrea...@nrao.edu
 Date: Tue, Jan 29, 2013 at 3:09 PM
 Subject: [Gbsapp] tcpborphserver3 failure in tg.c


 I've gotten the tcpborphserver to fail under the debugger, but because I
 don't yet understand the memory management used in this program I'm not
 yet sure what the problem is, so I'm putting this out in case someone
 who understands the tcpborphserver can help isolate the problem more
 quickly than I can.  The segv occurs in tg.c, line 421.  The gdb output is:

 Program received signal SIGSEGV, Segmentation fault.
 0x100092d4 in write_mac_fpga (gs=0x107b7928, offset=0, mac=0x107b7970
 \002\002\n\021) at tg.c:421
 421   *((uint32_t *)(base + offset)) = value;
 (gdb) where
 #0  0x100092d4 in write_mac_fpga (gs=0x107b7928, offset=0,
 mac=0x107b7970 \002\002\n\021) at tg.c:421
 #1  0x1000a140 in configure_fpga (gs=0x107b7928) at tg.c:877
 #2  0x1000ae68 in create_getap (d=0x107878b8, instance=0,
 name=0x10795da0 gbe0, tap=0x10795d9b tap0,
 ip=0x10795da5 10.17.0.65, port=6, mac=0x10795db6
 02:02:0A:11:00:41, period=10) at tg.c:1167
 #3  0x1000b258 in insert_getap (d=0x107878b8, name=0x10795da0 gbe0,
 tap=0x10795d9b tap0,
 ip=0x10795da5 10.17.0.65, port=6, mac=0x10795db6
 02:02:0A:11:00:41, period=10) at tg.c:1230
 #4  0x1000b514 in tap_start_cmd (d=0x107878b8, argc=6) at tg.c:1290
 #5  0x100143bc in call_katcp (d=0x107878b8) at dispatch.c:879
 #6  0x100145cc in dispatch_katcp (d=0x107878b8) at dispatch.c:951
 #7  0x10018994 in run_shared_katcp (d=0x10782008) at shared.c:659
 #8  0x1001cbe8 in run_core_loop_katcp (dl=0x10782008) at server.c:699
 #9  0x1001d0c0 in run_config_server_katcp (dl=0x10782008, file=0x0,
 count=32, host=0x10047c90 7147, port=0)
 at server.c:832
 #10 0x10002034 in main (argc=3, argv=0xbff188f4) at main.c:196
 (gdb) frame 1
 #1  0x1000a140 in configure_fpga (gs=0x107b7928) at tg.c:877
 877   if(write_mac_fpga(gs, GO_MAC, gs-s_mac_binary)  0){
 (gdb) frame 0
 #0  0x100092d4 in write_mac_fpga (gs=0x107b7928, offset=0,
 mac=0x107b7970 \002\002\n\021) at tg.c:421
 421   *((uint32_t *)(base + offset)) = value;
 (gdb) list
 416
 417   value = (   0x0  0xff00) |
 418   (   0x0  0xff) |
 419   ((mac[0]   8)  0xff00) |
 420(mac[1] 0xff);
 421   *((uint32_t *)(base + offset)) = value;
 422
 423
 424   value = ((mac[2]  24)  0xff00) |
 425   ((mac[3]  16)  0xff) |
 (gdb) print base
 $1 = (void *) 0x1033fff
 (gdb) print offset
 $2 = 0
 (gdb) print value
 $3 = 514
 (gdb)

 'base' is a void * which is set like this:
  base = gs-s_raw_mode-r_map + gs-s_register-e_pos_base;
 (back to gdb):

 (gdb) print *(gs-s_raw_mode)
 $12 = {r_registers = 0x10783d80, r_hwmon = 0x10783d90, r_fpga = 1, r_map
 = 0x, r_map_size = 33554432,
   r_image = 0x0, r_bof_dir = 0x10783da0 /boffiles, r_top_register =
 17314052, r_argc = 3,
   r_argv = 0xbff188f4, r_chassis = 0x107876e0, r_taps = 0x10785820,
 r_instances = 0}
 (gdb) print *(gs-s_register)
 $13 = {e_pos_base = 16990208, e_len_base = 16384, e_pos_offset = 0
 '\000', e_len_offset = 0 '\000',
   e_mode = 3 '\003'}
 (gdb)


 I should add that 'base' is pointing to memory gdb says it cannot access
 (hence the segv):

 (gdb) print *(uint32_t *)base
 Cannot access memory at address 0x1033fff


 Ray

Re: [casper] debugging communication with one_GbE from roach-2 's fpga

[Marc Welz]

Hello

 However, we are stuck in debugging the system: we think we are sending stuff
 properly, but we can not read anything from the python socket, coming from
 our roach 2 fpga.

Try running tcpdump on the receiving PC. If you are using tgtap logic,
you should see occasional arp traffic from the roach to work out where
to send its
data.

Some switches have UDP flood protection - if they see lots of UDP traffic,
especially broadcast UDP, they throttle it down. If tgtap is running and I
remember things correctly, data destined for machines which do not respond
to arp traffic will be broadcast. Alternatively if the destination MAC
is all zeros,
switches typically discard traffic instead of sending it on.

I believe you are one of the first people to use the GbE port, so please
let us know of your progress.

regards

marc