VME user-level device driver

[Ted Wilcox]

In <1990Oct5.001111.21349 at cs.uoregon.edu> brent at greylady.uoregon.edu (Brent Baker) writes:


>I've added the following line to /usr/sysgen/master.d/mem
>{NBPP,	0xbd00b000, },

Looks good so far.

>we have another driver that uses a page at 0xbd00a000 so I just took the
>next page. I've also tried using a page at 0xbd100000, because that is the 

Right.  The difference is whether you want supervisory or non-priveleged
bus accesses.  Most boards will respond to either.

>other address the manual reccommends fo VME-bus 16 bit addressing. And of
>course I run lboot and then reboot and all that jazz to invoke the new
>version of mem.

>My call to open and mmap is:
>	Fd = open("/dev/mmem", O_RDWR);
>	Addr = mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, Fd, 0xbd00b000);
>And indeed I get back a value. This is running of a PI-20, and the address
>is always 0x600000.

Also, good so far.

>When I try to read from the device via:
>	value = (unsigned char)(*(Addr + x));
>where x is 0 to 503, (the range our device places values in) it always crashes.
>I've used the cast (unsigned short) as well. The error I get in the console 
>window is:
>    Bus Error: Parity Error Bits: 0x0: physaddr: 0x9E34  (or 0x9D18 sometimes)

Ok.  The last time I saw this error, I was trying to do 32bit accesses to
a board that only accepts 16bit accesses.  I'd suggest trying a few type
casts that affect the size of accesses you're making to the board.  For
example:

value = *((uchar *)Addr + x);
or
value = *((ushort *)Addr + x);

Note that in the second one, the address will actually be (int)Addr + 2x.

Another thing to try is to access the board directly from the prom monitor
(the ">>" prompt you get if you select "5" when booting).  You could try
"g -b 0xbd00b0??" or "g -h 0xbd00b0??" to read from board registers.

>I've used dbx and it always crashes on the lbu instruction (load byte unsigned)
>that loads from the address Addr (plus whatever) into a register. 
>If you have any suggestions you can respond to this posting, or send
>it to: brent at chemiris.uoregon.edu. Thanks.

I hope this helps.
		   
                   
Ted.               
ted at sgi.com