BSP Developer's Guide

VxWorks 5.5
BSP Developer’s Guide
Multiple Buses
CPU Local Bus, VMEbus, VXI, QBus, SBus, PCI Local Bus: will it never end?
Computers are getting more complex and it is reaching the embedded computer
arena. Some buses define their own byte ordering differently from the local CPU
byte ordering. You want your drivers to work on any bus with a minimum of
configuration changes. Fortunately, the hardware access macros that were defined
for flexibility come to the rescue once again. It is simple to define the macros to
perform any byte swapping or other bus related operations.
The most complex board system to date is the Motorola MVME-1600 board. The
local bus is the PowerPC MPC bus. The MPC105 chip connects the MPC bus to a
PCI bus. A PCI chip connects to an ISA Bus. A different PCI chip connects the PCI
bus to a Motorola 68040 bus. From the 68040 Bus, there is a VME chip to interface
to the VMEbus. One board, five different buses. VMEbus supports seven interrupt
request levels and 256 possible vectors. PCI supports four interrupt levels. ISA
supports 16 interrupt levels. PCI is little endian by definition. The 040 bus is big
endian by definition. The MPC bus is ambidextrous (either ended).
Interrupt Controllers
Some hardware designs require special interrupt acknowledge steps. Sometimes
interrupts are processed through cascaded chains of interrupt controllers requiring
multiple steps with each interrupt just to reset or clear the interrupt controller
hardware.
With the rush to PCI bus devices, you must insure that all your interrupt service
routines are compatible with chaining. This means that the driver code must
determine if the device is actually asserting an interrupt request and if not then the
code must exit immediately.
Ideally, the device driver should not be concerned with connecting interrupt
vectors. This is definitely an area of BSP responsibility. The driver interrupt service
routine should be a global routine that the BSP connects to the vector as part of
sysHwInit2( ). If a driver must be involved in the interrupt connect step, then this
should be through a hardware abstraction macro. This needs to be a flexible
interface so that different boards with different interrupt structures can be
supported from the one driver.
94