MVME2431: how to use vme?

MVME2431: how to use vme?

[Simone Piccardi]

Hi,
after many problems (thanks to G.Paubert that gave the right patch for
the kernel and D. De Ridder for the many halps on setup) I have a
running system on a MVME2431.

I can also load the universe module without problems (at least it gave
me the message: Universe VME bridge #1 found at bus=0, dev=13 that seems
OK).

Now the problem is to test VME (to be precise the real problem is that
this is my first experience with VME, so have no idea from where to
start).
I read the README.universe in the kernel source, and I tried also to use
the program vmetest.c that I found in the same directory of the kernel
patches.

The problem is that that program cannot compile, it start with an error:
testvme.c:43:  'VME_attr' undeclared ....
and then gave a lot of other errors. I suppose that this depends on some
version mismatch (I'm using kernel 2.2.6, with related patch). 

Because this is not clear to me what I have to do to access another
board (the only one that I have use some fixed address memory location
in the VME bus, and no dma). I tried to look the testvme.c code but it
use some device (like /dev/cm_mem20) that I don't have on the system and
I cannot uned

Could someone send me some other test programs, just to try to
understand the right procedure, or also give me some directions for a
good starting point?

Thank you in advance for the further help, and thanks again for the
previous one.

Bye

PS. Just  another little question, but about the system setup. I used
linuxPPC pre5 rpms, installing them by hand with rpm, up to now (after
some modification to inittab, fstab and rc.sysinit) I have a working
system; my only concern is that I can telnet to other machines (also DNS
works), but when I try to telnet to the board I get:
Trying 192.84.146.131...
Connected to vmesez1.fi.infn.it.
Escape character is '^]'.
telnetd: All network ports in use.
Connection closed by foreign host.
and the same when I do the tlent from the board itself to localhost.
It's seems that it cannot allocate new port. Up to now I do not
understand from where came the problem (inetd.conf and all the tcp
wrapper files seems OK).
Thanks again
-- 
Simone Piccardi
Microsoft is NOT the answer. Microsoft is the Question.
The answer is: "NO!"

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: MVME2431: how to use vme?

[David De Ridder]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1668 bytes --]

On Mon, 10 May 1999, Simone Piccardi wrote:

> I can also load the universe module without problems (at least it gave
> me the message: Universe VME bridge #1 found at bus=0, dev=13 that seems
> OK).

 OK.

> Now the problem is to test VME (to be precise the real problem is that
> this is my first experience with VME, so have no idea from where to
> start).
> I read the README.universe in the kernel source, and I tried also to use
> the program vmetest.c that I found in the same directory of the kernel
> patches.

> The problem is that that program cannot compile, it start with an error:
> testvme.c:43:  'VME_attr' undeclared ....
> and then gave a lot of other errors. I suppose that this depends on some
> version mismatch (I'm using kernel 2.2.6, with related patch). 

 OK, Gabriel is currently unreachable for two weeks (correct me if
 I'm wrong). So here's some advice to all VME testers : take the
 testvme.c program from Gabriel's website - make sure you have
 a patched 2.2.6 kernel -, strip the program from everything you
 think you don't need. The problem is : use ``window'' instead
 of ``attr''. I think Gabriel was using different (newer? older?)
 include files, because this solves the problem.

 You can start from my own stripped-down version (in attachment).

 Regards,

+-----------------------------------------------------------------+
   David 'Septimus' De Ridder     <david.de.ridder@bitsmart.com>

"Watching eyes wait for sadness to rise,
 true superstitions combine and thicken
 this poison that reaches my soul,
 this terror that blackens my soul."
 - Anne Clark
+-----------------------------------------------------------------+


[-- Attachment #2: Type: TEXT/PLAIN, Size: 1247 bytes --]

#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <linux/vme.h>
#include <errno.h>
#include <sys/mman.h>

#define PATTERN 0x55

#define MBUFSIZE (1<<20)
/*
static char memorymap[MBUFSIZE];
*/

int main(int argc, char *argv[])
{
	u_char *mp;
  	int fd;
	int error;
	int i, j;
	VME_window memdesc = {base:  0xd00000, 
			      limit: 0xdfffff,
			      flags: VME_AM_A24(16) | VME_USE_MAP | VME_USE_RMW
	};
	VME_atomic_access rmw = {offset: 0,
	};


	/* Open the VME device : */
	fd = open("/dev/vme",O_RDWR);
	if (fd<0) 
	{
		perror("error opening vme"); 
		exit(0);
	}

	printf("/dev/vme opened.\n");

	error = ioctl(fd, VME_SET_WINDOW, &memdesc);
	if (error)
	 perror("Failed VME_SET_WINDOW");

	error = ioctl(fd, VME_GET_WINDOW, &memdesc);
	if (error) 
	 perror("Failed VME_GET_WINDOW");

	printf("memdesc: flags %x, vme_addr %x, length %d\n", memdesc.flags,
	       memdesc.base, memdesc.limit-memdesc.base+1);

	mp = mmap(0, MBUFSIZE, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0); 
	if ((u_long)mp == -1) 
	 perror("Mmap failed with");
	else 
 	 printf("mem mapped at %p\n", mp);

	close(fd);

	return 0;
}

Re: MVME2431: how to use vme?

[Simone Piccardi]

[-- Attachment #1: Type: text/plain, Size: 1424 bytes --]

Hi David,
thanks for the file. 

This time at least I can give to you an answer: looking carefully in the
Gabriel directory I found that vmetest.c is a new file, and I discover
also that the patches were newer than the ones I used )this was the
reason of the compilation failing). I downloaded them, recompiled
everything, and I could also compile testvme.c.

I find also a new file universe.tex in /usr/src/linux/drivers/vme/ with
some more info (I'm reading it carefully in this moment).

In any case I used your program and by simply changing the "window" with
"attr" (both in VME_window than in VME_GET_WINDOW and VME_SET_WINDOW) I
could compile it on the new patches and run it without error.

The problem is in the next step, when I try to write in the remapped
region I get a bus error (probably is right, because I don't know what
that region is), but at least when I try to read I have the dataway
display showing me activities on the bus, and this is enogh for the
moment!

Now the problem is to understand how to map a board that has a fixed
address set by jumpers in this way, and I'm still very confused by all
these VME_AM... constants.
I'm sending the "improved" version of your program in attachement, the
only things that it does is to read (showing bus activity) and get a bus
error when it try to write.

Bye
-- 
Simone Piccardi
Microsoft is NOT the answer. Microsoft is the Question.
The answer is: "NO!"

[-- Attachment #2: test.c --]
[-- Type: text/plain, Size: 1425 bytes --]

#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <linux/vme.h>
#include <errno.h>
#include <sys/mman.h>

#define PATTERN 0x55

#define MBUFSIZE (1<<20)
/* static char membuf[MBUFSIZE]; */

int main(int argc, char ** argv)
{
        u_char *mp,*rp;	
  	int fd;
	int error;
	int i, j;

	VME_attr memdesc = {
	  base:  0xd00000, 
	  limit: 0xdfffff,
	  flags: VME_AM_A24(16) | VME_USE_MAP | VME_USE_RMW
	};
	VME_atomic_access rmw = {
	  offset: 0,
	};

	fd = open("/dev/vme",O_RDWR);
	if (fd < 0) {
	  perror("error opening vme"); 
	  exit(0);
	}
	printf("/dev/vme opened.\n");

	error = ioctl(fd, VME_SET_ATTR, &memdesc);
	if (error) perror("Failed VME_SET_ATTR");

	error = ioctl(fd, VME_GET_ATTR, &memdesc);
	if (error) perror("Failed VME_GET_ATTR");

	printf("memdesc: flags %x, vme_addr %x, length %x\n", memdesc.flags,
	       memdesc.base, memdesc.limit-memdesc.base+1);

	mp = mmap(0, MBUFSIZE, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0); 
	if ((u_long)mp == -1) perror("Mmap failed with");
	else printf("mem mapped at %p\n", mp);

	/* new code from testvme.c */
	printf("Try to read\n");
	rp=mp;	
	for (i=0; i<0x100; i++) {
	  j=*(rp++);	
	  printf("Read %x at %x\n",j,rp);
	  usleep(1000);
	}

	printf("Try to write \n");
	for (i=0; i<MBUFSIZE; i+= 512) {
		memset(mp+i, PATTERN, 512);
		usleep(1000);
	}
	printf("Finished \n");


	close(fd);
	return 0;
}

Re: MVME2431: how to use vme?

[David De Ridder]

At 18:27 11-5-99 +0200, Simone Piccardi wrote:

>This time at least I can give to you an answer: looking carefully in the
>Gabriel directory I found that vmetest.c is a new file, and I discover
>also that the patches were newer than the ones I used )this was the
>reason of the compilation failing). I downloaded them, recompiled
>everything, and I could also compile testvme.c.

 So, the _ATTR is in Gabriel's latest patches ?
 For which kernel version are these patches ?

>I find also a new file universe.tex in /usr/src/linux/drivers/vme/ with
>some more info (I'm reading it carefully in this moment).

 That's nice.

>In any case I used your program and by simply changing the "window" with
>"attr" (both in VME_window than in VME_GET_WINDOW and VME_SET_WINDOW) I
>could compile it on the new patches and run it without error.

 Hahahaha. *I* could not compile testvme.c because it had ATTR instead
 of WINDOW, and now *you* have the opposite problem (because *I*
 changed it).

>The problem is in the next step, when I try to write in the remapped
>region I get a bus error (probably is right, because I don't know what
>that region is), but at least when I try to read I have the dataway
>display showing me activities on the bus, and this is enogh for the
>moment!

 We're testing it on an ADC board (it measures charges, converts them
 and writes them into a register ; we read these registers). It seems
 that Gabriel's driver is working fine. Of course, we're not messing
 with interrupts and DMA...yet.

>Now the problem is to understand how to map a board that has a fixed
>address set by jumpers in this way, and I'm still very confused by all
>these VME_AM... constants.
>I'm sending the "improved" version of your program in attachement, the
>only things that it does is to read (showing bus activity) and get a bus
>error when it try to write.

 Thanks. Good luck,



+-----------------------------------------------------------------+
  David 'Septimus' De Ridder       <david.de.ridder@bitsmart.com> 

"The result of two million mad monkeys bashing randomly on
 their keyboards is known today as the Internet."
 - someone

+-----------------------------------------------------------------+
  


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: MVME2431: how to use vme?

[Simone Piccardi]

Hi David,

I spent last 3 days playing with the board, using another custom board
used to control data acquisition (it also use some registers), but
without any success. 

As first I'm currently using 2.2.6; I rebiuld my system using the new
patches, and as I said it works, at least when I use the region that is
used both in your vme.c and in testvme.c. 

I also read the universe documentation, but it was not useful. Our board
use the normal 32 bit addressing, at a fixed (it is set by some jumper)
address that is 0xDAFFE000, it is an "hand made" board, so it only check
if this address is composed on the vme bus, and in this case it give the
answer (I think it don't even control the AM lines, only the A ones); I
tried to acces to this using this definition for memdesc:

        VME_attr memdesc = {
          base: 
0xDaffe000,                                                    
          limit:
0xDaffe020,                                                    
          flags: VME_AM_A32(16) | VME_USE_MAP |   VME_USE_RMW
        };
but when I try to register such a region I get:

Failed VME_SET_ATTR: Device not configured 
(just after the ioctl call with  VME_SET_ATTR).

I don't get the error if I remove the VME_USE_MAP and  VME_USE_RMW flag,
but in this way I cannot use the mmap routine and I do not know how to
access the board. As I said if I use the modified vme.c program I can
access the bus, but it work only for A24 addressing.

The problem was that we cannot access this custom board not even from
PPCBug, it simply do not allow access to such high address (at least
without playing with the ENV setting on VME slave images, yesterday some
collegues could do it, modifying that settings, but from what I
understand the driver must use its own settings).

As for you we don't need any interrupt or dma, just to read and write
some register in the board (it has a FIFO where it store data), wa have
only to clear it writing in a control word, look in another control word
to see if data are avalaible, and then read.

I think that still I'm not undertanding how to use the driver, and I
have the sensation that I'm doing absolutely stupid things because my
ignorance about the VME. The new manual that Gabriel put in the patch
has some info but probably there is some background I'm missing. for the
moment I'm looking in the code to try to understand how it work and what
options I have to use, but this is quite complex and I have no idea of
what to do. So if you have a working program, could you send it to me?
(at least I can see how it work from the user side!).

Ah, just another thing,as I already said I have a working system on the
board, but still I'm not capable to telnet on it. I always had that "All
network port in use" error. I try to use an X terminal (X in correctly
working, I can run also the emacs in the board looking the windows from
remote) but when I try to open an xterm it say me: "no available ptys".
I'm suspecting that the problem is that I don't have no virtual consoles
avalaible (I've only ttyS0 in inittab). 
Could you telnet in your board? There is some configuration file or some
inittab entry that I miss (I removed all the tty respawning because the
errors).

Thank you
-- 
Simone Piccardi
Microsoft is NOT the answer. Microsoft is the Question.
The answer is: "NO!"

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: MVME2431: how to use vme?

[Gabriel Paubert]

On Sat, 15 May 1999, Simone Piccardi wrote:

	Hi Simone and David,

Back from holiday, it was fun :-)

> As first I'm currently using 2.2.6; I rebiuld my system using the new
> patches, and as I said it works, at least when I use the region that is
> used both in your vme.c and in testvme.c. 
> 
> I also read the universe documentation, but it was not useful. Our board
> use the normal 32 bit addressing, at a fixed (it is set by some jumper)
> address that is 0xDAFFE000, it is an "hand made" board, so it only check
> if this address is composed on the vme bus, and in this case it give the
> answer (I think it don't even control the AM lines, only the A ones); I
> tried to acces to this using this definition for memdesc:
> 
>         VME_attr memdesc = {
>           base: 
> 0xDaffe000,                                                    
>           limit:
> 0xDaffe020,

It should probably be 0xdaffe01f but does not matter.
                                                    
>           flags: VME_AM_A32(16) | VME_USE_MAP |   VME_USE_RMW
>         };
> but when I try to register such a region I get:
> 
> Failed VME_SET_ATTR: Device not configured 
> (just after the ioctl call with  VME_SET_ATTR).
> 
> I don't get the error if I remove the VME_USE_MAP and  VME_USE_RMW flag,
> but in this way I cannot use the mmap routine and I do not know how to
> access the board. As I said if I use the modified vme.c program I can
> access the bus, but it work only for A24 addressing.

That's because there is no slave image setup in the universe to access
this range of A32 space. Hopefully I shall find time to improve the
documentation and add an example: probably  in your /proc/bus/vme/regions
you have the following: 

Address space   Width and flags Range                   Device
 CR/CSR         D32,PRM         00000000-00ffffff       vme (Universe)
 A32 BLT        D32             c8000000-cbffffff       vme (Universe)
 A24 DATA       D32,PRM         00000000-00feffff       vme (Universe)
 A16            D32,PRM         00000000-0000ffff       vme (Universe)
 A24 DATA       D16,PRM         00000000-00feffff       vme (Universe)
 A16            D16,PRM         00000000-0000ffff       vme (Universe)
 A24 DATA  PRIV D32,PRM         00000000-00feffff       vme (Universe)
 A16       PRIV D32,PRM         00000000-0000ffff       vme (Universe)
 A24 DATA  PRIV D16,PRM         00000000-00feffff       vme (Universe)
 A16       PRIV D16,PRM         00000000-0000ffff       vme (Universe)

These are the areas that you may access with the CPU (actually there are
tricks to access more). What you have to do is to modify he initialization 
of the universe so that image 2 (the one which is set up by default to
access A32 BLT with D32 width) accesses your area at 0xdaffe000. 

This can be achieved by modifying the attributes and translation offset
registers for image 2 in the initialization section of the driver: 

        /* Set up an A32/D32 image with BLT for tests */
        SET_REG(0xc8000000 - universe.bus_delta, LSI_BS(2));
        SET_REG(0xcc000000 - universe.bus_delta, LSI_BD(2));
        SET_REG(universe.bus_delta, LSI_TO(2));
        SET_REG(UNIVERSE_SLAVE_EN | UNIVERSE_VAS_A32 | UNIVERSE_VDW_32 |
                UNIVERSE_BLT,
                LSI_CTL(2));

should be replaced with: 

        /* Set up an A32/D32 image with BLT for tests */
        SET_REG(0xc8000000 - universe.bus_delta, LSI_BS(2));
        SET_REG(0xcc000000 - universe.bus_delta, LSI_BD(2));
        SET_REG(universe.bus_delta + 0xd8000000 - 0xc8000000, LSI_TO(2));
        SET_REG(UNIVERSE_SLAVE_EN | UNIVERSE_VAS_A32 | UNIVERSE_VDW_32,
                LSI_CTL(2));


this will give you access to the 0xd8000000-0xdbffffff range in A32 with 
32 bit width. The reason you have to modify this is that it is
impossible to map the whole A32 VME address space through the PCI
bridge on a 32 bit processor (and that the Universe uses 32 address bits). 

A24 and A16 do not have such a limitation, even with all attributes.

This change should modify your /proc/bus/vme/regions to: 
Address space   Width and flags Range                   Device
 CR/CSR         D32,PRM         00000000-00ffffff       vme (Universe)
 A32 DATA       D32             d8000000-dbffffff       vme (Universe)
 ...

And yes, I know that the driver could use the ENV settings of PPCBug but
there are significant advantages to reprogramming the Universe at start. 
Especially if we decide to reprogram the Raven/Falcon/Hawk in CHRP mode
to enable larger addresing windows on VME which is one of my goals. 

	Gabriel.


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: MVME2431: how to use vme?

[Simone Piccardi]

Hi Gabriel,
thanks for the help, I had already found the solution looking at the
code.
My universe.c now looks like:

        /* Set up an A32/D32 image with BLT for tests */
        SET_REG(0xd8000000 - universe.bus_delta, LSI_BS(2));
        SET_REG(0xdc000000 - universe.bus_delta, LSI_BD(2));
        SET_REG(universe.bus_delta, LSI_TO(2));
        SET_REG(UNIVERSE_SLAVE_EN | UNIVERSE_VAS_A32 | UNIVERSE_VDW_32 
                /*| UNIVERSE_BLT*/ ,
                LSI_CTL(2));

that is quite the same that you say me; and it work. I have just a
question, there is any drawback to set the region addresses directly
inside the BS and BD registers, or I have to put the different offset
like you did? Has I said I'm quite new to VME, and also if now I'm
beginning to understand some things, all these addresses stuffs are
still a little bit too complex for me.

I also had to modify the VME_attr declaration as:

        VME_attr memdesc = {
          base:  0xdaffe000, 
          limit: 0xdafff000, 
          flags: VME_AM_A32(32) | VME_USE_MAP 
        };       
and in this way mmap work (I can access the board after the mmap by some
*(mp)=0x5 or val[i]=*mp); I used this declaration (a page size) way
because using limit: 0xdaffe020 make mmap not working. I'll try your
values to see if everything is OK.

A second question is about the BLT flag, as I understand is used to
enable block tranfer. Now we don't need it because the board that we use
has only a readout address that take values stored inside internal FIFO;
this lead to about 700ns to read one word, but our hardware people are
thinking about to make a new board, putting everything inside a buffer,
so if I'll had to use this how I have to read? For what I undertand
block tranfer tranfer on read a whole block of data but how can I
specify the size? 

Just a last thing, I tried to compile the driver removing the 
#undef  UNIVERSE_DEBUG
line to use debugging info, but after I did this with make modules when
it try to compile the module I get:

universe.c:856: parse error before
`{'                                          
universe.c:856: `tmp' undeclared (first use in this
function)                   
universe.c:856: (Each undeclared identifier is reported only
once               
universe.c:856: for each function it appears
in.)                               
universe.c:856: parse error before
`,'                                          
universe.c: At top
level:                                                       
universe.c:856: parse error before
`,'                                          
universe.c:857: parse error before
`:'                                          
universe.c:857: warning: type defaults to `int' in declaration of
`tmp'         
universe.c:857: `tmp' used prior to
declaration                                 

and a lot of this (line number could be different from your original
code, because I put some debugging printk inside the code), I'm missing
some other declaration?

bye 
(and thanks for writing the driver!!!)
-- 
Simone Piccardi
Microsoft is NOT the answer. Microsoft is the Question.
The answer is: "NO!"

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: MVME2431: how to use vme?

[Gabriel Paubert]

On Mon, 24 May 1999, Simone Piccardi wrote:

> 
> Hi Gabriel,
> thanks for the help, I had already found the solution looking at the
> code.
> My universe.c now looks like:
> 
>         /* Set up an A32/D32 image with BLT for tests */
>         SET_REG(0xd8000000 - universe.bus_delta, LSI_BS(2));
>         SET_REG(0xdc000000 - universe.bus_delta, LSI_BD(2));
>         SET_REG(universe.bus_delta, LSI_TO(2));
>         SET_REG(UNIVERSE_SLAVE_EN | UNIVERSE_VAS_A32 | UNIVERSE_VDW_32 
>                 /*| UNIVERSE_BLT*/ ,
>                 LSI_CTL(2));
> 
> that is quite the same that you say me; and it work. I have just a
> question, there is any drawback to set the region addresses directly
> inside the BS and BD registers, or I have to put the different offset
> like you did? Has I said I'm quite new to VME, and also if now I'm
> beginning to understand some things, all these addresses stuffs are
> still a little bit too complex for me.

In this case, the problem is not on the VME side, but on possible
conflicts in the PCI address space. A generic resource allocation layer
will hopefully appear in 2.3.x to clean up this whole mess.

Addressing VME from the processor is a complex thing and it depends
on whether you access it from kernel or user space and of the correctness
and limitations of ioremap(). 

To access VME physical address vpa, you have to generate vpa-TO(image) on
the PCI bus (TO is translation offset register of the Universe). On PreP
(default Raven/Falcon setting), you have to generate processor physical
address vpa-TO(image)+0xc0000000 but this offset is 0 on CHRP and Intel 
boards.

Then to generate this address from kernel space you had (it might have
changed in recent releases so I'll use a past tense) to manage to have
this address in the 0xc0000000-0xcfffffff range which is mapped by a BAT
making it appear in the 0xd0000000-0xdfffffff kernel virtual address range
(this was because ioremap implementation was seriously limited). 

On the other hand, to access it from user mode, it can appear at any
physical address between 0xc0000000 and 0xfcffffff (upper limit might
depend on the bridge chip) but you have to make sure that you don't
conflict with any already allocated PCI address when setting the BS and BD
registers.

The first consideration is basically the reason for which I had only
allocated 64 MB of A32 space. I wanted it to be accessible from kernel
space but I also have an S3 graphics board (PMC module) in my system;
simply sum up taking into account the 256Mb limit of mapped PCI
memory address space: 

- 64 Mb for S3
- 64 Mb for Universe special slave image (A16 and A24)
- 16 MB for VME CR/CSR space (through one Universe image)
- 64 Mb for A32 

that's already 208Mb, leaving 48Mb for all the other devices. It was
clearly impossible to raise it to the next power of 2. 

In other words, your solution will work if you never need to access your
device from the kernel. 
 
> 
> I also had to modify the VME_attr declaration as:
> 
>         VME_attr memdesc = {
>           base:  0xdaffe000, 
>           limit: 0xdafff000, 
>           flags: VME_AM_A32(32) | VME_USE_MAP 
>         };       
> and in this way mmap work (I can access the board after the mmap by some
> *(mp)=0x5 or val[i]=*mp); I used this declaration (a page size) way
> because using limit: 0xdaffe020 make mmap not working. I'll try your
> values to see if everything is OK.

True, mmap can only access pages which are wholly contained inside the 
address range you want to access. That's a security feature: actually only
the VME_SET_ATTR ioctl is privileged, so you can pass the file descriptor
and mmap it in a non privileged process to access the device. 

> A second question is about the BLT flag, as I understand is used to
> enable block tranfer. Now we don't need it because the board that we use
> has only a readout address that take values stored inside internal FIFO;
> this lead to about 700ns to read one word, but our hardware people are
> thinking about to make a new board, putting everything inside a buffer,
> so if I'll had to use this how I have to read? For what I undertand
> block tranfer tranfer on read a whole block of data but how can I
> specify the size? 

Block transfer is mostly interesting for DMA and burst writes. Actually on
VME block transfers are signaled by a different addres modifier (AM) code
on the bus. You don't tell the length: it is the number of data strobes
cycles while the address strobe is active which determines the length. The
universe will only perform block transfers exceptionally on reads: when
you perform a read which is wider than the programmed VME bus width
(reading 32 bit on VME_A32_BLT(16) for example). It will perform block
transfers on writes, especially if you enable write posting which will use
the internal FIFOs and your processor performs store gathering (PPC750 for
example). 

> 
> Just a last thing, I tried to compile the driver removing the 
> #undef  UNIVERSE_DEBUG
> line to use debugging info, but after I did this with make modules when
> it try to compile the module I get:
> 
> universe.c:856: parse error before
> `{'                                          
> universe.c:856: `tmp' undeclared (first use in this
> function)                   
> universe.c:856: (Each undeclared identifier is reported only
> once               
> universe.c:856: for each function it appears
> in.)                               
> universe.c:856: parse error before
> `,'                                          
> universe.c: At top
> level:                                                       
> universe.c:856: parse error before
> `,'                                          
> universe.c:857: parse error before
> `:'                                          
> universe.c:857: warning: type defaults to `int' in declaration of
> `tmp'         
> universe.c:857: `tmp' used prior to
> declaration                                 
> 
> and a lot of this (line number could be different from your original
> code, because I put some debugging printk inside the code), I'm missing
> some other declaration?

I've not enabled debugging for a long time, so some other changes might
have broken it. I'm going to have a look. 
[...]
Here it is, 2 missing parentheses (introduced hen I had to fight a name
clash): 
--- drivers/vme/universe.c.orig Tue May 25 12:51:12 1999
+++ drivers/vme/universe.c      Tue May 25 12:55:36 1999
@@ -138,7 +138,7 @@
 
 /* Defining this makes the initialization verbose, perhaps too verbose !
*/
 #define UNIVERSE_DEBUG
-#undef UNIVERSE_DEBUG
+//#undef UNIVERSE_DEBUG
 
 
 /* values for the state field in the private section */
@@ -471,9 +471,9 @@
  * to access in memory structures like the DMA descriptors. 
  */
 #if defined(__powerpc__) 
-#define __get_le32(addr) {u32 tmp; \
+#define __get_le32(addr) ({u32 tmp; \
                asm("lwbrx %0,0,%1" : "=r" (tmp): "r"(addr), "m"(*addr));\
-               tmp;}
+               tmp;})
 #define __put_le32(val, addr) \
        asm("stwbrx %2,0,%1": "=m"(*addr) : "r"(addr), "r"(val))
 

	Bye,
	Gabriel.


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: MVME2431: how to use vme?

[David De Ridder]

Hi everyone,

we now have Gabriel's Universe driver working with a "LeCroy ADC1182"
VME board, which is simply an ADC board with 8 channels. We generate
the sample-pulses internally on the board, with the Universe driver.
In short, there is no problem using this board to measure (different)
charges (in parallel). Operation is in A24/D16 mode.

I just thought scientific-minded people might be interested in hearing
real-world applications of the Universe driver (and Linux).

In the meantime, Simone wrote : 

> > A second question is about the BLT flag, as I understand is used to
> > enable block tranfer. Now we don't need it because the board that we use
> > has only a readout address that take values stored inside internal FIFO;
> > this lead to about 700ns to read one word, but our hardware people are
> > thinking about to make a new board, putting everything inside a buffer,
> > so if I'll had to use this how I have to read? For what I undertand
> > block tranfer tranfer on read a whole block of data but how can I
> > specify the size? 
> 
> Block transfer is mostly interesting for DMA and burst writes. Actually on
> VME block transfers are signaled by a different addres modifier (AM) code
> on the bus. You don't tell the length: it is the number of data strobes
> cycles while the address strobe is active which determines the length. The
> universe will only perform block transfers exceptionally on reads: when
> you perform a read which is wider than the programmed VME bus width
> (reading 32 bit on VME_A32_BLT(16) for example). It will perform block
> transfers on writes, especially if you enable write posting which will use
> the internal FIFOs and your processor performs store gathering (PPC750 for
> example). 

 We too would like to use block transfers. It does not work however.
 ``Device not configured'' it seems. I just changed (in the VME_window
 struct) VME_AM_A24(16) to VME_AM_A24_BLT(16).
 Unfortunately, I'm no VME expert. So, are BLTs something a VME board
 itself must support ? Or do I need to set another parameter ?

 Any input is highly appreciated,
 
+-----------------------------------------------------------------+
   David 'Septimus' De Ridder     <david.de.ridder@bitsmart.com>

"Fortunately, Hill Giants have large blind  spots in
 which a human can easily hide. Unfortunately, these
 blind spots are beneath the bottoms of their feet."
 - 'Hill Giant' (M:TG)
+-----------------------------------------------------------------+


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: MVME2431: how to use vme?

[Gabriel Paubert]

On Wed, 26 May 1999, David De Ridder wrote:

> Hi everyone,
> 
> we now have Gabriel's Universe driver working with a "LeCroy ADC1182"
> VME board, which is simply an ADC board with 8 channels. We generate
> the sample-pulses internally on the board, with the Universe driver.
> In short, there is no problem using this board to measure (different)
> charges (in parallel). Operation is in A24/D16 mode.
> 
> I just thought scientific-minded people might be interested in hearing
> real-world applications of the Universe driver (and Linux).

Indeed, note that myself and colleagues in Grenoble are going to use it
for real world data acquisition in astronomy. The driver is being written
and will use all capabilities provided by the Universe driver (except RMW
cycles): triggering DMA from a data ready interrupt, several other
interrupts for synchronization and (probably) immediate bottom halves
to handle non time critical operations when returing from interrupts
and limit interrupt latencies.

> 
> In the meantime, Simone wrote : 
> 
> > > A second question is about the BLT flag, as I understand is used to
> > > enable block tranfer. Now we don't need it because the board that we use
> > > has only a readout address that take values stored inside internal FIFO;
> > > this lead to about 700ns to read one word, but our hardware people are
> > > thinking about to make a new board, putting everything inside a buffer,
> > > so if I'll had to use this how I have to read? For what I undertand
> > > block tranfer tranfer on read a whole block of data but how can I
> > > specify the size? 
> > 
> > Block transfer is mostly interesting for DMA and burst writes. Actually on
> > VME block transfers are signaled by a different addres modifier (AM) code
> > on the bus. You don't tell the length: it is the number of data strobes
> > cycles while the address strobe is active which determines the length. The
> > universe will only perform block transfers exceptionally on reads: when
> > you perform a read which is wider than the programmed VME bus width
> > (reading 32 bit on VME_A32_BLT(16) for example). It will perform block
> > transfers on writes, especially if you enable write posting which will use
> > the internal FIFOs and your processor performs store gathering (PPC750 for
> > example). 
> 
>  We too would like to use block transfers. It does not work however.
>  ``Device not configured'' it seems. I just changed (in the VME_window
>  struct) VME_AM_A24(16) to VME_AM_A24_BLT(16).
>  Unfortunately, I'm no VME expert. So, are BLTs something a VME board
>  itself must support ? Or do I need to set another parameter ?

By defaut the SLSI is used for VME A24 and A16 transfers. If you don't
need the VME A32 image which is enabled by default with BLT mode as an
example in the driver, you can just reprogram slave image 2 to use 
VME_AM_A24_BLT. 

However, this is not very interesting in itself since reads done using
standard PIO accesses will only use block transfers if you perform 
a 32 bit reads and the burst will only be for 2 channels. Only DMA can
efficiently use BLT.

But you can nevertheless try it, replace:

        /* Set up an A32/D32 image with BLT for tests */
        SET_REG(0xc8000000 - universe.bus_delta, LSI_BS(2));
        SET_REG(0xcc000000 - universe.bus_delta, LSI_BD(2));
        SET_REG(universe.bus_delta, LSI_TO(2));
        SET_REG(UNIVERSE_SLAVE_EN | UNIVERSE_VAS_A32 | UNIVERSE_VDW_32 |
                UNIVERSE_BLT,
                LSI_CTL(2));
#endif /* UNIVERSE_IMAGE_SETUP */

with something like: 

        /* Set up an A24/D16 image with BLT for tests */
        SET_REG(0xc8000000 - universe.bus_delta, LSI_BS(2));
        SET_REG(0xc9000000 - universe.bus_delta, LSI_BD(2));
        SET_REG(universe.bus_delta - 0xc8000000, LSI_TO(2));
        SET_REG(UNIVERSE_SLAVE_EN | UNIVERSE_VAS_A24 | UNIVERSE_VDW_16 |
                UNIVERSE_BLT,
                LSI_CTL(2));
#endif /* UNIVERSE_IMAGE_SETUP */

and it should work (have a look at /proc/bus/vme/regions: the A32 BLT
region should be transformed into an A24 BLT one).   

Now I have a RFC: 

Right now I have allocated an experimental major number (60) with minor 0
for /dev/vme and other vme devices use the same major with a different
minor. I am not sure that this is the best solution (TM) since it can make
things quite confusing: with only 8 bit minors and the variety of VME
boards available (often home made for research purposes), no 2 systems
will have the same numbering and you have to keep the drivers in sync with
the contents of /dev entries (you can have either automatic module loading
or dynamic minor allocation, but I've been unable to find a way to get
both at the same time, so for now none has been implemented).  Furthermore
this may create a large number of entries in /dev which increases the risk
of name clashes.

So I was considering the following change: give /dev/vme a fixed minor
among the miscellaneous character devices (this should not be a problem)
and when you need the services of a specific driver, you would have
to open /dev/vme and then use an ioctl specifying the name of the
board specific drivber which would override the standard /dev/vme
behaviour. 

It would have the following advantages: 
- only one entry in /dev: /dev/vme with a well known major/minor
combination allocated forever in the linux kernel.
 
- no potential name clashes in /dev

- name based resolution is more robust than the system dependant minor
list (of course 2 people can still choose the same name, but they are
likely to be on 2 completely different systems). 

- automatic module loading seems fairly easy to implement in the ioctl
code (without any need to add aliases in /etc/conf.modules)
(for now this feature has not been implemented at all).

- all the preceding makes the vme patch much less intrusive into the linux
kernel, which was one of my primary goals.

The only small drawbacks I see is that it is slightly more complex to
program, and it will still delay further the release of the documentation.

Comments ? 

	Gabriel.


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]