VxWorks 7 BSP Design Guide for Embedded Developers

Comprehensive Guide to BSP Design for VxWorks 7

In real-time operating system (RTOS) environments, VxWorks 7 is widely used in mission-critical systems across aerospace, automotive, defense, and industrial automation. One of the key mechanisms enabling VxWorks to run on different hardware platforms is the Board Support Package (BSP).

A BSP provides the hardware abstraction layer between the operating system and the target board. It contains initialization code, low-level drivers, and platform configuration that allow the VxWorks kernel to interact with CPU, memory, and peripherals.

This guide provides a practical overview of BSP design for VxWorks 7, including architecture, development workflow, driver integration, and debugging practices for embedded developers.

🧱 Understanding BSP in VxWorks 7

#

A Board Support Package (BSP) is a collection of hardware-specific software components that enable VxWorks to boot and operate on a target platform.

Typical responsibilities of a BSP include:

• Board hardware initialization during boot
• CPU and memory configuration
• Interrupt and timer setup
• Device driver initialization
• Providing interfaces between the OS and peripherals

Without a properly implemented BSP, the VxWorks kernel cannot boot or access the hardware resources of a board.

Compared with earlier releases, VxWorks 7 introduces a more modular architecture, primarily through two important frameworks:

• VxBus for device driver abstraction and device discovery
• Flattened Device Tree (FDT) for hardware description

This modular design significantly simplifies BSP porting and hardware support.

🏗️ VxWorks 7 BSP Architecture

#

The BSP architecture in VxWorks 7 is layered to improve portability and maintainability.

Typical layers include:

Board Layer

Contains board-specific configuration such as:

• Clock and PLL setup
• GPIO initialization
• Memory controller configuration

Processor Support Library (PSL)

Provides CPU-specific functionality including:

• Cache management
• MMU configuration
• Exception handling

Board Subsystem

This layer integrates peripheral devices using the VxBus framework, enabling device drivers to be registered and discovered dynamically.

Kernel Integration

The BSP connects hardware initialization routines to the VxWorks kernel boot sequence and startup tasks.

Together these layers form the platform abstraction that sits between hardware and the operating system.

🔌 Core Driver Frameworks

#

Several driver frameworks are commonly used within VxWorks BSP implementations.

VxBus

The primary device driver framework in VxWorks 7.
It provides:

• Bus-independent device driver architecture
• Automatic device discovery
• Driver lifecycle management

END (Enhanced Network Driver)

The END framework is used for Ethernet controller drivers and integrates with the VxWorks networking stack.

I/O System

The VxWorks I/O subsystem manages character and block devices such as:

• Serial ports
• Storage devices
• Pseudo terminals

These frameworks provide the standardized interfaces used by BSP developers.

🧰 Setting Up the Development Environment

#

Before starting BSP development, several tools and resources are required.

Development Tools

• Wind River Workbench 4 (or newer)
• VxWorks 7 source packages
• Reference BSP from Wind River BSP library

Simulation Tools

Virtual platforms such as Simics are often used to test early BSP implementations before hardware becomes available.

Hardware Documentation

Developers must obtain detailed hardware documentation including:

• CPU architecture manuals
• Peripheral register maps
• Board schematics
• Memory layout specifications

Prerequisites

Effective BSP development requires:

• Strong C programming skills
• Assembly language knowledge
• Familiarity with RTOS concepts
• Experience with embedded debugging tools

⚙️ BSP Creation Workflow

#

Creating a BSP typically follows a structured process. The example below assumes an ARMv8-A platform such as the NXP i.MX8.

Create a VxWorks Source Build (VSB)

#

A VxWorks Source Build (VSB) compiles the OS source code for the target architecture.

Typical steps include:

1. Create a new VxWorks Source Build project in Workbench.
2. Select a reference BSP and CPU architecture.
3. Enable features such as SMP if the platform is multicore.
4. Build the project to generate kernel libraries.

The VSB provides the base system components used by the BSP and image project.

Generate a BSP Skeleton

#

Workbench can generate a basic BSP template containing essential files.

Typical generated files include:

• romInit.s
• sysLib.c
• sysALib.s
• config.h
• Makefile

This skeleton provides the starting point for board initialization code.

🚀 Boot and Hardware Initialization

#

Early boot code is responsible for bringing the hardware into a usable state before the kernel starts.

Boot Assembly (romInit.s)

#

The romInit.s file contains the earliest execution code after reset.

.section .text
.globl romInit
romInit:
    ldr x0, =_vector_table
    msr VBAR_EL1, x0

    ldr x0, =__stack_top
    mov sp, x0

    ldr x0, =0x40000000
    ldr x1, =0x00001234
    str x1, [x0]

    bl sysInit
    b .

This stage typically performs:

• Exception vector setup
• Stack initialization
• Early clock configuration
• Transfer control to C initialization routines

System Library Initialization

#

The sysLib.c file implements core board initialization functions.

#include <vxWorks.h>

LOCAL char *sysPhysMemTop = (char *)0x80000000;

void sysHwInit(void)
{
    *(volatile UINT32 *)0x40001000 = 0x00000101;
}

char *sysMemTop(void)
{
    return sysPhysMemTop;
}

Common responsibilities include:

• Memory controller initialization
• Peripheral configuration
• Board-specific hardware setup

Interrupt Controller Setup

#

Interrupt controllers must be initialized before enabling interrupts.

void sysIntInit(void)
{
    *(volatile UINT32 *)0xF9000000 = 0x1;
}

This typically involves configuring components such as ARM Generic Interrupt Controller (GIC) hardware.

🔧 Device Driver Implementation

#

Device drivers are a central component of BSP development.

UART Serial Driver

#

Serial drivers are usually implemented first because they provide console access for debugging.

#define UART_BASE 0xF8000000

void uartInit(void)
{
    *(volatile UINT32 *)(UART_BASE + 0x0C) = 0x83;
}

int uartPutChar(char c)
{
    while (!(*(volatile UINT32 *)(UART_BASE + 0x14) & 0x20));
    *(volatile UINT32 *)(UART_BASE + 0x00) = c;
    return 1;
}

These drivers typically integrate with:

• ttyDrv
• tyLib

to provide standard terminal interfaces.

System Timer Driver

#

The system timer driver provides the periodic interrupt used by the kernel scheduler.

Responsibilities include:

• Hardware timer initialization
• Tick rate configuration
• Interrupt service routine implementation

Typical tick rates are 1 ms or 10 ms, depending on system requirements.

Network Driver (END Framework)

#

Ethernet drivers in VxWorks commonly use the END driver framework.

Example device structure:

typedef struct {
    END_OBJ endObj;
} MY_ENET_DEV;

The driver typically implements:

• Initialization routines
• Packet transmission
• Packet reception
• Interrupt handling

Devices are registered with the network stack using:

muxDevLoad()

🌳 Flattened Device Tree Integration

#

Modern VxWorks BSPs often use a Flattened Device Tree (FDT) to describe hardware components.

A device tree source file (.dts) defines:

• CPU configuration
• Memory regions
• Peripheral devices
• Interrupt mappings

This file is compiled into a .dtb binary and loaded during boot, allowing the kernel and drivers to discover hardware dynamically.

Using FDT significantly improves BSP portability across boards.

🧪 Testing and Debugging

#

After implementation, the BSP must be validated through systematic testing.

Common debugging methods include:

• Serial console output
• JTAG debugging
• Wind River Workbench debugger
• System Viewer performance analysis

Typical validation tests include:

Successful completion of these tests confirms correct BSP integration.

🧠 BSP Design Best Practices

#

Developing a reliable BSP requires careful design and testing.

Recommended practices include:

Use VxBus for drivers

This ensures consistent device management and simplifies integration.

Enable early debugging output

Early boot debug prints help diagnose failures before the kernel starts.

Design for scalability

Consider SMP support and future hardware revisions.

Validate hardware registers carefully

Incorrect register addresses are a common source of BSP failures.

Study reference BSPs

Wind River reference implementations provide valuable design patterns.

⚡ Advanced BSP Topics

#

As embedded platforms become more complex, BSP development may include additional capabilities:

• Secure boot integration
• Multicore CPU initialization
• Power management frameworks
• Virtualization support
• Containerized runtime environments

These advanced features often require close integration between the BSP, kernel configuration, and middleware.

A well-designed BSP is fundamental to building reliable embedded systems with VxWorks 7. By combining low-level hardware knowledge with VxWorks frameworks such as VxBus and FDT, developers can create robust platform support for modern embedded hardware.