Universal Method for Booting and Loading Applications in VxWorks

📘 Abstract

#

To support automatically loading different VxWorks images and applications from a single hard disk, this article presents a universal booting and application-loading method for VxWorks systems. The solution is based on separating bootrom, image, and startup configuration files, formatting the disk with DOS 7.1, and using config.sys and AutoExec.bat to dynamically select and deploy target programs. By leveraging DOS batch processing, the system can copy and activate the required bootrom, image, startup scripts, and executables at boot time, enabling a flexible “one disk, multiple applications” deployment model.

Keywords: VxWorks, embedded systems, booting and loading, system configuration

🧭 Introduction

#

VxWorks systems generally support two boot modes: load-based booting and bootable (standalone) booting.

In load-based mode, the system boots using a bootrom combined with a separate VxWorks image. This approach is widely used during development. The bootrom mounts a file system and loads the kernel image from a fixed disk location into RAM. While this method simplifies kernel replacement, it has several limitations:

• Multiple applications stored on disk must be manually renamed before loading.
• Automatic application selection is not supported without modifying the image.
• Adding or removing applications often requires recompiling the VxWorks image.

In bootable mode, the system boots directly from a self-contained image, which can be burned into Flash using VxWorks_rom. This eliminates file system dependencies but makes program updates inconvenient, as reflashing is required for every change.

To improve flexibility and usability, this article introduces a universal booting and loading method that allows multiple VxWorks images and applications to coexist on a single disk and be selected dynamically at startup.

🧠 VxWorks System Boot Process

#

A VxWorks target system requires two key components to boot:

• Bootrom – a minimal boot program responsible for hardware initialization and kernel loading
• Image – the VxWorks kernel and application image

The bootrom is generated by compiling the BSP (Board Support Package) in Tornado or Workbench. Its responsibilities include initializing hardware to a stable state and providing hardware abstraction services for the kernel.

Bootrom Execution Flow

#

1. romInit

   • Disables interrupts
   • Initializes registers and memory controller
   • Sets up the stack
   • Jumps to romStart

2. romStart

   • Copies romInit and itself into RAM (RAM_LOW_ADRS)
   • Decompresses the remaining bootrom into RAM
   • Transfers control to usrInit

3. usrInit

   • Initializes peripheral hardware
   • Prepares for kernel image download
   • Creates tUsrBoot, which calls usrRoot
   • Starts tBoot, invoking bootCmdLoop to load the image

After the image is downloaded, execution jumps to sysInit, starting the VxWorks kernel. When usrRoot completes, the system enters normal operation.

Boot Line Configuration

#

The boot process is controlled by DEFAULT_BOOT_LINE in the BSP’s config.h.

Network boot example:

#define DEFAULT_BOOT_LINE "fei(0,0) host:VxWorks h=192.168.0.33 e=192.168.0.18 u=user pw=123"

Local hard disk boot example:

#define DEFAULT_BOOT_LINE "ata=0,0(0,0) host:/ata0/VxWorks h=192.168.0.33 e=192.168.0.18 u=user pw=123"

🛠 Universal Method for Booting and Loading Applications

#

The proposed solution enables multiple images and applications to be loaded from the same disk through configuration rather than recompilation.

Generating Bootrom, Image, and Startup Files

#

The system uses load-based booting (bootrom + image). For each application set:

• Generate the corresponding bootrom and image
• Create a text-based startup script defining which applications to load and run

To enable automatic application loading, add the following code to usrAppInit.c in the image project:

int fd;
if ((fd = open("/ata0a/startup.txt", O_RDWR, 0644)) != NULL)
{
    usrStartupScript("/ata0a/startup.txt");
    close(fd);
}

Ensure the INCLUDE_STARTUP_SCRIPT component is enabled in the VxWorks image configuration.

Example startup.txt:

ld 1,0,"/ata0a/APP/rt.out";
DualNetWork_Switch_OO("198.1.108.1","198.1.108.253","255.255.255.0",66,0,0);

ld 1,0,"/ata1a/fei.out";
DualNetWorkSwitch("191.8.200.1","255.255.255.0","191.8.200.1",0);

ld 1,0,"/ata1a/iiutest";
taskSpawn 0, 100, 0, 0x1000000, main;

Disk Formatting

#

Format the boot disk using DOS 7.1, which provides compatibility with DOS startup scripts and batch processing required for dynamic file selection.

Startup Menu with config.sys and AutoExec.bat

#

The boot menu is defined in config.sys, while application-specific file replacement is handled in AutoExec.bat.

Example config.sys:

[MENU]
MENUITEM=vxWorks.dbg, Start default image
MENUITEM=jk1, JK1
MENUITEM=jk2, JK2
MENUITEM=jk1test, JK1 Test
MENUITEM=jk2test, JK2 Test
MENUDEFAULT=vxWorks.dbg,3

[vxWorks.dbg]
DEVICE=c:\HIMEM.SYS
DOS=HIGH,UMB
SHELL=C:\VXLOAD.COM C:\bootrom.dbg

Example AutoExec.bat (jk1test):

@echo off
goto %config%

:jk1test
del bootrom.dbg
copy bootrom.ts1 bootrom.dbg
del D:\APP\rt.out
copy D:\APP\rt1.out D:\APP\rt.out
del test.txt
copy test1.txt test.txt
del iiutest
copy iiutest1 iiutest
goto end

:end

This mechanism replaces default files with application-specific versions before VxWorks boots.

✅ Conclusion

#

This article presents a universal VxWorks booting and application-loading method that enables multiple images, configurations, and executables to coexist on a single disk. By separating bootrom, image, startup scripts, and applications, the system achieves high flexibility and maintainability. New applications can be added or removed by editing configuration files only, without recompiling bootroms or kernel images. The approach significantly improves usability and supports scalable, production-ready VxWorks deployments.