BSP Developer's Guide

VxWorks 5.5
BSP Developer’s Guide
The target agent’s linked-in approach has several advantages over the traditional
approach:
■
■
There is only one initialization code module to write. In a traditional
ROM-monitor approach, you must write two initialization code modules: one
for the monitor and one for the OS. In addition, the traditional approach
requires non-standard modifications to resolve contention issues over MMU,
vector table, and device initialization. 1
The code size is smaller because VxWorks and the target agent can share
generic library routines such as memcpy( ).
■
Traditional ROM monitors debug only in “system mode.” The whole OS is
debugged as a single thread. The WDB agent provides, in addition to system
mode, a fully VxWorks-aware tasking mode. This mode allows debugging
selected parts of the OS (such as individual tasks), without affecting the rest of
the system.
How you download the WDB agent and VxWorks kernel depends on your phase
of development. When writing and debugging the board initialization code, you
must create your own download path. This is no better or worse than the
traditional ROM-monitor approach in which you had to create the download path
for porting the monitor itself. After you have the board initialization code working,
how you proceed depends on the speed of your download path.
If you have a fast download path, continue to use it for further kernel
development. This is a win over a traditional ROM monitor approach which often
forces you to use a serial-line download path. If you have a slow download path,
you should burn into ROM the kernel, the agent, and as much generic VxWorks
code as fits.
Because the Tornado development tools let you download and execute code
dynamically, you can download extensions (such as application code, new drivers,
extra hardware initialization code, and the like) and use the WDB agent to debug
the extensions. This is a win over a traditional monitor approach, which requires
that you to download the entire kernel every time, even though most of the code
has not changed.
1. The traditional ROM-monitor approach is to modify the OS initialization code temporarily
to ensure that the MMU, certain parts of the vector table, and the device used by the monitor
are not reset. By running only one set of initialization code, these problem go away.
42