Are the wizards on vaca ? (was: SCO UNIX SysV device driver)

[michael k finegan]

>    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).
    This problem I figured out - vas...() returns an user address, not a kernel
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.

					Thanks,
						Michael K. Finegan, Jr.
						mfinegan at uceng.UC.EDU

Please reply via EMAIL {as well as | instead of} any post.