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

    Sorry, I was wrong about my second point, mmap: MAP_SHARED works=20
fine and anyway seems more reasonable than MAP_PRIVATE. I just made=20
A24/D16 transfers, with a sequence similar to yours.
    Good luck.
    Didier

Didier Kryn a =E9crit :
>     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 use=
s=20
> 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 =

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

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

> *. If you configure your interface for D16, you must perform D16 access=
=2E=20
> For example, you might do the following:
>
> unsigned short *rdPtr;
> ...
> 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 =

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

> 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 byt=
e=20
> 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 :
>  =20
>> 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=
=20
>> 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 =

>> I'm actually reading something on the VME, i.e. which addresses respon=
d.
>> 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=
=20
>> 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() =

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

>> succeed in reading 0 bytes, and when I try to read in chunks from the =

>> VME bus i get errno 22 on reads like read(fd, buffer, 1024) for exampl=
e.
>>
>> 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 =

>> the read() operations.
>> So my question is whether I make the right steps in reading an address=
=20
>> 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",=
=20
>> 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",=
=20
>> 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
>>    =20
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>  =20

  reply	other threads:[~2007-03-27 12:39 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
2007-03-27 12:38   ` Didier Kryn [this message]
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=46091060.4000500@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).