Using VxWorks 7 VxBus Device-Specific Parameters

Using VxWorks 7 VxBus Device-Specific Parameters

Embedded driver development frequently involves balancing flexibility, portability, and boot-time efficiency across multiple hardware configurations. Hard-coded driver parameters may work well during initial bring-up, but they often become problematic as systems evolve and new peripherals are introduced.

VxWorks 7 addresses this challenge through VxBus device-specific parameters, allowing driver behavior to be customized dynamically using device tree configuration rather than static source modifications.

This article explores how device-specific parameters can be used to improve driver flexibility using a practical PCI Express example from a VxWorks 7 BSP developed for the Renesas R-Car H3 platform.

⚙️ The Original BSP Environment
#

The BSP targeted the Renesas R-Car H3 SIP evaluation board and included drivers for several major SoC peripherals:

Serial interfaces
Ethernet controllers
MMC storage
I2C buses
GPIO controllers
PCI Express

As part of PCIe validation, an Intel i210 PCIe Ethernet adapter was connected to the board’s PCIe slot.

The validation process confirmed:

PCIe link establishment
Endpoint enumeration
VxBus device discovery
Network stack integration

The i210 adapter successfully appeared as a secondary Ethernet interface on the system.

At this stage, the PCIe controller driver appeared stable.

🧩 The Real-World Problem
#

The BSP was later deployed across multiple engineering teams working in different locations and using different PCIe peripherals.

One team reported a failure involving a PCIe CAN controller card.

Symptoms included:

PCIe endpoint not detected
Link training failures
Device initialization timeouts

Investigation revealed the root cause:

The PCIe root complex driver used a hard-coded link establishment timeout of:

1 ms

This was sufficient for the Intel i210 card but insufficient for the CAN controller hardware, which required up to:

5 ms

to establish the PCIe link reliably.

🚫 Why Hard-Coding Was the Wrong Solution
#

The simplest fix would have been increasing the timeout globally.

However, this introduced a tradeoff.

If no PCIe endpoint device was installed:

The driver would still wait unnecessarily
System boot time would increase
All deployments would incur the penalty

For embedded systems, particularly those with strict startup requirements, unnecessary delays are undesirable.

The better solution was making the timeout configurable per target system.

🔧 Converting the Timeout into a VxBus Parameter
#

The first step was converting the hard-coded timeout into a VxBus device-specific parameter.

A parameter table was added to the driver:

LOCAL VXB_PARAMS rcarH3PcieParams[] =
    {
    { DLLACT_TIMEOUT_PARAM, VXB_PARAM_INT32, { (void *)DLLACT_TIMEOUT_US } },
    { NULL, VXB_PARAM_END_OF_LIST, { NULL } }
    };

This table defines:

Parameter name
Parameter type
Default value

The driver now had a configurable timeout rather than relying on a fixed compile-time constant.

🚌 Enabling Parameter Support in the Driver
#

Next, the VxBus driver definition was updated to advertise parameter support.

This was done using:

VXB_DRVFLAG_PARAM

Example:

VXB_DRV vxbFdtRcarH3PcieDrv =
    {
    { NULL },
    RCAR_H3_PCIE_DRV_NAME,
    "Renesas R-Car H3 PCIe driver",
    VXB_BUSID_FDT,
    VXB_DRVFLAG_PARAM,
    0,
    rcarH3PcieMethodList,
    rcarH3PcieParams
    };

This flag tells the VxBus framework that the driver supports configurable runtime parameters.

📥 Retrieving Parameters During Driver Initialization
#

The driver initialization logic was then updated to retrieve the parameter dynamically:

if (vxbParamGet (pDev,
                 DLLACT_TIMEOUT_PARAM,
                 VXB_PARAM_INT32,
                 &param) == OK)
    {
    dllActTimeoutUs = (unsigned)param.int32Val;
    }

If the parameter was unavailable, the driver fell back to its default value.

This mechanism allows:

Sensible default behavior
Optional board-specific overrides
Runtime flexibility without source changes

The resulting implementation became substantially more portable across hardware variants.

🌲 Overriding Parameters from the Device Tree
#

The final step involved overriding the parameter using the device tree.

VxWorks 7 supports driver parameter overrides inside the chosen node using a devparam section.

General structure:

chosen {
    devparam {
        <device>@<unit> {
            <parameter> = <value>;
        };
    };
};

This mechanism allows platform-specific driver tuning without modifying driver source code.

🛠️ PCIe Timeout Override Example
#

The R-Car H3 device tree was updated to increase the PCIe DLL activation timeout:

chosen
{
    devparam
    {
        renesas,rcar-h3-pcie@0
        {
            dllActTimeoutUs = <5000>;
        };
    };
};

This changed the timeout from:

1000 us

to:

5000 us

for that specific hardware configuration.

No driver recompilation was required.

🧪 Debug Output and Validation
#

With no PCIe card installed, the driver produced:

rcarH3PcieHwInit: pDev 0xffff80000011f980:
PCIe DLL not ready after 5000us

This confirmed:

The parameter override was applied
The driver used the new timeout value
Device-tree configuration successfully influenced runtime behavior

The engineering team using the CAN controller could now tune the timeout independently for their deployment.

🚀 Why Device-Specific Parameters Matter
#

Device-specific parameters provide several major advantages in embedded systems development.

Flexible Hardware Support
#

Different boards and peripherals often require:

Different timing constraints
Alternative initialization sequences
Hardware-specific tuning

Device parameters allow a single driver binary to support multiple deployment scenarios.

Reduced Source Modifications
#

Without configurable parameters, teams frequently:

Fork drivers
Introduce board-specific patches
Create maintenance fragmentation

Parameterization reduces long-term maintenance overhead.

Faster BSP Scalability
#

As BSPs expand across:

Multiple boards
Multiple customers
Multiple peripherals

device-specific tuning becomes increasingly important.

Cleaner Separation of Policy and Mechanism
#

The driver provides:

Mechanism

while the device tree provides:

Policy

This separation is a core principle of modern embedded platform design.

🧠 VxBus and Modern Embedded Driver Architecture
#

VxBus provides a modular driver framework designed to support scalable BSP development across modern SoCs and heterogeneous hardware environments.

Capabilities include:

Device tree integration
Runtime parameterization
Dynamic driver discovery
Layered bus management
Platform abstraction

As embedded systems continue to grow more configurable and modular, runtime tunability becomes increasingly valuable.

Device-specific parameters are a small but powerful feature that can dramatically improve BSP portability, maintainability, and deployment flexibility.