Next Previous Contents

## 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 for up to date information.

## 7.1 Project List

- 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. Latest activity September 1, 2000.
- The "other" Tundra Universe driver - Linux driver for the Tundra Semiconductor Universe PCI/VME bridge. Also known as the Hannappe driver. Web Site.
- Gabriel Paubert has been busy with yet another Tundra Universe driver. FTP Site. 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.
- Synergy has a port for their PowerPC boards at Synergy.
- VMIC supports the 2.2.x and 2.4.x kernels for their boards. Linux on VMIC VME CPUs.

## 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:

- /dev/m0 c 221 0
- /dev/m1 c 221 1
- /dev/m2 c 221 2
- /dev/m3 c 221 3
- /dev/s0 c 221 4
- /dev/s1 c 221 5
- /dev/s2 c 221 6
- /dev/s3 c 221 7
- /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:

- /dev/m0 c 221 0
- /dev/m1 c 221 1
- /dev/m2 c 221 2
- /dev/m3 c 221 3
- /dev/m4 c 221 4
- /dev/m5 c 221 5
- /dev/m6 c 221 6
- /dev/m7 c 221 7
- /dev/ctl c 221 8

The good folks responsible for organizing Linux devices suggest the following device organization:

- /dev/bus/vme/m0 c 221 0
- /dev/bus/vme/m1 c 221 1
- /dev/bus/vme/m2 c 221 2
- /dev/bus/vme/m3 c 221 3
- /dev/bus/vme/s0 c 221 4
- /dev/bus/vme/s1 c 221 5
- /dev/bus/vme/s2 c 221 6
- /dev/bus/vme/s3 c 221 7
- /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:

- /dev/bus/vme/ca91c142/m0..m3,s0..s4,ctl for the original Tundra Universe
- /dev/bus/vme/ca91c042/m0..m7,s0..s7,ctl for the Tundra Universe II
- /dev/bus/vme/motorola/680x0/whatever for the Motorola boards
- 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 for more details on this and every other assigned Linux device major number.

Next Previous Contents