RTOS Clause 45 PHY Support in QNX and VxWorks

Table of Contents

RTOS Clause 45 PHY Support in QNX and VxWorks

Modern Ethernet PHY devices have evolved far beyond the simple 10/100 Mbit/s transceivers originally envisioned by early IEEE 802.3 specifications. As network speeds increased and PHY functionality expanded, vendors introduced increasingly sophisticated devices requiring larger register spaces, proprietary initialization sequences, and advanced management interfaces.

Supporting these newer PHYs in embedded real-time operating systems can become surprisingly complex, particularly when combining:

Clause 45 PHY devices
Legacy Clause 22 MAC interfaces
Vendor-specific register models
RTOS-specific network driver architectures

Recently, two separate projects required adding support for a new IEEE 802.3 Clause 45 PHY:

One targeting QNX
One targeting VxWorks

Although the underlying hardware requirements were similar, the networking architectures of the two RTOSes led to very different implementation strategies.

This article explores how Clause 45 PHY management works and compares how QNX and VxWorks approach Ethernet PHY integration.

🌐 Understanding IEEE 802.3 Clause 22
#

The Ethernet PHY (physical layer device) is responsible for transmitting and receiving Ethernet signals between the MAC (Media Access Controller) and the physical medium.

Typical media include:

Twisted-pair Ethernet
CAT-5/CAT-6 cabling
Fiber optics
Backplane interfaces

IEEE 802.3 Clause 22 defines the traditional PHY management model, including the MDIO (Management Data Input/Output) interface used for:

PHY configuration
Link management
Status reporting
Auto-negotiation control

Although MDIO is technically distinct from MII, the terms are often used interchangeably in practice.

Clause 22 Addressing Model
#

Clause 22 provides:

Up to 32 PHY devices on a shared MDIO bus
A 5-bit PHY address space
32 standard registers per PHY

This model worked well for early Ethernet hardware but eventually became too limited as PHY devices evolved.

⚡ Why Clause 45 Was Introduced
#

As Ethernet PHYs became more advanced, vendors needed:

Larger register spaces
Extended diagnostics
Calibration controls
Vendor-specific features
Multi-gigabit configuration support

IEEE 802.3 Clause 45 expanded the management architecture significantly.

Clause 45 defines:

Up to 32 PHY devices on MDIO
Up to 32 MDIO Manageable Devices (MMDs) per PHY
A 16-bit register space per MMD
Up to 65,536 registers per MMD

This dramatically increased management flexibility.

Clause 45 also introduced dedicated MMDs for:

PMA/PMD management
PCS management
PHY XS layers
Vendor-specific extensions

If standard Clause 22 registers exist, they typically appear within:

MMD 0

🔄 Accessing Clause 45 Devices Through Clause 22
#

A practical problem quickly emerged after Clause 45 adoption:

Many systems still used older Clause 22 MAC controllers.

The industry solution was an indirect access mechanism allowing Clause 45 registers to be accessed using standard Clause 22 MDIO operations.

The mechanism uses:

Clause 22 Register 13
#

Used to:

Select the target MMD
Define read/write operations

Clause 22 Register 14
#

Used to:

Specify Clause 45 register addresses
Read register values
Write register values

This indirect mechanism allows legacy MAC hardware to communicate with modern Clause 45 PHYs without requiring native Clause 45 controllers.

⚠️ The Real Problem: Vendor-Specific PHY Behavior
#

Although Clause 45 standardizes much of the management model, PHY vendors frequently implement proprietary behavior.

Common examples include:

Non-standard status registers
Vendor-specific initialization sequences
Custom calibration procedures
Proprietary link reporting
Hidden diagnostic features

From a software engineering perspective, this creates substantial complexity.

Two PHYs may both claim Clause 45 support while requiring completely different initialization and runtime handling logic.

Marvell and Broadcom PHYs are particularly well known for requiring extensive vendor-specific handling.

🧩 QNX PHY Management Architecture
#

In QNX, the Ethernet MAC driver is responsible not only for MAC management but also for PHY interaction.

Responsibilities include:

PHY register access via MDIO
PHY initialization
Link negotiation
Media advertisement
Status reporting

QNX simplifies this using its MII management library.

The library provides APIs for:

PHY reset
Auto-negotiation
Link status retrieval
Duplex configuration
Speed management

This avoids duplicating PHY logic across multiple Ethernet drivers.

However, the architecture tightly couples PHY behavior with MAC driver implementation.

🔧 Clause 45 Support in QNX
#

Recent QNX releases added Clause 45 support through an updated MII management library.

QNX SDP 7.1 includes:

Clause 45 MDIO indirection support
Limited support for several PHY devices
Clause 22-to-Clause 45 register translation

However, extending support for new PHYs introduces complications.

A standard QNX development license typically does not include operating system source code, including networking libraries.

This leaves several options:

Purchase source licenses
Use vendor consulting services
Implement PHY support inside the MAC driver

None of these options were ideal for the customer involved in this project.

📊 A Data-Driven PHY Abstraction for QNX
#

Instead of modifying the MII library directly, the solution adopted a data-driven PHY abstraction model.

The implementation defined device-specific attributes such as:

PHY device identifiers
Link-speed configuration sequences
Link-status register mappings
Initialization register sequences

The key insight was to emulate a standard Clause 22 PHY interface.

Internally:

Clause 22 register accesses were intercepted
Corresponding Clause 45 operations were performed
Results were translated back into Clause 22-compatible values

This allowed the existing QNX MII management library to interact with the PHY transparently.

Advantages included:

No modification to QNX libraries
Extensible PHY support
Reduced future engineering effort
Device support driven by configuration data

This approach effectively virtualized Clause 45 PHY behavior behind a Clause 22-compatible interface.

🚌 VxWorks PHY Management Architecture
#

VxWorks uses a fundamentally different networking model.

In VxWorks:

The MAC driver handles MDIO register access
A separate PHY driver manages PHY behavior

The PHY driver is responsible for:

Link negotiation
Media advertisement
PHY configuration
Link monitoring
Speed and duplex management

This separation creates a cleaner driver architecture.

Most standard PHYs can operate using generic PHY drivers with little additional work.

Only more complex devices require dedicated PHY drivers.

🚀 Clause 45 Support in VxWorks
#

VxWorks 7 includes native support for:

Clause 45 register indirection
PHY driver models
VxBus PHY integration
MDIO abstraction layers

Unlike QNX, VxWorks development licenses typically include:

Kernel source code
Driver source code
PHY framework implementation

As a result, adding support for a new Clause 45 PHY was relatively straightforward.

The solution involved:

Implementing a new PHY driver
Integrating it with VxBus
Defining Clause 45 access behavior
Supporting vendor-specific initialization

The existing VxWorks networking infrastructure handled the remaining integration automatically.

Compared to the QNX implementation, the VxWorks solution was significantly simpler from an architectural perspective.

🧠 Comparing QNX and VxWorks PHY Models
#

The two RTOSes illustrate different philosophies in networking subsystem design.

QNX Approach
#

Advantages:

Centralized MII management
Shared PHY functionality
Reduced duplication

Disadvantages:

Tighter MAC/PHY coupling
Limited extensibility
Difficult vendor-specific integration
Restricted library visibility

VxWorks Approach
#

Advantages:

Dedicated PHY driver model
Cleaner separation of responsibilities
Easier vendor-specific support
Better scalability

Disadvantages:

More individual drivers
Potentially greater implementation effort for simple devices

For advanced Clause 45 PHYs, the VxWorks model generally scales better.

📈 The Growing Importance of Advanced PHY Support
#

Modern embedded networking increasingly relies on sophisticated Ethernet PHY devices supporting:

Multi-gigabit Ethernet
Time-sensitive networking (TSN)
Automotive Ethernet
Industrial Ethernet
Precision timing
Advanced diagnostics

As embedded systems evolve toward:

Autonomous platforms
Industrial edge computing
High-speed networking
Distributed real-time systems

robust PHY abstraction layers become increasingly important.

Clause 45 support is no longer optional in many modern embedded platforms.

🔍 Final Thoughts
#

Although both QNX and VxWorks ultimately support Clause 45 PHY devices, the engineering effort required differs significantly because of their driver architectures.

The QNX implementation required:

Protocol abstraction
Clause 22 emulation
Data-driven register translation

The VxWorks implementation largely involved:

Writing a conventional PHY driver
Integrating with VxBus
Leveraging existing PHY infrastructure

In many ways, the project highlighted how operating system architecture strongly influences driver complexity, extensibility, and long-term maintainability.

Sometimes the most difficult part of embedded networking is not the protocol itself, but the surrounding software architecture used to support it.