From owner-freebsd-questions Mon Apr 14 19:51:46 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA07787 for questions-outgoing; Mon, 14 Apr 1997 19:51:46 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA07781 for ; Mon, 14 Apr 1997 19:51:43 -0700 (PDT) Received: from iworks.InterWorks.org (deischen@iworks.interworks.org [128.255.18.10]) by who.cdrom.com (8.8.5/8.6.11) with ESMTP id TAA01819 for ; Mon, 14 Apr 1997 19:47:23 -0700 (PDT) Received: (from deischen@localhost) by iworks.InterWorks.org (8.7.5/) id VAA15380; Mon, 14 Apr 1997 21:47:41 -0500 (CDT) Message-Id: <199704150247.VAA15380@iworks.InterWorks.org> Date: Mon, 14 Apr 1997 21:47:41 -0500 (CDT) From: "Daniel M. Eischen" To: krygier@kph.uni-mainz.de, questions@freebsd.org Subject: Re: special memory device Sender: owner-questions@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > 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