rt-es - 1 real-time embedded systems computer science & engineering department arizona state...
TRANSCRIPT
RT-ES - 1
Real-Time Embedded Systems
Computer Science & Engineering DepartmentArizona State University
Tempe, AZ 85287
Contact: Dr. Yann-Hang [email protected](480) 727-7507
RT-ES - 2
Real-time Operating System To manage system resource through
system calls -- issued by tasks interrupts -- timer and external events
Typical requirements Support for scheduling of real-time tasks and interrupt
handlers Inter-process communication I/O support -- driver User control of system resource -- memory and file system
Thread or process for task execution: smallest execution units that can be scheduled lives in a virtual, insulated environment uses or owns system resources
RT-ES - 3
Real-time Operating Systems
Kernel Structure -- monolithic kernel that contains all services micro-kernel -- contain the minimal services to support optional and
cooperating processes small (10K bytes) and modular configurable
Services task management inter-task communication -- message queue, mailbox, and shared
memory synchronization & mutual exclusion -- semaphore and signal interrupt support and error handling memory management time management and timer services multiprocessor support
RT-ES - 4
Task Management
Task structure: task control block --
priority(initial and inherited), stack frame, task current state, entry point, processor states (program counter, registers) callback function (hook) pointers for OS events
Create and initialization taskInit, taskActivate, taskSpawn task_id = taskSpawn (name, priority, options, stacksize, main, arg1,…,
arg10); Task control and deletion: taskDelay (nanosleep), taskSuspend,
taskResume, taskRestart, exit, taskDelete
Execution
Ready Blocked
executing
pending ready delayed
suspendedtaskInit()
RT-ES - 5
Scheduling Mechanism
Priority-driven and round-robin with timeslicing taskPrioritySet (tid, priority), kernelTimeSlice taskLock, taskUnlock -- disable and enable scheduling (preemption) 0 (highest) to 255 (lowest) in vxWorks
RT-ES - 6
Shared Code and Reentrancy
A single copy of code is invoked by different concurrent tasks must reentrant
pure code variables in task stack (parameters) guarded global and static variables (with semaphore or taskLock) variables in task content (taskVarAdd)
taskOne ( ) { ..... myFunc ( ); ..... }
taskTwo ( ) { ..... myFunc ( ); ..... }
myFunc ( ) { ..... ..... }
RT-ES - 7
Inter-task Communication
Shared memory vxWorks has all tasks in a single address space
simple and unprotected direct access as long as the address is known
Message queue -- half-duplex communication multiple senders and receivers msgQCreate( ), msgQDelete( ), msgQReceive( )
status = msgQSend(msgQId, buffer, nBytes, timeout, priority ) queue size, message size, timeout parameters msg_pri_normal -- to be added to the queue tail msg_pri_urgent -- to be added to the queue head ISR cannot read a message queue mq_notify( ) in POSIX -- notification to a single task when a new
message arrives at an empty queue
RT-ES - 8
Inter-task Communication
Pipe -- virtual I/O, built on top of msgQ pipeDevCreate (name, nMessages, nBytes) -- create a named pipe in the
global file descriptor table open, read, write, and ioctl routines for device control select( ) -- wait for input from multiple pipes (with a timeout)
Network Inter-task communication Socket and RPC of vxWorks -- compatible with BSD 4.3 Unix
Signals (for asynchronous events) between tasks and ISR -- to execute signal handler of a task bind a handler to a signal, send a signal (kill(tid, signo)), signal masks sigqueue( ) in POSIX sigInit( ), sigqueueInit( )
RT-ES - 9
Signals
To register a handler -- signal (signo, sigHandler)void sigHandler ( int sig, int code, struct sigcontext * pSigCtx);
Exception: vxWorks issues a signal to the running task if no signal handler, suspend the task hardware dependent return with exit(), taskRestart(), longjump()
If signaled by ISR, handler should use return
normal program { . . . . }
sigHandler { . . . . }
signal
RT-ES - 10
Synchronization and Mutual Exclusion
Semaphores in vxWorks: binary mutual exclusion -- addresses inheritance, deletion safety and
recursion counting
Routines: semBCreate( ), semMCreate( ), semCCreate( ), semDelete( )
semTake( ), semGive( ), semFlush( ) (broadcasting)
Semaphore id, queue type (SEM_Q_PRIORITY or SEM_Q_FIFO), and timeout on waiting
SEM_ID sem = semBCreate (SEM_Q_PRIORITY, SEM_FULL);semTake(sem, WAIT_FOREVER);. . . . . semGive(sem);
Synchronozation: ISR calls semGive( ) to signal an event task calls semTake( ) to wait for the event
RT-ES - 11
Binary Semaphore
A task calls semTake(semin, timeout)
semFlush(semid) : to unblock all tasks waiting for a semaphore
semaphoreavailable
task continues;semTake()
returns OK;
task unpends;semTake()
returns error;
task unpends;semTake()
returns OK;
task suspended;
timeoutsemaphore available
RT-ES - 12
Synchronization and Mutual Exclusion
Mutual Exclusive -- restriction: can be given by the task took it (owns it) cannot be given from an ISR no flush
Priority inheritance: set flag = SEM_Q_PRIORITY | SEM_INVERSION_SAFE
Deletion Safety: delete a task while it is holding a semaphore SEM_DELETE_SAFE: protect from deletion
Recursion: (task ownership count) take a semaphore more than once by the task that owns it released when it is given the same number of times
POSIX semaphore (counting) unnamed -- malloc a semaphore struct and use * to operate named --open a semaphore in OS, shared among processes
RT-ES - 13
ISR
Interrupt service routines (ISRs) run outside of any task’s context. Thus they involves no task context switch.
intConnect ( ) -- to install user-defined ISR_routine If intConnect() is used for PowerPC, it is not needed to explicitly disable the
current interrupt source and do interrupt acknowledgement.
Save registersset up stackcheck interrupt source (vector)invoke routinerestore registers and stackexit
ISR_routine ( ) { . . . . . . . . }
handler wrapper
user ISR
intConnect(INUM_TOIVEC(someIntNum), ISR_routine, someVal);
RT-ES - 14
ISR
Interrupt stack -- a suitable size of maximum interrupt nesting depth
Whenever the architecture allows it, all ISRs use the same interrupt stack The stack is allocated as system starts up Must be large enough to handle the worst case
For architectures that are not allowed to have a separate ISR stack ISRs use the stack of interrupted task Have to create tasks with enough stack space to handle the worst
case There are special limitations of ISRs stemming from the
following facts ISRs do not run in a regular task stack ISRs have no task control block All ISRs share a single stack
RT-ES - 15
ISR
Limitations to ISRs ISR should not be blocked
don’t take a semaphore (malloc() and free() takes a semaphore), giving semaphore however is permitted
don’t perform I/O via vxWorks drivers that can get blocked ISRs cannot call printf() to output message to console,
please use logMsg() and other functions defined in logLib ISRs must not call routines that use a floating-point
coprocessor Interrupt driver created by intConnect() does not save and
restore floating-point registers If an ISR must requires floating-point instructions, it must
explicitly save and restore the registers of the floating coprocessor using routines in fppArchLib
RT-ES - 16
ISR
Hardware exception while in ISR When a task causes a hardware exception, the task is suspended
and the rest of the system continues uninterrupted If an ISR causes such a exception, there is no safe way to handle
the exception since ISRs have no context vxWorks stores the description of the exception in a special location
in low memory and executes a system start Interrupt levels
In vxWorks it is possible to reserve highest interrupt levels to ensure zero-latency response. intLockLevelSet() sets the system-wide interrupt-lockout level to the specified level
ISRs connected to interrupt levels that are not locked out have restrictions ISR can only be connected with intVecSet() ISR cannot use system facilities that depend on interrupt locks for
correct operations
RT-ES - 17
ISR
Interrupt-to-task communications Interrupt events usually propagate to task-level code. The following techniques can be used to communicate from
ISRs to task-level code Shared memory and ring buffers. ISRs can share variables,
buffers, and ring buffers with task level code Semaphores. Giving semaphores is permitted Message queues. ISR can send messages to message queues
for tasks to receive Pipes. ISRs can write messages to pipes that tasks can read Signals. ISRs can signal tasks, causing asynchronous
scheduling of their signal handlers
RT-ES - 18
Timer and Clock
Clock tick Watchdog timer in vxWorks -- mantained by the
system clock ISR wdCreate( ), wdDelete( ), wdStart( ), wdCancel( ) invokes a callback function when the delay is expired (at the
interrupt level of the system clock) real-time clock -- POSIX timer
create, set and delete a timer that signals tasks when goes off
Delay a period: taskDelay( ) in vxWork nanosleep( ) in POSIX
RT-ES - 19
Device Driver
Purpose: a well defined and consistent interface to handle requests for device
operations isolate device-specific code in the drivers
A software interface to hardware devices resides in kernel or user spaces
Classification character device (terminal) block (disk) -- with buffer cache network pseudodevice
When to call a device driver configuration, I/O operations, and interrupt
OS specificcode
I/O classspecific code
Hardwarespecific code
I/O adapters
devicedriver
RT-ES - 20
Device Driver in vxWorks
A driver of non-block devices -- basic I/O functions:
create, remove, open, close, read, write, and ioctl
initialization routing add devices that are to be serviced by the driver ISR
Routines in iosLib -- iosDrvInstall : adds the driver in the driver table and sets up function
pointers. (returns drvnum) iosDevAdd: adds the device in the list and sets up a link to the deriver
When open -- allocate a slot in fd table find the device name in device list call open function of the deriver (with *dev)
RT-ES - 21
Device Driver in vxWorks
“/tty0/”1
“/xx1/”3
“/pty0/”1
Device-dependent
data
Device list(of device descriptors)
drvnum create remove open close read write ioctl0 ** **123
Driver table(function pointers)
drvnum value221 *dev3
File descriptortable
0123
RT-ES - 22
Device Driver in vxWorks – an Example
Pseudo code of a simple driver for PCI data acquisition cards of National Instruments
/* This routine should be called by a hook function in system boot sequence. We can use usrAppInit() in usrAppInit.c in system image project directory as the hook function.*/
void installDaqDriver(){
daqDrv(); /* driver initialization */ idaqDevCreate("/daq"); /* add a device named “/daq” */
} /* This routine initializes the driver. It installs the driver via iosDrvInstall(). It may allocate
data structures, connects ISRs, and initialize hardware*/STATUS daqDrv(){
/* can register up to 7 functions, but only 3 here */daqDrvNum = iosDrvInstall(0,0,daqOpen,0,daqRead,daqWrite,0);
/* relate interrupt vector to ISR */intConnect ((VOIDFUNCPTR *)IV_PCI_INTA,
(VOIDFUNCPTR) Interrupt_Service_Routine,0);}
RT-ES - 23
Device Driver in vxWorks – an Example
/* The following routine is called to add device called name to be serviced by this driver. The routine adds the device to the I/O system by calling iosDevAdd(). It may also allocate and initialize data structures for the device, initialize semaphores if concurrent operations to the device are not allowed, initialize device hard ware, and so on*/ STATUS daqDevCreate(char *name){
/* do PCI configuration for the board */Setup_Mite();/* allocate space for device structure */pDaqDev = (DEV_HDR*) calloc(1, sizeof(DEV_HDR));
/* add the device */return iosDevAdd(pDaqDev, name, daqDrvNum);
}/* This routine configures PCI bus configuration space and tries to find attached device by specifying vendorId and deviceId. Plug and Play can be implemented here. */ STATUS Setup_Mite(){
/* find the specified device */pciFindDevice(vendorId,deviceId,0,&busNum,&deviceNum,&funcNum);/* activate the found PCI device and choose I/O or memory mapping address */pciDevConfigMemDaq(busNum, deviceNum, funcNum,ioAddr, memAddr,0x102);/* other card-specific code for PCI configuration */… …
}
RT-ES - 24
Device Driver in vxWorks – an Example
/* This routine opens the device and returns an fd. It mainly sets registers related to selecting input (AI) and output (AO) channels and working modes. */
int daqOpen(DEV_HDR *pDaqDev, char* name, int flags, int mode){
if (flags == O_RDONLY) /* read only, analog-to-digital conversion */
adc(); if (flags == O_WRONLY) /* write only, digital-to-analog conversion */
dac();if (flags == O_RDWR) /* both read and write */{
adc();dac();
}return (int) pDaqDev; /* return an fd */
}/*The following two routines call respective subroutines to read data to the given buffer from an AI channel and
write data from the given buffer to an AO channel. nByte is the number of bytes that are hoped to be read or written. The actual number of read or written data is returned */
int daqRead(DEV_HDR *pDaqDev, char* buffer, int nByte){
return readBuffer(buffer, nByte); /*subroutine for reading AI */}
RT-ES - 25
Device Driver in vxWorks – an Example
int daqWrite(DEV_HDR *pDaqDev, char* buffer, int nByte) {
return writeBuffer(buffer, nByte); /* subroutine for writing AO */} /*The following code is ISR that is connected to the specified interrupt vector. In this
example, interrupt is used only to analog input */void Interrupt_Service_Routine(int arg){
/* interrupt disable, may not be necessary for PowerPC */intDisable(IVEC_TO_ILVL(IV_PCI_INTA));
/* read AI from corresponding register */Board_Read(ADC_FIFO_Data_Register);
/* interrupt enable, may not be necessary for PowerPC */intEnable(IVEC_TO_ILVL(IV_PCI_INTA));
}
RT-ES - 26
Asynchronous Input/Output
Concurrent I/O with task execution -- when calls aio routines, control returns immediately and no blocking aio_read( ), aio_write( ), aio_listio( ), aio_return( ), aio_cancel( ),
aio_error( ), aio_suspend( ) aioPxLibInit( )and aioSysInit( ) AIO control block -- aiocb
struct aiocb {
int aio_fildes; /* file descriptor */
volatile void *aio_buf; /* buffer location */
size_t aio_nbytes; /* length of transfer */
off_t aio_offset; /* file offset */
int aio_reqprio; /* request priority offset */
struct sigevent aio_sigevent; /* signal number and offset */
int aio_lio_opcode; /* listio operation */
};
RT-ES - 27
Asynchronous Input/Output
task
.initialize aiocb_read
.aio_read(&aiocb_read)
.
.aio_error(&aiocb_read)aio_return(&aiocb_read)
.
.
sigHandler
aiocb_readfilebuffersignal
aioSysDrv
Request queue
I/Ooperation
aio system task
RT-ES - 28
Scheduling &System Clock
Facilities
Synchronization & Intertask Communication
MutualExclusion
I/Osystem
FileSystems
MemoryManagement
NetworkingSupport
DeviceSupport
. . .
VxWorks RTOS
RT-ES - 29
Board Support Package
Most of VxWorks is independent of the particular target board used.
The board-specific code for initializing and managing a board’s hardware is called the BSP. The BSP provides VxWorks with standard hardware interface functions which allow it to run on a board.
The primary BSP source file, sysLib.c, lives in the BSP directory target\config\bspName. This is also the directory in which VxWorks may be reconfigured and rebuilt.
RT-ES - 30
BSP
Tools - Applications
Hardware-Independent Software
I/O System vxWorks Libraries TCP/IP
File Systems
Hardware-Dependent Softwarewind Kernel
BSP
HardwareSCSI Controller
SCSI Driver Network Driver
Serial Controller Clock Timer Ethernet Controller
In order to port vxWorks to a new target board and tailor system image, we need to understand the BSP (board support package) structure, vxWorks boot sequence, and the process to create a new BSP
BSP consists of files for the particular hardware used to run vxWorks. These files include the routines that provide vxWorks with its main interface to the hardware environment.
RT-ES - 31
BSP
BSP source and include files Files in target/config/all are the modules shared by all BSPs.
Do not change these files unless absolutely necessary Files in target/config/bspname are BPS files for the
architecture indicated by bspname When building project images, the component configlettes
(any C source code complied by the project facility as part of the project build step) in target/config/comps/src replace the files in target/config/all.
configAll.h sets the default configuration for all vxWorks images
If we need a vxWorks image that differs from the default configuration, use BSP’s config.h to override the default values in configAll.h
RT-ES - 32
BSP
BSP file list Files in target/config/all
bootConfig.c – the main initialization and control file for all boot ROM images.
bootInit.c – the second stage of boot ROM initialization dataSegPad.s – VxVMI text segment protection usrConfig.c – initialization code for vxWorks image
Files in target/comps/vxWorks – the basic component descriptor files for the vxWorks real-time kernel
Files in target/config/comps/src – the configlettes associated with the kernel components
Files in target/config/bspname README – BSP release record Makefile and depend.bspname – Makefile controls the building of
images from the command line; depend.bspname tracks the all module dependencies
RT-ES - 33
BSP
Files in target/config/bspname – cont. config.h – all includes and definitions specific to the CPU board romInit.s – the assembly language source for initialization code
that is the entry point for the vxWorks boot ROMs and ROM-based versions of vxWorks
sysALib.s – the assembler source of target-specific, system-dependent routines
sysLib.c – routine providing the interface on which vxWorks and application code can be built in a system-independent way
sysSerial.c (optional) – all the serial I/O setup and initialization for the SIO device drivers
sysScsi.c (optional) – SCSI-2 setup and initialization sysNet.c (optional) – setup and initialization for network devices bspname.h – setting for non-optional, board specific information target.nr – board-specific information necessary to run vxWorks
RT-ES - 34
BSP
The steps to create a new BSP Set up the basis of the development environment
Establishing a mechanism to download code to the target and then testing the down code
Using the download protocol and debug tool supported by the board vendor’s debug ROMs
Write the BSP pre-kernel initialization code Create a BSP directory by copying BSP template files from
target/config/templateCPU Add and modify some routines Build and download vxWorks Debug the initialization code
Start a minimal vxWorks kernel and add the basic drivers for timers, serial devices, and an interrupt controller
RT-ES - 35
BSP
The steps to create a new BSP – cont. Start the target agent and connect the Tornado development
tools Done by a call to wdbConfig() at the very end of usrRoot()
Complete the BSP. Configurations involve networking, boot ROMs, SCSI, caches, MMU initialization, and DMA
Generate a default project for use with the new project facility
RT-ES - 36
Target Boot Process - Tornado Environment(vxWorks)
Basic initialization code exits in ROM. This code can initialize the serial port or ethernet controller allows the user to set the target parameters like the name of
kernel image , target IP address, host IP address etc needed initially to pull over the kernel image into target .
It can perform TFTP and other serial port transfers.
VxWorks
TargetRS-232
Ethernet
Host Tornado
RT-ES - 37
Press any key to stop auto-boot... 3[VxWorks Boot]: c'.' = clear field; '-' = go to previous field; ^D = quit
boot device : eiprocessor number : 0host name : sylvanfile name : c:\Tornado\target\config\mv162\vxWorksinet on ethernet (e) : 167.21.32.168inet on backplane (b):host inet (h) : 167.21.32.17gateway inet (g) :user (u) : targetftp password (pw) (blank = use rsh): openSesameflags (f) : 0x8target name (tn) : ashstartup script (s) :other (o) :
Boot Parameters
RT-ES - 38
[VxWorks Boot]: @< boot parameters printed >Attaching network interface ei0... done.Attaching network interface lo0... done.Loading... 335336 + 28936 + 33948 text + data + bssStarting at 0x20000...
downloaded image runs nowAttaching network interface ei0... done.Attaching network interface lo0... done.NFS client support not included.
VxWorks
Copyright 1984-1996 Wind River Systems, Inc.
CPU: Motorola MVME162 VxWorks: 5.3.1 BSP version: 1.1/4 Creation date: Sep 28 1997 WDB: Ready.
A Successful Boot!
RT-ES - 39
Target’s boot ROM code executes on power up. Default Boot ROM’s does not contain the VxWorks
system. The boot ROM code :
Allows setting of boot parameter. Downloads VxWorks into target memory via the network
(FTP) Starts executing VxWorks.
Boot ROM
RT-ES - 40
X.cX.cpp
X.sMakefile
GNU
X.oX.out
vxWorks
CrossWind
WindSh
Browser
3rd Party
TornadoTools VxWorks
RTOS
WDBAgent
TargetServer
Xtextdatabss
Development Host(s)Target
Subdividing Tornado
RT-ES - 41
Ethernet
RS-232
Development Host VxWorks Target
Cross-Development
Typical scenario: 1. Boot target. 4. Download object module. 2. Attach target server. 5. Test & Debug. 3. Edit & compile. 6. Return to 3 or 1 as
necessary!
RT-ES - 42
VxWorks
WDB
Application
TargetServer
WDB Protocol
WindSh
CrossWind
Browser
WTX Protocol
Development Host Target
(Ethernet, serial, netrom, custom)
WTX = Wind River Tool eXchange WDB = Wind DeBug
3rd Party
Target Server / WDB Agent
RT-ES - 43
Target servers inregistry listed here.
Auxiliary Host Processes
The Registry Manages a list of target servers.
Must be running before you launch
a target server. Provides information tools need to
contact a target server. Prevents two target servers from attaching to the same
target.
Wind License Manager Daemon Floating license manager daemon allocates a finite number
of seats to users of target servers. Each seat allows one user on one networked host to create
any number of target servers.
RT-ES - 44
wind
target config allbspNameh
libsrc
share
host host-os
resource
bin
Tornado Directory Structure
RT-ES - 45
Scaling & Configuration
Configuring VxWorks involves Specifying which VxWorks facilities will be included (scaling
VxWorks). May be done with the WindConfig tool, or by editing files.
Specifying additional constants needed by some modules. Requires editing files.
The configuration of the VxWorks images you build is governed by information from three sources: target\config\all\configAll.h default base configuration target\config\bsp\config.h board specific configuration The WindConfig tool, if used.
RT-ES - 46
...#include “configAll.h”#include “bsp.h”
/* Override defaults here */#undef NUM_FILES#define NUM_FILES (80).../* Added by WindConfig */#include “configdb.h”
config.h
configAll.h and config.h
target\config\all\configAll.h specifies a default, or base configuration which applies to all boards. WRS discourages modifying this file.
target\config\bsp\config.h extends and/or overrides the defaults specified in configAll.h for the particular board bsp. Modify this file to change the VxWorks image for this board.
RT-ES - 47
Back to Booting
Hardware must first be configured: VxWorks Boot ROMs replace board manufacturer’s ROMs. Jumpers (etc.) set as described in target\config\bsp\target.txt.
VxWorks Boot ROMs enable: Setting boot parameters via a serial connection. Downloading & executing VxWorks image.
Booting scenarios: ethernet shared memory network serial (PPP/SLIP) local disk BOOTP / TFTP
RT-ES - 48
Boot Sequence
vxWorks boot sequenceromInit.s : romInit()
bootInit.c : romStart()
usrConfig.c and bootConfig.c : usrInit()
Libcuptoolvx.a : kernelInit()
usrCofig.c and bootConfig.c : usrRoot()
Routine calling chain in boot sequence
Disables interrupts, puts the boot type on the stack, clears caches
The text and data segments are copied from ROM to RAM
Cache initialization, zeroing out the system bss segment, initializing interrupt vectors and initializing system hardware to a quiescent state
Initiates the multitasking environment: disables round-robin mode, creates an interrupt stack, creates root stack and TCB
Initializes the I/O system, installs drivers, creates devices, and then sets up the network as configured in configAll.h and config.h
RT-ES - 49
Boot Process in VxWorks
At power-up the processor begins executing at romInit() defined in romInit.s
The target-specific romInit.s(in assembly language) module performs the minimal preliminary board initialization and then jumps to the C routine romStart().
romInit - entry point for VxWorks in ROM This is the start of the ROM code. The CPU will vector here upon
reset. This routine, still executing out of ROM, copies the first stage of the
startup code to a RAM address and jumps to it. The next stage clears memory and then uncompresses the remainder of ROM into the final VxWorks ROM image in RAM.
The romInit() routine disables interrupts, puts the boot type(cold/warm) on the stack, performs hardware dependent initialization(such as clearing the caches or enabling DRAM), and branches to romStart().
RT-ES - 50
Boot Process in VxWorks
Main functions that must be performed by romInit(): Disable interrupts and set up the CPU Set up the memory system. This usually involves turning off
the caches and setting up memory controllers as needed. Set up the stack pointer and other registers to begin
executing C code. The address of the romStart() routine is calculated and the routine is called. There is no return from romStart().
It is important that romInit() must be coded as position-independent code(PIC). This is needed to support the complex boot strategies of Vxworks.
RT-ES - 51
Boot Process in VxWorks
The file bootConfig.c is the configuration module for the boot ROM
userConfig.c later replaces this file if VxWorks starts executing
We can configure VxWorks to execute from ROM. In such configurations, the text and data segments of the boot or VxWorks image
are first copied into the system RAM, then the boot procedure executes in RAM. What can we do if
the memory is scarce? A ROM resident image can be built with an
uncompressed version of either the boot ROM or standalone VxWorks system image.
RT-ES - 52
Memory Layout
The data segment of a ROM-resident standalone VxWorks system is loaded at low address to minimize fragmentation.
The data segment of the ROM-resident boot ROMs is loaded at high address so that loading VxWorks does not overwrite the resident boot ROMs.
RT-ES - 53
Configuration and Build
What is VxWorks System Image? The system image is a binary module that can be booted and
run on the system.
We need to tailor the image configuration to reflect the applications requirements. need to understand the BSP structure and the VxWorks
initialization process.
RT-ES - 54
Standard Images
Not all BSPs will support all of these images. Some BSPs supportaddititional images.
Standalone VxWorks has a target shell and built-in symbol table.Network support is included but not initialized.
The file target\h\make\rules.bsp has the make rules for buildingthese images.
Types ofImages
VxWorksTornado
VxWorksStandalone
Boot Program
ROMablecompressed
_ vxWorks.st_rom bootrom
ROMableuncompressed
vxWorks_rom _ bootrom_uncmp
ROMresident
vxWorks.res_rom_nosym vxWorks.res_rom bootrom_res
Downloadableuncompressed
vxWorks vxWorks.st _