From: stevek@gobi.UUCP (Stephen Kogge)
Newsgroups: comp.unix.wizards,alt.unix.wizards
Subject: Re: SBus device driver questions
Date: 13 Aug 92 01:06:47 GMT
Organization: Underwater Imaging


	I have been working on a Bit3 to Multibus device driver. Not
finished yet...

In article <1997@tycho.UUCP> coltoff@tycho.UUCP (Joel Coltoff) writes:
>
>I'm attempting to write a loadable device driver for a Sparc Station
>SBus adapter. It isn't one that we designed so there is a suprise
>here and there. It's a Bit3 card for a remote VME bus. The driver
>actually controls the cards in the remote VME backplane. At least
>for now they are all the same type If anyone has done this and would
>like to share their experiences I'd be happy to listen.
>
>The first set of problems deals with addresses. The adapter card
>has a set of registers at offset 0x200000. At offset 0x1000000
>is the area that maps to the remote VME bus. I've walked the devinfo
>tree a little bit but can't seem to get at the base address of the
>Sbus card. Am I going to get burned by doing the following to get
>the base address of my VME cards?
>
>	u_int * bit3_addr;
>
>	bit3_addr = (caddr_t) devinfo_p->devi_reg->reg_addr;  
>	bit3_addr = (caddr_t) ((u_int) bit3_addr & ~(0x200000));  
>	bit3_addr = (caddr_t) ((u_int) bit3_addr | 0x1000000);
>

	The Multibus and VME systems look the same from the
Sun/bit3/sbus side.

	You will need to have two kernel mapped regions. One for the
bit3 control registers and the other for your VME memory space.
No problem with the control region, but the memory region presents
problems for the kernel.

	Sun only lets the kernel map in 8 (I think it is only 8) meg max
so you cannot just map in the entire VME space.  My first attempts
tried to just map in all 16meg of my Multibus space, it took a while
to realize that this approach would not work.
	The solution is to set up the sbus card to map in say 64k and use the
bit3 map registers to look into any part of the VME space.
	Problems:
	1) you have to lock the bit3/sbus/VME map register so that a second
	call does not change it out from under you. You do your IO
	to your IO VME memory registers mapped via the bit3 "map".
	2) to transfer data between the VME and the Sun you change the bit3
	"map" and do a "bcopy". Again you will need to lock the sbus
	bit3 "map" with software.
	3) The user is allowed to map in the entire VME (multibus)
	space but to do so you will have to change those bit3 mapping
	registers, again the code that allows these changes must remember
	what the kernel set them to.

	Messy no matter how you do it. Time keeps me from finishing
my driver. Simple user mmaps lets me get away with fake drivers from
user code == motivation to get the driver done is low. I sure would
like the interrupts to work ;-)

>Secondly, I'd like to be able to use as much of the Sun VME driver
>as possible. However, that deals with virtual addresses and what
>I get from above is a physical address. I know that you can use
>map_regs() to get a virtual address but that's where my knowledge
>ends. The Sun SBus driver manual shows an example driver that
>when unloaded does an unmap_regs(). Is the unmap_regs() strictly
>necessary? This is important becuase if it is I can't jam the return
>value of map_regs() into a automatic variable. Is there another approach
>to doing this? Physical memory is contiguous but what about mapped
>virtual memory? Given the word "map" in the function calls I would be
>surprised if it is.
>

	Remember that this is a kernel routine and each map_regs() uses
resources and you really ought to unmap them else after a few "loads"
of your driver you will use up all the kernel map resources.

>Lastly, at least for now, is there anything that falls in the category
>of EVERY NOVICE SBUS DEVICE DRIVER WRITER FORGETS TO DO THIS?
>
>	Thanks,
>	  - Joel Coltoff
>	  tycho!coltoff@cs.widener.edu


	Maybe it's is time to start annoying Chris Torek again and finish
up my bit3-multibus driver. I got a lot more done when he was in Maryland and
came over to watch Quantum leap.

	Steve Kogge
	stevek@uimage.com
Newsgroups: comp.unix.wizards