1301 lines
42 KiB
Plaintext
1301 lines
42 KiB
Plaintext
Linux VME Howto
|
||
John Huggins and Michael Wyrick, vmelinux@va.net
|
||
$Revision: 1.4 $, $Date: 2002/02/12 19:11:51 $
|
||
|
||
This document came about to show the embedded system community how to
|
||
run Linux on their VMEbus Pentium and other PCI local bus based VMEbus
|
||
processor designs. The latest version is always available at Linux
|
||
VME HOWTO <http://howto.vmelinux.org/>.
|
||
______________________________________________________________________
|
||
|
||
Table of Contents
|
||
|
||
|
||
|
||
1. Introduction
|
||
|
||
1.1 Knowledge Required
|
||
1.2 Why use Linux on VMEbus systems?
|
||
1.3 Purpose
|
||
1.4 Feedback
|
||
1.5 VMELinux Revision History
|
||
1.6 Copyright/Distribution
|
||
|
||
2. Installation of the VMELinux Kernel Driver
|
||
|
||
2.1 Download the Source
|
||
2.2 Install the source to the software
|
||
2.3 Compile the VMELinux components
|
||
2.4 Load the VMELinux Kernel Module
|
||
2.5 Difficulties
|
||
|
||
3. How to talk to the VMEbus with the VMEUtils and the VMEShell Packages
|
||
|
||
3.1 What is the VMEUtils program
|
||
3.2 What are the VMEShell Scripts
|
||
3.3 The "vmemap" command.
|
||
3.4 Read Byte, Word or Long
|
||
3.5 Write Byte, Word or Long
|
||
3.6 Read the VMEbus to a file
|
||
3.7 Write a file to the VMEbus
|
||
3.8 Parameters
|
||
3.9 Options
|
||
3.10 A Note about DMA mode.
|
||
|
||
4. How to talk to the Tundra Universe PCI-VME bridge using the devices drivers.
|
||
|
||
4.1 The device drivers used with VMELinux
|
||
4.2 VMEMaster Device Drivers
|
||
4.3 VMESlave Device Drivers
|
||
4.4 Direct Control of the Universe Registers
|
||
4.5 read()
|
||
4.6 write()
|
||
4.7 lseek()
|
||
4.8 ioctl()
|
||
4.9 open() and close()
|
||
|
||
5. Advantages of the VMEbus, Linux and VMELinux
|
||
|
||
5.1 Pin and socket connectors
|
||
5.2 Eurocard assembly
|
||
5.3 Linux is Low Cost
|
||
5.4 Linux is Stable
|
||
5.5 Linux is Dynamic
|
||
|
||
6. Current and planned Board Support
|
||
|
||
6.1 Xycom XVME655 Pentium VMEbus Board
|
||
6.2 XyCom XVME656 Pentium VMEBus Board
|
||
6.3 Dynatem DPC1-0367
|
||
6.4 SBS/Or Computer VP7
|
||
6.5 DY4 179, A Power PC board
|
||
6.6 Planned Board Support
|
||
|
||
7. Other "Linux on VME" Projects
|
||
|
||
7.1 Project List
|
||
7.2 Major Device Numbers
|
||
|
||
8. Conclusion
|
||
|
||
9. FAQ
|
||
|
||
9.1 The Shell utilities return a bunch of stars (*) when I access a board I know is there. What gives?
|
||
9.2 The Shell utilities still return a bunch of stars (*) when I access a board I know is there. Now what?
|
||
9.3 The Shell utilities still return a bunch of stars (*) when I access a board I know is there. HELP?
|
||
9.4 How does VMELinux handle interrupts?
|
||
9.5 I have RedHat 5.1 and can't get VMELinux programs to compile.
|
||
9.6 I have RedHat 6.x so I assume the above issue is fixed. Right?
|
||
9.7 When will your ca91c042 Tundra Universe driver support the 2.4 kernels?
|
||
9.8 Hey! The Universe II has eight master and eight slave images. You support four each. Why?
|
||
9.9 How can we contribute to your VME-LINUX working group?
|
||
|
||
|
||
______________________________________________________________________
|
||
|
||
1. Introduction
|
||
|
||
1.1. Knowledge Required
|
||
|
||
Using Linux on an embedded VMEbus processor board is not difficult.
|
||
However, more than fundamental knowledge is required. This document
|
||
is not a primer on how to fully configure a Linux machine.
|
||
|
||
|
||
In order to understand this HOWTO document it is assumed that you are
|
||
thoroughly familiar with the following:
|
||
|
||
|
||
<20> Configuring and compiling a Linux kernel to operate the various
|
||
peripherals on your board. Kernel-HOWTO
|
||
<http://www.linuxdoc.org/HOWTO/Kernel-HOWTO.html>
|
||
|
||
<20> Setting up and configuring of network devices NET HOWTO
|
||
<http://www.linuxdoc.org/HOWTO/Net-HOWTO/index.html>
|
||
|
||
<20> Setting up of inetd NET HOWTO <http://www.linuxdoc.org/HOWTO/Net-
|
||
HOWTO/index.html>
|
||
|
||
<20> Setting up and use of the Tundra Universe PCI to VME Bridge Chip
|
||
Tundra Universe <http://www.tundra.com/page.cfm?TREE_ID=100361>.
|
||
The new VMEUtils program makes knowledge of the Universe
|
||
unnecessary for those who do not wish to deal with register level
|
||
Universe access.
|
||
|
||
<20> Compiling and installing various network packages like Apache Site
|
||
<http://www.apache.org/> Wu-Ftpd FAQ
|
||
<http://www.cetis.hvu.nl/~koos/wu-ftpd-faq.html>
|
||
|
||
<20> The VMEbus Rev. D and VME64. Excellent information may be found at
|
||
the VMEbus International Trade Association (VITA)
|
||
<http://www.vita.com/>.
|
||
|
||
If you are uncertain of how to proceed with any of the above it is
|
||
STRONGLY recommended that you use the links provided to familiarize
|
||
yourself with all packages. We may not reply to any mail regarding any
|
||
of the above. Please direct any questions to the appropriate author
|
||
of the HOWTO or consult the respective hardware manufacturer.
|
||
|
||
This document describes the installation and use of VMELinux on a
|
||
Xycom XVME-655 6U VME processor board. Other brands of VME boards that
|
||
use a Pentium and the Tundra Universe chip should be capable of
|
||
running VMELinux. Please consult the Board Support Section of the
|
||
VMELinux web site for tested boards. VMELinux Project Web Site
|
||
<http://www.vmelinux.org/>
|
||
|
||
|
||
1.2. Why use Linux on VMEbus systems?
|
||
|
||
Operating systems for VMEbus computers are usually Real-time Operating
|
||
Systems (RTOS) which have high cost and a significant learning curve.
|
||
In return the RTOS offers quick response to real world events for
|
||
control of machinery or response to a process.
|
||
|
||
The VMEbus provides a rugged computer enclosure and interconnection
|
||
system. Many system integrators require this ruggedness and also need
|
||
very fast real-time response. However, there are many times when
|
||
there is little need for real-time response, but the software still
|
||
needs:
|
||
|
||
<20> networking capability,
|
||
|
||
<20> remote access via telnet or similar program,
|
||
|
||
<20> file transfer via FTP or similar programs,
|
||
|
||
<20> remote booting via BOOTP or similar method,
|
||
|
||
<20> a way to respond to system interrupts.
|
||
|
||
Linux has all these capabilities. Thus, the VMELinux Project
|
||
exists.
|
||
|
||
|
||
|
||
1.3. Purpose
|
||
|
||
The purpose of VMELinux is to give the VME system integrator another
|
||
choice in operating systems. Rich in features, high in reliability and
|
||
low in cost, Linux offers benefits to the embedded computer industry.
|
||
High cost operating systems economically prohibit the use of VME in
|
||
many applications. With Linux and the VMELinux drivers, the rugged
|
||
VMEbus has new possibilities.
|
||
|
||
The purpose of the VMELinux Project is to:
|
||
|
||
<20> Maintain and improve the free VMELinux Kernel Driver software,
|
||
|
||
<20> Offer added value software components such as the VMEUtils program
|
||
and VMEShell utilities.
|
||
|
||
<20> Test the software on various makes and brands of manufacturer
|
||
supplied VME processor boards,
|
||
|
||
<20> Maintain web based documentation on each tested brand and make of
|
||
boards,
|
||
|
||
<20> Maintain this HOWTO.
|
||
|
||
<20> Integrate user suggested and user supplied improvements into the
|
||
virgin code so we may all benefit from the programming talents of
|
||
others.
|
||
|
||
<20> Become the original source for all the above software so VMELinux
|
||
users can be assured of original code from the authors.
|
||
|
||
|
||
1.4. Feedback
|
||
|
||
As VMELinux is tested in the field, we encourage comments about how
|
||
well or how bad it works. Please feel free to send comments to The
|
||
VMELinux Project <mailto:vmelinux@va.net>
|
||
|
||
As we get experience about each brand of VME CPU, we will list the
|
||
different configurations in this HOWTO. For now we will describe only
|
||
the Xycom board.
|
||
|
||
|
||
1.5. VMELinux Revision History
|
||
|
||
This document's revision is $Revision: 1.4 $, $Date: 2002/02/12
|
||
19:11:51 $.
|
||
|
||
The latest version is always available at Linux VME HOWTO
|
||
<http://howto.vmelinux.org/>.
|
||
|
||
Linux Kernel Driver
|
||
|
||
<20> November 1997, v0.2 - Initial version on Xycom Board
|
||
|
||
<20> December 1997, v0.3 - Useable version used for actual work with
|
||
project.
|
||
|
||
<20> February 1998, v0.6 - DMA mode added to VME access modes.
|
||
|
||
<20> June, 1998, v0.8 - Fixed a few things to allow the new VMEUtils to
|
||
work.
|
||
|
||
<20> June 24, 1998, v0.8a - Last version for the 2.0.x kernels
|
||
|
||
<20> April 18 2000, v0.95 - First version for the 2.2.x kernels
|
||
|
||
<20> October 16, 2000, v1.00a - Release for the 2.2.x kernels
|
||
|
||
<20> April 23, 2001, v1.01a - Same as 1.00a, but with the new device
|
||
major number 221.
|
||
|
||
<20> October 16, 2001, v1.1 - Our first release with support for 2.4 and
|
||
2.2 kernels.
|
||
|
||
<20> October 25, 2001 - All version numbers restructured to make more
|
||
sense. What was version 1.1 is now 1.2.0. Development tree
|
||
started at 1.3.0 which includes support for eight images.
|
||
|
||
<20> February 11, 2002, More work done on ca91c042.c driver code
|
||
available from the CVS respository.
|
||
|
||
VMEUtils Program
|
||
|
||
<20> February, 1998, v0.6 - Created a command line interpreter to access
|
||
the VMEbus
|
||
|
||
<20> June, 1998, v0.8 - Fixed several issues to allow VMEShell Utilities
|
||
to function
|
||
|
||
<20> June 24, 1998, v0.8a - Previous working release.
|
||
|
||
<20> April 2000, v0.95 - Pretty much the same as before. Better install
|
||
instructions.
|
||
|
||
VMEShell Utilities
|
||
|
||
<20> June, 1998, v0.8 - Created command line utilities that allow access
|
||
to the VMEbus from the Linux shell prompt. These shell programs
|
||
interface with the VMEUtils program.
|
||
|
||
<20> June 24, 1998, v0.8a - Changed the name of all the shell programs
|
||
so they all begin with "vme." Current version made available on
|
||
the website.
|
||
<20> April 2000, v 0.95 - Improved installation scripts.
|
||
|
||
|
||
1.6. Copyright/Distribution
|
||
|
||
This document is Copyright 1997-2002 by John Huggins and the VMELinux
|
||
Project.
|
||
|
||
|
||
A verbatim copy may be reproduced or distributed in any medium
|
||
physical or electronic without permission of the author. Translations
|
||
are similarly permitted without express permission if it includes a
|
||
notice on who translated it. Commercial redistribution is allowed and
|
||
encouraged; however please notify The VMELinux Project
|
||
<mailto:vmelinux@va.net> of any such distributions.
|
||
|
||
|
||
Excerpts from the document may be used without prior consent provided
|
||
that the derivative work contains the verbatim copy or a pointer to a
|
||
verbatim copy.
|
||
|
||
|
||
Permission is granted to make and distribute verbatim copies of this
|
||
document provided the copyright notice and this permission notice are
|
||
preserved on all copies.
|
||
|
||
|
||
In short, we wish to promote dissemination of this information through
|
||
as many channels as possible. However, we wish to retain copyright on
|
||
this HOWTO document, and would like to be notified of any plans to
|
||
redistribute this HOWTO.
|
||
|
||
|
||
2. Installation of the VMELinux Kernel Driver
|
||
|
||
2.1. Download the Source
|
||
|
||
Download the distribution from the VMELinux Web Site
|
||
<http://www.vmelinux.org/>.
|
||
|
||
|
||
2.2. Install the source to the software
|
||
|
||
Place the file in your source directory; We suggest /usr/src. Untar
|
||
the zipped/tarred file by typing...
|
||
|
||
tar -xzf VMELinux_1.3.x.tar.gz
|
||
|
||
|
||
|
||
Then:
|
||
|
||
cd vmelinux
|
||
|
||
|
||
You should see three directories:
|
||
|
||
ca91c042
|
||
vmeshell
|
||
vmeutils
|
||
|
||
|
||
|
||
In ca91c042 you should find:
|
||
|
||
|
||
ca91c042/
|
||
ca91c042/Makefile
|
||
ca91c042/ca91c042.c
|
||
ca91c042/ca91c042.h
|
||
ca91c042/README
|
||
ca91c042/e
|
||
ca91c042/ins
|
||
ca91c042/stat
|
||
ca91c042/uns
|
||
|
||
|
||
|
||
In vmeshell you should find:
|
||
|
||
vmeshell/vmer
|
||
vmeshell/README
|
||
vmeshell/vmeseek
|
||
vmeshell/cmd.vme
|
||
vmeshell/vmew
|
||
vmeshell/vmeregw
|
||
vmeshell/vmeregr
|
||
vmeshell/vmefa
|
||
vmeshell/vmecall
|
||
vmeshell/e
|
||
vmeshell/ec
|
||
vmeshell/fa.vme
|
||
vmeshell/map.vme
|
||
vmeshell/tmp.vme
|
||
vmeshell/vmedb
|
||
vmeshell/vmedl
|
||
vmeshell/vmedw
|
||
vmeshell/vmemap
|
||
vmeshell/vmerb
|
||
vmeshell/vmerf
|
||
vmeshell/vmerl
|
||
vmeshell/vmerw
|
||
vmeshell/vmewb
|
||
vmeshell/vmewf
|
||
vmeshell/vmewl
|
||
vmeshell/vmeww
|
||
vmeshell/makelinks
|
||
|
||
|
||
|
||
In the vmeutils directory you should find:
|
||
|
||
vmeutils/commands.cpp
|
||
vmeutils/commands.h
|
||
vmeutils/universe.h
|
||
vmeutils/Makefile
|
||
vmeutils/vmeutils.h
|
||
vmeutils/unilib.h
|
||
vmeutils/unilib.cpp
|
||
vmeutils/vmeutils.cpp
|
||
vmeutils/README
|
||
|
||
|
||
|
||
2.3. Compile the VMELinux components
|
||
|
||
Enter the "ca91c042" directory and make the VMELinux device driver
|
||
module.
|
||
|
||
make
|
||
|
||
|
||
Now you must create the several /dev driver files. Type:
|
||
|
||
make devices
|
||
|
||
|
||
|
||
DON'T FORGET TO MAKE THE /dev/vme* DEVICES!!!
|
||
|
||
Once made, you should see the file "ca91c042.o" in the directory.
|
||
This is a loadable module. See below for loading information. Plus,
|
||
you should find several "vme..." files in the /dev directory. Here is
|
||
how the files should look:
|
||
|
||
hostname:/dev# ls -l vme*
|
||
crw-rw-rw- 1 root root 221, 8 Jul 30 10:51 vme_ctl
|
||
crw-rw-rw- 1 root root 221, 0 Jul 30 10:51 vme_m0
|
||
crw-rw-rw- 1 root root 221, 1 Jul 30 10:51 vme_m1
|
||
crw-rw-rw- 1 root root 221, 2 Jul 30 10:51 vme_m2
|
||
crw------- 1 root root 221, 3 Jul 30 10:51 vme_m3
|
||
crw-rw-rw- 1 root root 221, 4 Jul 30 10:51 vme_m4
|
||
crw-rw-rw- 1 root root 221, 5 Jul 30 10:51 vme_m5
|
||
crw-rw-rw- 1 root root 221, 6 Jul 30 10:51 vme_m6
|
||
crw------- 1 root root 221, 7 Jul 30 10:51 vme_m7
|
||
hostname:/dev#
|
||
|
||
|
||
|
||
Change to the "vmeutils" directory and type make there.
|
||
|
||
make
|
||
|
||
|
||
|
||
This will compile the "vmeutils" program. This program directly
|
||
speaks to the kernel driver. It is a reference work for those of you
|
||
who wish to write your own programs to directly speak with the driver.
|
||
|
||
Copy the program "vmeutils" to your user binary directory or let the
|
||
makelinks script do this for your in the next step. On our system
|
||
this is "/usr/local/bin." Alternatively, you can create a link in the
|
||
user bin directory to the "vmeutils" program.
|
||
|
||
Change to the "vmeshell" directory. There are no files to be compiled
|
||
here. These are shell programs that use the "vmeutils" program to
|
||
access the VMEbus. All the files beginning with "vme" should with
|
||
have a link made or be copied to the "/usr/local/bin" directory.
|
||
|
||
just type:
|
||
|
||
./makelinks
|
||
|
||
|
||
|
||
Have a look in the libvme directory for a C++ example on how to
|
||
communicate with the driver. You can use the libvme code as your
|
||
interface to the driver for your programs if you wish. Docmentation
|
||
for this is planned for the future.
|
||
|
||
You are now ready to try the driver.
|
||
|
||
|
||
2.4. Load the VMELinux Kernel Module
|
||
|
||
Make sure you are root and insert "load" the VMELinux Kernel Module
|
||
for the Universe chip by typing...
|
||
|
||
insmod ca91c042
|
||
|
||
|
||
|
||
Or just type "./ins" to let the shell script do this for you. Once
|
||
complete, type...
|
||
|
||
./stat
|
||
|
||
|
||
|
||
or
|
||
|
||
more /proc/ca91c042
|
||
|
||
|
||
You should see a list of registers displayed on your screen. Some<6D>
|
||
thing like this...
|
||
|
||
Universe driver info:
|
||
Control Pointer = 0000
|
||
Stats reads = 0 writes = 0 ioctls = 0
|
||
LSI0_CTL = 00800000 LSI1_CTL = 00800000
|
||
LSI0_BS = C0000000 LSI1_BS = 00000000
|
||
LSI0_BD = C0010000 LSI1_BD = 00000000
|
||
LSI0_TO = 40009000 LSI1_TO = 00000000
|
||
LSI2_CTL = 00800000 LSI3_CTL = 00800000
|
||
LSI2_BS = 00000000 LSI3_BS = 00000000
|
||
LSI2_BD = 00000000 LSI3_BD = 00000000
|
||
LSI2_TO = 00000000 LSI3_TO = 00000000
|
||
image_va0 = 00000000 image_va1 = 00000000
|
||
image_va2 = 00000000 image_va3 = 00000000
|
||
|
||
Driver Program Status:
|
||
DMACTL 0 = 00000000 DMACTL 1 = 00000000
|
||
DMACTL 2 = 00000000 DMACTL 3 = 00000000
|
||
OkToWrite 0 = 0 OkToWrite 1 = 0
|
||
OkToWrite 2 = 0 OkToWrite 3 = 0
|
||
Mode 0 = 0 Mode 1 = 0
|
||
Mode 2 = 0 Mode 3 = 0
|
||
|
||
|
||
If not, something went wrong.
|
||
|
||
2.5. Difficulties
|
||
|
||
The Universe driver does a good job of finding the Universe chip on a
|
||
PCI bus, but differences in board design may prevent this. We tested
|
||
all our routines on a Xycom XVME-655, Dynatem DPC and SBS VP7. There
|
||
is little reason why this should not work on any other Intel board
|
||
with a PCI bus and the Universe PCI-VME bridge chip. If you encounter
|
||
problems, please let us know at the The VMELinux Project Bug Reporter
|
||
<http://bugs.vmelinux.org/>
|
||
|
||
|
||
3. How to talk to the VMEbus with the VMEUtils and the VMEShell Pack<63>
|
||
ages
|
||
|
||
3.1. What is the VMEUtils program
|
||
|
||
This program can be run as is. Once started, you will see a command
|
||
prompt. Type ? And you will see a list of commands. While useful, I
|
||
think you will find the VMEShell scripts a better way to go. They do
|
||
use this program to speak with the kernel driver so it is necessary to
|
||
have this program available in the current PATH.
|
||
|
||
The source code for "vmeutils" is also instruction on how to speak
|
||
directly to the kernel driver. For those of you who wish to create
|
||
programs that directly speak with the driver, these source files are
|
||
good examples.
|
||
|
||
3.2. What are the VMEShell Scripts
|
||
|
||
The VMEShell programs are unix shell scripts. They offer the operator
|
||
a simple way to access the data on a VMEbus. Using these commands
|
||
creates temporary files in the user's working directory which store
|
||
information on the last access you did. This is nice because it will
|
||
be possible to log off the machine, log back in and proceed from where
|
||
you left off without having to re-enter VMEbus information again.
|
||
Plus, these files are stored in the current working directory, so you
|
||
can have different VME access configuration just by setting up
|
||
different directories for each VME board of interest.
|
||
|
||
Assuming you placed the shell programs and the "vmeutils" program in
|
||
the /usr/local/bin directory, you should be able to log in as a
|
||
regular user and run them. What follows assumes exactly this.
|
||
|
||
3.3. The "vmemap" command.
|
||
|
||
Login as a regular user and create a directory to experiment with.
|
||
Once in this directory type:
|
||
|
||
vmemap
|
||
|
||
|
||
You should get a help screen like this...
|
||
|
||
Usage: map address count space size type
|
||
where address is VME Address to set Universe image to
|
||
|
||
Space = 0 CR/CSR Space = 1 A16
|
||
Space = 2 A24 Space = 3 A32
|
||
|
||
Size = 1 8 bit Size = 2 16 bit
|
||
Size = 3 32 bit Size = 4 64 bit
|
||
|
||
Type = 0 USR/DATA Type = 1 USR/PRG
|
||
Type = 2 SUP/DATA Type = 3 SUP/PRG
|
||
|
||
|
||
This is where you tell VMELinux how you want to access the VMEbus. We
|
||
assume you already know about the VMEbus' many modes of operation, but
|
||
here is a short list to help you.
|
||
|
||
<20> address is the actual VMEbus address you wish to see. This should
|
||
be set to the lower most value of the address range of interest.
|
||
|
||
<20> count is the number of bytes you consider a valid range to view.
|
||
This is the number of bytes starting at the address specified
|
||
above.
|
||
|
||
<20> space is the addressing space (mode). For those of you who do not
|
||
know what we are talking about here, the VMEbus has four
|
||
overlapping address spaces that can be called independent of each
|
||
other. A16 is a 64 Kilobyte space. A24 is a 16 Megabyte space.
|
||
A32 is a 4 Gigabyte space. There is an A64 space defined the VME
|
||
specification, but the Universe does not support it.
|
||
|
||
<20> Size refers to the maximum data width allowed for the VME board you
|
||
are accessing. Some VMEbus board only handle 8 bit data paths.
|
||
Others transfer 32 bits (four bytes) at a time. Some can handle a
|
||
special VME block mode which can move 64 bits per transaction. The
|
||
Universe can handle all these modes allowing you to mix inexpensive
|
||
serial port boards with hugh memory arrays.
|
||
|
||
<20> Type is the type of VME transaction performed. Some VME boards
|
||
make a distinction between "User" access (USR) and "Supervisor"
|
||
access (SUP). Also, some boards allow access to two "pages" of
|
||
memory: Program (PRG) and Data. The Universe supports all modes.
|
||
|
||
Typing...
|
||
|
||
vmemap 0x8000 0x100 1 2 0
|
||
|
||
|
||
sets up the VMELinux driver to access an A16 board at base address
|
||
8000 Hex with a range of 100H bytes with 16 bit data width and
|
||
USR/DATA mode.
|
||
|
||
You will find two new files in your current directory.
|
||
|
||
<20> fa.vme
|
||
|
||
<20> map.vme
|
||
|
||
fa.vme stores a "fixed adder" value that will be added to all
|
||
subsequent accesses with the programs below.
|
||
|
||
map.vme store the parameters above so you do not have to enter them
|
||
every time.
|
||
|
||
All the following shell utilities read values from these two files to
|
||
performs VME accesses.
|
||
|
||
|
||
3.4. Read Byte, Word or Long
|
||
|
||
Syntax:
|
||
|
||
<20> vmerb -options address size
|
||
|
||
<20> vmerw -options address size
|
||
|
||
<20> vmerl -options address size
|
||
|
||
3.5. Write Byte, Word or Long
|
||
|
||
Syntax:
|
||
|
||
<20> vmewb -options address value
|
||
|
||
<20> vmeww -options address value
|
||
|
||
<20> vmewl -options address value
|
||
|
||
3.6. Read the VMEbus to a file
|
||
|
||
Syntax:
|
||
|
||
<20> vmerf -options address size filename
|
||
|
||
3.7. Write a file to the VMEbus
|
||
|
||
Syntax:
|
||
|
||
<20> vmewf -options address filename
|
||
|
||
|
||
3.8. Parameters
|
||
|
||
There are several parameters used with these commands: address, size
|
||
and filename.
|
||
|
||
<20> address - The actual hexadecimal VMEbus address you wish to read.
|
||
If the map command is set to access A16 VME address space, the
|
||
address should be 0xABCD. If the space is A24 then use 0xABCDEF.
|
||
For A32 space use 0xABCDEFGH.
|
||
|
||
<20> size - The number of bytes to read. This value is always the
|
||
number of bytes regardless of the data word size read. For
|
||
example, if you want to read 16 bytes of information and use vmerl,
|
||
the display will show 16 bytes displayed as 4 long words.
|
||
|
||
<20> filename - The name of the file to send "read" VMEbus data to or
|
||
"write" VMEbus data from.
|
||
|
||
<20> value - a hex value written as "0xXXXX."
|
||
|
||
3.9. Options
|
||
|
||
Available options are defined with a single dash with the any
|
||
combination of the following:
|
||
|
||
<20> q - Hides details on the access to the vmeutils program (default)
|
||
|
||
<20> Q - Shows details on the access to the vmeutils program
|
||
|
||
<20> p - Single access PCI addressing mode (opposite of d) (default)
|
||
|
||
<20> d - DMA access PCI addressing mode (opposite of p) (very fast
|
||
access to the VMEbus)
|
||
|
||
<20> 0, 1, 2, or 3 - Which Universe chip "Image" to use (defaults to 0)
|
||
|
||
<20> b - binary mode off (default)
|
||
|
||
<20> B - binary mode on
|
||
|
||
<20> v - turn off verbose parameter printing (default)
|
||
|
||
<20> V - turn on verbose parameter printing to see how the driver is
|
||
begin used
|
||
|
||
3.10. A Note about DMA mode.
|
||
|
||
VMELinux offers access to all the features of the Universe Chip.
|
||
Especially useful is access to the DMA engine on the chip. With this
|
||
feature the Universe chip transfers data on the PCI bus by becoming a
|
||
PCI master. This is nice, but the real benefit comes from the VMEbus
|
||
accesses. Even if the VMEbus interface is not using block mode
|
||
transfers, the Universe chip can complete VMEbus transfers under 400
|
||
nanoseconds sustained. This is the direct result of the Universe
|
||
taking complete control of both the PCI bus and the VMEbus. Thus, it
|
||
is possible to access non block mode VMEbus peripherals much faster
|
||
than older technologies.
|
||
|
||
|
||
4. How to talk to the Tundra Universe PCI-VME bridge using the
|
||
devices drivers.
|
||
|
||
4.1. The device drivers used with VMELinux
|
||
|
||
|
||
|
||
<20> /dev/vme_ctl
|
||
|
||
<20> /dev/vme_m0
|
||
|
||
<20> /dev/vme_m1
|
||
|
||
<20> /dev/vme_m2
|
||
|
||
<20> /dev/vme_m3
|
||
|
||
<20> /dev/vme_m4
|
||
|
||
<20> /dev/vme_m5
|
||
|
||
<20> /dev/vme_m6
|
||
|
||
<20> /dev/vme_m7
|
||
|
||
4.2. VMEMaster Device Drivers
|
||
|
||
/dev/vme_m* are drivers used to access the VMEbus as a bus master.
|
||
|
||
The Universe chip offers the programmer eight VMEMaster windows to the
|
||
VMEbus. These windows are called Images. The details of the
|
||
registers within these windows is beyond the scope of this Howto.
|
||
Please refer to the Universe documentation for details. Tundra
|
||
Universe <http://www.tundra.com/>
|
||
|
||
Version 1.1 of our tools only supported the first four images. This
|
||
is because we originally designed this to work with the original
|
||
Universe device. When the Universe II became available, Tundra did
|
||
not update their documentation. Thanks to reports from other Universe
|
||
users we are now aware of the new images, have found and downloaded
|
||
the latest Universe manual from Tundra and have added these images to
|
||
the 1.3.0 release.
|
||
|
||
4.3. VMESlave Device Drivers
|
||
|
||
The Universe chip offers the programmer four (eight for the
|
||
UniverseII) VMESlave windows to the VMEbus. These windows are called
|
||
Images. The details of the registers within these windows is beyond
|
||
the scope of this Howto. Please refer to the Universe documentation
|
||
for details. Tundra Universe <http://www.tundra.com/>
|
||
|
||
We originally intended to support the Universe's slave mode. We never
|
||
had a need for this thus our efforts concentrated solely on using the
|
||
Universe as a VME master only. So for 1.3.0 and the near future, we
|
||
will not support the eight slave images.
|
||
|
||
I'll repeat this for clarity. Slave VME modes are not yet supported
|
||
by our VMELinux Universe Kernel driver.
|
||
|
||
4.4. Direct Control of the Universe Registers
|
||
|
||
/dev/vme_ctl allows read and write access to the Universe registers.
|
||
|
||
For experienced users, this device allows direct access to the
|
||
Universe chip's internal registers. Explanation of these registers
|
||
and what they do is beyond the scope of this howto. Please consult the
|
||
Universe documentation available from Tundra Universe
|
||
<http://www.tundra.com/Tundra/unidex.html>
|
||
|
||
4.5. read()
|
||
|
||
n = read(vme_handle,buf,len);
|
||
|
||
Where:
|
||
|
||
<20> vme_handle = The value returned by "open,"
|
||
|
||
<20> buf = pointer to data block,
|
||
|
||
<20> len = number of bytes to read from the VMEbus.
|
||
|
||
4.6. write()
|
||
|
||
write(vme_handle,buf,len);
|
||
|
||
Where:
|
||
|
||
<20> vme_handle = The value returned by "open,"
|
||
|
||
<20> buf = pointer to data block,
|
||
|
||
<20> len = number of bytes to write to the VMEbus.
|
||
|
||
4.7. lseek()
|
||
|
||
lseek(vme_handle,vme_pnt,Seek_Type);
|
||
|
||
Where:
|
||
|
||
<20> vme_handle = The value returned by "open,"
|
||
|
||
<20> vme_pnt = The actual VME address to access,
|
||
|
||
<20> Seek_Type = SEEK_SET or SEEK_CUR
|
||
|
||
4.8. ioctl()
|
||
|
||
ioctl(vme_handle, command, argument);
|
||
|
||
Where:
|
||
|
||
<20> vme_handle = The value returned by "open,"
|
||
|
||
<20> command = IOCTL_SET_CTL or IOCTL_SET_MODE or IOCTL_SET_BS or
|
||
IOCTL_SET_BD or IOCTL_SET_TO
|
||
|
||
<20> argument to be sent
|
||
|
||
And:
|
||
|
||
<20> IOCTL_SET_CTL = Sets the image CTL register to argument. Argument
|
||
must be 32 bits.
|
||
|
||
<20> IOCTL_SET_MODE = "MODE_DMA" or "MODE_PROGRAMMED" - Sets the mode by
|
||
which the Universe chips communicates to the PCI bus (Not VME Block
|
||
Mode)
|
||
|
||
<20> IOCTL_SET_BS = Sets the image BS register to arguments. NOTE: The
|
||
BD register must already be set prior to making this call.
|
||
|
||
<20> IOCTL_SET_BD = Sets the image BD register to argument.
|
||
|
||
<20> IOCTL_SET_TO = Set the image TO register to argument.
|
||
|
||
4.9. open() and close()
|
||
|
||
Here is where you open and close the four VMELinux Master or Slave
|
||
devices plus the Control device. Slave images are not yet supported.
|
||
|
||
<20> vme_handle = open("//dev//vme_m0",O_RDWR,0);
|
||
|
||
<20> uni_handle = open("//dev//vme_ctl",O_RDWR,0);
|
||
|
||
|
||
<20> close(vme_handle);
|
||
|
||
<20> close(uni_handle);
|
||
|
||
|
||
5. Advantages of the VMEbus, Linux and VMELinux
|
||
|
||
5.1. Pin and socket connectors
|
||
|
||
The VMEbus standard uses pin and socket connectors. This is superior
|
||
to edge connections in that the connection is not exposed to humidity
|
||
and other environmental conditions. It is a more expensive way of
|
||
doing things, but offers longer times before failure.
|
||
|
||
5.2. Eurocard assembly
|
||
|
||
A VME board is either a 3U (160 x 100 mm) or a 6U size (160 x 233.35
|
||
mm). These sizes correspond to the Eurocard standard for board modules
|
||
and card cages. Eurocard is a popular format used by many different
|
||
busses including CompactPCI. This popularity makes the materials
|
||
needed for cage assembly inexpensive and easy to obtain.
|
||
|
||
5.3. Linux is Low Cost
|
||
|
||
The nature of Linux is in its user supported and freely available
|
||
format. The number of people using Linux is growing. The number of
|
||
people contributing to the continued development of the Linux software
|
||
base is growing. It is unfair to state that Linux is a good value
|
||
because it is available for little to no charge. Linux is a good value
|
||
because it works.
|
||
|
||
5.4. Linux is Stable
|
||
|
||
There are those who say that Linux us an unstable operating system. It
|
||
is true that the new Linux kernels in development are experimental and
|
||
should not be relied on for critical applications. However, stable
|
||
versions of the Linux OS are always available and provide very robust
|
||
operation. VMELinux is always based on the stable versions of the
|
||
kernel source; Today's stable kernels are the 2.0.X and 2.2.x series.
|
||
We have received reports that the latest 2.4.x kernels appear to be
|
||
solid. I would say the future is plenty bright for Linux.
|
||
|
||
5.5. Linux is Dynamic
|
||
|
||
Because so many people are developing Linux, you do not have to wait
|
||
long for improvements, fixes or new features to become part of the
|
||
Linux distribution.
|
||
|
||
6. Current and planned Board Support
|
||
|
||
While the VMELinux driver should work with any PCI based design, the
|
||
following boards have actually run our software.
|
||
|
||
6.1. Xycom XVME655 Pentium VMEbus Board
|
||
|
||
|
||
<20> This XyCom board is compatible with the standard VMELinux kernel
|
||
driver package from VMELinux Project <http://www.vmelinux.org/>
|
||
|
||
<20> A prepared kernel will be available soon. It will be based on the
|
||
newest version of the Linux kernel and will include appropriate
|
||
drivers for the on board NE2100 Ethernet interface. Check the
|
||
website for details.
|
||
|
||
6.2. XyCom XVME656 Pentium VMEBus Board
|
||
|
||
|
||
<20> This XyCom board is compatible with the standard VMELinux kernel
|
||
driver package from VMELinux Project <http://www.vmelinux.org/>
|
||
|
||
<20> A prepared kernel will be available soon. It will be based on the
|
||
newest version of the Linux kernel and will include appropriate
|
||
drivers for the on board AHA2940/AIC7000 SCSI and 82558 Intel
|
||
EtherExpress Ethernet peripherals. Check the website for details.
|
||
|
||
6.3. Dynatem DPC1-0367
|
||
|
||
|
||
<20> This board is compatible with the standard VMELinux kernel driver
|
||
package from VMELinux Project <http://www.vmelinux.org/>
|
||
|
||
<20> A prepared kernel will be available soon. It will be based on the
|
||
newest version of the Linux kernel and will include appropriate
|
||
drivers for the on board SCSI and Tulip Ethernet peripherals.
|
||
Check the website for details.
|
||
|
||
6.4. SBS/Or Computer VP7
|
||
|
||
|
||
<20> This board is compatible with the standard VMELinux kernel driver
|
||
package from VMELinux Project <http://www.vmelinux.org/>
|
||
|
||
<20> A prepared kernel will be available soon. It will be based on the
|
||
newest version of the Linux kernel and will include appropriate
|
||
drivers for PCNET Ethernet peripheral. Check the website for
|
||
details.
|
||
|
||
<20> The VP7 has a nice feature which performs the BOOTP protocol
|
||
without need of a bootrom or similar modification. However, you
|
||
must ask SBS for an updated BIOS with this modification.
|
||
|
||
6.5. DY4 179, A Power PC board
|
||
|
||
|
||
<20> An independent engineer finds this board is compatible with the
|
||
standard VMELinux kernel driver package from VMELinux Project
|
||
<http://www.vmelinux.org/>
|
||
|
||
6.6. Planned Board Support
|
||
|
||
If you do not see VMELinux support for your board let us know. Maybe
|
||
the manufacture will lend us a board for development.
|
||
|
||
7. Other "Linux on VME" Projects
|
||
|
||
This HOWTO emphasizes the efforts of just one particular way of
|
||
accessing the VMEbus from a Linux system; Our way requires the Tundra
|
||
Universe PCI/VME bridge device which will not work with many VME
|
||
processor boards. Fortunately, there are several other efforts out
|
||
there in various stages of development which provide the VME system
|
||
integrator with options.
|
||
|
||
Since it is our desire to make this HOWTO reflect the efforts of the
|
||
entire community of VME folks, we will be adding coverage of the other
|
||
projects in future versions of this document. For the moment, we are
|
||
simply going to list the other efforts in this section. Please refer
|
||
to the latest documentation at The VMELinux Project
|
||
<http://www.vmelinux.org/> for up to date information.
|
||
|
||
7.1. Project List
|
||
|
||
|
||
<20> Linux for 680x0 based VME boards. Currently there are ports for
|
||
Motorola boards (MVME147, MVME162, MVME166, MVME167, MVME172,
|
||
MVME177), BVM boards (BVME4000 and BVME6000), and the Tadpole
|
||
TP34V. Web Site <http://www.sleepie.demon.co.uk/linuxvme/>.
|
||
Latest activity September 1, 2000.
|
||
|
||
<20> The "other" Tundra Universe driver - Linux driver for the Tundra
|
||
Semiconductor Universe PCI/VME bridge. Also known as the Hannappe
|
||
driver. Web Site <http://lisa2.physik.uni-
|
||
bonn.de/~hannappe/software/universe_doc/universe.html>.
|
||
|
||
<20> Gabriel Paubert has been busy with yet another Tundra Universe
|
||
driver. FTP Site <ftp://vlab1.iram.es/pub/linux-vme/>. His
|
||
emphasis is having a driver that will allow writing kernel modules
|
||
for specific devices in the VME cage. Emphasis includes interrupt
|
||
handling and queuing DMA transfers.
|
||
|
||
<20> Synergy has a port for their PowerPC boards at Synergy
|
||
<http://www.synergymicro.com/Software/Linux.html>.
|
||
|
||
<20> VMIC supports the 2.2.x and 2.4.x kernels for their boards. Linux
|
||
on VMIC VME CPUs
|
||
<http://www.vmic.com/products/embeddedpc/products/hw_sbc_linux.html>.
|
||
|
||
7.2. Major Device Numbers
|
||
|
||
There has been some confusion about the major device number to assign
|
||
VME bus devices. Originally, the VMELinux Universe driver used 70.
|
||
This quickly came into conflict with the "SpellCaster Protocol" as the
|
||
number became assigned by the Linux folks. I requested and received a
|
||
device number of 221 for VME devices. In a perfect world, all Linux
|
||
VME design efforts would have a common interface to their driver
|
||
through this device. I doubt we will ever see unity on this
|
||
particular aspect, however, I think we can all at least agree to use
|
||
this number for our devices.
|
||
|
||
Up to version 1.2.0 The VMELinux driver supports the following
|
||
devices:
|
||
|
||
<20> /dev/m0 c 221 0
|
||
|
||
<20> /dev/m1 c 221 1
|
||
|
||
<20> /dev/m2 c 221 2
|
||
|
||
<20> /dev/m3 c 221 3
|
||
|
||
<20> /dev/s0 c 221 4
|
||
|
||
<20> /dev/s1 c 221 5
|
||
|
||
<20> /dev/s2 c 221 6
|
||
|
||
<20> /dev/s3 c 221 7
|
||
|
||
<20> /dev/ctl c 221 8
|
||
|
||
As of version 1.3.0 The VMELinux driver drops support for the slave
|
||
images (it never did support them) and substitutes the four additional
|
||
master images offered by the Universe II:
|
||
|
||
<20> /dev/m0 c 221 0
|
||
|
||
<20> /dev/m1 c 221 1
|
||
|
||
<20> /dev/m2 c 221 2
|
||
|
||
<20> /dev/m3 c 221 3
|
||
|
||
<20> /dev/m4 c 221 4
|
||
|
||
<20> /dev/m5 c 221 5
|
||
|
||
<20> /dev/m6 c 221 6
|
||
|
||
<20> /dev/m7 c 221 7
|
||
|
||
<20> /dev/ctl c 221 8
|
||
|
||
The good folks responsible for organizing Linux devices suggest the
|
||
following device organization:
|
||
|
||
<20> /dev/bus/vme/m0 c 221 0
|
||
|
||
<20> /dev/bus/vme/m1 c 221 1
|
||
|
||
<20> /dev/bus/vme/m2 c 221 2
|
||
|
||
<20> /dev/bus/vme/m3 c 221 3
|
||
|
||
<20> /dev/bus/vme/s0 c 221 4
|
||
|
||
<20> /dev/bus/vme/s1 c 221 5
|
||
|
||
<20> /dev/bus/vme/s2 c 221 6
|
||
|
||
<20> /dev/bus/vme/s3 c 221 7
|
||
|
||
<20> /dev/bus/vme/ctl c 221 8
|
||
|
||
This was established from our 1.2.0 and earlier collections and makes
|
||
sense for the Universe I device. For the Universe II and the many
|
||
other completely different ways to the VMEbus, it makes no sense at
|
||
all. I may ask the Linux folks to further breakdown the device tree
|
||
like this:
|
||
|
||
<20> /dev/bus/vme/ca91c142/m0..m3,s0..s4,ctl for the original Tundra
|
||
Universe
|
||
|
||
<20> /dev/bus/vme/ca91c042/m0..m7,s0..s7,ctl for the Tundra Universe II
|
||
|
||
<20> /dev/bus/vme/motorola/680x0/whatever for the Motorola boards
|
||
|
||
<20> etc.
|
||
|
||
All this is nice I suppose, but we like our devices to be /dev/vme* so
|
||
our make file creates them in /dev. So far, the term "VME" has
|
||
remained a unique identifier so conflicts with other devices should
|
||
not occur; However, we should all remain watchful. So long as we all
|
||
agree to use the major number of 221, all should be just fine. How we
|
||
define the minor numbers does not need to be (and really cannot be)
|
||
the same as other Linux-VME projects. However, this should not result
|
||
in any conflicts in a particular installation. After all, one Linux
|
||
VME system is not going to have more than one way to access the
|
||
VMEbus.
|
||
|
||
|
||
Refer to the kernel.org web site
|
||
<http://www.kernel.org/pub/linux/docs/device-list/devices.txt> for
|
||
more details on this and every other assigned Linux device major
|
||
number.
|
||
|
||
8. Conclusion
|
||
|
||
VMELinux and the other Linux on VME efforts offer the user a low cost
|
||
way to implement a VMEbus system quickly, reliably and with all the
|
||
advantages of a unix environment. We are using VMELinux in our
|
||
projects. Our task list includes:
|
||
|
||
<20> Porting to other brands of Intel VMEbus boards,
|
||
|
||
<20> Porting of VMELinux to other processors that use the Universe chip,
|
||
|
||
<20> Creation of various slave board drivers for use by all VMELinux
|
||
users,
|
||
|
||
<20> A study of running the VMELinux kernel driver module as a RT-Linux
|
||
task.
|
||
|
||
This document outlines the steps you need to install the VMELinux
|
||
Kernel Driver into the example Xycom XVME-655 Pentium VME board. It
|
||
is our hope that others will attempt installation of VMELinux into
|
||
other boards and let us know their success.
|
||
|
||
|
||
This method of code development works best when the users tell us of
|
||
their successes and describe the equipment used. Please, please drop
|
||
a note to the VMELinux Mail List
|
||
<http://lists.va.net/mailman/listinfo/vmelinux-users> and share your
|
||
experience with others.
|
||
|
||
Send bug reports and feature requrests to the VMELinux Project Bug
|
||
Tracker <http://bugs.vmelinux.org/>. If you have a question or an
|
||
update to this document send email to John <mailto:jhuggins@va.net>.
|
||
|
||
|
||
|
||
9. FAQ
|
||
|
||
|
||
9.1. The Shell utilities return a bunch of stars (*) when I access a
|
||
board I know is there. What gives?
|
||
|
||
Check to be sure the /dev/vme... files have their permissions set to
|
||
666. If not, the shell utilities will return a * in place of data to
|
||
indicate an error condition similar to a VME bus error.
|
||
|
||
|
||
9.2. The Shell utilities still return a bunch of stars (*) when I
|
||
access a board I know is there. Now what?
|
||
|
||
It is possible the ca91c042 Linux kernel module has been compromised.
|
||
Get root access and type "lsmod" to review the loaded modules. Do you
|
||
see the ca91c042? If yes, try removing it and reinstalling it with
|
||
"rmmod ca91c042" and then "insmod /path/to/the/ca91c042.o" to get
|
||
things up again. If it is not there check to see if you are loading
|
||
the module when you boot the machine, etc.
|
||
|
||
|
||
9.3. The Shell utilities still return a bunch of stars (*) when I
|
||
access a board I know is there. HELP?
|
||
|
||
|
||
Time to get a VMetro board into the VME cage and see if any accesses
|
||
are occurring. Also look at the /proc/ca91c042 file to see if the
|
||
read and write counters are incrementing.
|
||
|
||
|
||
9.4. How does VMELinux handle interrupts?
|
||
|
||
The driver does handle interrupts, but if you compile your interrupt
|
||
handler program as a Linux loadable module, that program can handle
|
||
the interrupts directly. Examples of this will be available soon. It
|
||
is important to note that user level program can be made to handle
|
||
interrupts, but it is a much better idea to have your interrupt
|
||
handlers as part of the Linux kernel via loadable modules. Yes, you
|
||
can totally hose the kernel if you do something wrong, but that is the
|
||
trade off between safety and performance.
|
||
|
||
|
||
9.5. I have RedHat 5.1 and can't get VMELinux programs to compile.
|
||
|
||
RedHat 5.1 includes a new compiler. If you manually edit the Makefile
|
||
in each directory to call up the new egcs compiler, things should
|
||
compile. We fully intend to support RedHat 5.1 installations, but for
|
||
now I suggest using 5.0 or Slackware.
|
||
|
||
|
||
9.6. I have RedHat 6.x so I assume the above issue is fixed. Right?
|
||
|
||
Maybe. RedHat threw us, and many other kernel module driver writers,
|
||
a curve ball with the move to the egcs compiler. Thankfully, the two
|
||
compiler camps, GCC and egcs, have united their efforts. All this
|
||
incompatibility should just go away. For the moment, however,
|
||
VMELinux will only be tested with GCC 2.95.x so that is what we
|
||
suggest you use for a compiler. If you type "gcc --version" at your
|
||
prompt and get an "egcs..." back then we cannot say it will work for
|
||
you.
|
||
|
||
|
||
|
||
9.7. When will your ca91c042 Tundra Universe driver support the 2.4
|
||
kernels?
|
||
|
||
Now. Download the latest tar ball from the download directory at the
|
||
main site. 2.4 support was added in version vmelinux-1.2.0.
|
||
|
||
9.8. Hey! The Universe II has eight master and eight slave images.
|
||
You support four each. Why?
|
||
|
||
We have been at this a long time and initially created these tools for
|
||
the original Universe I which according to the documentation has four
|
||
images each. When boards arrived with the Universe II, we searched
|
||
the Tundra web site in vain for new documentation. We were told by
|
||
the board manufacturers the II works just like the original; Thus, we
|
||
only worried about the original four images. Just recently some good
|
||
folks pointed out our omission. We finally found the correct
|
||
documentation on the web site and support the extra images as of the
|
||
1.3.0 development release.
|
||
|
||
More news! The latest CVS snapshots of the ca91c042.c and ca91c042.h
|
||
files will notice which Universe version is in your system and act
|
||
accordingly.
|
||
|
||
Please note, we have not yet found any good reason to spend time
|
||
developing support for the eight (or four) slave images. The current
|
||
tools only support the master images and this has proven adequate for
|
||
every need we have come across. If you think slave support is a good
|
||
thing, let us know.
|
||
|
||
The folks at VMIC have a kernel driver they say does support the slave
|
||
images and is available under a BSD style license. The announcment
|
||
may be found in our mail list archive mail list archive
|
||
<http://lists.va.net/pipermail/vmelinux-
|
||
devel/2002-January/000000.html> and the correct link to there web site
|
||
is here
|
||
<http://www.vmic.com/products/embeddedpc/products/hw_sbc_linux.html>.
|
||
|
||
9.9. How can we contribute to your VME-LINUX working group?
|
||
|
||
All programming efforts thus far have been accomplished by Michael
|
||
Wyrick. My role has been to coordinate the VMELinux Project and help
|
||
define and test the resulting programs.
|
||
|
||
We have successfully placed the working code into a CVS system and are
|
||
using it to track code changes. Right now only Mike and myself have
|
||
write access to this. If you are seriously interested in VMELinux
|
||
development and you know your way around Linux kernel programming,
|
||
please join us by joining the developers mailing list and creating an
|
||
account on our bug tracking system located here
|
||
<http://bugs.vmelinux.org/>.
|
||
|
||
If you cannot develop code, please consider keeping us informed about
|
||
any bugs you see or features we should add. You can send mail to the
|
||
user or developer mail lists, but contributing your comments to the
|
||
bug tracking system is much more useful. Just visit VMELinux Project
|
||
Bug Tracking System <http://bugs.vmelinux.org/>, create an account,
|
||
submit your report and we will address it as soon as we can.
|
||
|
||
|
||
|