Click “Read the original text” to access more VxWorks resources
If you are transitioning from an earlier version of VxWorks to VxWorks 7, you may wonder: how do I compile a bootrom? This article will explain how the boot mechanism of VxWorks 7 has changed and what it means for projects based on customized hardware. If you want to upgrade from an earlier version of VxWorks BSP, you need to read the following.
Boot Process of VxWorks 4/5/6
Before using VxWorks 7, I can remember that the boot process of VxWorks was the same: the so-called VxWorks ‘bootrom’ exists in flash memory and runs automatically from reset. The bootrom initializes all the hardware required to run VxWorks, then loads the VxWorks system (usually in ELF file format) into memory and runs it. The bootrom can load the VxWorks image from various formats of flash storage file systems or via network connections from another machine.Indeed, the bootrom is a special compiled image of VxWorks containing an application that is solely used to load the main VxWorks system image. This special compiled image contains the code that can start the processor from a reset state and bring the system to a working state; typically, this involves setting clocks, pin multiplexing, memory controllers, etc. Another special feature of the bootrom is that it can reside and be installed on read-only storage.Although this method has worked well in the past, it still has some issues:
If you are designing a BSP for a customized hardware, you will encounter the “chicken and egg” problem: you need a working BSP before you have a working bootrom, and you often need a working bootrom before you can test and debug a BSP.
As systems on chips (SoCs) integrate more functions, the process of initializing hardware becomes more complicated, and sometimes the chip manufacturers do not document it well.
SoCs have begun to include their own built-in boot code to support booting from different storage types, including NOR flash, SD cards, etc. This makes it more challenging to compile a VxWorks BSP that can work alongside the boot code of the SoC in various scenarios.
Changes Introduced by VxWorks 7
Although the overall process of booting VxWorks 7 is quite similar to older versions, some details have significantly changed, with the main changes as follows:
VxWorks 7 no longer contains code in read-only storage that can boot directly from reset to the system.
VxWorks 7 uses a Linux-style device tree to define hardware, which often needs to be loaded into memory in binary ‘blob’ format before the VxWorks kernel boots.
It may be obvious that VxWorks 7 no longer supports compiling an old-style bootrom (or any form of read-only VxWorks image); instead, the hardware must have a separate bootloader installed to run from reset and start the system.If you are using a commercial off-the-shelf hardware product, the most commonly used bootloader is likely U-Boot, and many vendors, such as NXP, provide evaluation boards with U-Boot installed. U-Boot is a widely used and powerful bootloader that can boot other operating systems such as Linux.However, what if you are building a system based on customized designed hardware and do not want to port U-Boot to that hardware? One option is to use the new VxWorks bootloader provided by Wind River, VxBL.
What is VxBL?
VxBL is a streamlined, standalone primary bootloader that can be installed on flash storage to run from reset. After initializing the processor and storage subsystem, its job is to identify a subsequent program and load it into main memory, then run it. As part of this process, VxBL can also load a standalone device tree
