DR11-W to Model-1/20 on 4.1 BSD - (nf)
rpw3 at fortune.UUCP
rpw3 at fortune.UUCP
Sun Dec 18 02:05:28 AEST 1983
#R:osu-dbs:-42800:fortune:11600029:000:5624
fortune!rpw3 Dec 17 01:44:00 1983
(I also hate DMA devices, Patrick!) The following technique may prove
helpful to someone.
We hooked a 4.1 VAX to another (guess which) machine using a DR-11C,
and the most useful thing was a little peek/poke program that used
/dev/kUmem to bang the registers before the driver was ever written.
***WARNING*** If you do this, make DAMN SURE you don't
***WARNING*** turn on the interrupt enable bits by
***WARNING*** mistake. (Crash, tinkle, tinkle,...)
Having gotten that to work (without ever crashing anything -- didn't
mean to scare you, just to warn), and therefore knowing the hardware
path and the other end were o.k., the next thing was to write the
more-or-less complete driver and check it out in user mode (as
subroutines to the peek/poke program), using the following trick:
Your driver will have a struct which describes the registers, and
a register variable that will hold the address of the registers
at run time, so that you read data with "x = dr->dr_Rdata", for
example. (See any UNIX driver.)
When debugging in user mode, you make 'dr' point to an actual
data struct in your program, which your driver code cheerfully
reads and writes just as if it were the real hardware registers.
[Here's the trick] At "appropriate" places in the driver, put
macros called (for example) DR_GET and DR_PUT which read and
write "/dev/kUmem" into/out-of the in-core copy. ("Appropriate"
means whenever you need a change manifested from/to the outside
world, see example, below.) After you have successfully gotten
the driver algorithms debugged, the macro definitions get
nulled, and you drop the driver into the kernel.
This was so successful that we only had to take the system down three
times: one to install the board, and twice to boot new kernels
(yes, there was one bug left, dammit, having to do with the squirrily
4.1 "auto-config").
Needless to say, the same technique was also used on the other machine,
which in fact never went to a kernel driver since that machine had a
version of the old "phys()" system call. The hardware was just mapped
into user space, avoiding the kUmem reads and writes.
<<FLAME ON>> I would not have bothered on the VAX, either, but
4.1 gave me no easy (or possible?) way to map the UNIBUS
addresses into user virtual space. With a "phys"-equivalent,
and a reasonable scheduler, most device-driver writing (and
therefore system downtime) for random hack devices can be
avoided. <<FLAME OFF>>
Fine points:
1. You will need to know the /dev/kUmem address for your board, which
can be gotten by looking at the addresses printed out by some other
device's "probe" routine. If needed, write a stub driver to print it
out. (I never figured out how to predict it from the config. in 4.1.)
2. The kUmem version of our link ran at about 600 transfers/sec (each
GET (or PUT) was one seek and one read (or write)), while the driver version
ran at about 20-25000/sec, since it touched memory directly. <<FLAME ON/OFF>>
3. Extending the approach to handle (pseudo)interrupts is a little more
work, but not impossible. The test-bed program just has to continually
do GET's until the status changes, and then call the interrupt routine.
(But I don't have a strong enough heart or a weak enough mind to
try it on DMA!)
Good luck!
Rob Warnock
UUCP: {sri-unix,amd70,hpda,harpo,ihnp4,allegra}!fortune!rpw3
DDD: (415)595-8444
USPS: Fortune Systems Corp, 101 Twin Dolphins Drive, Redwood City, CA 94065
-------- edited (censored) excerpts from the user-mode version --------------
/* hack to test dr11 through kUmem */
typedef struct dr11c_s {
short dr_csr;
unsigned short dr_Tdata;
unsigned short dr_Rdata;
} dr11c_t;
dr11c_t dr_; /* local copy, to avoid so many kUmem accesses */
dr11c_t *dr = &dr_; /* so it looks like the production pointer code */
#define DR_KVADDR 0x800e0ff8 /* address in kernel through kUmem */
/* WILL VARY BY SYSTEM */
/*
* These routines update the in-memory copy
*/
#define DR_GET dr_rd();/* update local copy from kUmem */
#define DR_PUT dr_wr();/* flush local copy back to kUmem */
dr_rd()
{
lseek(dr_fd,DR_KVADDR,0);
if(read(dr_fd,(char *)dr,6) != 6){ /* **HACK** machine dependent */
printf("[ dr_rd failed!]\n");
exit(1); /* aaaUUUUgah, die! die! */
}
}
dr_wr()
{
lseek(dr_fd,DR_KVADDR,0);
dr->dr_csr &= ~(DR_IENABA | DR_IENABB); /* make no waves! */
if(write(dr_fd,(char *)dr,6) != 6){ /* **HACK** machine dependent */
printf("[ dr_wr failed!]\n");
exit(1);
}
}
int dr_fd; /* fildes for kUmem */
main(argc,argv,env)
int argc;
char **argv, **env;
{ int i, val, addr, tseq, rseq, otseq, orseq;
if( (dr_fd = open("/dev/kUmem",2)) < 0) {
printf("[ can't get kUmem!\n");
exit(1);
}
DR_GET /* see what's out there */
connect(); /* try to connect */
transfer(); /* move the data */
disconnect(); /* ensure orderly end */
}
connect()
{ int i;
DR_GET
dr->dr_data = PK_RESET; /* try out connection with a reset */
DR_PUT /* Go! */
for(i = PK_INITTO; i > 0; i--){
DR_GET
if(
(dr->dr_data == PK_RESET)
) break;
else sleep(1);
}
if(i <= 0){
dr->dr_Tflag &= ~DR_CFLG;
DR_PUT
printf("[ Initial connection attempt failed!]\n");
exit(1);
}
printf("[ Connect]\n");
}
transfer()
{
int tikto;
register int c;
dr->dr_Tdata &= ~DR_CFLG; /* start sending data */
DR_PUT
while((c = getchar()) != EOF){
tikto = 5000;
while(1){
DR_GET
"if dr->Rdata looks ready, break;"
if(--tikto < 0)
sleep(1);
}
dr->dr_Tdata = c;
dr->dr_Tdata ^= DR_TSEQ;
DR_PUT
}
}
---------------- end of edited excerpt ----------------
More information about the Comp.unix.wizards
mailing list