NXP QorIQ P1010 VxWorks 6.6 BSP Architecture Guide

NXP QorIQ P1010 VxWorks 6.6 BSP Architecture Guide

The NXP QorIQ P1010 is a low-power communications processor based on the e500-v2 Power Architecture core. Developing a Board Support Package (BSP) for VxWorks 6.6 requires more than basic CPU initialization: the BSP must establish memory translation, cache behavior, Local Access Windows (LAW), interrupt routing, peripheral address spaces, and VxBus device discovery.

The BSP forms the hardware abstraction layer between the P1010 platform and the VxWorks kernel. Its initialization sequence must bring the processor from early boot assembly into a fully configured runtime environment where drivers can safely access DDR memory, CCSR registers, Ethernet controllers, PCI Express, USB, storage, and other peripherals.

At a high level, the platform initialization path can be represented as:

                 P1010 Reset
                      |
                      v
                 romInit.s
                      |
                      v
        CPU / Cache / Initial TLB Setup
                      |
                      v
             CCSR / LAW Configuration
                      |
                      v
               DDR / eLBC Mapping
                      |
                      v
             Interrupt Controller
                      |
                      v
               VxWorks Kernel
                      |
                      v
              VxBus Enumeration
                      |
          +-----------+-----------+
          |           |           |
          v           v           v
        eTSEC       PCIe        USB/eSDHC

🧠 P1010 Processor Architecture

#

The P1010 integrates a single e500-v2 Power Architecture CPU core with an integrated memory and peripheral subsystem targeted at embedded networking and communications applications.

CPU Core

#

The processor contains a single 32-bit e500-v2 core.

The core provides:

• Power Architecture instruction execution
• Memory-management support
• L1 instruction and data caches
• Integrated interrupt support
• Signal Processing Engine (SPE) functionality
• Application-specific acceleration support

The SPE APU extends the processor’s computational capabilities for signal-processing and floating-point workloads.

Cache and Memory Hierarchy

#

The P1010 memory subsystem includes:

• 32 KB L1 instruction cache
• 32 KB L1 data cache
• 256 KB unified L2 cache/SRAM
• Integrated DDR3/DDR3L memory controller
• Optional DDR ECC support

The BSP must initialize cache and memory attributes correctly before normal VxWorks execution begins.

Incorrect memory attributes can produce particularly difficult failures because the same physical region may be accessed through different mappings with incompatible cacheability or coherency behavior.

System Controllers

#

Two components are particularly important during BSP initialization:

• Local Access Windows (LAW): Define how system address regions are routed toward memory and peripheral targets.
• Enhanced Local Bus Controller (eLBC): Provides interfaces for NOR Flash, NAND Flash, and other static-memory devices.

LAW configuration is therefore closely connected to the BSP’s MMU/TLB mapping strategy.

🔌 P1010 Peripheral and VxWorks Driver Mapping

#

VxWorks 6.6 uses the VxBus infrastructure to provide a structured mechanism for discovering and attaching hardware devices to their corresponding drivers.

The following mapping provides a conceptual relationship between P1010 hardware and the VxWorks driver stack.

Exact driver names and supported capabilities can vary with the VxWorks 6.6 installation, BSP revision, and vendor-specific driver package.

🌐 Ethernet: eTSEC Integration

#

The P1010 integrates three Enhanced Three-Speed Ethernet Controllers (eTSEC).

The Ethernet BSP layer typically has to coordinate several components:

VxWorks Network Stack
          |
          v
      MUX / END
          |
          v
   eTSEC VxBus Driver
          |
          v
       eTSEC MAC
          |
       MII / MDIO
          |
          v
        PHY

The controller supports common Ethernet rates including:

• 10 Mbps
• 100 Mbps
• 1000 Mbps

Depending on board design, the MAC may connect to the external PHY through interfaces such as RGMII, SGMII, or MII.

The BSP’s network initialization must establish the MAC address, configure the PHY, initialize the MII/MDIO management interface, and register the network device with the VxWorks networking stack.

Hardware-assisted checksum operations and timestamping can also reduce CPU overhead for supported network workloads.

MAC and PHY Initialization

#

A BSP network implementation commonly needs to address:

1. Reading or defining the Ethernet MAC address.
2. Configuring the eTSEC controller.
3. Initializing the MII/MDIO bus.
4. Detecting and configuring the external PHY.
5. Establishing link speed and duplex state.
6. Registering the interface with the VxWorks network stack.

The PHY configuration must match the actual board-level interface and clocking arrangement.

🧱 PCI Express Integration

#

The P1010 provides two PCI Express controllers.

A VxWorks BSP must configure the PCIe controller and establish the address translation required between the processor’s address space and PCIe memory or I/O regions.

The conceptual architecture is:

VxWorks PCI Device Driver
          |
          v
      vxbPci Layer
          |
          v
     PCIe Controller
          |
          v
   PCIe Address Translation
          |
          v
       PCIe Device

Inbound and Outbound Windows

#

PCIe address translation generally requires two directions of mapping:

• Outbound: CPU-generated accesses targeting PCIe devices.
• Inbound: PCIe bus transactions targeting processor memory.

These mappings are controlled through PCIe controller configuration and related CCSR registers.

A BSP implementation may centralize this configuration in code such as:

sysPci.c

The exact register programming depends on whether the P1010 operates as a PCIe Root Complex or under another supported configuration.

🔗 USB 2.0 and eSDHC Storage

#

The P1010’s USB and storage controllers also need to be integrated into the VxBus hierarchy.

USB EHCI

#

The USB 2.0 controller supports high-speed USB operation through an EHCI-compatible controller.

The corresponding software path can be represented as:

VxWorks USB Stack
        |
        v
     vxbEhci
        |
        v
   USB Controller
        |
        v
    USB Device

Mass-storage devices can then be exposed through the appropriate VxWorks USB storage and block-device layers.

eSDHC

#

The integrated eSDHC controller provides SD/MMC storage support.

A typical software stack is:

DOSFS / HRFS
     |
     v
   XBD
     |
     v
 vxbSdMmc
     |
     v
   eSDHC
     |
     v
 SD / MMC Media

DMA support is particularly important for reducing CPU involvement during sustained storage transfers.

🛠️ BSP Source Tree and Responsibilities

#

A P1010 VxWorks BSP typically separates hardware initialization, network configuration, build parameters, and low-level system definitions across several source files.

config.h

#

The BSP configuration header commonly contains:

• BSP feature flags
• Clock-frequency definitions
• SYS_CLK_RATE
• CCSR base address definitions
• Driver inclusion macros
• Board-specific configuration options

For example, definitions related to the system clock should match the actual board clocking architecture rather than relying on generic processor assumptions.

sysLib.c

#

sysLib.c is typically responsible for low-level board initialization.

Important routines may include:

sysModel()
sysHwInit()
sysHwInit2()

Responsibilities can include:

• Board identification
• LAW configuration
• MMU/TLB initialization
• Peripheral mapping
• Memory configuration
• Hardware initialization sequencing

The exact division of responsibilities depends on the BSP implementation and VxWorks version.

sysNet.c

#

Network-specific initialization is commonly placed in sysNet.c.

Typical responsibilities include:

• MAC address configuration
• PHY initialization
• MII/MDIO configuration
• Ethernet controller setup
• Network-device registration

This layer connects board-specific Ethernet information to the generic VxWorks network driver infrastructure.

Makefile

#

The BSP Makefile controls the build configuration.

Relevant settings can include:

CC_ARCH = -tPPCe500v2

as well as:

RAM_LOW_ADRS
RAM_HIGH_ADRS

and BSP image-generation rules.

These settings determine the target processor architecture, memory layout assumptions, and boot image configuration.

🚀 BSP Boot and Initialization Sequence

#

The P1010 BSP must establish a valid execution environment before the VxWorks kernel can initialize higher-level services.

A simplified boot sequence is:

Reset
  |
  v
romInit.s
  |
  +--> Disable / initialize interrupts
  |
  +--> Establish initial TLB mappings
  |
  +--> Configure CCSR access
  |
  +--> Initialize preliminary hardware
  |
  v
usrInit()
  |
  v
sysHwInit()
  |
  +--> LAW configuration
  +--> MMU / TLB mappings
  +--> Memory initialization
  +--> Peripheral address mapping
  |
  v
Interrupt / Timer Initialization
  |
  v
VxWorks Kernel Initialization
  |
  v
VxBus Device Discovery
  |
  +--> eTSEC
  +--> PCIe
  +--> USB
  +--> eSDHC
  |
  v
Application Runtime

⚡ Early Boot: romInit.s

#

romInit.s executes during the earliest BSP startup phase.

Because normal kernel services are not yet available, this stage must rely on low-level processor operations.

Typical responsibilities include:

• Initial interrupt-state configuration
• Processor register setup
• Preliminary TLB configuration
• Early CCSR access configuration
• Basic memory or bus initialization
• Transfer of control to the next initialization stage

The exact sequence is strongly dependent on the boot medium and BSP image type.

The critical requirement is to establish enough addressability and processor state for C code to execute safely.

🗺️ LAW and MMU/TLB Configuration

#

LAW and MMU configuration is one of the most important parts of the P1010 BSP.

These mechanisms solve related but distinct problems.

Local Access Windows

#

LAW configuration determines how processor address ranges are routed to hardware targets.

A conceptual mapping might look like:

Processor Address Space
        |
        +------------------> DDR
        |
        +------------------> CCSR
        |
        +------------------> eLBC / Flash
        |
        +------------------> PCIe

The BSP must configure these windows so that accesses to each physical region reach the intended hardware target.

TLB1 Memory Mappings

#

The e500-v2 MMU uses translation structures to map effective addresses to physical addresses.

Static TLB entries can be used for regions such as:

• DDR RAM
• CCSR registers
• Flash
• PCIe memory space
• Other memory-mapped peripherals

Each mapping also needs appropriate memory attributes.

For example, device registers generally should not be treated like ordinary cacheable RAM.

A conceptual mapping table might look like:

The exact MAS/TLB attributes depend on the e500-v2 memory model and BSP implementation.

⏱️ Interrupt and Timer Initialization

#

The BSP must configure the P1010 interrupt architecture before peripheral drivers can reliably operate.

The interrupt path can be represented as:

Peripheral
    |
    v
Hardware IRQ
    |
    v
OpenPIC / EPIC
    |
    v
CPU Exception / Interrupt Vector
    |
    v
VxWorks Interrupt Handling
    |
    v
Device Driver ISR

The interrupt controller is responsible for routing hardware events from devices such as:

• eTSEC
• PCIe
• Timers
• USB
• Other local peripherals

Correct interrupt initialization is essential because a driver may appear to initialize successfully while remaining non-functional if its interrupt vector, priority, or controller routing is incorrect.

System Timers

#

VxWorks also requires a functioning system clock source for task scheduling, timeout handling, and other kernel services.

The BSP therefore needs to establish the appropriate timer source and configure the interrupt path before normal kernel scheduling begins.

🧩 VxBus Device Discovery

#

One of the major architectural differences between older VxWorks BSPs and VxWorks 6.x is the use of VxBus for structured device discovery and driver attachment.

A simplified VxBus flow is:

Hardware Description / BSP Configuration
                  |
                  v
             VxBus Core
                  |
                  v
          Device Discovery
                  |
                  v
        Driver Matching
                  |
                  v
          Driver Attach
                  |
                  v
       Device Initialization

The BSP provides the platform information required for VxBus to identify devices and establish their resources.

These resources can include:

• Register addresses
• Interrupt vectors
• DMA resources
• Clocks
• PHY interfaces
• Bus relationships

hardWareInterFaceInit()

#

A BSP may invoke a hardware-interface initialization routine such as:

hardWareInterFaceInit();

to establish the platform’s hardware interface and trigger VxBus-related device initialization.

The exact function name and call path should be verified against the specific BSP source because VxWorks BSP implementations can differ.

🔬 Driver Initialization Dependencies

#

Peripheral initialization is not independent. Many devices depend on lower-level resources being configured first.

For example, Ethernet initialization may require:

Clock Setup
    |
    v
CCSR Mapping
    |
    v
eTSEC Initialization
    |
    v
MII / MDIO
    |
    v
PHY Configuration
    |
    v
MAC Link Setup
    |
    v
VxBus / Network Registration

Likewise, PCIe initialization can depend on correct LAW and MMU mappings:

LAW Configuration
       |
       v
PCIe Controller Setup
       |
       v
Inbound / Outbound Windows
       |
       v
Link Training
       |
       v
PCI Enumeration
       |
       v
Device Driver Attachment

This dependency chain explains why a peripheral driver failure is not necessarily caused by the driver itself. A missing LAW entry, invalid TLB attribute, incorrect clock configuration, or interrupt-routing problem can surface later as a driver initialization failure.

🐞 BSP Debugging Strategy

#

Debugging a VxWorks BSP should proceed from the lowest hardware layer upward.

A useful diagnostic hierarchy is:

CPU Reset / Assembly
        |
        v
MMU / TLB
        |
        v
LAW / CCSR
        |
        v
DDR / Memory
        |
        v
Interrupt Controller
        |
        v
Peripheral Controller
        |
        v
VxBus Driver
        |
        v
VxWorks Service
        |
        v
Application

If the system fails before sysHwInit() completes, investigating application-level drivers is premature.

Similarly, if VxBus discovers the device but the driver fails during attachment, verify the hardware resource information before assuming a driver implementation problem.

Useful Debugging Questions

#

For a failing peripheral, verify:

1. Is the corresponding LAW configured?
2. Is the device register region mapped by a valid TLB entry?
3. Are the memory attributes correct?
4. Is the peripheral clock enabled?
5. Is the hardware reset state released?
6. Is the interrupt routed correctly?
7. Does the VxBus device resource table match the hardware?
8. Does the driver receive the expected register base address?
9. For Ethernet, is the PHY accessible through MDIO?
10. For PCIe, has link training completed?

This approach reduces debugging time by separating address-translation, hardware, interrupt, and software-layer failures.

📊 P1010 BSP Initialization Summary

#

🔍 Conclusion

#

A VxWorks 6.6 BSP for the NXP QorIQ P1010 is fundamentally an exercise in establishing a correct hardware abstraction layer before higher-level VxWorks services and drivers are allowed to operate.

The critical initialization path begins with the e500-v2 processor and early boot assembly, then establishes CCSR access, LAW routing, MMU/TLB mappings, DDR memory, interrupt routing, and system timers. Once those foundations are stable, VxBus can discover and attach drivers for eTSEC Ethernet, PCI Express, USB, eSDHC storage, and other peripherals.

The most important architectural relationship is:

        CPU / MMU
           |
           v
      LAW / Addressing
           |
           v
   CCSR + Peripheral Maps
           |
           v
     Interrupt System
           |
           v
         VxBus
           |
     +-----+-----+--------+
     |           |        |
    eTSEC       PCIe     USB/eSDHC
     |           |        |
     +-----------+--------+
                 |
                 v
          VxWorks Services

For BSP development, address translation and hardware routing should be validated before driver debugging begins. A correctly configured LAW window, TLB entry, interrupt vector, and peripheral resource table establishes the foundation on which VxBus and the rest of the VxWorks software stack depend.