[comp.unix.questions] *HELP* needed on device driver

lasala@svax.cs.cornell.edu (Steve LaSala) (05/13/89)

        I'm looking for any comments people may have on a pretty thorny problem.

        I'm trying to write a driver to run under SunOS 4.0, for a board
which has each register on a different page of memory.  Their bus addresses
differ by something on the order of 0x10000000.  I'm not quite sure how to
"address" this, but my current attempt is to declare that the board needs
'n' pages of virtual memory, which will presumably be allocated adjacent to
each other (is this so?).  Then, I'll add the offset for the next register
to the base (the address of the first register), which was specified in the
'config' file as the bus address of the board.  Will this work?  Do I have to
'decode' the 'base vaddr', add, and then re-encode?
        The more immediate problem is simply finding the board, which my 'probe'
routine seems to be unable to do.  The correct bus address (0x20000000) is being
correctly transferred from 'config' to the 'mb_device' structure in 'conf.c',
but when I print out the argument to 'probe', it seems to be vaddr 0xF0F20000.
This does not seem to be in 32d32 space, as it should be, else the prefix would
be 0xFC.  I cannot see any way to relate this vaddr to the real paddr, though I
have tried all the mappings discussed in the Sun driver manual.
        Am I way off the track here?  Do the page tables get set up before
'probe' routines are called?  (I should think so.)  Can anybody tell me about
the insides of the autoconf process?  Is there a better way to go about this?
        I should mention that the hardware seems to be working correctly.  I
am able to read and write the on-board memory from the PROM monitor.
        Any and all suggestions are profusely appreciated.  PLEASE RESPOND BY
MAIL, as I don't usually get to read these groups.

                                        Steve LaSala, cucs

p.s.  I took a guess as to where to post this.  Sorry if it clutters up
        the wrong space.