From: rws@cs.brown.edu (Richard W. Sabourin)
Subject: Re: OSK... how to access vme bus -- MVME147
Organization: Brown University Department of Computer Science
Date: Wed, 7 Oct 1992 15:09:11 GMT

In article <1992Oct6.205444.16684@cs.brown.edu> I wrote:
>
>Can someone who uses OS-9 (2.4, bundled C compiler) on the MVME 147SA-1 or
>similar cpu send me a basic example of how to do reads and writes to a
>device on the VME bus?? No interrupts need to be handled.
>Advice is needed quickly, so please mail me.
>

I received the following very helpful reply:


    Date: Wed, 7 Oct 92 09:17:13 BST
    From: "G.J.Milne" <G.J.Milne@uk.ac.daresbury>
    Message-Id: <9210070817.AA04558@gserv1>
    To: rws@cs.brown.edu
    Subject: Re: OSK... how to access vme bus -- MVME147

    Hi!

    >Can someone who uses OS-9 (2.4, bundled C compiler) on the MVME 147SA-1 or
    >similar cpu send me a basic example of how to do reads and writes to a
    >device on the VME bus?? No interrupts need to be handled.

    If your system uses the system security module (SSM) then things can get a
    bit complicated. If not, then things are really easy.

    NO-SSM
    Merely load a pointer with the address of the device you wish to
    control on the VME bus and stick values into it as follows:

    char * p = 0x00900000;  /* Set up device address        */
    *p = 10;                /* Write to device              */
    a = *p;                 /* Read from device             */

    It could not be any easier could it?

    WITH SSM
    The SSM is a wonderful piece of software designed to stop people doing
    the above ... actually it was designed to stop people trashing other
    processes.

    If you want to run the SSM then you must make it think you have access
    to the memory you want to control. The way you do this is via a
    system-state call (F$Permit and F$Protect). Below I have reporduced a
    Microware Application Note that will allow you to do this.

    There are now many newer OS-9 systems which have the System
    Security Module (SSM) installed, particularly 68030 systems. One
    frequent problem which users find is that User-State programs can
    no longer access memory areas outside of programs and data space,
    such as dedicated I/O devices or shared RAM.

    The recommended method for such access is to delegate it to
    System-State code such as a Device Driver or OS(p2 module, since
    such code has full access to all addresses. However, it is
    recognised that this is not always feasible, and it is now possible
    for User-State processes owned by group 0 (super-user) to select
    specific address ranges to be permitted or denied access.

    This facility is available under SSM edition #24 or greater (OS-9
    V2.3), by calling the F$Permit and F$Protect system functions. The
    following bindings allow them to be called from C programs.

    *	permit (addr, len, perm) /* grant access */
    *	void * addr;
    *	int  len;
    *	int  perm;
    permit:
    link 	a5,#0
    movem.l	d1-d2/a0,-(sp)
    movem.l	a2,-(sp)
    movea.l	d0,a2		start address to allow
    move.l	d1,d0		length of allow
    move.l	24(sp),d1	permission required (read/write/exec)
    os9	F$Permit
    movem.l	(sp)+,a2
    bra	_sysret

    *	protect (addr, len)	/* deny access	*/
    *	void * addr
    *	int  len;
    protect:
    link	a5,#0
    movem.l	d1-d2/a0,-(sp)
    movem.l	a2,-(sp)
    movea.l	d0,a2		start address of deny
    move.l	d1,d0		length of deny
    os9	F$Protect
    movem.l	(sp+),a2
    bra	_sysret

    These routines should be assembled using r68 and included at link
    time. The would be calledby the process requiring special access to
    certain addresses, e.g.

    #define IOPORT ((char *) 0xffffe030)
    #define DPRAM  ((char *) 0xff008000)
    #define DPEND  ((char *) 0xff00a000)
    #define READ   1
    #define WRITE  2
    .
    .
    permit (IOPORT, 1, READ);
    permit (DPRAM, DPEND-DPRAM, READ|WRITE)
    .
    port = *IOPORT;
    .
    DPRAM[100] = char_value;

    Remember that you might need to use "fixmod" to make sure your
    user-state program is owned by group 0.

    Alternatively, compile you program as the super-user. Changing the
    ownership of the file in which a user-state program is located does
    not change the ownership of the executable program.

    Finally, I run the SSM on my system. I, however, wrote a device driver
    to do my VME bus accesses since I had to deal with interrupts. Having
    said that, I know someone here (SERC Daresbury Laboratory, UK) who uses
    the first solution by commenting the SSM out of the bootlist file. The
    second solution is preferable because you cannot trash another process
    with an errant pointer.

    Ciao!

    Gordon

    S.E.R.C. Daresbury Laboratory, Warrington, WA4 4AD, United Kingdom.
    e-mail     : g.j.milne@dl.ac.uk (INTERNET)  g.j.milne@uk.ac.daresbury (JANET)
    Opinions expressed are my own, not necessarily those of my employer!