BSP Developer's Guide

VxWorks 5.5
BSP Developer’s Guide
sysALib.s
This file contains the entry point for RAM-based images such as vxWorks. The
entry point, sysInit( ), performs the minimal setup necessary to transfer control to
usrInit( ) (defined in config/all/usrConfig.c). This routine is similar to romInit( ).
The sysInit( ) routine is largely the same for each architecture. As such, copying
the code from a template BSP is the best way to start. The sysInit( ) routine
typically just masks processor interrupts and sets the stack pointer. For processors
whose stack grows down, the stack pointer is set to sysInit( ). For processors
whose stack grows up, it is set to a few hundred bytes below sysInit( ). It then calls
usrInit( ), passing it the parameter BOOT_WARM_AUTOBOOT. Most hardware
and device initialization is performed later in the initialization sequence by
sysHwInit( ) in sysLib.c.
BSP routines should be coded in C when possible, but if there are compelling
technical reasons for resorting to assembler, then place the routines in sysALib.s.
config/all/usrConfig.c
During development you will want to add debugging code and make other such
modifications to the generic (non-BSP) configuration files. Rather than modifying
the generic code directly, instead create local copies in the BSP directory as follows:
1. First copy the files config/all/usrConfig.c and config/all/bootInit.c into your
BSP directory. Next, add the following lines to your BSP’s Makefile, right after
the definition of HEX_FLAGS:
BOOTINIT
USRCONFIG
= bootInit.c
= usrConfig.c
This causes the makefile to use your copy of these generic configuration files
when building VxWorks.
2. Next, modify your copy of usrConfig.c to remove everything except the
pre-kernel initialization code by using #if FALSE/#endif pairs so that
usrExtra.c is not included, and the body of usrRoot( ) is empty:
...
#if FALSE
#include "usrExtra.c"
#endif
...
void usrRoot
...
{
#if FALSE
48