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:
- Recompile
.ofiles - Rebuild archive:
arppc -crusv usrAPI.a *.o
- 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
usrAPIunder BSP directory - Modify
config.hfor 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)