Device Tree-Based Driver Development in VxWorks 7.0

Table of Contents

In embedded systems development, platform independence and hardware abstraction are increasingly important. VxWorks 7.0 introduces support for the Device Tree (DT) mechanism, significantly improving driver portability and system configuration flexibility. This article explains how to develop drivers based on Device Tree in VxWorks 7.0, helping developers support diverse hardware platforms more efficiently.

1. What is Device Tree?
#

The Device Tree (DT) is a hardware description format that uses .dts source files to define system hardware such as peripheral addresses, interrupts, clocks, and GPIO mappings. VxWorks uses the compiled binary form .dtb during boot to dynamically parse the hardware structure and build the system device model.

2. Role of Device Tree in VxWorks
#

In VxWorks 7.0, the device tree primarily serves to:

Describe peripheral information: e.g., I2C, SPI, UART, and GPIO controllers;
Replace hard-coded hardware parameters: such as fixed addresses or register definitions in drivers or BSPs;
Support the VxBus device model: using APIs like vxbFdtDevCreate() and vxbDevRegister() to bind DT nodes to drivers.

3. Overview of the Driver Development Process
#

We’ll now use a GPIO controller and device as an example to demonstrate the driver development process based on Device Tree in VxWorks.

4. GPIO Controller & Device Example
#

4.1 Writing the Device Tree Node
#

Assume we have an integrated GPIO controller and a connected LED. The .dts configuration might look like this:

gpio@ff0a0000 {
    compatible = "xlnx,zynq-gpio-1.0";
    reg = <0xff0a0000 0x1000>;
    gpio-controller;
    #gpio-cells = <2>;
    interrupts = <0 45 4>;
    interrupt-controller;
    #interrupt-cells = <2>;
    status = "okay";
};

led@0 {
    compatible = "mycompany,gpio-led";
    gpios = <&gpio 12 0>;  // GPIO12, active high
    label = "status-led";
};

4.2 Matching the Device in the Driver
#

In the GPIO LED driver, define a compatible match:

LOCAL const VXB_FDT_DEV_MATCH_ENTRY gpioLedMatch[] = {
    {
        .compatible = "mycompany,gpio-led"
    },
    { NULL }
};

LOCAL STATUS gpioLedProbe(VXB_DEV_HANDLE pDev)
{
    if (vxbFdtDevMatch(pDev, gpioLedMatch) == NULL)
        return ERROR;
    return OK;
}

4.3 Extracting Device Tree Properties
#

Retrieve the gpios property (controller + pin + flags):

VXB_DEV_HANDLE pDev = ...;
VXB_FDT_DEV * pFdtDev = vxbFdtDevGet(pDev);
VXB_DEV_HANDLE gpioCtrl;
UINT32 pin, flags;

vxbFdtDevGetGpios(pDev, "gpios", 0, &gpioCtrl, &pin, &flags);
vxbGpioModeSet(gpioCtrl, pin, GPIO_DIR_OUTPUT);
vxbGpioWrite(gpioCtrl, pin, 1);  // Turn on LED

4.4 Registering the Driver
#

VXB_DRV_DEF gpioLedDrv = {
    .name = "gpioLed",
    .probe = gpioLedProbe,
    .attach = gpioLedAttach,
    .devMatch = gpioLedMatch,
};

VXB_DRV_DEF_INSTALL(gpioLedDrv)

VxBus will automatically invoke this driver during system initialization based on the DT bindings.

5. Debugging and Verification
#

Use vxbFdtShow() to view parsed device tree info;
Use devs, gpioShow, or other commands to confirm driver is loaded;
Add log output in attach() to verify pin and label values.

6. Summary and Best Practices
#

Device Tree-based driver development significantly enhances code maintainability and reusability. Recommended practices include:

Consolidate all hardware configurations in the .dts file;
Use standard compatible strings to support multiple devices;
Leverage vxbFdtDevGet*() APIs to read DT properties cleanly;
Reuse existing VxBus controller drivers (e.g., GPIO controller) whenever possible.

By adopting the Device Tree mechanism in VxWorks 7.0, driver development becomes more modular and platform-independent. This approach is especially effective for edge AI, industrial automation, and communication systems—where hardware abstraction and rapid deployment are key.