Home Category Blog Introduction to VxBus
Introduction to VxBus

The VxBus device driver infrastructure is fairly new to VxWorks, having been added in release 6.2. Before then drivers were not integrated with VxWorks project configurations, and therefore relied on editing the BSP directly. Now that VxBus is maturing, it's likely to be used by more drivers. Therefore the aim of this article is to introduce what VxBus is, its benefits, as well as the fundamental differences between it and older drivers.

Benefits

One of the key changes and benefits of VxBus is the configuration. Previously everything was handled by config.h and sysLib.c in the BSP directory. The VxBus model allows for driver integration and configuration within a workbench project, where as previously it required modification to the BSP. This means that individual drivers can be added to a project, configured and removed as required, all within the workbench environment.

To write or integrate a VxBus driver into a BSP, knowledge of the VxBus infrastructure is important.

Classes

In VxBus there are different classes of drivers, based on the particular function the device and driver are expected to perform. These classes are:

  • Bus Controller, providing support services that are required to enable other drivers attached to downstream devices to communicate with their associated hardware in a uniform way.
  • Console
  • DMA, providing a standard method for presenting the services of DMA engines to other drivers in the system.
  • Interrupt Controller.
  • Multifunction, bringing together other VxBus drivers for a single device allowing for simplified configuration.
  • Network, separate MAC and PHY drivers which were combined with older END drivers.
  • NVRAM, for mangmanet of non volatile memory to store boot images, configuration and flash file systems.
  • Remote Processing
  • Resource
  • Serial
  • Storage
  • Timer
  • USB
  • Other (eg control systems, A-D converters)

Files

The driver source supplied with VxWorks for each class are found in a single directory under the target/src/hwif hierarchy. Third party drivers should be placed into target/3rdparty/.

 
Each driver must have:

  • source file(s)
  • component description file (with a cdf extension)
  • .dc file containing a prototype for the driver registration function
  • .dr file containing C code to call the driver registration function
  • README file including version information
  • makefile providing the rules to build the driver
 

Together the cdf, dc and dr files are known as driver configuration files, and are located under target/config/comps. In each BSP, a file called hwconf.c provides configuration data in structures for each VxBus driver used in the system. This defines each hardware device and what driver should be used with it. Each driver instance can use information contained in its own resource structure in hwconf.c. This will typically include a base address for registers and any interrupt details, although any device instance specific configuration that is required can be added. The driver itself accesses this configuration using a devResourceGet call.

VxBus

Figure1: Example hwconf.c file showing VxBus relationships.

Show Routines

When developing a VxBus driver, or using VxBus drivers in a BSP, it can very useful to find out what the status is with particular VxBus drivers. The show routines can tell the developer a lot about what is going on with any VxBus driver.

  • vxBusShow() provides a list of information, the details of which depends on its parameter:
    • Available bus types
    • Registered drivers
    • Buses present
    • Devices present
    • Device driver pairings
  • vxbDevStructShow() displays the fields of the device structure
  • vxbDevPathShow() indicates the upstream bus controllers
The following is an example of output from vxBusShow:

-> vxBusShow
Registered Bus Types:
  USB-OHCI_Bus @ 0x801ff1e0
  USB-HUB_Bus @ 0x8019dc34
  Local_Bus @ 0x801947cc

Registered Device Drivers:
  vxbUsbPegasus at 0x801ff6c0 on bus USB-HUB_Bus, funcs @ 0x8019dc18
  vxbUsbSpeaker at 0x801ff4c0 on bus USB-HUB_Bus, funcs @ 0x8019dc18
  vxbUsbHubClass at 0x801ba298 on bus USB-HUB_Bus, funcs @ 0x8019dc18
  timestamp at 0x8019617c on bus Local_Bus, funcs @ 0x80196160
        VxBus version 2
  timer at 0x80196118 on bus Local_Bus, funcs @ 0x801960fc
  intCtlr at 0x80196068 on bus Local_Bus, funcs @ 0x8019605c
  vxbPciUsbOhci at 0x8019db70 on bus PCI_Bus, funcs @ 0x8019dac8
  vxbPlbUsbOhci at 0x8019db30 on bus Local_Bus, funcs @ 0x8019dac8
  vxbUsbOhciHub at 0x8019daf0 on bus USB-OHCI_Bus, funcs @ 0x8019dad4
  uart at 0x80195ff0 on bus Local_Bus, funcs @ 0x80195fe4
  plbCtlr at 0x801947f4 on bus Local_Bus, funcs @ 0x801947e8

Busses and Devices Present:
  Local_Bus @ 0x801bc798 with bridge @ 0x80194834
    Device Instances:
        uart unit 2 on Local_Bus @ 0x801bd758 with busInfo 0x00000000
        timer unit 0 on Local_Bus @ 0x801bd958 with busInfo 0x00000000
        interrupt controller intCtlr0 = 0x801bdb58
        timestamp unit 0 on Local_Bus @ 0x801bde58 with busInfo 0x00000000
    Orphan Devices:
        auxClk unit 0 on Local_Bus @ 0x801bdc58 with busInfo 0x00000000
        vxbPlbUsbOhci unit 0 on Local_Bus @ 0x801bdd58 with busInfo 0x00000000
        legacy unit 0 on Local_Bus @ 0x801be058 with busInfo 0x00000000

Differences & Conclusion

Fundamentally, a VxBus driver is similar to a non VxBus driver. The extra files to support independent configuration of each driver (by anyone building the BSP) has added a layer of complexity. For a simple driver it significantly increases the work required, and may be of little benefit. For a complex driver that may be used with multiple devices and across multiple BSPs, the VxBus configuration should prove more beneficial than the extra driver work.

This has hopefully given an insight into VxBus drivers, but for more information it's worth reading the VxWorks Device Driver Developers Guides included with VxWorks.