Fast Boot Techniques for VxWorks-Based UAV Flight Controllers

🚁 Why Fast Booting Matters for UAV Flight Controllers

#

In unmanned aerial vehicles (UAVs), system reliability is inseparable from timing guarantees. A transient software fault, electromagnetic interference, or memory corruption can trigger a watchdog reset in the flight control computer. For medium-sized UAVs using single-redundancy architectures, recovery latency directly determines survivability.

If reboot time exceeds a few seconds, the aircraft may drift outside its controllable envelope before guidance logic resumes. While VxWorks is widely adopted for its deterministic scheduling and fault tolerance, its traditional multi-stage boot sequence can become a liability in airborne reset scenarios.

A 2010 research study from Northwestern Polytechnical University proposed a fast-boot method that transforms reboot behavior from a liability into a recovery mechanism suitable for in-flight use.

🧠 Standard VxWorks Boot Flow on x86 Platforms

#

On x86-based flight control computers using flash storage such as DiskOnChip (DOC), the VxWorks boot process is typically split into two distinct stages.

Conventional Two-Stage Boot

#

1. Bootrom Stage

   • Minimal VxWorks image compiled from BSP sources
   • Initializes CPU, memory controller, and basic devices
   • Loads the full VxWorks kernel image from storage or network

2. Kernel + Application Stage

   • Parses boot parameters (BOOT_LINE_ADRS)
   • Initializes file systems and device drivers
   • Starts the kernel and invokes user application entry points

This design favors flexibility but introduces duplicated initialization and excessive I/O for time-critical systems.

⏱️ Where the Time Is Lost

#

For DOC-based systems, boot latency typically accumulates from:

• Flash driver initialization (TrueFFS)
• File system mounting
• Secondary kernel image loading
• Repeated hardware probing

In measured UAV deployments, these steps commonly result in 9–10 seconds of reboot time—far beyond acceptable limits for in-flight recovery.

⚡ One-Step Fast Boot Architecture

#

The proposed optimization collapses the two-stage boot into a single, monolithic image containing:

• CPU and board initialization
• VxWorks kernel
• User flight-control applications

Instead of loading a kernel from Bootrom, the system boots directly into the operational runtime.

🧩 BSP-Level Implementation Details

#

1. Integrating Applications into the Kernel Image

#

User applications are statically linked into the VxWorks image and initialized from usrAppInit().

/* usrAppInit.c */

#include "vxWorks.h"
#include "taskLib.h"
#include "stdio.h"

void flightControlTask (void)
{
    while (1)
    {
        /* Core flight control loop */
        printf("Flight control running...\n");
        taskDelay(sysClkRateGet());
    }
}

void usrAppInit (void)
{
    taskSpawn(
        "tFlightCtrl",
        100,
        VX_FP_TASK,
        8192,
        (FUNCPTR)flightControlTask,
        0,0,0,0,0,0,0,0,0,0
    );
}

This eliminates the need to load applications after kernel startup.

2. Building a ROM-Resident VxWorks Image

#

In the BSP or project configuration, the image is built as vxWorks_rom:

# Makefile fragment
VX_IMAGE_TYPE = vxWorks_rom

This ensures the image is fully self-contained and directly executable from flash.

3. Bootrom Replacement via Image Conversion

#

Instead of a minimal Bootrom, the full image is converted into Bootrom.sys:

objcopypentium vxWorks_rom \
    -O binary \
    Bootrom.sys

Unlike a traditional Bootrom, this binary already includes:

• Kernel
• Drivers
• Applications

No secondary image loading is required.

4. DiskOnChip Boot Configuration

#

DOC preparation follows standard tooling but becomes significantly simpler:

FDISK /dev/doc0
DFORMAT /dev/doc0
vxsys Bootrom.sys

The BIOS is configured to boot directly from DOC, bypassing unnecessary self-tests where possible.

🚀 Eliminating DOC Driver Initialization

#

In a traditional setup, TrueFFS must be initialized during boot:

/* Traditional approach */
#include "tffsDrv.h"

STATUS usrTffsInit (void)
{
    return tffsDrv();
}

With the one-step fast boot approach, this entire path is removed, since no runtime access to DOC is required after boot.

📉 Measured Performance Gains

#

The researchers validated the approach on a real UAV flight controller:

• Platform: SBS PC/104
• CPU: 486-class processor
• Storage: DiskOnChip 2000

Boot Time Comparison

#

This 3× reduction allows watchdog-triggered resets to occur during flight without loss of control.

🛡️ Reliability Benefits in UAV Systems

#

Key advantages for airborne systems include:

• Predictable reboot latency
• Reduced software complexity
• Fewer failure points during recovery
• Improved watchdog effectiveness

In practice, the reboot becomes a fault containment mechanism, not a catastrophic event.

🔮 Broader Embedded-System Implications

#

While demonstrated on x86 UAV controllers, the same principles apply broadly:

• Aerospace mission computers
• Robotics controllers
• Industrial real-time systems

Any VxWorks-based system that prioritizes availability over flexibility can benefit from collapsing boot stages and integrating applications into the kernel image.