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.
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.
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.
- 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
- Other (eg control systems, A-D converters)
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.
Figure1: Example hwconf.c file showing VxBus relationships.
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.
The following is an example of output from vxBusShow:
- 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
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
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
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.