Appendix

E
VME Basics

Tornado Device Driver Workshop

Copyright Wind River Systems

Wind River Systems

E-1

Introduction to the VMEbus Accessing boards across the VMEbus VMEbus interrupt handling

VME Basics
8.6 VMEbus Addressing VMEbus Interrupts

Tornado Device Driver Workshop

Copyright Wind River Systems

Wind River Systems

E-2

VMEbus address spaces (Address Modiers) CPU memory maps Converting a VMEbus address to a local address Creating a virtual to physical map to access (unmapped) VMEbus address

VMEbus Terminology
Master Slave Arbiter A board which can initiate data transfer A board which responds to requests generated by a master A board that grants masters control of the bus

Only the system controller in the rst slot can be the arbiter. Most I/O boards are slaves. Some I/O boards are masters. Most masters are also slaves.

Tornado Device Driver Workshop

Copyright Wind River Systems

Wind River Systems

E-3

VMEbus is called a multimaster bus, since multiple boards may initiate data transfers. Whether a board can be a master, slave, or arbiter is hardware determined.
The Matrix DAADIO is an example of a slave. CPU cards are typically masters and slaves. I/O boards with microprocessors on-board may be masters. The Matrix MS-SCSIFD (SCSI & oppy controller) is an example of an I/O master.Since most I/O boards are slaves only, the driver writer needs to know how the master (CPU card) accesses the I/O board, but does not have to concern themselves with the I/O board accessing the master (since it only responds to the masters requests). If the I/O board is also a master, then the driver needs to be aware how access can be made in both directions.Note that while most masters are slaves, not all slaves are masters.

VME Backplane
VME Chassis P1 backplane connectors P2

The VMEbus is designed for exibility to accommodate varying needs: P1/J1 P2/J2 24 bit addressing, 16 bit data, plus control lines Expands capability to 32 bit addressing and 32 bit data
Copyright Wind River Systems Wind River Systems

Tornado Device Driver Workshop

E-4

The most common cards are double height (6U), which connect into both P1 and P2. Single height (3U) cards are also common. Do NOT leave empty slots between boards (unless the backplane is correctly jumpered for it).
The Matrix DAADIO is an example of a slave. CPU cards are typically masters and slaves. I/O boards with microprocessors on-board may be masters. The Matrix MS-SCSIFD (SCSI & oppy controller) is an example of an I/O master.Since most I/O boards are slaves only, the driver writer needs to know how the master (CPU card) accesses the I/O board, but does not have to concern themselves with the I/O board accessing the master (since it only responds to the masters requests). If the I/O board is also a master, then the driver needs to be aware how access can be made in both directions. Note that while most masters are slaves, not all slaves are masters.

VMEbus Address Spaces

Name
Short I/O (A16) Standard (A24) Extended (A32)

Address Length
16-bit 24-bit 32-bit

Size
64 Kbytes 16 Mbytes 4 Gbytes

Tornado Device Driver Workshop

Copyright Wind River Systems

Wind River Systems

E-5

The VMEbus was designed with these different addressing modes to permit a wide range of applications: less demanding applications can use Short I/O (A16) addressing which requires less hardware (e.g. address decoding logic) while more complex applications can use the full 32-bit addressing.

Typical CPU Board Memory Map

0xffffffff
Short I/O

0xffff0000
Local Devices

0xff000000
St

0xfe000000
Extended

0x00400000
Local RAM

Tornado Device Driver Workshop

Copyright Wind River Systems

Wind River Systems

E-6

The addresses and ordering will differ between boards. Note that picture above is not to scale. Short I/O space (64K) is less than 4/1000 of the 32-bit address space.
The map above shows an 1 Mbyte local RAM, 3 Gbytes 991 Mbytes extended space, 16 Mbytes standard space, 15 Mbytes 1008 Kbytes for local devices, and 64 Kbytes for short I/O.

Map To VMEbus Address Space

Memory Map Short I/O Short I/O Standard Standard VMEbus Address Space

Extended

Extended

Tornado Device Driver Workshop

Copyright Wind River Systems

Wind River Systems

E-7

The diagram above is an example. Your board will differ. It is common for a CPU to have non-contiguous regions that map to VMEbus extended address space. Typically, all of VME short I/O and standard address space is accessible. Only a subset of VME extended address space is accessible.

Address Modiers
CPU I/O

/ 32 Address Lines / 32 Data Lines / 6 Address Modier Address modiers specify the VMEbus address space.

Tornado Device Driver Workshop

Copyright Wind River Systems

Wind River Systems

E-8

Boards typically have jumpers to specify where registers or memory reside in a given address space. For example, if a board has one Mbyte of memory in standard space, it will typically have jumpers to select where in the 16 Mbyte Standard address space it is mapped.

Address Modiers
Privilege Level
q q

Supervisor Supervisor or User Data Program Block Transfer Extended Standard Short I/O
Copyright Wind River Systems Wind River Systems

Type of access
q q

Address Size
q q

Tornado Device Driver Workshop

E-9

For VxWorks privilege level is irrelevant, since VxWorks runs in supervisor mode. Typically, I/O boards select Privilege Level with jumpers. Not all combinations above are used. Symbolic constants for Address Modiers are dened in wind/target/h/ vme.h.
Program is text or code. Block transfer (sometimes called burst mode) allows transferring up to 256 bytes with only one address cycle (like DMA).

Accessing a Board on the VMEbus

You must know:
q q

The address modier to which the board responds The addresses to which it responds The CPU address mapping Address Modier is VME_AM_SUP_SHORT_IO (Short I/0 supervisor) Address is 0x100 CPU maps Short I/O space to 0xffff0000.

Example:
q

Tornado Device Driver Workshop

Copyright Wind River Systems

Wind River Systems

E-10

What address would be used on the CPU to access the board described above?
The address to use would be 0xffff0100 (0xffff0000 + 0x100). In this example, the address put on the bus is 0x100 (address lines A01-A15). The most signicant 16-bits (0xffff) is used to indicate to the CPU that this is a VMEbus address and the address modier should be set to 0x2d (AM0AM5).

Converting a VMEbus Address

STATUS sysBusToLocalAdrs (addrSpace, busAddr, pLocalAddr)
addrSpace busAddr pLocalAddr The VMEbus address modier The VMEbus address to be accessed A pointer to store the converted address

Returns OK on success, else ERROR. To enhance portability, use this routine in lieu of hardcoding the local address. Typically, called once in driver initialization routine.
Tornado Device Driver Workshop Copyright Wind River Systems Wind River Systems

E-11

Use the symbolic constants dened in wind/target/h/vme.h for the addrSpace parameter. Example:
#include "vxWorks.h" #include "vme.h" ... char * pBoard; ... if (sysBusToLocalAdrs (VME_AM_SUP_SHORT_IO, (char *)0x100, &pBoard) == ERROR) return (ERROR);
Assuming that your board only uses one address space, the routine above need only be called once. This may not be obvious to all students.

Probing A Bus Address

STATUS vxMemProbe (addr, mode, len, pVal)
addr mode len pVal Address to test. Test for reading, VX_READ(0), or writing VX_WRITE (1). Length in bytes to probe--must be 1, 2, or 4. Address of data to write (VX_WRITE) or address to store value read (VX_READ).

Traps bus errors. Useful in initialization code when unsure of location of hardware.
Tornado Device Driver Workshop Copyright Wind River Systems Wind River Systems

E-12

Include vxLib.h.

Boards with MMUs

0xffffffff 0xffff0000 0xff000000 0xfe000000

not map p ed 0x01400000 0x00400000

PHYSICAL

0xffffffff 0xffff0000 0xff000000 0xfe000000

VMEbus Short I/O Local Devices VMEbus Standard

VIRTUAL

VMEbus Extended

0x00400000

Local RAM
Wind River Systems

Tornado Device Driver Workshop

Copyright Wind River Systems

E-13

By default, boards with Memory Mapping Units map virtual to physical addresses one-to-one. Not all virtual addresses are mapped. As in the example above, BSPs typically map all of VMEbus short I/O and standard addresses, but do not map all the extended addresses. This is in addition to the earlier limitation already discussed: In the example above, most of the 4Gb VMEbus Extended space (0x00400000 to 0xfe000000) is mapped by the address decode logic on the CPU board. Of these addresses only a subset have virtual address mapping (0x00400000 to 0x01400000).
q q

To access an unmapped VMEbus extended address requires adding a mapping.

Mapping VMEbus Addresses

This is only an issue for boards with MMUs that do not map addresses needed by an application. Writing to an unmapped address causes a bus error. To map an (unmapped) VMEbus address:
r

Convert the bus address to a local address using sysBusToLocalAdrs( ). Create a virtual address mapping for these addresses using one of two methods which will be described: Modify sysLib.c Use VxVMI routines
q q

Tornado Device Driver Workshop

Copyright Wind River Systems

Wind River Systems

E-14

VxVMI is an optional product. There may be architecture-dependent constraints on how much memory may be mapped. For example, the MC68K requires 512 bytes for each megabyte mapped (to store translation table information)

Method 1: Modifying sysLib.c

Modify the sysPhysMemDesc initialized in sysLib.c. It is as an array of PHYS_MEM_DESC structures: virtualAddr physicalAddr len initialStateMask Starting virtual address Starting physical address Number of bytes to map Initial state mask, e.g.:
VM_STATE_MASK_VALID VM_STATE_MASK_WRITABLE VM_STATE_MASK_CACHEABLE

initialState Initial state, e.g.:

VM_STATE_VALID / VM_STATE_VALID_NOT VM_STATE_WRITABLE / VM_STATE_WRITABLE_NOT VM_STATE_CACHEABLE / VM_STATE_CACHEABLE_NOT
Tornado Device Driver Workshop Copyright Wind River Systems Wind River Systems

E-15

The virtualAddr and physicalAddr must be on page boundaries. The len must be a multiple of page size. To get page size, use vmBasePageSizeGet ( ) or vmPageSizeGet ( ). The state and state mask values above are generic, architecture independent. Different architectures may have provided additional, architecture dependent, states. The state mask is a generic tool to allow modifying a state ag without knowing the current state values. It must be provided here for consistency purposes. The sysPhysMemDesc may be modied by:
q q

Changing an existing PHYS_MEM_DESC element Adding one or more PHYS_MEM_DESC elements

Modifying Mapping Example

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 PHYS_MEM_DESC sysPhysMemDesc [] = { ... { /* some A32 vme */ (void *) 0x1000000, /* address 0 */ (void *) 0x1000000, 0x1000000 0x2000000 /* 16 32 Mbytes */ VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE, VM_STATE_VALID | VM_STATE_WRITABLE | VM_STATE_CACHEABLE_NOT }, ... { /* add some A32 vme */ (void *) 0x8000000, (void *) 0x8000000, 0x1000000, /* 16 Mbytes */ VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE, VM_STATE_VALID | VM_STATE_WRITABLE | VM_STATE_CACHEABLE_NOT }, ...
Copyright Wind River Systems Wind River Systems

Tornado Device Driver Workshop

E-16

The example above shows how to modify sysPhysMemDesc by: Modifying an existing PHYS_MEM_DESC element (in this case, by increasing the size of the existing extended (A32) address space from 16 to 32Mb.), or Adding a new PHYS_MEM_DESC element (in this case, to map additional, non-contiguous VMEbus extended addresses). Starting virtual address to map Starting physical address to map Size in bytes State mask Initial state. Note that the VMEbus addresses are set to
q q

VM_STATE_CACHEABLE_NOT.

Method 2: Mapping Addresses Using VxVMI

Allows building application initialization code to map addresses without having to modify sysLib.c. First map the memory:

STATUS vmGlobalMap (virtualAddr, physicalAddr, len)

q q

Call before creating any virtual memory contexts. Address and length must be on page boundaries.

Next call:

STATUS vmStateSet (NULL, virtualAddr, len, stateMask, state)

Tornado Device Driver Workshop Copyright Wind River Systems Wind River Systems

E-17

Requires optional VxVMI product. The NULL argument in vmStateSet( ) indicates that the current virtual context is to be used. The values and meaning for stateMask and state are identical to those previously described for modifying sysPhysMemDesc. Must dene INCLUDE_MMU_FULL in cong.h in the target directory.

VME Basics

VMEbus Addressing 8.7 VMEbus Interrupts

Tornado Device Driver Workshop

Copyright Wind River Systems

Wind River Systems

E-18

VMEbus interrupt acknowledge cycle Enabling a CPU board to respond to VMEbus interrupts Managing multiple I/O boards Vectored interrupts and autovectored interrupts

Interrupts and Priorities

Absolute System-Wide Priority
Interrupt

Interrupt Level
Interrupt . . . Interrupt
(Hard Wired)

Execution Order Controlled by Hardware Execution Order Controlled by Kernel

Task Task . . . Task

Task Priority
(Programmable)

Tornado Device Driver Workshop

Copyright Wind River Systems

Wind River Systems

E-19

Interrupts preempt even highest priority task.

Interrupt Terminology
Interrupt Level
q q

Seven VMEbus levels available: IRQ1 - IRQ7 IRQ7 is the highest priority Only one CPU can respond to a given IRQ 256 available (Motorola) Index into the interrupt vector table The byte offset of an entry in the interrupt vector table

Interrupt Number
q q

Interrupt Vector
q

Tornado Device Driver Workshop

Copyright Wind River Systems

Wind River Systems

E-20

Any board (with the appropriate hardware) can generate interrupts (does not have to be a master). The interrupt number is selected by programming (or setting jumpers) on the interrupting board. The usage interrupt number and interrupt vector are WRS specic. In the industry, interrupt vector typically refers to the index into the interrupt table.

VMEbus Interrupts

CPU

I/O

IRQ1 - IRQ7

Tornado Device Driver Workshop

Copyright Wind River Systems

Wind River Systems

E-21

To generate an interrupt, the I/O board asserts one of the seven interrupt lines. The line it asserts is the interrupt level. The CPU board recognizes the assertion of the interrupt line (if enabled) and begins the interrupt acknowledge cycle.
The enabling of interrupts is done by sysIntEnable() -- some (usually older) boards can not enable interrupts through software but require the setting of jumpers. Only one board should be programmed to handle a given interrupt level. With multiple CPUs and I/O boards on the same backplane, different I/O boards can generate different interrupt levels which could then be handled by different CPUs.

VMEbus Interrupts

CPU

I/O

IACK A01-A03

Tornado Device Driver Workshop

Copyright Wind River Systems

Wind River Systems

E-22

The acknowledging CPU places the interrupt level number on the lower order address lines and asserts the Interrupt Acknowledge (IACK) line. The IACK line is daisy-chained through the backplane. Starting with the card in slot 0, each board determines if the interrupt being acknowledged is one that it generated. If not, it passes the signal down. If it is, the board continues the interrupt acknowledge cycle and does not pass the signal on. The daisy-chaining of IACK allows multiple boards to use the same IRQ line (only one will be acknowledged at a time). The interrupting board may be in a lower numbered slot then the acknowledging CPU.

VME Interrupts

CPU

I/O

DTACK D00-D31

Tornado Device Driver Workshop

Copyright Wind River Systems

Wind River Systems

E-23

The I/O card places the STATUS/ID on the data bus and asserts DTACK. The CPU card (typically) reads the STATUS/ID and uses it as the interrupt number, i.e. an index into the Interrupt Vector Table. The Interrupt Vector Table holds the addresses of interrupt service routines.
DTACK is used by interrupting board to terminate cycle.

VME Interrupts
Multiple boards may generate interrupts using the same interrupt level. A CPU card must be programmed to respond to the specied interrupt level:

STATUS sysIntEnable (intLevel)

Only one CPU card can handle a given IRQ line.

Tornado Device Driver Workshop

Copyright Wind River Systems

Wind River Systems

E-24

If more than one interrupt of the same level occurs at the same time, the board closest to slot 0 will be processed rst. Boards typically assert an IRQ line until they are acknowledged. If two boards assert the same IRQ:
q q

The responsible CPU card begins the interrupt acknowledge cycle. The rst board serviced releases the IRQ line after acknowledgment. The second board still has the IRQ line asserted, so the CPU begins a second interrupt acknowledge cycle. The second board serviced releases the IRQ line after acknowledgment.

Managing Multiple Boards

CPU #0

CPU #1

I/O #0

I/O #1

IRQ3 IRQ4 IACK

Multiple I/O boards can be managed by one or more CPUs.

Tornado Device Driver Workshop Copyright Wind River Systems Wind River Systems

E-25

To have separate CPUs control multiple I/O boards: CPU #0 calls sysIntEnable( ) for IRQ3, but not IRQ4 CPU #1 calls sysIntEnable( ) for IRQ4, but not IRQ3 I/O #0 generates interrupts on IRQ3 I/O #1 generates interrupts on IRQ4
q q q q

One CPU may control multiple I/O boards using the same interrupt level: CPU #0 calls sysIntEnable( ) for IRQ3 I/O #0 and #1 generate interrupts on IRQ3 If both boards generate interrupts at the same time, I/O #0 is serviced rst (board closest to slot 0).
q q q

Interrupt Acknowledge Cycle

Most CPU boards perform the interrupt acknowledge cycle automatically. If a CPU board does not do so, it will autovector, i.e., use the interrupt level as an index into the vector table to obtain the address of an ISR. In the event of autovectoring, the interrupt acknowledge cycle must be completed by executing the following call:

int sysBusIntAck (intLevel)

which returns the STATUS/ID read from the bus.
E-26

Tornado Device Driver Workshop

Copyright Wind River Systems

Wind River Systems

Boards that perform the interrupt acknowledge cycle in hardware have a null sysBusIntAck( ) routine.

Interrupt Vector Table

Interrupt Number
0 1 . . . 0 4 . . .

Interrupt Vector

255

1020

Interrupt Service Routine (ISR)

Tornado Device Driver Workshop

Copyright Wind River Systems

Wind River Systems

E-27

The size of the Interrupt Vector Table is architecture dependent. The table holds pointers to Interrupt Service Routines (ISRs). The Interrupt Vector Table is normally (but not always) located at address 0. The Interrupt Vector is the address of a specic entry in the Interrupt Vector Table. Use the INUM_TO_IVEC(intNumber) macro to convert interrupt number to interrupt vector. The above example is for a typical Motorola 68K board.

VMEbus Interrupt Handling

Vectored interrupts
q q

Most common STATUS/ID from interrupt acknowledge cycle is used as index into interrupt table to select ISR Interrupt level indexes ISR entry Interrupt acknowledge cycle must still be completed

Autovectored interrupts
q q

For most architectures, ISRs use a separate interrupt stack.

Tornado Device Driver Workshop

Copyright Wind River Systems

Wind River Systems

E-28

The size of the interrupt stack is determined by the ISR_STACK_SIZE in wind/target/cong/all/congAll.h. The default stack size is architecture dependent. ISRs for the following architectures use the current tasks stack: Motorola CPU32 Motorola MC68000, MC68010 and MC68060 Intel 80386, 80486 and Pentium RAD 6000