Synergy Microsystems VxWorks BSP Guide for PowerPC CPU Boards

Synergy Microsystems VxWorks BSP Guide for PowerPC CPU Boards

The Synergy Microsystems Board Support Package (BSP) provides a production-ready software foundation for a broad range of PowerPC-based VMEbus and CompactPCI processor boards running VxWorks 5.4 with Tornado 2.0. Designed for both single-processor and symmetric multi-processor deployments, the BSP includes hardware abstraction layers, device drivers, boot firmware, and platform-specific utilities required for embedded system development.

This guide summarizes installation procedures, supported hardware, multi-processor architecture, memory management, networking, and system configuration, giving developers a practical reference for integrating and deploying Synergy PowerPC platforms.

🚀 BSP Overview

#

The BSP supports numerous Synergy Microsystems CPU boards, including the Gemini family, VGM, VGMD, VSS4, KGM5, and related PowerPC platforms.

Key capabilities include:

• Single-, dual-, and quad-processor support
• Ethernet networking
• PCI and VMEbus interfaces
• SCSI storage
• Flash memory support
• ECC and parity-protected memory
• Cache management
• Boot ROM generation
• Built-in diagnostics

This release targets:

• VxWorks 5.4
• Tornado 2.0
• Document Revision 1.0b (April 6, 2001)

📦 Installing the BSP

#

Installation differs slightly between Windows and Unix development hosts.

Windows Installation

#

Execute the installer directly from the BSP distribution media:

setup.exe

Install the BSP beneath the Tornado target/ directory.

Unix Installation

#

Extract the archive from the target/ directory:

tar -xf synBSP1_21g.tar

After extraction, remove directories corresponding to unsupported board models to reduce workspace size.

Directory Layout

#

Processor-specific directories contain BSP configurations for each CPU instance.

Examples include:

svgm5x/
svgm5y/
kgm5x/

Keep the shared BSP infrastructure intact:

target/config/synergy/

Removing this directory will render the BSP unusable.

Boot ROM Images

#

A dedicated bootroms/ directory contains prebuilt bootrom.hex images suitable for programming supported hardware.

📝 Revision Highlights

#

The BSP evolved significantly throughout the 1.2/01a–1.2/01h maintenance releases.

Major enhancements include:

• END Ethernet driver as the default network interface
• Tornado Project support for bootable applications
• Improved multi-processor memory allocation
• Altivec support for PowerPC G4 processors
• External L2 cache support
• ECC and parity memory support
• Numerous VME, PCI, Ethernet, and stability fixes

Boot ROM Compatibility

#

Developers should note an important compatibility change introduced in revision 1.21h.

• Single-processor kernels generally remain backward compatible.
• Dual- and quad-processor kernels require matching, updated Boot ROM images.

Mixing newer SMP kernels with older Boot ROMs is not supported.

🖥️ Board Organization

#

The BSP separates shared infrastructure from board-specific configurations.

Common code resides within:

synergy/

Each processor type has its own configuration directory, allowing multiple hardware variants to share common drivers while maintaining independent initialization logic.

For development and testing, dual-processor hardware can also operate in single-processor mode by booting a standard single-processor kernel and Boot ROM.

⚠️ Known Limitations

#

Several platform-specific limitations should be considered during development.

Shared Memory

#

On KGM5 systems using the PReP (Grackle Map A) memory map, the shared-memory (sm) driver may hang.

Using the CHRP memory map (Map B) avoids this issue.

Processor Restart

#

Restarting VSS4 systems using Ctrl+X is not always reliable.

If processors must be restarted manually, restart the X processor last.

Build Warnings

#

Minor compiler warnings may appear during multi-processor project builds.

These warnings are expected and do not affect runtime behavior.

⚙️ Multi-Processor Architecture

#

The BSP supports dual- and quad-processor boards by running an independent VxWorks kernel on each processor.

Resource Partitioning

#

Hardware resources are divided across processors.

Typical allocation includes:

• Partitioned onboard memory
• Dedicated serial ports
• Shared Ethernet controller managed by processor X
• Shared SCSI controller
• VME interrupt routing through processor X
• Flash programming services executed exclusively by processor X

Communication between processors is typically implemented using shared memory and mailbox interrupts.

Performance Recommendation

#

All processors should either:

• boot completely, or
• operate in single-processor mode.

Leaving secondary processors inactive while powered can negatively impact system performance.

Exception Management

#

Each processor maintains its own exception table while sharing the primary exception vector located at:

0x100

This design allows processor-specific exception handling without duplicating the complete vector table.

Serial Port Allocation

#

Serial interfaces are divided among processors and can be configured using:

NUM_TTY

System Reset

#

Supported reset mechanisms include:

• Front-panel reset switches
• sysReset()

🌐 Ethernet Boot Configuration

#

Single-processor systems typically boot using the Ethernet interface.

Example boot parameters:

boot device              : esyf
file name                : /path/to/vxWorks
inet on ethernet (e)     : <target IP>
host inet (h)            : <host IP>

The default interface:

esyf

automatically negotiates 10 Mbps or 100 Mbps operation.

To force a specific speed:

• esyft — Force 10 Mbps
• esyfh — Force 100 Mbps

The Ethernet MAC address is stored in NVRAM through:

NV_ENET_ADRS

🔄 Multi-Processor Boot Configuration

#

Secondary processors boot differently from the anchor processor.

Boot Device

#

Processor X boots normally from Ethernet.

Processors Y, Z, and W typically boot from shared memory:

sm=0x4100

or another configured VME shared-memory address.

Processor Numbering

#

Processors are assigned sequential identifiers.

Only processor 0 requires a standard Ethernet address.

Secondary processors communicate using backplane networking.

Boot ROM Configuration

#

Boot parameters for additional processors can be configured directly from the X processor console using:

y

Equivalent commands exist for Z and W processors.

🛠️ Tornado Project Integration

#

The BSP supports both traditional makefile-based development and Tornado Projects.

Tornado Projects

#

Enable:

• Target Shell components
• Downloaded symbol table support

This configuration allows applications to be downloaded and debugged through Tornado.

Traditional Builds

#

For conventional BSP builds, enable:

INCLUDE_CONFIGURATION_5_2

inside:

config.h

to activate the target shell.

💾 Memory and ECC Support

#

ECC and parity initialization occurs during Boot ROM startup when:

INCLUDE_RAM_PAR_ECC

is enabled.

Capabilities include:

• Automatic correction of single-bit errors
• Detection of multi-bit memory faults
• Machine check exception reporting

Although ECC introduces moderate overhead, it substantially improves long-term system reliability.

High-Radiation Applications

#

For aerospace or industrial environments with elevated radiation exposure, implement a background memory scrubber task that periodically scans RAM.

This process proactively corrects recoverable single-bit errors before they accumulate into uncorrectable failures.

🔌 VMEbus and PCI Support

#

The BSP provides extensive support for both VMEbus and PCI hardware.

Features include:

• Universe bridge configuration
• Direct VME interface
• PCI auto-configuration
• PEX3 support
• Configurable master and slave windows

Memory mappings are defined using:

uMaster[]
dMaster[]

Address translation APIs include:

sysBusToLocalAdrs()
sysLocalToBusAdrs()

along with PCI-specific equivalents.

⚡ Additional BSP Features

#

Beyond core processor support, the BSP includes numerous platform services.

Highlights include:

• Internal and external cache management
• G4 L2 cache sizing
• Decrementer-based timestamp support
• System tick timer
• Mailbox interrupts
• NVRAM services
• Real-time clock and calendar
• SCSI support
• Local multi-processor boot capability
• Built-In Self Test (BIST)
• PU32 support
• Front-panel LED diagnostics

🏗️ Building Boot ROMs and Kernels

#

The BSP supports multiple build workflows.

Traditional BSP Build

#

Unix hosts:

make

Windows hosts use the Standard BSP Build tools provided with Tornado.

Tornado Projects

#

Bootable applications can also be generated using Tornado BSP Projects.

For multi-processor systems, build separate kernel images for each processor:

• X
• Y
• Z
• W

The BSP supports both Flash-based Boot ROM deployment and RAM-disk configurations.

🐞 Troubleshooting

#

Several utilities are available for diagnosing low-level hardware issues.

Bus Errors and Machine Checks

#

When machine checks occur, interrupt the shell using:

Ctrl+C

For memory probing, read operations are generally safer than writes.

Whenever possible, use:

sysVxMemProbe()

instead of the standard vxMemProbe() when accessing VME memory, as it provides more reliable behavior across bridge hardware.

LED Diagnostics

#

The BSP includes an extensive LED diagnostic system capable of indicating boot progress, processor state, and hardware failures.

Refer to the original BSP documentation for the complete LED status reference and fault code definitions.