RT-ES - 1 Real-Time Embedded Systems Computer Science & Engineering Department Arizona State...

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


/* 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


/* 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


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


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


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 _

RT-ES - 1 Real-Time Embedded Systems Computer Science & Engineering Department Arizona State...

Documents

Transcript of RT-ES - 1 Real-Time Embedded Systems Computer Science & Engineering Department Arizona State...