SCO UNIX SysV device driver (is the manual correct?)
michael k finegan
I have written a device driver for a graphics board. It PANICS the
system on the first access to graphics board memory. I have followed
the suggestions of the SCO Device Driver Writer's Guide, and suspect
that some of the info. is incorrect. No, I can't call SCO, as I am
waiting for authorization to get software support (~$500).
For those with familiarity: I check to see if the physical address
is being used with a call to vasmapped(). It isn't. I then allocate
virtual address space using vasmalloc(). This returns fine. I then
bind the physical address to the virtual address using vasbind(). This
also returns successfully. On access to the physical memory via
bcopy(vaddr,caddr_t,number), I get a panic, with vaddr being the contents
of one of the registers (esi?) displayed by the panic (actually a trap 0x...E).
I have tried sptalloc(), with provisions for not swapping page (PG_P), ...
I have also tried every other possible way to access physical memory with no
success. I/O accesses (outb) work fine, and I suspect that the 'memory' access
described in the Device Driver Writer's Guide may actually refer to memory
mapped I/O, which means that my memory accesses are being converted to outb's ?
The device driver examples in the book, or on disk (in the directory
/usr/lib/samples/pack.d/*), have zero examples of physical memory access.
A previous device driver (for another graphics board, but same O.S)
worked for one type of physical memory access: copyio(paddr,caddr,number,R_?UD).
Did this work because the board allowed I/O access to memory ? I know the
current board's memory is not accessible via I/O.
Any ideas would be appreciated. It is probably a misunderstanding, on my
part, of the manual - but it really shouldn't be so difficult ...
Thanks,
Michael K. Finegan, Jr.
mfin...@uceng.UC.EDU
Please reply via EMAIL {as well as | instead of} any post.
michael k finegan
>is being used with a call to vasmapped(). It isn't. I then allocate
>virtual address space using vasmalloc(). This returns fine. I then
>bind the physical address to the virtual address using vasbind(). This
>also returns successfully. On access to the physical memory via
>bcopy(vaddr,caddr_t,number), I get a panic, with vaddr being the contents
>of one of the registers (esi?) displayed by the panic (actually a trap 0x...E).
address. Thus the panic (apparently page fault ?). I also tried just translating
my desired address 0xC0000 to a virtual address, and then binding the virtual
address to the physical address with vasbind(); but the virtual address would
be in kernel virtual address space, and so vas...() cannot be used. :-(
> I have tried sptalloc(), with provisions for not swapping page (PG_P), ...
>I have also tried every other possible way to access physical memory with no
>success. I/O accesses (outb) work fine, and I suspect that the 'memory' access
>described in the Device Driver Writer's Guide may actually refer to memory
>mapped I/O, which means that my memory accesses are being converted to outb's ?
I am now sure that this just does i/o space addressing ...
> The device driver examples in the book, or on disk (in the directory
>/usr/lib/samples/pack.d/*), have zero examples of physical memory access.
Well, almost zero - scsi..() and vid...() translate physical addresses to
virtual addresses, but the page swapping side-stepping is done behind the back.
(i. e. they don't show/talk about it) I tried this: page fault ==> panic. :-(
>A previous device driver (for another graphics board, but same O.S)
>worked for this physical memory access: copyio(paddr,caddr,number,R_?UD).
>Did this work because the board allowed I/O access to memory ? I know the
>current board's memory is not accessible via I/O.
No, it wasn't i/o accessing. There must be some use of 0xD0000 by the
kernel, as this driver worked, and yet did not page fault! This board also
only decoded 20 bits of address, and the Unix virtual addresses happen to be
identical except for the high order nibble/byte (at least for the two
addresses I have tried) ...
> Any ideas would be appreciated. It is definitely NOT a misunderstanding, on
> my part, of the manual. It really shouldn't be so difficult ...
Is the idea that if you are really serious about writing a device driver,
you would be willing to pay SCO's outrageous training fee - fly out to CA
for a class, at which time the instructor either can't help you, or says that
the details were left out of the manual intentionally ? I think I may switch
to Xinu soon ...
I realize that the 'kernel' library for SCO Unix 386 is apparently different
from other kernel support (according to the book Unix Papers, which has very
different routines ...). But surely there is a standard way to access physical
memory, with no page swapping, no matter what the address is, or flavor of Unix.
Guy Harris
>But surely there is a standard way to access physical
>memory, with no page swapping, no matter what the address
>is, or flavor of Unix.
No, there isn't. Next question....
michael k finegan
Next question:
What is ONE way ... i.e. any example is better than NO example.
Are the flavors of SysV that different, or are you referring to Sys7 (BSD) ?
Thanks,
Mike Finegan
Guy Harris
I'm referring to all of the above. SunOS 4.x is different from BSD is
different from 3B2 S5R3 as shipped by AT&T is different from S5R4 is
different from....
There is, for example, no "vasmapped()" nor "vasmalloc()" nor
"vasbind()" routine in 3B2 S5R3 as shipped by AT&T, at least according
to the "grep" that I just did. There is an "sptalloc()", but I don't
know that there is one in S5R4 (I wouldn't be surprised if there
weren't); the S5R4 VM subsystem is quite different from the S5R3 one
(it's derived from the SunOS 4.x one).
("Sys7", by which I presume you mean V7, and 4BSD are also pretty
different; the former, as AT&T sent it out, doesn't do paging and
supports the PDP-11 MMU, while the latter supports paging and supports
the VAX and now CCI 6/32 MMU.)
Really, there are limits to how "generic" the interface the kernel
provides to a device driver is; there's no answer for "UNIX", but there
is probably an answer for SCO System V, and it may even be similar to
the answer for other S5R3.2-based 386 UNIXes. You might ask in
"comp.unix.i386" instead....