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
len
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-offse
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, A
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
?
Yes its the trailing newline i think so
echo -en "\xFF"
would work
On Tue, Aug 28, 2012 at 7:39 PM, Tom Kuiper 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
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
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
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'. Whate
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 tri
Just to share python tricks, note that there's no need for a separate
module for this:
'%x' % 1234
--> '42d'
int('42d', base=16)
--> 1234
of course the binascii module may be more convenient.
On Tue, Aug 28, 2012 at 2:05 PM, Patrick Brandt wrote:
> Tom Kuiper wrote:
>>
>> It appears that the
Great glad it works..
On Tue, Aug 28, 2012 at 7:51 PM, Tom Kuiper 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: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-r
On 08/28/2012 01:30 PM, Larry D'Addario wrote:
I noticed your thread on this subject on the CASPER list. (Although I
subscribe to the list, I'm unable to post to it for some reason that I
have not yet figured out.)
That's strange. An e-mail to Mark Wagner may resolve that. Hopefully
he'll se
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
hi larry,
i think if you are sending emails to casper@lists.berkeley.edu
from an email address that is different from your subscription
email address, your email will be rejected by the list server.
best wishes,
dan
On Tue, Aug 28, 2012 at 3:11 PM, Tom Kuiper wrote:
> On 08/28/2012 01:30 PM,
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,
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 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 wri
On 08/28/2012 03:36 PM, Adam Barta wrote:
Looking in /proc most other "kernel generated files" for example
/proc/interrupts or /proc/mdstat also have 0 filesizes.
Well, that seems pretty common with things that aren't really files but
I don't know how to get Python to read more than teh nominal
I think you can assume to read 1 (32 bit word) or (4bytes) as a minimum
from each of the register file descriptors safely?
On Wed, Aug 29, 2012 at 12:39 AM, Tom Kuiper wrote:
> **
> On 08/28/2012 03:36 PM, Adam Barta wrote:
>
> Looking in /proc most other "kernel generated files" for example
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 by
On 08/28/2012 03:48 PM, Adam Barta wrote:
I think you can assume to read 1 (32 bit word) or (4bytes) as a
minimum from each of the register file descriptors safely?
No, on reading I get back zero bytes. I tried that with buffering=0 and
buffering=4.
Tom
On Wed, Aug 29, 2012 at 12:39 AM
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
be
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?
On Wed, Aug 29, 2012 at 1:00 AM, Tom Kuiper wrote:
> On 08/28/2012 03:54 PM, David MacMahon wrote:
>
>> On Aug 28, 2012, at 3:39 PM, Tom K
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
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 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
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 fi
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 <
On 08/28/2012 04:35 PM, David MacMahon wrote:
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?
I read four bytes from all the registers defined in the model an
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, 2
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
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
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
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 offere
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
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,
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
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-inp
hi tom,
you might consider using the vegas mode 1 spectrometer design:
1024 channels, dual pol, 1.5 GHz bandwidth (3 Gsps),
full stokes, roach I, 4 tap polyphase,
best wishes,
dan
On Wed, Aug 29, 2012 at 2:32 AM, Tom Kuiper wrote:
> On 08/29/2012 02:30 AM, Jason Manley wrote:
>
>> If you tak
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
On 08/30/2012 07:23 AM, Marc Welz wrote:
katcmd looks like a nice way to avoid having to use something like
pexpect on the ROACH PPC telnet port. That's good for people who really
want to avoid Python.
I've decided to have our firmware compatible with core.katcp_wrapper.
Using pyro has oth
40 matches
Mail list logo
