Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 14 Apr 1997 21:47:41 -0500 (CDT)
From:      "Daniel M. Eischen" <deischen@iworks.InterWorks.org>
To:        krygier@kph.uni-mainz.de, questions@freebsd.org
Subject:   Re: special memory device
Message-ID:  <199704150247.VAA15380@iworks.InterWorks.org>

next in thread | raw e-mail | index | archive | help

> Perhaps some one of you can give me some hints to solve following problem
> with FreeBSD:
>
> I am using an ISA-VMEbus interface which allows access to VMEbus hardware
> by a FreeBSD-PC. For the PC it is a conventional ISA card which occupies
> 64 KB at the physical address 0xd0000. It is very easy to access this
> memory location and by this parts of the VMEbus using /dev/mem and mmap().
> Everything works fine. But now the problem:
>
> For our applications a memory window of 64 KB is to small. We need access
> to several megabytes. The interface allows to move this window to any
> location in the VMEbus address space. But for that purpose special
> programming is needed which is not acceptable in our case because we
> want to use exisiting software which can't be rewritten. This software
> uses the interface of SunOS/Solaris where a special memory device (e.g.
> /dev/vmed16a24) can be mmaped and allows in a very simple way memory
> mapped i/o on the complete VMEbus from any user applicaiton.
> 
> Now I want to install a similar device which is compatible to the Sun
> solution. It will never be used by read/write i/o but only by mmaped i/o.
> It shall be able to do a dynamic remapping of the VMEbus window every time
> an address is accessed which is out of the current 64 KB window using the
> page fault mechanism. Is this possible? Unfortunately I found no solution
> of a similar problem in any existing device driver of FreeBSD. Are there
> any other examples? What's about documentation of kernel software?

This might be better answered on -hackers.

I also want to do similar things with a Pentium Single Board Computer
with a PCI<->VME bridge chip.  The bridge chip acts like a normal
PCI device and allows you to use memio/port IO to access it's registers,
but you've got to be able to map 16MB chunks of PCI address space to
the VMEbus.  This isn't something that can be automatically detected
at probe time by our current PCI code, AFAIK.                       

This bridge chip, a Tundra Universe (docs fully available from
www.tundra.com), allows up to 5 PCI slave images.  One of these
is a special PCI slave image that maps 4 consecutive 16Mbyte 
regions of the VMEbus.  The Tundras registers allow you to map
any 64MB PCI address space to any 64MB VME space when using this
special slave image.  My intent is to also create the /dev/vmed16a16
and /dev/vmed16a24 devices (and driver, obviously) so that you 
mmap/read/write to the VMEbus through the special slave image.

The problem I have, is that if I create a driver for this chip,
how do I ask the PCI support code for 4 consecutive 16MB regions
of the PCI bus?  From what I can tell, the PCI code will only let
you map an address space as it is defined in the PCI configuration
space registers.  For the Tundra Universe chip, the registers
that configure the special PCI slave image are not in the PCI         
configuration space.  

This bridge chip also lets one catch VMEbus interrupts and
generates a PCI interrupt.  The PCI interrupt handler can then
check the registers of Universe to find out what the VMEbus
interrupt priority and acknowldge were.

This is going to be one of my pet projects when I get some time.
We've got a few of these Pentium PCI/VME boards at work, and
expect to be doing some FreeBSD development on them sometime in
the next few months.  We've also got a few Force Technologies
SPARC SBCs with SBUS<->VMEbus interface chips.  Force supplied
a VME nexus driver for Solaris which uses the /dev/vmed16a16,
/dev/vmed16a24, and /dev/vmed32a32 which you also mention above.
I'd like to model a FreeBSD driver after the Force driver, at
least for the mem mapping.

Dan Eischen
deischen@iworks.InterWorks.org



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704150247.VAA15380>