Booting a Hardware Target in VxWorks

#

Deploying and booting a kernel image is one of the first steps in working with hardware in a VxWorks project. This guide explains how the boot process works, the role of VxBL and BootApp, and how to use common bootloader commands.

---

Learning Objectives

#

After completing this section, you will be able to:

• Understand how VxWorks boots on hardware targets.
• Explain the two-stage bootloader model.
• Use VxBL and BootApp commands for managing the boot process.

---

Understanding the VxWorks Boot Process

#

When writing code for a target in Workbench, you are modifying the kernel image. To run it on your hardware, you need a bootloader—software that deploys the kernel image and starts the initialization sequence.

VxWorks supports multiple boot strategies, many of which depend on the specific board being used.

For board-specific details, check the readme.md file in your BSP directory:
installDir/vxworks/release/source/os/arch/
From there, locate your CPU architecture and vendor-specific board.

---

---

The Two-Stage Bootloader Model

#

VxWorks typically uses a two-stage bootloader approach, which provides flexibility and scalability across different hardware.

Here’s a breakdown of the process:

1. Power On
   The hardware target receives power and begins initialization.

2. Stage 1 Bootloader (e.g., VxBL)
   Also called bootstrap code, this lightweight loader starts the boot process.

3. Physical Storage
   The bootloader loads from storage such as Flash memory, SD card, SSD, or HDD.

4. Stage 2 Bootloader (BootApp)
   A more advanced loader that requires Stage 1. It has more resources since it runs in target memory.

5. Network Connection
   Stage 2 can fetch the kernel image via FTP or NFS server if configured.

6. Kernel Image Launch
   Once loaded, the VxWorks kernel is executed, bringing your project online.

7. ROM or System Initialization

   • romInit: Used for fast booting from ROM.
   • sysInit: Default system initialization.

---

VxBL Commands

#

The VxBL bootloader provides commands for managing files, memory, and launching the kernel.
Type help in the terminal to see the full list.

Common commands include:

• fdt – manage device tree operations
• env – manage environment variables
• ls – list directory contents
• pwd – show current working directory
• cd – change directory
• load <file> <memory address> – load file to memory
• boot <kernel address> - <device tree address> – boot kernel
• pm – show persistent memory area
• help – display command help
• @ – boot kernel using predefined scripts
• d – display address content

---

BootApp Commands

#

The BootApp stage 2 bootloader adds extended functionality.
Type h in the terminal for a quick reference.

Useful commands include:

• ? – show help list
• @ – boot (load and go)
• p – print boot parameters
• c – change boot parameters
• l – load boot file
• g adrs – jump to memory address
• e – print fatal exceptions
• v – show boot logo and version
• d adrs[,n] – display memory
• m adrs – modify memory
• f adrs, nbytes, value – fill memory
• t adrs, adrs, nbytes – copy memory

---

---

Key Takeaways

#

• The VxWorks boot process relies on a two-stage bootloader model.
• VxBL handles early initialization, while BootApp provides advanced boot and configuration options.
• Commands in both bootloaders allow developers to manage kernel loading, memory, and parameters.
• Proper understanding of the boot sequence ensures faster setup and more reliable deployment of real-time applications.