Overview

After development is completed, you may need to:
– Exclude unneeded VxWorks facilities.
– Link application code into VxWorks.
– Extend VxWorks’s start-up code to spawn application tasks.

Final application may be:
– Linked with VxWorks and put into ROM or flash.
– Downloaded from host over a network.
– Loaded from a local disk.
®
13-2
1. Scaling VxWorks

The Project Facility may be used to configure all VxWorks
images (downloadable, ROMable, ROM resident) except
for boot ROM images.

Boot ROM images must be configured by editing the
config.h file for the BSP involved. VxWorks must be
rebuilt using the Tornado 1.0.1 mechanism (make in the
BSP directory).

When the new VxWorks image is built and booted, it will
initialize the facilities selected.
®
13-3
Autoscaling VxWorks

The project facility contains an Auto Scale feature which
scales VxWorks based on user application code.

Access via Project => Auto Scale... or context menu Auto
Scale... item on Workspace Builds tab.

First locates VxWorks components required by your BSP
or application; then looks for included components which
might not be needed by your application.

Auto Scale can only detect direct references to VxWorks
modules by your application. Indirect references through
pointers are not detected, so Auto Scale may suggest a
module is unneeded when it really is needed.

Provides an easy, quick start scaling VxWorks.
®
13-4
2. Application Start-up Code

The file usrAppInit.c is provided containing a stub routine
usrAppInit() in every bootable project.
void usrAppInit (void)
{
#ifdef USER_APPL_INIT
USER_APPL_INIT; /* for backwards compatibility */
#endif
/* add application specific code here */
}

If application components > application initialization is included,
then usrAppInit() will be called at startup after VxWorks
components have been initialized.

Edit usrAppInit() to include code starting your
application. Often a single taskSpawn() suffices.
®
13-5
3. Linking An Application with VxWorks

Several approaches:
– Add application source code to the bootable VxWorks project and
build together.
– Build application object modules in separate projects, and list
these modules in the EXTRA_MODULES makefile macro in the
VxWorks project build spec. The modules will be linked with the
VxWorks image when it is built.
– Build archive(s) containing application modules. Add archive(s) to
LIBS makefile macro in VxWorks build spec. VxWorks /
usrAppInit() code will be linked against these libraries.

Combined approaches are possible.
®
13-6
4. VxWorks Build Targets

The Project Facility can build the following VxWorks
images in a bootable project:
– vxWorks
– vxWorks_rom
– vxWorks_romCompress
– vxWorks_romResident

These are listed in the drop-down list in the drop-down
list on the Rules tab of the projects build spec Properties
dialog.

The rule selected in the drop down list is the default rule
which is built in a Build Project or Re-Build All.
®
13-7
ROMable Images

ROMable images contain bootstrap code which copies
VxWorks from ROM to RAM, decompressing if necessary.

The bootstrap code is target/config/comps/src/romStart.c,
which is shared by all ROMable and ROM resident
projects.

vxWorks_rom contains an uncompressed, and
vxWorks_romCompress a compressed, VxWorks image,
built using the vxWorks rule.

S-record hex format images are automatically built as
vxWorks_rom.hex or vxWorks_romCompress.hex.
®
13-8
Compressed ROMable Startup
®
13-9
ROM Resident Image

vxWorks_romResident is a ROM resident image.

It executes out of ROM.

This image contains start-up code which copies only the
VxWorks data segment into RAM at RAM_LOW_ADRS. It
clears RAM in a cold reboot.

This image starts faster and uses less RAM than the
other ROMable images, but executes more slowly.

An S-record hex image is produced automatically in
vxWorks_romResident.hex.
®
13-10
“Downloadable” Image

The vxWorks image does not contain within it the
bootstrap code to copy itself out of ROM into RAM.

It requires a separate boot program to:
– obtain the image from a local storage device or from across the
network; and
– load it into RAM at RAM_LOW_ADRS to execute.

The standard VxWorks boot program which does this is a
specialized VxWorks application, coming in several
variants: bootrom, bootrom_uncmp, and bootrom_res.

The boot program may not currently be built with the
project facility. It must instead be configured and built
using the traditional BSP mechanism.
®
13-11
Standard bootrom Program, A
®
13-12
Standard bootrom Program, B
®
13-13
Rebuilding Boot ROM’s

If system image is large, downloading will overwrite the
booting code, which may fail while printing:
Loading... 400316 + 28744 + 23852

Need to increase RAM_HIGH_ADRS in:
– wind/target/config/bspName/config.h
– wind/target/config/bspName/Makefile
– The Project facility configuration for the bootable VxWorks
project.

New ROM’s are also required to boot from a local disk, or
other boot devices not configured by default into the boot
program.
®
13-14
Traditional VxWorks Configuration

The traditional VxWorks configuration mechanism is
required for configuring boot ROMs and still available for
other builds.

Edit target/config/bspName/config.h to configure
VxWorks.
– Define the INCLUDE_xxx macro for a component to include it.
– Define the values of other parameter macros.
– Many defaults are defined in target/config/all/configAll.h, and may
need to be redefined.

Build VxWorks or boot ROM using Makefile in BSP
directory, e.g. make bootrom.
®
13-15
Redundant Address Parameters

The following macros are defined in: 1. The bootable
project build spec; 2. bspName/config.h; and 3.
bspName/Makefile.
RAM_LOW_ADRS
RAM_HIGH_ADRS

They should be kept consistent in all three locations.

Also, the following should be kept consistent in a BSP’s
config.h and Makefile:
ROM_TEXT_ADRS
ROM_SIZE
®
13-16
ROM-based VxWorks Start-up
1. _romInit in config/bspName/romInit.s
– Minimal initialization: mask interrupts, disable caches, set
initial stack, initialize DRAM access.
2. romStart( ) in romStart.c or bootInit.c
– Copy text/data segment(s) to RAM, clear other RAM.
Decompress if necessary.
3. usrInit( ) in prjConfig.c or bootConfig.c
– Do pre-kernel hardware & software initialization; start
kernel by calling kernelInit( ).
4. usrRoot( ) in prjConfig.c or bootConfig.c
– Initialize facilities configured into VxWorks; start boot
program or user application
5. Boot program or user application.
®
13-17
Downloaded VxWorks Start-up
1. Boot program loads VxWorks over network, from
local disk, etc.. Call:
2. _sysInit in config/bspName/sysALib.s
– Similar to _romInit: mask interrupts, disable caches, set
initial stack pointer. Then call:
3. usrInit( ) in prjConfig.c
4. usrRoot( ) in prjConfig.c
5. User application.
®
13-18
Summary
1. Scale VxWorks using the project facility. Auto Scale
may be helpful.
2. Define application start-up code by editing the stub
usrAppInit() in usrAppInit.c in the project directory.
3. Link you application with VxWorks by including its
files, or specifying its object modules or libraries in
the EXTRA_MODULES or LIBS macros.
4. Rebuild ROMable (compressed or uncompressed),
ROM resident, or “downloadable” VxWorks images
in the project facility.
When required,
5. Rebuild boot ROMs in the BSP using the traditional
build mechanism.
®
13-19