VME Basics. Appendix. Introduction to the VMEbus Accessing boards across the VMEbus VMEbus interrupt handling

Size: px

Start display at page:

Download "VME Basics. Appendix. Introduction to the VMEbus Accessing boards across the VMEbus VMEbus interrupt handling"

Olivia Reed
5 years ago
Views:

1 Appendix E VME Basics Tornado Device Driver Workshop Copyright E-1 Introduction to the VMEbus Accessing boards across the VMEbus VMEbus interrupt handling

2 VME Basics 8.6 VMEbus Addressing VMEbus Interrupts Tornado Device Driver Workshop Copyright E-2 VMEbus address spaces (Address Modifiers) CPU memory maps Converting a VMEbus address to a local address Creating a virtual to physical map to access (unmapped) VMEbus address

3 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 first 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 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 & floppy 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 master s 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.

4 VME Backplane VME Chassis backplane connectors P1 P2 The VMEbus is designed for flexibility 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 Tornado Device Driver Workshop Copyright 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 & floppy 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 master s 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.

5 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 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.

6 Typical CPU Board Memory Map Short I/O Local Devices St 0xffffffff 0xffff0000 0xff xfe Extended Local RAM 0x Tornado Device Driver Workshop Copyright 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.

7 Map To VMEbus Address Space Memory Map Short I/O Short I/O VMEbus Address Space Standard Standard Extended Extended Tornado Device Driver Workshop Copyright 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.

8 Address Modifiers CPU I/O / 32 / 32 / 6 Address Lines Data Lines Address Modifier Address modifiers specify the VMEbus address space. Tornado Device Driver Workshop Copyright 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.

9 Address Modifiers Privilege Level Supervisor Supervisor or User Type of access Data Program Block Transfer Address Size Extended Standard Short I/O Tornado Device Driver Workshop Copyright 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 Modifiers are defined 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).

10 Accessing a Board on the VMEbus You must know: The address modifier to which the board responds The addresses to which it responds The CPU address mapping Example: Address Modifier is VME_AM_SUP_SHORT_IO (Short I/0 supervisor) Address is 0x100 CPU maps Short I/O space to 0xffff0000. Tornado Device Driver Workshop Copyright E-10 What address would be used on the CPU to access the board described above? The address to use would be 0xffff0100 (0xffff x100). In this example, the address put on the bus is 0x100 (address lines A01-A15). The most significant 16-bits (0xffff) is used to indicate to the CPU that this is a VMEbus address and the address modifier should be set to 0x2d (AM0- AM5).

11 Converting a VMEbus Address STATUS sysbustolocaladrs (addrspace, busaddr, plocaladdr) addrspace busaddr plocaladdr The VMEbus address modifier 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 E-11 Use the symbolic constants defined 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.

12 Probing A Bus Address STATUS vxmemprobe (addr, mode, len, pval) addr mode len pval Traps bus errors. 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). Useful in initialization code when unsure of location of hardware. Tornado Device Driver Workshop Copyright E-12 Include vxlib.h.

13 VIRTUAL 0xffffffff 0xffff0000 0xff xfe not mapped 0x x Boards with MMUs PHYSICAL 0xffffffff 0xffff0000 0xff xfe x VMEbus Short I/O Local Devices VMEbus Standard VMEbus Extended Local RAM Tornado Device Driver Workshop Copyright 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, BSP s 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 (0x to 0xfe000000) is mapped by the address decode logic on the CPU board. Of these addresses only a subset have virtual address mapping (0x to 0x ). To access an unmapped VMEbus extended address requires adding a mapping.

14 Mapping VMEbus Addresses This is only an issue for boards with MMU s that do not map addresses needed by an application. Writing to an unmapped address causes a bus error. To map an (unmapped) VMEbus address: 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 Tornado Device Driver Workshop Copyright 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)

15 Method 1: Modifying syslib.c Modify the sysphysmemdesc initialized in syslib.c. It is as an array of PHYS_MEM_DESC structures: virtualaddr Starting virtual address physicaladdr Starting physical address len Number of bytes to map initialstatemask 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 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 flag without knowing the current state values. It must be provided here for consistency purposes. The sysphysmemdesc may be modified by: Changing an existing PHYS_MEM_DESC element Adding one or more PHYS_MEM_DESC elements

16 Modifying Mapping Example 1 PHYS_MEM_DESC sysphysmemdesc [] = {... 2 { /* some A32 vme */ 3 (void *) 0x , /* address 0 */❶ 4 (void *) 0x ,❷ 5 0x x /* Mbytes */ ❸ 6 VM_STATE_MASK_VALID VM_STATE_MASK_WRITABLE VM_STATE_MASK_CACHEABLE, ❹ 7 VM_STATE_VALID VM_STATE_WRITABLE VM_STATE_CACHEABLE_NOT ➎ 8 },... 9 { /* add some A32 vme */ 10 (void *) 0x , ❶ 11 (void *) 0x , ❷ 12 0x , /* 16 Mbytes */ ❸ 13 VM_STATE_MASK_VALID VM_STATE_MASK_WRITABLE VM_STATE_MASK_CACHEABLE, ❹ 14 VM_STATE_VALID VM_STATE_WRITABLE VM_STATE_CACHEABLE_NOT ➎ 15 },... Tornado Device Driver Workshop Copyright 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 VM_STATE_CACHEABLE_NOT.

17 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) 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 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 define INCLUDE_MMU_FULL in config.h in the target directory.

18 VME Basics VMEbus Addressing 8.7 VMEbus Interrupts Tornado Device Driver Workshop Copyright 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

19 Interrupts and Priorities Absolute System-Wide Priority Interrupt Interrupt. Interrupt Task Task. Task Interrupt Level (Hard Wired) Execution Order Controlled by Hardware Execution Order Controlled by Kernel Task Priority (Programmable) Tornado Device Driver Workshop Copyright E-19 Interrupts preempt even highest priority task.

20 Interrupt Terminology Interrupt Level Seven VMEbus levels available: IRQ1 - IRQ7 IRQ7 is the highest priority Only one CPU can respond to a given IRQ Interrupt Number 256 available (Motorola) Index into the interrupt vector table Interrupt Vector The byte offset of an entry in the interrupt vector table Tornado Device Driver Workshop Copyright 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 specific. In the industry, interrupt vector typically refers to the index into the interrupt table.

21 VMEbus Interrupts CPU I/O IRQ1 - IRQ7 Tornado Device Driver Workshop Copyright 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.

22 VMEbus Interrupts CPU I/O IACK A01-A03 Tornado Device Driver Workshop Copyright 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.

23 VME Interrupts CPU I/O DTACK D00-D31 Tornado Device Driver Workshop Copyright 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.

24 VME Interrupts Multiple boards may generate interrupts using the same interrupt level. A CPU card must be programmed to respond to the specified interrupt level: STATUS sysintenable (intlevel) Only one CPU card can handle a given IRQ line. Tornado Device Driver Workshop Copyright 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 first. Boards typically assert an IRQ line until they are acknowledged. If two boards assert the same IRQ: The responsible CPU card begins the interrupt acknowledge cycle. The first 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.

25 Managing Multiple Boards CPU CPU I/O I/O #0 #1 #0 #1 IRQ3 IRQ4 IACK Multiple I/O boards can be managed by one or more CPU s. Tornado Device Driver Workshop Copyright E-25 To have separate CPU s 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 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 first (board closest to slot 0).

26 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. Tornado Device Driver Workshop Copyright E-26 Boards that perform the interrupt acknowledge cycle in hardware have a null sysbusintack( ) routine.

27 Interrupt Vector Table Interrupt Number Interrupt Vector Interrupt Service Routine (ISR) Tornado Device Driver Workshop Copyright 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 specific 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.

28 VMEbus Interrupt Handling Vectored interrupts Most common STATUS/ID from interrupt acknowledge cycle is used as index into interrupt table to select ISR Autovectored interrupts Interrupt level indexes ISR entry Interrupt acknowledge cycle must still be completed For most architectures, ISRs use a separate interrupt stack. Tornado Device Driver Workshop Copyright E-28 The size of the interrupt stack is determined by the ISR_STACK_SIZE in wind/target/config/all/configall.h. The default stack size is architecture dependent. ISRs for the following architectures use the current task s stack: Motorola CPU32 Motorola MC68000, MC68010 and MC68060 Intel 80386, and Pentium RAD 6000

The Peripheral Component Interconnect (PCI) Bus and vxworks

The Peripheral Component Interconnect (PCI) Bus and vxworks A Discussion of the implementation of PCI support on Tornado/vxWorks BSPs. Copyright 1984-1999 Wind River Systems Inc. ALL RIGHTS RESERVED. vxworks,