linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Didier Kryn <kryn@in2p3.fr>
To: Konstantin Boyanov <kkboyanov@gmail.com>
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Reading and writing from/to VME device
Date: Tue, 27 Mar 2007 11:09:41 +0200	[thread overview]
Message-ID: <4608DF55.90508@in2p3.fr> (raw)
In-Reply-To: <929bf310703260814q18957942s218d56bed8fb4009@mail.gmail.com>

    Hi Konstantin,
    I am new to this board, and, by chance I am just starting this week=20
my first test wit the VME on this board (I have however more than 20=20
years of VME experience). Your whole logic is mainly OK.  My driver uses =

slightly different device names but it seems very similar and the API=20
uses the same structures. I just noticed three things which bother me:
    1) You declare outWinCfg and use later in the code outWinCfgADC. I=20
guess the compiler will complain, unless I missed something. I guess=20
this is not the file you actually compiled.
    2) Why do you specify MAP_SHARED in the mmap() call ? I sort of=20
understood that the philosophy of this driver was all against sharing.=20
Maybe it works, but I wouldn't try it the first time.
    3) I think it is an error to declare your data pointer as a u_char=20
*. If you configure your interface for D16, you must perform D16 access. =

For example, you might do the following:

unsigned short *rdPtr;
=2E..
rdPtr =3D (unsigned short *)mmap(...);
    for(i=3D0;i<0x50;i++){
       printf("# Read at VME address %x =3D %x\n", i*sizeof(*rdPtr),=20
rdPtr[i] );
    }

I like using sizeof() instead of 2 because it remains valid if you=20
convert your code for D32.
If you want to perform D8 access, you should configure your window=20
accordingly. Beware that there are 2 kinds of D8 transfers, which make=20
them more complicated and, for that reason mostly abandonned. IIRC, the=20
VITA standard for CR/CSR defines 1byte data words at even addresses so=20
as to transfer them as D16. Therefore you should transfer them as short=20
and then mask the high order byte. I don't know what the high order byte =

will be in case of successfull transfer. If it is 0, then it is fine,=20
because, since a bus error would set all bits to 1, you can check=20
immediately the sucess of the transfer.

    Hope this helps.
    Didier

Konstantin Boyanov a =E9crit :
> Hi list,
>
> I'm using the MVME6100 board with the Motorola driver for linux v3.5=20
> (kernel 2.6.15). I try to access the CSR registers of an ADC board, in =

> order to configure it as to be able to access its memory, on the VME=20
> bus using one of the outbound windows defined by the driver. As I am=20
> new to the whole VME stuff, I'm getting into trouble to find out when=20
> I'm actually reading something on the VME, i.e. which addresses respond=
=2E
> I'm trying the following schema (source code @ EOM):
>
> 1. open() and ioctl() one of the /dev/vme_m* devices, which I assume=20
> is corresponding to an outbound window (at least I try to configure it =

> as one),
> 2. then mmap() a memory area to hold the contents of the /dev/vme_m*=20
> device file
> 3. and finally doing incrementation of the pointer returned by mmap()=20
> and dereferencing it in the hope that I'll read something, which in=20
> most cases is 0xFF
>
> In fact my code is very similar to test code that comes with the=20
> driver and also with a sample code I found in this thread=20
> ->http://ozlabs.org/pipermail/linuxppc-dev/1999-May/001906.html=20
> <http://ozlabs.org/pipermail/linuxppc-dev/1999-May/001906.html>
> I've tried to do a read() on the opened /dev/vme_m* device but I only=20
> succeed in reading 0 bytes, and when I try to read in chunks from the=20
> VME bus i get errno 22 on reads like read(fd, buffer, 1024) for example=
=2E
>
> I don't know if my strategy is correct in the first place but that's=20
> what I came up with.
> When I try to run one of the test applications that came with the=20
> driver (the "testout" one) I get an errno =3D 29 (Illegal seek?! ) on=20
> the read() operations.
> So my question is whether I make the right steps in reading an address =

> on the VME bus. I know I'm missing something, so I'll be glad to get=20
> some directions as to how to be sure whether I'm reading something=20
> from the VME bus and where I'm able to write.
>
> Best regards,
> Konstantin
> ________________________________
>
> #include <stdio.h>
> #include <string.h>
> #include <errno.h>
> #include <sys/ioctl.h>
> #include <unistd.h>
> #include "vmedrv.h"
>
> int main(int argc, char* argv[])
> {
>     vmeOutWindowCfg_t outWinCfg;
>     vmeOutWindowCfg_t outWinGet;
>
>     int fdOut, status, i, j;
>     unsigned int  n;
>     u_char *rdPtr, *getPtr;
>
>     if(getMyVmeInfo()){
>       printf("getMyVmeInfo failed.\n");
>       exit (1);
>     }
>
>     fdOut =3D open("/dev/vme_m0", O_RDWR);
>     perror("open");
>     if(fdOut < 0){
>       printf("Opening /dev/vme_m0 failed. Errno =3D %d\n", errno);
>     }
>
>     memset(&outWinCfgADC, 0, sizeof(vmeOutWindowCfg_t));
>     perror("memset");
>
>     outWinCfgADC.windowNbr           =3D 0;
>     outWinCfgADC.windowEnable     =3D 1;
>     outWinCfgADC.wrPostEnable      =3D 0;
>     outWinCfgADC.userAccessType  =3D VME_SUPER;
>     outWinCfgADC.dataAccessType  =3D VME_DATA;
>     outWinCfgADC.windowSizeL        =3D 0x200000;
>     outWinCfgADC.xferProtocol         =3D VME_SCT;
>     outWinCfgADC.addrSpace           =3D VME_A24;
>     outWinCfgADC.maxDataWidth     =3D VME_D16;
>
>     status =3D ioctl(fdOut, VME_IOCTL_SET_OUTBOUND, &outWinCfgADC);
>     perror("ioctl");
>     if(status < 0){
>         printf("*** ioctl set on outWinCfgADC failed. Errno =3D %d\n", =

> errno);
>         exit (1);
>     }
>     memset(&outWinGetADC, 0, sizeof(vmeOutWindowCfg_t));
>     outWinGetADC.windowNbr =3D 0;
>
>     status =3D ioctl(fdOut, VME_IOCTL_GET_OUTBOUND, &outWinGetADC);
>     perror("ioctl");
>     if(status < 0){
>         printf("*** ioctl get on outWinGetADC failed. Errno =3D %d\n", =

> errno);
>         exit (1);
>     }
>
>     /*
>      * Check wheather the get and set configurations are the same
>      */
>
>     getPtr =3D (u_char *) mmap(0, outWinCfgADC.windowSizeL,=20
> PROT_READ|PROT_WRITE, MAP_SHARED, fdOut, 0);
>     perror("mmap");
>     printf("# Start of outbound win in virtual address space of the=20
> process: %p\n", getPtr);
>
>     rdPtr =3D getPtr;
>
>     for(i=3D0;i<0x100;i++){
>        printf("# Read at address %x =3D %x\n", rdPtr, *rdPtr);
>        rdPtr++;
>     }
>
>     status =3D close(fdOut);
>     if(status !=3D 0){
>         printf("*** close() failed. Errno =3D %d\n", errno);
>         exit (1);
>     }
>   =20
>     return 0;
> }
>
> __________________________________
> Part of the output:
>
> mmap: Illegal seek
> # Start of outbound win in virtual address space of the process:=20
> 0x30029000
> # Read at address 30029000 =3D ff
> # Read at address 30029001 =3D ff
> # Read at address 30029002 =3D ff
> # Read at address 30029003 =3D ff
> # Read at address 30029004 =3D ff
> # Read at address 30029005 =3D ff
> # Read at address 30029006 =3D ff
> # Read at address 30029007 =3D ff
> # Read at address 30029008 =3D ff
> # Read at address 30029009 =3D ff
> # Read at address 3002900a =3D ff
> # Read at address 3002900b =3D ff
>
> and etc.
> -----------------------------------------------------------------------=
-
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded

  parent reply	other threads:[~2007-03-27 11:05 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-26 15:14 Reading and writing from/to VME device Konstantin Boyanov
2007-03-26 18:31 ` Martin, Tim
2007-03-27  9:09 ` Didier Kryn [this message]
2007-03-27 12:38   ` Didier Kryn
2007-03-27 15:47   ` Konstantin Boyanov
2007-03-27 19:02     ` Martin, Tim
2007-03-28  9:56       ` Didier Kryn
2007-03-29 10:13         ` Konstantin Boyanov
2007-03-29 19:27           ` Martin, Tim
2007-03-30  9:24           ` Didier Kryn
2007-04-02  9:15             ` Didier Kryn
2007-04-02  9:21               ` Didier Kryn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4608DF55.90508@in2p3.fr \
    --to=kryn@in2p3.fr \
    --cc=kkboyanov@gmail.com \
    --cc=linuxppc-embedded@ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).