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

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

#

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

3. Force rebuild:

makeclean
makeall

⚖️ Method Comparison

#

🔧 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.