Path: utzoo!attcan!uunet!samsung!munnari.oz.au!csc.anu.oz.au!csc3.anu.oz.au!anucsd!arp!peterf
From: peterf@arp.anu.oz.au (Peter Fletcher)
Newsgroups: comp.unix.sysv386
Subject: AT&T unix V 3.2.2 device drivers
Message-ID: <1990Sep17.084302.2350@arp.anu.oz.au>
Date: 17 Sep 90 08:43:02 GMT
Organization: Automated Reasoning Project, ANU, Australia
Lines: 65

Hello,

I have a PC-AT compatible running AT&T's UNIX V/386 Release 3.2 upon which I am
developing a device driver.  The driver is for a Data Translation DT 2853 frame
grabber.  I cannot access the Frame Grabber's memory directly, but I have no 
trouble with the control and status registers.  Here is some of the critical
information relating to the problem:

1. In AT&T's Integrated Software Development Guide I found the following line in
the sdevice description, " SCMA..(Start Controller Memory Address) is used by
controllers that have internal memory. ... This field must be within 0xa0000 and
0xfbfff."  I also found a matching description for ECMA (End Controller Memory 
Address).  I assume from this description that devices with memory can reside
directly on the AT memory bus, but that they must be configured to reside within
0xa0000 and 0xfbfff. 

Question a. Is this an 80386 segment or offset?  
	 b. Must I access it using assembler so as to avoid virtual memory 
	    problems?  
	 c. This range seems so limited, am I missing something?  My device has
	    a .5 meg buffer supposedly directly accessible.

2. In the DT 2853 manual I have found a table of strappings for various blocks of
.5 meg address ranges.  The manual suggests I set the memory base address at 
something greater than 0x100000, which appears to me to be outside the range 
specified as available to the AT&T unix driver, unless the AT&T range is denoted
in segments not offsets.  The factory configured setting is oxa00000.

Question d. Is this a horrible oversite on the designers of v386 unix, a mis-
	    understanding on my part, simply that I cannot use DT 2853s with
	    this unix, all or none of the above.  
	 e. These memory ranges seem wildly different to me, what is going on?

3. The sdevice file entry looks like:
   fg	Y	1	5	1	10	230	24F	a00000	a7ffff
   ^    ^       ^	^	^	^	 ^	 ^	   ^	   ^
   |    |	|	|	|	|	 |	 |	   |	   |   
device  |       |       |       |       |        |       |         |       |
configure       |       |       |       |        |       |         |       |
subdevices------|       |       |       |        |       |         |       |
ipl---------------------|       |       |        |       |         |       |
type (req int. line)------------|       |        |       |         |       |
interrupt vect #------------------------|        |       |         |       |
I/O Base Address---------------------------------|       |         |       |
I/O Base address-----------------------------------------|         |       |
SCMA---------------------------------------------------------------|       |
ECMA-----------------------------------------------------------------------|

If I attempt to access the device's memory with this entry in the sdevice table,
I can do file system damage.  If I enter 0 for both SCMA and ECMA then I don't
crash the file system, but in neither case do I read or write the device memory.
Note that SCMA and ECMA are both well out of the range specified in the AT&T
developer's guide mentioned earlier. ( 0xa0000 - oxfbfff ).  

While I am not a complete ignoramus when it comes to device drivers, I am stumped
here, and hoping that someone out there sees this as a painfully trivial prob-
lem and is willing to pass that knowledge on to me.  

If you need more technical details ask away.


Regards,


David Keightley davidk@csis.dit.csiro.au