Re: [casper] ROACH memory-mapped IO
Hello To minimize network traffic, the file with the commands could be on the local host rather than on a remote machine; then the only thing that goes over the network is the file name. I also have a small program that allows you to run individual katcp commands but is far more user-friendly than trying to type those commands directly to the server over a telnet connection. That's a front end to katcpComm, I guess. I'm not sure how I could grow from that into a complex interactive graphical program, except very painfully using the Motif library or something like that. There is a good reason for languages like Python and Matlab. If your gateware control functions are not particularly complicated you could use kcpcmd to do the work - so from a program shell out (eg system(kcpcmd ...), or from a script invoke it like any other utility. Shell example (-p allows more interesting constructs) #!/bin/sh if kcpcmd -i -s $ROACHNAME wordread sys_scratchpad 0 | grep -q deadbeef ; then echo scratchpad already set to to deadbeef exit 0 else kcpcmd -i -s $ROACHNAME wordwrite sys_scratchpad 0 0xc0cac01a fi kcpcmd can be found at github.com/ska-sa/katcp_devel/ - git clone the tree, do a make and if things work out then you should have an executable in cmd/kcpcmd [1] I'll cross-compile it for the roach 2, so that one can run code locally there too. Another option, if you wish to talk to a roach without using any existing tool or library, is to use a trick I saw in troll ftpd long ago: In C use the normal logic to connect a network socket/fd, and then use fdopen on it, that allows you to do things such as fprintf(fp, ?wordread sys_scratchpad 0\n); It isn't ideal, but will allow you to talk to a roach without using a library (other than libc). regards marc [1] You probably don't want to run a make install in the full katcp_devel tree, unless you want to set a correlator control server, but a make -C cmd install is ok.
Re: [casper] ROACH memory-mapped IO
Thanks for that, Jason! It is very timely. The reason I went down this path is because I have a spectrometer design, by Joseph Trinh, which takes a slightly different approach to bram access and so I could not use the katcp_wrapper which I'd been using with your 16K spectrometer. He'd offered to modify it but I thought it cool to try the file access I/O. I think as a result of this exchange, I'll ask Joseph to modify his design and I'll start using pyro. I hope he can squeeze it into a ROACH-1. He's got a 2x1024 spectrometer design for me now but had to drop the PFBs because of insufficient resources. I'm asking him to try 2x512 with PFBs. Does anyone already have something like that? Next time around we'll use ROACH-2 but at the time we placed the orders we weren't sure that the support for that would evolve fast enough to meet our deadline (next month). Cheers Tom On 08/29/2012 01:09 AM, Jason Manley wrote: On 29 Aug 2012, at 02:44, Adam Barta wrote: You could also try an ssh port forward to the katcp port ssh -vNL 7147:roach:7147 gateway Then use the katcp interface to read / write the registers. There is a katcp_wrapper.py in the corr library I would like to re-inforce this suggestion if you need SSH tunnelling through a firewall. A general word of warning to the CASPER community, which we also explained at the recent workshop... MeerKAT will not be supporting filesystem-level access in future boards (quite possibly starting with ROACH-2 already) and so, unless someone else in the collaboration picks it up, you'll be on your own if you write custom software to run on the PPC/BORPH because new platforms might not even run BORPH at all. There are a number of reasons for this decision, one being that we've run into performance limitations with BORPH, but also that it's a big overhead to port and debug and to keep it running reliably. The only interface supported by SKA-SA will be through KATCP. So if you start using the KATCP interface now, you'll have a transparent upgrade path to future boards. I'd suggest you don't worry yourself too much with the low-level detail... this is part of what CASPER tries to abstract away to ease your life as an instrument designer. If you don't want to write your own KATCP interface (and who does?!), consider using one of the existing ones. The best developed ones are in c (which includes a command-line executable for a single-line, ipython-like interactive experience from the shell prompt if you just want to call a shell script with a bunch of commands), available at https://github.com/ska-sa/katcp_devel, or a number of CASPER collaborators are using the python wrapper from corr if you want to build a higher-level GUI application. You can find a one-page getting started guide here: https://casper.berkeley.edu/wiki/Corr Jason -- I or me? http://www.oxforddictionaries.com/page/145
Re: [casper] ROACH memory-mapped IO
If you take a look at the pocket correlator design (tutorial 4), you'll find that it does four inputs of 400MHz bandwidth (800Msps). I think it has 4-tap PFBs with 1024 channels by default, which fits into a ROACH-1. If you forfeit two of the inputs, you should be able to get at least twice the channel resolution. If there's BRAM left over, you should be able to get even more. Jason On 29 Aug 2012, at 11:19, Tom Kuiper wrote: Thanks for that, Jason! It is very timely. The reason I went down this path is because I have a spectrometer design, by Joseph Trinh, which takes a slightly different approach to bram access and so I could not use the katcp_wrapper which I'd been using with your 16K spectrometer. He'd offered to modify it but I thought it cool to try the file access I/O. I think as a result of this exchange, I'll ask Joseph to modify his design and I'll start using pyro. I hope he can squeeze it into a ROACH-1. He's got a 2x1024 spectrometer design for me now but had to drop the PFBs because of insufficient resources. I'm asking him to try 2x512 with PFBs. Does anyone already have something like that? Next time around we'll use ROACH-2 but at the time we placed the orders we weren't sure that the support for that would evolve fast enough to meet our deadline (next month). Cheers Tom On 08/29/2012 01:09 AM, Jason Manley wrote: On 29 Aug 2012, at 02:44, Adam Barta wrote: You could also try an ssh port forward to the katcp port ssh -vNL 7147:roach:7147 gateway Then use the katcp interface to read / write the registers. There is a katcp_wrapper.py in the corr library I would like to re-inforce this suggestion if you need SSH tunnelling through a firewall. A general word of warning to the CASPER community, which we also explained at the recent workshop... MeerKAT will not be supporting filesystem-level access in future boards (quite possibly starting with ROACH-2 already) and so, unless someone else in the collaboration picks it up, you'll be on your own if you write custom software to run on the PPC/BORPH because new platforms might not even run BORPH at all. There are a number of reasons for this decision, one being that we've run into performance limitations with BORPH, but also that it's a big overhead to port and debug and to keep it running reliably. The only interface supported by SKA-SA will be through KATCP. So if you start using the KATCP interface now, you'll have a transparent upgrade path to future boards. I'd suggest you don't worry yourself too much with the low-level detail... this is part of what CASPER tries to abstract away to ease your life as an instrument designer. If you don't want to write your own KATCP interface (and who does?!), consider using one of the existing ones. The best developed ones are in c (which includes a command-line executable for a single-line, ipython-like interactive experience from the shell prompt if you just want to call a shell script with a bunch of commands), available at https://github.com/ska-sa/katcp_devel, or a number of CASPER collaborators are using the python wrapper from corr if you want to build a higher-level GUI application. You can find a one-page getting started guide here: https://casper.berkeley.edu/wiki/Corr Jason -- I or me? http://www.oxforddictionaries.com/page/145
Re: [casper] ROACH memory-mapped IO
On 08/29/2012 02:30 AM, Jason Manley wrote: If you take a look at the pocket correlator design (tutorial 4), you'll find that it does four inputs of 400MHz bandwidth (800Msps). I think it has 4-tap PFBs with 1024 channels by default, which fits into a ROACH-1. If you forfeit two of the inputs, you should be able to get at least twice the channel resolution. If there's BRAM left over, you should be able to get even more. I forgot to mention that we need a bandwidth of at least 640 MHz. Tom Jason On 29 Aug 2012, at 11:19, Tom Kuiper wrote: Thanks for that, Jason! It is very timely. The reason I went down this path is because I have a spectrometer design, by Joseph Trinh, which takes a slightly different approach to bram access and so I could not use the katcp_wrapper which I'd been using with your 16K spectrometer. He'd offered to modify it but I thought it cool to try the file access I/O. I think as a result of this exchange, I'll ask Joseph to modify his design and I'll start using pyro. I hope he can squeeze it into a ROACH-1. He's got a 2x1024 spectrometer design for me now but had to drop the PFBs because of insufficient resources. I'm asking him to try 2x512 with PFBs. Does anyone already have something like that? Next time around we'll use ROACH-2 but at the time we placed the orders we weren't sure that the support for that would evolve fast enough to meet our deadline (next month). Cheers Tom On 08/29/2012 01:09 AM, Jason Manley wrote: On 29 Aug 2012, at 02:44, Adam Barta wrote: You could also try an ssh port forward to the katcp port ssh -vNL 7147:roach:7147 gateway Then use the katcp interface to read / write the registers. There is a katcp_wrapper.py in the corr library I would like to re-inforce this suggestion if you need SSH tunnelling through a firewall. A general word of warning to the CASPER community, which we also explained at the recent workshop... MeerKAT will not be supporting filesystem-level access in future boards (quite possibly starting with ROACH-2 already) and so, unless someone else in the collaboration picks it up, you'll be on your own if you write custom software to run on the PPC/BORPH because new platforms might not even run BORPH at all. There are a number of reasons for this decision, one being that we've run into performance limitations with BORPH, but also that it's a big overhead to port and debug and to keep it running reliably. The only interface supported by SKA-SA will be through KATCP. So if you start using the KATCP interface now, you'll have a transparent upgrade path to future boards. I'd suggest you don't worry yourself too much with the low-level detail... this is part of what CASPER tries to abstract away to ease your life as an instrument designer. If you don't want to write your own KATCP interface (and who does?!), consider using one of the existing ones. The best developed ones are in c (which includes a command-line executable for a single-line, ipython-like interactive experience from the shell prompt if you just want to call a shell script with a bunch of commands), available at https://github.com/ska-sa/katcp_devel, or a number of CASPER collaborators are using the python wrapper from corr if you want to build a higher-level GUI application. You can find a one-page getting started guide here: https://casper.berkeley.edu/wiki/Corr Jason -- I or me? http://www.oxforddictionaries.com/page/145 -- I or me? http://www.oxforddictionaries.com/page/145
Re: [casper] ROACH memory-mapped IO
On 08/29/2012 02:47 AM, Jason Manley wrote: Trying to clock the FPGA at 320MHz will be tricky, so I'd suggest just demux again and run it at 160MHz. I believe that you should have enough resources to do this with at least a 4-tap PFB and 1024 channels. 2-inputs at 800MHz is equivalent to 4-inputs at 400MHz in terms of processing load. The only catch I can think of now might be in the bitwidth of the output BRAMs; I think tut4 requantises. I'd suggest you try it and see how you go. The new libraries let you trade off BRAM for logic resources in the FFT, so you should be able to pack that FPGA quite tightly. Thanks for the tip. I'll talk to Joseph in the morning. Meanwhile, I tested the example in http://irmen.home.xs4all.nl/pyro3/sshtunnel.html and it works perfectly so I can now build on that. Now to get back to sleep... Cheers, Tom Jason On 29 Aug 2012, at 11:32, Tom Kuiper wrote: On 08/29/2012 02:30 AM, Jason Manley wrote: If you take a look at the pocket correlator design (tutorial 4), you'll find that it does four inputs of 400MHz bandwidth (800Msps). I think it has 4-tap PFBs with 1024 channels by default, which fits into a ROACH-1. If you forfeit two of the inputs, you should be able to get at least twice the channel resolution. If there's BRAM left over, you should be able to get even more. I forgot to mention that we need a bandwidth of at least 640 MHz. Tom Jason On 29 Aug 2012, at 11:19, Tom Kuiper wrote: Thanks for that, Jason! It is very timely. The reason I went down this path is because I have a spectrometer design, by Joseph Trinh, which takes a slightly different approach to bram access and so I could not use the katcp_wrapper which I'd been using with your 16K spectrometer. He'd offered to modify it but I thought it cool to try the file access I/O. I think as a result of this exchange, I'll ask Joseph to modify his design and I'll start using pyro. I hope he can squeeze it into a ROACH-1. He's got a 2x1024 spectrometer design for me now but had to drop the PFBs because of insufficient resources. I'm asking him to try 2x512 with PFBs. Does anyone already have something like that? Next time around we'll use ROACH-2 but at the time we placed the orders we weren't sure that the support for that would evolve fast enough to meet our deadline (next month). Cheers Tom On 08/29/2012 01:09 AM, Jason Manley wrote: On 29 Aug 2012, at 02:44, Adam Barta wrote: You could also try an ssh port forward to the katcp port ssh -vNL 7147:roach:7147 gateway Then use the katcp interface to read / write the registers. There is a katcp_wrapper.py in the corr library I would like to re-inforce this suggestion if you need SSH tunnelling through a firewall. A general word of warning to the CASPER community, which we also explained at the recent workshop... MeerKAT will not be supporting filesystem-level access in future boards (quite possibly starting with ROACH-2 already) and so, unless someone else in the collaboration picks it up, you'll be on your own if you write custom software to run on the PPC/BORPH because new platforms might not even run BORPH at all. There are a number of reasons for this decision, one being that we've run into performance limitations with BORPH, but also that it's a big overhead to port and debug and to keep it running reliably. The only interface supported by SKA-SA will be through KATCP. So if you start using the KATCP interface now, you'll have a transparent upgrade path to future boards. I'd suggest you don't worry yourself too much with the low-level detail... this is part of what CASPER tries to abstract away to ease your life as an instrument designer. If you don't want to write your own KATCP interface (and who does?!), consider using one of the existing ones. The best developed ones are in c (which includes a command-line executable for a single-line, ipython-like interactive experience from the shell prompt if you just want to call a shell script with a bunch of commands), available at https://github.com/ska-sa/katcp_devel, or a number of CASPER collaborators are using the python wrapper from corr if you want to build a higher-level GUI application. You can find a one-page getting started guide here: https://casper.berkeley.edu/wiki/Corr Jason -- I or me? http://www.oxforddictionaries.com/page/145 -- I or me? http://www.oxforddictionaries.com/page/145 -- I or me? http://www.oxforddictionaries.com/page/145
Re: [casper] ROACH memory mapped IO
Hi Tom, If you are running tcpborphserver2 on the roach then you can use the following commands to write and read from registers through the tcp interface on port 7147. ?wordwrite register-name word-offset payload ?write register-name register-offset payload ?wordread register-name word-offset length ?bulkread register-name [register-offset [byte-count]] Is there a reason you would like to use the files? This seemed to work for me root@192:/proc/389/hw/ioreg# cat sys_scratchpad | hd 12 34 56 78 |.4Vx| 0004 root@192:/proc/389/hw/ioreg# echo -e \FF\FF sys_scratchpad root@192:/proc/389/hw/ioreg# cat sys_scratchpad | hd 46 46 46 46 || 0004 Hope this helps Regards Adam On Tue, Aug 28, 2012 at 6:38 PM, Tom Kuiper kui...@jpl.nasa.gov wrote: It appears that there is something I don't understand about memory mapped IO. I'm trying to write directly to a firmware register. I have tried in Python in binary mode with various options regarding buffering. I have also tried the command line 'echo 1 register'. Whatever I try, the length of the register 'file' changes from 4 to 0. Can someone point me towards enlightenment? Many thanks Tom -- I or me? http://www.oxforddictionaries.**com/page/145http://www.oxforddictionaries.com/page/145 -- *Adam Barta* c: +27 72 105 8611 e: a...@ska.ac.za w: www.ska.ac.za
Re: [casper] ROACH memory mapped IO
Sorry I made a mistake This is what it should look like root@192:/proc/411/hw/ioreg# echo -en \xff\xff\xff\xff sys_scratchpad root@192:/proc/411/hw/ioreg# cat sys_scratchpad | hd ff ff ff ff || 0004 On Tue, Aug 28, 2012 at 7:22 PM, Adam Barta a...@ska.ac.za wrote: Hi Tom, If you are running tcpborphserver2 on the roach then you can use the following commands to write and read from registers through the tcp interface on port 7147. ?wordwrite register-name word-offset payload ?write register-name register-offset payload ?wordread register-name word-offset length ?bulkread register-name [register-offset [byte-count]] Is there a reason you would like to use the files? This seemed to work for me root@192:/proc/389/hw/ioreg# cat sys_scratchpad | hd 12 34 56 78 |.4Vx| 0004 root@192:/proc/389/hw/ioreg# echo -e \FF\FF sys_scratchpad root@192:/proc/389/hw/ioreg# cat sys_scratchpad | hd 46 46 46 46 || 0004 Hope this helps Regards Adam On Tue, Aug 28, 2012 at 6:38 PM, Tom Kuiper kui...@jpl.nasa.gov wrote: It appears that there is something I don't understand about memory mapped IO. I'm trying to write directly to a firmware register. I have tried in Python in binary mode with various options regarding buffering. I have also tried the command line 'echo 1 register'. Whatever I try, the length of the register 'file' changes from 4 to 0. Can someone point me towards enlightenment? Many thanks Tom -- I or me? http://www.oxforddictionaries.**com/page/145http://www.oxforddictionaries.com/page/145 -- *Adam Barta* c: +27 72 105 8611 e: a...@ska.ac.za w: www.ska.ac.za -- *Adam Barta* c: +27 72 105 8611 e: a...@ska.ac.za w: www.ska.ac.za
Re: [casper] ROACH memory mapped IO
On 08/28/2012 10:22 AM, Adam Barta wrote: If you are running tcpborphserver2 on the roach then you can use the following commands to write and read from registers through the tcp interface on port 7147. ?wordwrite register-name word-offset payload ?write register-name register-offset payload ?wordread register-name word-offset length ?bulkread register-name [register-offset [byte-count]] I'm familiar with that. Thanks. Is there a reason you would like to use the files? Generally speaking, the ROACH is on a private network and the controller host is behind a firewall. Also, the network link can be pretty bad at times. 100 kbps or even as low as 50 kbps. That could be because I'm at home using DSL or because I'm using a Deep Space Network circuit at a time when some huge higher-priority data transfer is in progress. I can really cut down on the traffic is I use sshfs to mount the ROACH file system locally. This seemed to work for me root@192:/proc/389/hw/ioreg# cat sys_scratchpad | hd 12 34 56 78 |.4Vx| 0004 root@192:/proc/389/hw/ioreg# echo -e \FF\FF sys_scratchpad root@192:/proc/389/hw/ioreg# cat sys_scratchpad | hd 46 46 46 46 || 0004 That works for me too. It tells me that the firmware is acting as it should. Thanks for the tip. Hope this helps Note quite there yet, though. Notice that what was stored are ASCII symbols. It isn't just because of a missing 'x': root@roach1:/proc/1174/hw/ioreg# echo -e \01\00 trig_adc0 root@roach1:/proc/1174/hw/ioreg# cat trig_adc0 | hd 30 31 30 30 |0100| 0004 root@roach1:/proc/1174/hw/ioreg# echo -e \x01\x00 trig_adc0 root@roach1:/proc/1174/hw/ioreg# cat trig_adc0 | hd 78 30 31 78 |x01x| 0004 But this hangs: root@roach1:/proc/1174/hw/ioreg# echo -e \\x01\\x00 trig_adc0 Regards Tom
Re: [casper] ROACH memory mapped IO
Yes its the trailing newline i think so echo -en \xFF would work On Tue, Aug 28, 2012 at 7:39 PM, Tom Kuiper kui...@jpl.nasa.gov wrote: ** On 08/28/2012 10:22 AM, Adam Barta wrote: If you are running tcpborphserver2 on the roach then you can use the following commands to write and read from registers through the tcp interface on port 7147. ?wordwrite register-name word-offset payload ?write register-name register-offset payload ?wordread register-name word-offset length ?bulkread register-name [register-offset [byte-count]] I'm familiar with that. Thanks. Is there a reason you would like to use the files? Generally speaking, the ROACH is on a private network and the controller host is behind a firewall. Also, the network link can be pretty bad at times. 100 kbps or even as low as 50 kbps. That could be because I'm at home using DSL or because I'm using a Deep Space Network circuit at a time when some huge higher-priority data transfer is in progress. I can really cut down on the traffic is I use sshfs to mount the ROACH file system locally. This seemed to work for me root@192:/proc/389/hw/ioreg# cat sys_scratchpad | hd 12 34 56 78 |.4Vx| 0004 root@192:/proc/389/hw/ioreg# echo -e \FF\FF sys_scratchpad root@192:/proc/389/hw/ioreg# cat sys_scratchpad | hd 46 46 46 46 || 0004 That works for me too. It tells me that the firmware is acting as it should. Thanks for the tip. Hope this helps Note quite there yet, though. Notice that what was stored are ASCII symbols. It isn't just because of a missing 'x': root@roach1:/proc/1174/hw/ioreg# echo -e \01\00 trig_adc0 root@roach1:/proc/1174/hw/ioreg# cat trig_adc0 | hd 30 31 30 30 |0100| 0004 root@roach1:/proc/1174/hw/ioreg# echo -e \x01\x00 trig_adc0 root@roach1:/proc/1174/hw/ioreg# cat trig_adc0 | hd 78 30 31 78 |x01x| 0004 But this hangs: root@roach1:/proc/1174/hw/ioreg# echo -e \\x01\\x00 trig_adc0 Regards Tom -- *Adam Barta* c: +27 72 105 8611 e: a...@ska.ac.za w: www.ska.ac.za
Re: [casper] ROACH memory mapped IO
On 08/28/2012 10:45 AM, Adam Barta wrote: Yes its the trailing newline i think so echo -en \xFF would work Yes, thanks for the -n tip. Here's what I get. root@roach1:/proc/1174/hw/ioreg# echo -en \x01\x00 trig_adc0 root@roach1:/proc/1174/hw/ioreg# cat trig_adc0 | hd 78 30 31 78 |x01x| 0004 root@roach1:/proc/1174/hw/ioreg# echo -en \xff\xff trig_adc0 root@roach1:/proc/1174/hw/ioreg# cat trig_adc0 | hd 78 66 66 78 |xffx| 0004 root@roach1:/proc/1174/hw/ioreg# echo -en \xFF\xFF trig_adc0 root@roach1:/proc/1174/hw/ioreg# cat trig_adc0 | hd 78 46 46 78 |xFFx| 0004 Since this is on a ROACH-1 PPC we should be running the same OS, so I'm puzzled. Tom
Re: [casper] ROACH memory mapped IO
Aha! root@roach1:/proc/1174/hw/ioreg# echo -en \xFF\xFF trig_adc0 root@roach1:/proc/1174/hw/ioreg# cat trig_adc0 | hd ff ff 46 78 |..Fx| 0004 Tom On 08/28/2012 10:48 AM, Tom Kuiper wrote: On 08/28/2012 10:45 AM, Adam Barta wrote: Yes its the trailing newline i think so echo -en \xFF would work Yes, thanks for the -n tip. Here's what I get. root@roach1:/proc/1174/hw/ioreg# echo -en \x01\x00 trig_adc0 root@roach1:/proc/1174/hw/ioreg# cat trig_adc0 | hd 78 30 31 78 |x01x| 0004 root@roach1:/proc/1174/hw/ioreg# echo -en \xff\xff trig_adc0 root@roach1:/proc/1174/hw/ioreg# cat trig_adc0 | hd 78 66 66 78 |xffx| 0004 root@roach1:/proc/1174/hw/ioreg# echo -en \xFF\xFF trig_adc0 root@roach1:/proc/1174/hw/ioreg# cat trig_adc0 | hd 78 46 46 78 |xFFx| 0004 Since this is on a ROACH-1 PPC we should be running the same OS, so I'm puzzled. Tom -- I or me? http://www.oxforddictionaries.com/page/145
Re: [casper] ROACH memory mapped IO
On 08/28/2012 11:05 AM, Patrick Brandt wrote:
Tom Kuiper wrote:
It appears that there is something I don't understand about memory
mapped IO.
I'm trying to write directly to a firmware register. I have tried in
Python in binary mode with various options regarding buffering. I
have also tried the command line 'echo 1 register'. Whatever I
try, the length of the register 'file' changes from 4 to 0.
In python, you'll want to use the 'binascii' module functions
'b2a_hex' and 'a2b_hex' (or the colorfully aliased equivalents,
'hexlify' and 'unhexlify', respectively) to encode the data before
writing it to the firmware register.
I'm using struct pack and unpack. Isn't that more flexible?
Tom
ex:
unhexlify('04') # data going into the file
'\x04'
hexlify('\x04') # data coming out of the file
'04'
Obviously this is using hexadecimal representation. There are
probably ways to handle plain integers, but I didn't stumble upon it
when I was writing my control code.
--
I or me? http://www.oxforddictionaries.com/page/145
Re: [casper] ROACH memory mapped IO
Great glad it works.. On Tue, Aug 28, 2012 at 7:51 PM, Tom Kuiper kui...@jpl.nasa.gov wrote: ** Aha! root@roach1:/proc/1174/hw/ioreg# echo -en \xFF\xFF trig_adc0 root@roach1:/proc/1174/hw/ioreg# cat trig_adc0 | hd ff ff 46 78 |..Fx| 0004 Tom On 08/28/2012 10:48 AM, Tom Kuiper wrote: On 08/28/2012 10:45 AM, Adam Barta wrote: Yes its the trailing newline i think so echo -en \xFF would work Yes, thanks for the -n tip. Here's what I get. root@roach1:/proc/1174/hw/ioreg# echo -en \x01\x00 trig_adc0 root@roach1:/proc/1174/hw/ioreg# cat trig_adc0 | hd 78 30 31 78 |x01x| 0004 root@roach1:/proc/1174/hw/ioreg# echo -en \xff\xff trig_adc0 root@roach1:/proc/1174/hw/ioreg# cat trig_adc0 | hd 78 66 66 78 |xffx| 0004 root@roach1:/proc/1174/hw/ioreg# echo -en \xFF\xFF trig_adc0 root@roach1:/proc/1174/hw/ioreg# cat trig_adc0 | hd 78 46 46 78 |xFFx| 0004 Since this is on a ROACH-1 PPC we should be running the same OS, so I'm puzzled. Tom -- I or me? http://www.oxforddictionaries.com/page/145 -- *Adam Barta* c: +27 72 105 8611 e: a...@ska.ac.za w: www.ska.ac.za
Re: [casper] ROACH memory mapped IO
On 08/28/2012 10:53 AM, Adam Barta wrote: I think the quotes are important too There's still something funny going on. Look at the file size for sys_scratchpad after writing. Tom root@roach1:/proc/1221/hw/ioreg# ls -l total 0 -r--r--r-- 1 root root 4 Jul 28 02:13 acc_cnt ... -rw-rw-rw- 1 root root 4 Jul 28 02:13 sys_scratchpad -rw-rw-rw- 1 root root 4 Jul 28 02:13 trig_adc0 root@roach1:/proc/1221/hw/ioreg# echo -en \xFF\xFF\xFF\xFF sys_scratchpad root@roach1:/proc/1221/hw/ioreg# cat sys_scratchpad | hd ff ff ff ff || 0004 root@roach1:/proc/1221/hw/ioreg# ls -l total 0 -r--r--r-- 1 root root 4 Jul 28 02:13 acc_cnt ... -rw-rw-rw- 1 root root 0 Jul 28 02:21 sys_scratchpad -rw-rw-rw- 1 root root 4 Jul 28 02:13 trig_adc0 On Tue, Aug 28, 2012 at 7:48 PM, Tom Kuiper kui...@jpl.nasa.gov mailto:kui...@jpl.nasa.gov wrote: On 08/28/2012 10:45 AM, Adam Barta wrote: Yes its the trailing newline i think so echo -en \xFF would work Yes, thanks for the -n tip. Here's what I get. root@roach1:/proc/1174/hw/ioreg# echo -en \x01\x00 trig_adc0 root@roach1:/proc/1174/hw/ioreg# cat trig_adc0 | hd 78 30 31 78 |x01x| 0004 root@roach1:/proc/1174/hw/ioreg# echo -en \xff\xff trig_adc0 root@roach1:/proc/1174/hw/ioreg# cat trig_adc0 | hd 78 66 66 78 |xffx| 0004 root@roach1:/proc/1174/hw/ioreg# echo -en \xFF\xFF trig_adc0 root@roach1:/proc/1174/hw/ioreg# cat trig_adc0 | hd 78 46 46 78 |xFFx| 0004 Since this is on a ROACH-1 PPC we should be running the same OS, so I'm puzzled. Tom -- *Adam Barta* c: +27 72 105 8611 e: a...@ska.ac.za mailto:a...@ska.ac.za w: www.ska.ac.za http://www.ska.ac.za -- I or me? http://www.oxforddictionaries.com/page/145
Re: [casper] ROACH memory mapped IO
Hi Tom,
I can confirm the same effect my side. I also checked using the katcp
command
?wordwrite sys_scratchpad 0 0x
And this doesn't effect the filesize, however all the registers are open
file descriptors after the ?progdev.
strace'ing the echo -ne command seems to show a mmap of 4k then a write
then a close and an munmap
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x3001a000
write(1, \377\0\377\0, 4) = 4
close(1)
= 0
munmap(0x3001a000, 4096)= 0
while strace'ing tcpborphserver2 shows a seek then a write.
read(9, ?wordwrite sys_scratchpad 0 0xff..., 512) = 39
lseek(35, 0, SEEK_SET) = 0
write(35, \377\377\377\22, 4) = 4
I suspect it has something to do with the inode for the register file not
being refreshed ??? i dug into linux/borph.c but can't seem to see anything
yet.
I will look into it more.
Regards
Adam
On Tue, Aug 28, 2012 at 10:06 PM, Tom Kuiper kui...@jpl.nasa.gov wrote:
**
On 08/28/2012 10:53 AM, Adam Barta wrote:
I think the quotes are important too
There's still something funny going on. Look at the file size for
sys_scratchpad after writing.
Tom
root@roach1:/proc/1221/hw/ioreg# ls -l
total 0
-r--r--r-- 1 root root 4 Jul 28 02:13 acc_cnt
...
-rw-rw-rw- 1 root root 4 Jul 28 02:13 sys_scratchpad
-rw-rw-rw- 1 root root 4 Jul 28 02:13 trig_adc0
root@roach1:/proc/1221/hw/ioreg# echo -en \xFF\xFF\xFF\xFF
sys_scratchpad
root@roach1:/proc/1221/hw/ioreg# cat sys_scratchpad | hd
ff ff ff ff ||
0004
root@roach1:/proc/1221/hw/ioreg# ls -l
total 0
-r--r--r-- 1 root root 4 Jul 28 02:13 acc_cnt
...
-rw-rw-rw- 1 root root 0 Jul 28 02:21 sys_scratchpad
-rw-rw-rw- 1 root root 4 Jul 28 02:13 trig_adc0
On Tue, Aug 28, 2012 at 7:48 PM, Tom Kuiper kui...@jpl.nasa.gov wrote:
On 08/28/2012 10:45 AM, Adam Barta wrote:
Yes its the trailing newline i think so
echo -en \xFF
would work
Yes, thanks for the -n tip. Here's what I get.
root@roach1:/proc/1174/hw/ioreg# echo -en \x01\x00 trig_adc0
root@roach1:/proc/1174/hw/ioreg# cat trig_adc0 | hd
78 30 31 78 |x01x|
0004
root@roach1:/proc/1174/hw/ioreg# echo -en \xff\xff trig_adc0
root@roach1:/proc/1174/hw/ioreg# cat trig_adc0 | hd
78 66 66 78 |xffx|
0004
root@roach1:/proc/1174/hw/ioreg# echo -en \xFF\xFF trig_adc0
root@roach1:/proc/1174/hw/ioreg# cat trig_adc0 | hd
78 46 46 78 |xFFx|
0004
Since this is on a ROACH-1 PPC we should be running the same OS, so I'm
puzzled.
Tom
--
*Adam Barta*
c: +27 72 105 8611
e: a...@ska.ac.za
w: www.ska.ac.za
--
I or me? http://www.oxforddictionaries.com/page/145
--
*Adam Barta*
c: +27 72 105 8611
e: a...@ska.ac.za
w: www.ska.ac.za
Re: [casper] ROACH memory-mapped IO
On 08/28/2012 03:11 PM, Tom Kuiper wrote: I have the feeling that the file length going to zero on a simple write is unintended and been lurking in the borph code since no one ever tried such a simple OS-level write. I'm guessing that the file pointer, which is reset to zero before the write, is not advanced after the write. Well, scratch that idea. The file pointer is definitely 4 before I close the file. Tom
Re: [casper] ROACH memory-mapped IO
Looking in /proc most other kernel generated files for example /proc/interrupts or /proc/mdstat also have 0 filesizes. On Wed, Aug 29, 2012 at 12:28 AM, Tom Kuiper kui...@jpl.nasa.gov wrote: On 08/28/2012 03:11 PM, Tom Kuiper wrote: I have the feeling that the file length going to zero on a simple write is unintended and been lurking in the borph code since no one ever tried such a simple OS-level write. I'm guessing that the file pointer, which is reset to zero before the write, is not advanced after the write. Well, scratch that idea. The file pointer is definitely 4 before I close the file. Tom -- *Adam Barta* c: +27 72 105 8611 e: a...@ska.ac.za w: www.ska.ac.za
Re: [casper] ROACH memory-mapped IO
Hi, Tom, On Aug 28, 2012, at 3:39 PM, Tom Kuiper wrote: I don't know how to get Python to read more than teh nominal file size if it is supposed to look like a file. If you want to read the register value a second time, you need to seek to the beginning of the file first, then read four bytes. You should be able to repeat the seek/read pattern as many times as you want. If that's not what's confusing you, can you please clarify what is? Thanks, Dave
Re: [casper] ROACH memory-mapped IO
On 08/28/2012 03:54 PM, David MacMahon wrote: On Aug 28, 2012, at 3:39 PM, Tom Kuiper wrote: I don't know how to get Python to read more than teh nominal file size if it is supposed to look like a file. If you want to read the register value a second time, you need to seek to the beginning of the file first, then read four bytes. You should be able to repeat the seek/read pattern as many times as you want. I close the file after I write to it and open it again for the read. After I write to the file, ls -l gives a size of zero instead of 4. If that's not what's confusing you, can you please clarify what is? I am not trying to mix reads and writes on an open file. I know about seek and tell if that were what I wanted to do. Tom
Re: [casper] ROACH memory-mapped IO
On 08/28/2012 04:11 PM, Adam Barta wrote: is it possible that ipython is not actually closing the file but keeping the file descriptor open behind your back, if so then seeking to 0 might solve it? Clever idea! but, alas, Python is cleverer than that. I put a seek(0) after (re)opening the file and before reading. Still get 0 bytes back. I'm not having much luck in finding a way to change the file size. There is a 'truncate' method that will do it but Linux will zero fill an extended file. Cheers Tom On Wed, Aug 29, 2012 at 1:00 AM, Tom Kuiper kui...@jpl.nasa.gov mailto:kui...@jpl.nasa.gov wrote: On 08/28/2012 03:54 PM, David MacMahon wrote: On Aug 28, 2012, at 3:39 PM, Tom Kuiper wrote: I don't know how to get Python to read more than teh nominal file size if it is supposed to look like a file. If you want to read the register value a second time, you need to seek to the beginning of the file first, then read four bytes. You should be able to repeat the seek/read pattern as many times as you want. I close the file after I write to it and open it again for the read. After I write to the file, ls -l gives a size of zero instead of 4. If that's not what's confusing you, can you please clarify what is? I am not trying to mix reads and writes on an open file. I know about seek and tell if that were what I wanted to do. Tom -- *Adam Barta* c: +27 72 105 8611 e: a...@ska.ac.za mailto:a...@ska.ac.za w: www.ska.ac.za http://www.ska.ac.za -- I or me? http://www.oxforddictionaries.com/page/145
Re: [casper] ROACH memory-mapped IO
Could you share a code snippet? If you cat the file to hd does it read correctly even with the zero filesize? On Wed, Aug 29, 2012 at 1:19 AM, Tom Kuiper kui...@jpl.nasa.gov wrote: ** On 08/28/2012 04:11 PM, Adam Barta wrote: is it possible that ipython is not actually closing the file but keeping the file descriptor open behind your back, if so then seeking to 0 might solve it? Clever idea! but, alas, Python is cleverer than that. I put a seek(0) after (re)opening the file and before reading. Still get 0 bytes back. I'm not having much luck in finding a way to change the file size. There is a 'truncate' method that will do it but Linux will zero fill an extended file. Cheers Tom On Wed, Aug 29, 2012 at 1:00 AM, Tom Kuiper kui...@jpl.nasa.gov wrote: On 08/28/2012 03:54 PM, David MacMahon wrote: On Aug 28, 2012, at 3:39 PM, Tom Kuiper wrote: I don't know how to get Python to read more than teh nominal file size if it is supposed to look like a file. If you want to read the register value a second time, you need to seek to the beginning of the file first, then read four bytes. You should be able to repeat the seek/read pattern as many times as you want. I close the file after I write to it and open it again for the read. After I write to the file, ls -l gives a size of zero instead of 4. If that's not what's confusing you, can you please clarify what is? I am not trying to mix reads and writes on an open file. I know about seek and tell if that were what I wanted to do. Tom -- *Adam Barta* c: +27 72 105 8611 e: a...@ska.ac.za w: www.ska.ac.za -- I or me? http://www.oxforddictionaries.com/page/145 -- *Adam Barta* c: +27 72 105 8611 e: a...@ska.ac.za w: www.ska.ac.za
Re: [casper] ROACH memory-mapped IO
Hi, Tom, On Aug 28, 2012, at 4:00 PM, Tom Kuiper wrote: If you want to read the register value a second time, you need to seek to the beginning of the file first, then read four bytes. You should be able to repeat the seek/read pattern as many times as you want. I close the file after I write to it and open it again for the read. After I write to the file, ls -l gives a size of zero instead of 4. Is there a functional problem here or are you just annoyed that the file size shows 0? So what if the files size shows up as 0? Does it prevent you from reading/writing to the register? Dave
Re: [casper] ROACH memory-mapped IO
Thanks Okay looks like the culprit is *sshfs* I tried it my side and it seems to fail when using it that way. I guess the problem is that *fuse* just wont let you read a zero byte file. It might be possible to trick fuse by making a character device. (mknod or mkfifo) Adam On Wed, Aug 29, 2012 at 1:36 AM, Tom Kuiper kui...@jpl.nasa.gov wrote: ** On 08/28/2012 04:24 PM, Adam Barta wrote: Could you share a code snippet? Here's the code. If you cat the file to hd does it read correctly even with the zero filesize? I'll have to make a small mod before trying that. I'll let you know. Tom On Wed, Aug 29, 2012 at 1:19 AM, Tom Kuiper kui...@jpl.nasa.gov wrote: On 08/28/2012 04:11 PM, Adam Barta wrote: is it possible that ipython is not actually closing the file but keeping the file descriptor open behind your back, if so then seeking to 0 might solve it? Clever idea! but, alas, Python is cleverer than that. I put a seek(0) after (re)opening the file and before reading. Still get 0 bytes back. I'm not having much luck in finding a way to change the file size. There is a 'truncate' method that will do it but Linux will zero fill an extended file. Cheers Tom On Wed, Aug 29, 2012 at 1:00 AM, Tom Kuiper kui...@jpl.nasa.gov wrote: On 08/28/2012 03:54 PM, David MacMahon wrote: On Aug 28, 2012, at 3:39 PM, Tom Kuiper wrote: I don't know how to get Python to read more than teh nominal file size if it is supposed to look like a file. If you want to read the register value a second time, you need to seek to the beginning of the file first, then read four bytes. You should be able to repeat the seek/read pattern as many times as you want. I close the file after I write to it and open it again for the read. After I write to the file, ls -l gives a size of zero instead of 4. If that's not what's confusing you, can you please clarify what is? I am not trying to mix reads and writes on an open file. I know about seek and tell if that were what I wanted to do. Tom -- *Adam Barta* c: +27 72 105 8611 %2B27%2072%20105%208611 e: a...@ska.ac.za w: www.ska.ac.za -- I or me? http://www.oxforddictionaries.com/page/145 -- *Adam Barta* c: +27 72 105 8611 e: a...@ska.ac.za w: www.ska.ac.za -- I or me? http://www.oxforddictionaries.com/page/145 -- *Adam Barta* c: +27 72 105 8611 e: a...@ska.ac.za w: www.ska.ac.za
Re: [casper] ROACH memory-mapped IO
Sure no problem. Glad I could help. It is possible that there is a mount option (man mount) in FILESYSTEM INDEPENDENT MOUNT OPTIONS which may help sshfs however I tried -o dev,atime without any luck either. I think after the write or the echo -ne you need to (lseek) the file pointer back to 0 then it will be okay? The file size is correct in the beginning because it is set from proc initialization code in kernel/mkd.c and kernel/borph.c which use the structure described here http://www.6test.edu.cn/~lujx/linux_networking/0131777203_ch02lev1sec8.html Also the offsets and sizes are stored in the bof header in the bof elf file. I guess to keep it working program the bof then open all the registers and hold the file descriptors and read / write at will then before closing seek the file descriptors back to zero. This might keep sshfs happy! You could also try an ssh port forward to the katcp port *ssh -vNL 7147:roach:7147 gateway* Then use the katcp interface to read / write the registers. There is a katcp_wrapper.py in the corr library Regards Adam On Wed, Aug 29, 2012 at 1:58 AM, Tom Kuiper kui...@jpl.nasa.gov wrote: ** On 08/28/2012 04:45 PM, Adam Barta wrote: Thanks Okay looks like the culprit is *sshfs* I tried it my side and it seems to fail when using it that way. I guess the problem is that *fuse* just wont let you read a zero byte file. I never thought of that! Thanks. There's Glenn's approach which is a bit more complex. It might be possible to trick fuse by making a character device. (mknod or mkfifo) I suspect that given the learning curve that would involve for me, pyro will be the way to go. Thanks for helping me track it down. Out of curiosity, do you know why the files sizes are correct at the beginning and don't stay that way? Tom Adam On Wed, Aug 29, 2012 at 1:36 AM, Tom Kuiper kui...@jpl.nasa.gov wrote: On 08/28/2012 04:24 PM, Adam Barta wrote: Could you share a code snippet? Here's the code. If you cat the file to hd does it read correctly even with the zero filesize? I'll have to make a small mod before trying that. I'll let you know. Tom On Wed, Aug 29, 2012 at 1:19 AM, Tom Kuiper kui...@jpl.nasa.gov wrote: On 08/28/2012 04:11 PM, Adam Barta wrote: is it possible that ipython is not actually closing the file but keeping the file descriptor open behind your back, if so then seeking to 0 might solve it? Clever idea! but, alas, Python is cleverer than that. I put a seek(0) after (re)opening the file and before reading. Still get 0 bytes back. I'm not having much luck in finding a way to change the file size. There is a 'truncate' method that will do it but Linux will zero fill an extended file. Cheers Tom On Wed, Aug 29, 2012 at 1:00 AM, Tom Kuiper kui...@jpl.nasa.gov wrote: On 08/28/2012 03:54 PM, David MacMahon wrote: On Aug 28, 2012, at 3:39 PM, Tom Kuiper wrote: I don't know how to get Python to read more than teh nominal file size if it is supposed to look like a file. If you want to read the register value a second time, you need to seek to the beginning of the file first, then read four bytes. You should be able to repeat the seek/read pattern as many times as you want. I close the file after I write to it and open it again for the read. After I write to the file, ls -l gives a size of zero instead of 4. If that's not what's confusing you, can you please clarify what is? I am not trying to mix reads and writes on an open file. I know about seek and tell if that were what I wanted to do. Tom -- *Adam Barta* c: +27 72 105 8611 %2B27%2072%20105%208611 e: a...@ska.ac.za w: www.ska.ac.za -- I or me? http://www.oxforddictionaries.com/page/145 -- *Adam Barta* c: +27 72 105 8611 %2B27%2072%20105%208611 e: a...@ska.ac.za w: www.ska.ac.za -- I or me? http://www.oxforddictionaries.com/page/145 -- *Adam Barta* c: +27 72 105 8611 e: a...@ska.ac.za w: www.ska.ac.za -- I or me? http://www.oxforddictionaries.com/page/145 -- *Adam Barta* c: +27 72 105 8611 e: a...@ska.ac.za w: www.ska.ac.za
