Skip to main content

Build Self-Booting VxWorks Images with Archive Libraries (.a)

·611 words·3 mins
VxWorks RTOS Embedded Systems U-Boot BSP Static Linking Archive Library Tornado PowerPC
Table of Contents

Build Self-Booting VxWorks Images with Archive Libraries (.a)

🔍 Overview
#

Modern embedded systems increasingly require autonomous operation without manual intervention. A common production requirement is a self-booting VxWorks image that integrates both the operating system and user applications into a single binary, enabling automatic execution at power-on.

This article presents a practical and scalable approach for building self-booting VxWorks images. It compares traditional static linking methods with a more maintainable and optimized approach using archive libraries (.a), including concrete build examples and integration techniques.


⚙️ VxWorks System Composition
#

A typical VxWorks-based system consists of three core components:

  • bootrom: Initializes hardware and loads the OS
  • VxWorks kernel: Provides RTOS services
  • User applications: Implement system functionality

Development vs Deployment Model
#

Phase Component Description
Development bootrom Hardware-specific initialization, stored in ROM
VxWorks Kernel image, downloaded or loaded
User Programs Developed and debugged independently
Deployment bootrom Fixed in ROM
VxWorks + User Applications Integrated and stored in Flash

A self-booting image combines VxWorks and user applications into a single executable that runs automatically after system startup.


🚀 Self-Booting Image Creation Methods
#

Static Linking Overview
#

Static linking embeds user code directly into the VxWorks image. Two approaches are commonly used:


🧩 Method 1: Linking Source Files (.c)
#

Integration Example
#

/* usrConfig.c */

#include "usrAPI/myApp.c"

void usrRoot(char *pMemPoolStart, unsigned memPoolSize)
{
    /* VxWorks initialization */
    
    myAppInit();  /* Start user application */
}

Characteristics
#

  • Simple integration
  • Requires direct source inclusion
  • Poor portability across BSPs
  • Exposes source code

🧩 Method 2: Linking Object Files (.o)
#

Makefile Integration
#

# Makefile

LIB_EXTRA = \
    usrAPI/app1.o \
    usrAPI/app2.o

Header Declaration
#

/* usrAPI.h */

#ifndef __USR_API_H__
#define __USR_API_H__

void app1Init(void);
void app2Init(void);

#endif

Usage in usrRoot
#

#include "usrAPI/usrAPI.h"

void usrRoot(char *pMemPoolStart, unsigned memPoolSize)
{
    app1Init();
    app2Init();
}

Characteristics
#

  • Keeps BSP and application code separate
  • Protects source code (binary distribution)
  • Maintains clean project structure

📦 Archive Library Method (.a) — Recommended #

Why Use Archive Libraries
#

Using .a libraries provides:

  • Automatic inclusion of only referenced symbols
  • Reduced final image size
  • Clean separation of modules
  • Simplified portability across BSPs

🛠️ Step 1: Create Archive Library
#

Build Script (makea.bat)
#

@echo off

set WIND_HOST_TYPE=x86-win32
set WIND_BASE=C:\Tornado
set PATH=%WIND_BASE%\host\%WIND_HOST_TYPE%\bin;%PATH%

rem Create archive library for PowerPC
arppc -crusv usrAPI.a app1.o app2.o utils.o

🛠️ Step 2: Integrate Library into VxWorks
#

Makefile Configuration
#

# Makefile

LIB_EXTRA = usrAPI/usrAPI.a

🛠️ Step 3: Header Interface
#

/* usrAPI.h */

#ifndef __USR_API_H__
#define __USR_API_H__

void app1Init(void);
void app2Init(void);
void utilsInit(void);

#endif

🛠️ Step 4: Application Entry Hook
#

#include "usrAPI/usrAPI.h"

void usrRoot(char *pMemPoolStart, unsigned memPoolSize)
{
    app1Init();
    app2Init();
}

🛠️ Step 5: Full Build Process
#

makeclean
makeall

🔄 Updating User Applications
#

To update application logic without restructuring:

  1. Recompile .o files
  2. Rebuild archive:
arppc -crusv usrAPI.a *.o
  1. Force rebuild:
makeclean
makeall

⚖️ Method Comparison
#

Method Pros Cons
.c Linking Simple, no Makefile changes Poor portability, exposes source
.o Linking Clean structure, protects IP Includes all symbols
.a Linking Optimized size, modular, portable Slightly more setup

🔧 BSP Integration Notes
#

  • Place usrAPI under BSP directory
  • Modify config.h for feature inclusion
  • Customize boot behavior via bootconfig.c

Example: Auto-Boot Configuration
#

/* bootconfig.c */

void autoboot(void)
{
    sysClkRateSet(100);
    printf("Auto booting VxWorks with user app...\n");
}

✅ Conclusion
#

Creating a self-booting VxWorks image is essential for production-grade embedded systems. While traditional static linking methods remain viable, the archive library (.a) approach offers clear advantages:

  • Smaller and optimized binaries
  • Better code organization
  • Easier cross-platform portability
  • Improved maintainability

For modern embedded workflows, especially in large-scale or multi-platform deployments, the .a-based integration method provides the most robust and scalable solution.

Reference: Build Self-Booting VxWorks Images with Archive Libraries (.a)

Related

VxWorks 7 on T2080: BSP, U-Boot, and Kernel Adaptation Guide
·626 words·3 mins
VxWorks 7 T2080 U-Boot BSP Device-Tree Embedded Systems RTOS PowerPC VxBus
Adapting VxWorks 7 to the T2080 PowerPC Processor
·823 words·4 mins
VxWorks RTOS PowerPC Embedded Systems BSP
VxWorks Target Hardware Configuration: A Practical Guide
·482 words·3 mins
VxWorks RTOS Embedded Systems Hardware BSP